<span class="Apple-style-span" style="border-collapse: collapse; ">The question of imperative versus pure declarative coding has brought to my mind some may be off-topic speculations. (so please donīt read it if you have no time to waste): Iīm interested in the misterious relation bentween mathematics, algoritms and reality (<a href="http://arxiv.org/pdf/0704.0646">see this</a> for example). Functional programming is declarative, you can model the entire world functionally with no concern for the order of calculations. The world is mathematical. The laws of physics have no concern for sequencing.<div>
<br></div><div>But CPUs and communications are basically sequential. Life is sequential, and programs run along the time coordinate. Whenever you have to run a program, you or your compiler must sequence it. The sequentiation must be done by you or your compiler or both. The functional declarative code can be sequenced on-the-run by the compiler in the CPU by the runtime. but IO is different. <div>
<div><br></div><div>You have to create, explicitly or implicitly the sequence of IO actions because the external events in the external world are not controlled by you or the compiler. So you, the programmer are the responsible of sequencing effects in coordination with the external world. so every language must give you ways to express sequencing of actions. that is why, to interact with the external world you must think in terms of algorithms, that is , imperatively, no matter if you make the imperative-sequence (relatively) explicit with monads or if you make it trough pairs (state, value) or unsafePerformIO or whatever. You have to think imperatively either way, because yo HAVE TO construct a sequence. I think that the elegant option is to recognize this different algorithmic nature of IO by using the IO monad.<div>
<br></div><div><div>In other terms, the appearance of input-output in a problem means that you modelize just a part of the whole system. the interaction with the part of the system that the program do not control appears as input output. if the program includes the model of the environment that give the input output (including perhaps a model of yourself), then, all the code may be side effects free and unobservable. Thus, input output is a measure of the lack of a priori information. Because this information is given and demanded at precide points in the time dimension with a quantitative (real time) or ordered (sequential) measure, then these impure considerations must be taken into account in the program. However, the above is nonsensical, because if you know everithing a priory, then you donīt have a problem, so you donīt need a program. Because problem solving is to cope with unknow data that appears AFTER the program has been created, in oder to produce output at the corrrect time, then the program must have timing on it. has an algoritmic nature, is not pure mathemathical. This applies indeed to all living beings, that respond to the environment, and this creates the notion of time.</div>
<div><br></div></div><div><br></div><div>Concerning monadic code with no side effects, In mathematical terms, sequenced (monadic) code are mathematically different from declarative code: A function describes what in mathematics is called a "manifold" with a number of dimensions equal to the number of parameters. In the other side, a sequence describe a particular trayectory in a manifold, a ordered set of points in a wider manyfold surface. For this reason the latter must be described algorithmically. The former can be said that include all possible trajectories, and can be expressed declaratively. The latter is a sequence . You can use the former to construct the later, but you must express the sequence because you are defining the concrete trajectory in the general manifold that solve your concrete problem, not other infinite sets of related problems. This essentially applies also to IO.</div>
<div><br></div><div> Well this does not imply that you must use monads for it. For example, a way to express a sequence is a list where each element is a function of the previous. The complier is forced to sequence it in the way you whant, but this happens also with monad evaluation. </div>
<div><br></div><div>This can be exemplified with the laws of Newton: they are declarative. Like any phisical formula. has no concern for sequencing. But when you need to simulate the behaviour of a ballistic weapon, you must use a sequence of instructions( that include the l newton laws). (well, in this case the trajectory is continuous integrable and can be expressed in a single function. In this case, the manifold includes a unique trajectory, but this is not the case in ordinary discrete problems,) . So any language need declarative as well as imperative elements to program mathematical models as well as algorithms.</div>
<div><br></div><div><br></div><div>Cheers<br></div><div> Alberto.</div></div></div></div></span><br><div class="gmail_quote">2009/1/11 Apfelmus, Heinrich <span dir="ltr"><<a href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Ertugrul Soeylemez wrote:<br>
> Let me tell you that usually 90% of my code is<br>
> monadic and there is really nothing wrong with that. I use especially<br>
> State monads and StateT transformers very often, because they are<br>
> convenient and are just a clean combinator frontend to what you would do<br>
> manually without them: passing state.<br>
<br>
The insistence on avoiding monads by experienced Haskellers, in<br>
particular on avoiding the IO monad, is motivated by the quest for elegance.<br>
<br>
The IO and other monads make it easy to fall back to imperative<br>
programming patterns to "get the job done". But do you really need to<br>
pass state around? Or is there a more elegant solution, an abstraction<br>
that makes everything fall into place automatically? Passing state is a<br>
valid implementation tool, but it's not a design principle.<br>
<br>
<br>
A good example is probably the HGL (Haskell Graphics Library), a small<br>
vector graphics library which once shipped with Hugs. The core is the type<br>
<br>
Graphic<br>
<br>
which represents a drawing and whose semantics are roughly<br>
<br>
Graphic = Pixel -> Color<br>
<br>
There are primitive graphics like<br>
<br>
empty :: Graphic<br>
polygon :: [Point] -> Graphic<br>
<br>
and you can combine graphics by laying them on top of each other<br>
<br>
over :: Graphic -> Graphic -> Graphic<br>
<br>
This is an elegant and pure interface for describing graphics.<br>
<br>
After having constructed a graphic, you'll also want to draw it on<br>
screen, which can be done with the function<br>
<br>
drawInWindow :: Graphic -> Window -> IO ()<br>
<br>
This function is in the IO monad because it has the side-effect of<br>
changing the current window contents. But just because drawing on a<br>
screen involves IO does not mean that using it for describing graphics<br>
is a good idea. However, using IO for *implementing* the graphics type<br>
is fine<br>
<br>
type Graphics = Window -> IO ()<br>
<br>
empty = \w -> return ()<br>
polygon (p:ps) = \w -> moveTo p w >> mapM_ (\p -> lineTo p w) ps<br>
over g1 g2 = \w -> g1 w >> g2 w<br>
drawInWindow = id<br>
<br>
<br>
Consciously excluding monads and restricting the design space to pure<br>
functions is the basic tool of thought for finding such elegant<br>
abstractions. As Paul Hudak said in his message "A regressive view of<br>
support for imperative programming in Haskell"<br>
<br>
In my opinion one of the key principles in the design of Haskell has<br>
been the insistence on purity. It is arguably what led the Haskell<br>
designers to "discover" the monadic solution to IO, and is more<br>
generally what inspired many researchers to "discover" purely<br>
functional solutions to many seemingly imperative problems.<br>
<br>
<a href="http://article.gmane.org/gmane.comp.lang.haskell.cafe/27214" target="_blank">http://article.gmane.org/gmane.comp.lang.haskell.cafe/27214</a><br>
<br>
The philosophy of Haskell is that searching for purely functional<br>
solution is well worth it.<br>
<br>
<br>
Regards,<br>
H. Apfelmus<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>