which Haskell compiler/interpreter...?
charif
I want to learn functional programming. After reading the many
questions/answers in this newsgroup, I decided to start with Haskell, but as
I went to download a compiler/interpreter, I couldn't decide which one to
download. I guess I should download hugs (cuz it seems to be the most talked
about...) but I just want to hear different opinions on the question. Any
opinion, advice and/or suggestion would be very appreciated.
Thanks in advance for any help.
Charif
Rijk-Jan van Haaften
The mostly used haskell interpreter for learning functional
programming is Hugs. Mainly because it is small, quite easy to install
and easy to use. The drawback is that it gives quite poor error
messages.
On the other hand, there is the ghc compiler which gives (especially
if you use the "wall" option (Warnings ALL)) much better error
messages and warnings. However it has the drawback that it is hard to
install, and not as easy to use as Hugs. Moreover, it is very large (I
guess about 50 times the size of Hugs).
So if you like to start off fast and easy, use Hugs. If you have
experience with unix flavours, or you don't mind learning it, and you
have patience enough to install ghc, I recommend that compiler.
Rijk-Jan
. Hi all,
. I want to learn functional programming. After reading the many
. questions/answers in this newsgroup, I decided to start with Haskell, but as
. I went to download a compiler/interpreter, I couldn't decide which one to
. download. I guess I should download hugs (cuz it seems to be the most talked
. about...) but I just want to hear different opinions on the question. Any
. opinion, advice and/or suggestion would be very appreciated.
. Thanks in advance for any help.
.
. Charif
.
Hans Aberg
<cha...@aioros.ocn.ne.jp> wrote:
>I want to learn functional programming. After reading the many
>questions/answers in this newsgroup, I decided to start with Haskell, but as
>I went to download a compiler/interpreter, I couldn't decide which one to
>download. I guess I should download hugs (cuz it seems to be the most talked
>about...) but I just want to hear different opinions on the question.
Even if you eventually plan to use a compiler, I understand that people
still use an interpreter to work the code up. So it seems best for you to
start with an interpreter. (In addition, the Haskell compilers make use of
assembler optimized code. So for example, no-one has been able yet to get
GHC working under the MacOS.)
As I have made a Mac port of Hugs for a couple of years, I think Hugs is a
good start. What other Haskell interpreters are there? I have heard about
GHCi, but if it exists, it is still at the experimental stage, while Hugs
is very stable, but still up-to-date and supported with respect to the
Haskell 98 standard.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
George Russell
>
> Hi all,
> I want to learn functional programming. After reading the many
> questions/answers in this newsgroup, I decided to start with Haskell, but as
> I went to download a compiler/interpreter, I couldn't decide which one to
> download.
Quick answer: download Hugs, compile it, turn on, tune in and drop out . . .
Long answer: at the moment Hugs is better for you because it's quick and easy
to compile and comparatively bug free. However for serious applications where
speed is important, or you want access to the operating system, I think GHC
is superior. In addition, GHC is making welcome strides which means that
I think it may very well soon be superior to Hugs for beginners. Some
positive points:
(1) ghci, which is like hugs only in some ways better, for example it is
possible to define new identifiers on the command line. This is
extremely useful for testing and for playing around generally.
(2) GHC is adding a Make facility. At the moment it looks pretty crude to
me, but I'm hoping it will improve.
The only disadvantage of GHC really is that installing it can be
difficult. Even if there are downloadable binaries for your operating
system (and if not I would certainly not recommend it for you), you may
still have to muck around finding libreadline.a and so on.
Andrew Rock
] Even if you eventually plan to use a compiler, I understand that people
] still use an interpreter to work the code up. So it seems best for you to
] start with an interpreter. (In addition, the Haskell compilers make use of
] assembler optimized code. So for example, no-one has been able yet to get
] GHC working under the MacOS.)
The good news is that GHC is now available for Mac OS X. That alone makes
OS X worth the price.
] As I have made a Mac port of Hugs for a couple of years, I think Hugs is a
I have used your port for all that time and I'd like to take the opportunity
to thank you for it.
As to the original question, for a beginner, Hugs is the go, but even
after you start using GHC in anger, you'll be using Hugs for rapid
development. By adding the right stubs, you can use it as a type
checker, even when all the GHC libraries you want aren't available.
Hugs error messages are good enough.
Cheers,
Rock.
Andrew Rock -- ar...@cit.gu.edu.au -- http://www.cit.gu.edu.au/~arock/
School of Computing and Information Technology
Griffith University -- Nathan, Brisbane, Queensland 4111, Australia
Hans Aberg
Rock) wrote:
>The good news is that GHC is now available for Mac OS X. That alone makes
>OS X worth the price.
Is this the version made by Atze Dijkstra? (I do not have MacOS X yet, so
I have not followed these developments.)
>] As I have made a Mac port of Hugs for a couple of years, I think Hugs is a
>
>I have used your port for all that time and I'd like to take the opportunity
>to thank you for it.
Great. I started to make the port only for my own personal needs, so it is
great if somebody else also benefitted from it, as well.
I think that Atze made a port to MacOS X, but it probably runs under BSD,
with no GUI.
So there still remains the question of finding someone willing to make a
GUI under MacOS X as well (plus linking up with other MacOS X features as
well).
>As to the original question, for a beginner, Hugs is the go, but even
>after you start using GHC in anger, you'll be using Hugs for rapid
>development. By adding the right stubs, you can use it as a type
>checker, even when all the GHC libraries you want aren't available.
>Hugs error messages are good enough.
This is also what I discovered when making the port: Apparently
"professional" computer scientists was trying to use this port for quick
development of code that later was moved over to a compiler like GHC. This
was one motivation for adding features such an adjustable parameter stack
size. Pablo Azero, who also developed this port, is a computer scientist,
which helped to add features that computer scientists like.
One thing I learned from Pablo is the importance of the heap profiler:
Anyone starting programming with Hugs should learn to use it, I think.
Then convert the output with hp2ps, and perhaps ps2pdf to get a PS or PDF
file.
Pretty often one gets programmer questions like "how should I know what to
do when my program overflows"? -- The answer is, run it through the heap
profiler, and one will get an indication of where the problem is.
Hugs still lacks other good debugging tools, I think. They announced
something about Hugs debugging, but I did not follow up on that.
Hans Aberg
>Long answer: at the moment Hugs is better for you because it's quick and easy
>to compile and comparatively bug free.
>(1) ghci, which is like hugs only in some ways better, for example it is
> possible to define new identifiers on the command line. This is
> extremely useful for testing and for playing around generally.
I think that the idea is that eventually GHCi should replace Hugs, but
that has not happened yet. So for beginners, in the meantime, it is
probably better with Hugs.
One advantage with GHCi is though that it uses the same Haskell engine as
GHC, so the incompatibilities will be less than when working with Hugs and
GHC.
Alexander V. Voinov
George Russell wrote:
> Quick answer: download Hugs, compile it, turn on, tune in and drop out . . .
>
> Long answer: at the moment Hugs is better for you because it's quick and easy
> to compile and comparatively bug free. However for serious applications where
> speed is important,
Not only speed. At my toy program it ran into a stack overflow around `take`ing
first 1000 or so elements of a lazy, computed on the fly list. The program was
really toy, it just applied a stupid pattern matching function to integers from
[0..].
> or you want access to the operating system, I think GHC
> is superior. In addition, GHC is making welcome strides which means that
> I think it may very well soon be superior to Hugs for beginners. Some
> positive points:
> (1) ghci, which is like hugs only in some ways better, for example it is
> possible to define new identifiers on the command line. This is
> extremely useful for testing and for playing around generally.
Ghci lacks a 'runhugs' feature, therefore it's hard to run from the command line
as 'ghci x.hs'. Of course you can teach emacs to use ghci instead of hugs, but
what if you hate emacs?
Alexander
ko...@icm.edu.pl
> Hello,
>
> The mostly used haskell interpreter for learning functional
> programming is Hugs. Mainly because it is small, quite easy to install
> and easy to use. The drawback is that it gives quite poor error
> messages.
>
> On the other hand, there is the ghc compiler which gives (especially
> if you use the "wall" option (Warnings ALL)) much better error
> messages and warnings. However it has the drawback that it is hard to
> install, and not as easy to use as Hugs. Moreover, it is very large (I
> guess about 50 times the size of Hugs).
>
> So if you like to start off fast and easy, use Hugs. If you have
> experience with unix flavours, or you don't mind learning it, and you
> have patience enough to install ghc, I recommend that compiler.
Or use .deb binary package. It's in the unstable(woody) release of Debian/Linux
system. Just download and dpkg --install ... I had no problems with it.
Still, I often use hugs, as(at least on my computer) ghci(interactive GHC
add-on) starts and analyzes sources a bit slowly.
Greetings :-)
Michal Gajda
ko...@icm.edu.pl
*knowledge-hungry student*
ko...@icm.edu.pl
> Hi All,
> (snipped large part)
> Ghci lacks a 'runhugs' feature, therefore it's hard to run from the command line
> as 'ghci x.hs'. Of course you can teach emacs to use ghci instead of hugs, but
> what if you hate emacs?
Next feature missing in ghci is :e command, which runs your favourite $EDITOR
and reloads source when it quits. Found it convenient(even Celeron with 128Megs
may be too slow for XEmacs, when you compile something in background!).
Greetings :-)
Michal Gajda
ko...@icm.edu.pl
*knowledge-hungry student*
PS Anyone has cooledit/mcedit mode for haskell?
Marcin 'Qrczak' Kowalczyk
> Next feature missing in ghci is :e command, which runs your favourite
> $EDITOR and reloads source when it quits.
You could almost implement yourself it using :def - the problem is
that it would have to be given the module name to edit explicitly,
because there is no way to communicate the current module to it -
or at most remember it in a file and use the same name as previously
if invoked as :e without explicit name (IORef created at the prompt
or in .ghci would not survive reloads, so a file must be used).
> PS Anyone has cooledit/mcedit mode for haskell?
I have a syntax highlighting mode for jed.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Hartmann Schaffer
> ...
>(1) ghci, which is like hugs only in some ways better, for example it is
>(2) GHC is adding a Make facility. At the moment it looks pretty crude to
haskell.org mentions a third haskell system (hbc?). any comments about
that?
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
Ketil Z Malde
>> On the other hand, there is the ghc compiler which gives (especially
>> if you use the "wall" option (Warnings ALL)) much better error
That's -Wall, I believe. Anyway, I agree that ghc is a good choice --
if you have a fast box with enough memory.
>> experience with unix flavours, or you don't mind learning it, and you
>> have patience enough to install ghc, I recommend that compiler.
> Or use .deb binary package. It's in the unstable(woody) release of
> Debian/Linux system. Just download and dpkg --install ... I had no
> problems with it.
You still download? I just did an 'apt-get install ghc5', and went
for a cup of coffee while the system downloaded and installed it for
me.
Anyway, I expect packages (rpms, debs, tgzs) are available for most
Linux distributions by now, and if the InstallShield package for those
other OSes isn't available yet, it probably will be RSN. Check the
web pages.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Jerzy Karczmarczuk
> Not only speed. At my toy program it ran into a stack overflow around `take`ing
> first 1000 or so elements of a lazy, computed on the fly list. The program was
> really toy, it just applied a stupid pattern matching function to integers from
> [0..].
Are you sure?
Increase your memory. I generated lists with 3000 elements or more through
an incredibly messy program with an algorithm using simultaneously lazy
co-recursion and strict recursion, and I have no reason to complain.
Jerzy Karczmarczuk
Caen, France
Pixel
> > Or use .deb binary package. It's in the unstable(woody) release of
> > Debian/Linux system. Just download and dpkg --install ... I had no
> > problems with it.
>
> You still download? I just did an 'apt-get install ghc5', and went
> for a cup of coffee while the system downloaded and installed it for
> me.
>
> Anyway, I expect packages (rpms, debs, tgzs) are available for most
> Linux distributions by now
ghc 5.00.1 available for mandrake-linux (use "urpmi ghc"), and SuSE has 4.08
RedHat still doesn't include it.
hugs98 2001/02 available for mandrake-linux, SuSE has 2000/03, RedHat has
1999/02, and debian has 2000/02
cu Pixel.
PS: Cc'ed hugs debian maintainer
--
Posted from office.mandrakesoft.com [195.68.114.34]
via Mailgate.ORG Server - http://www.Mailgate.ORG
ko...@icm.edu.pl
> ko...@icm.edu.pl writes:
(snip)
>> Debian/Linux system. Just download and dpkg --install ... I had no
>> problems with it.
>
> You still download? I just did an 'apt-get install ghc5', and went
> for a cup of coffee while the system downloaded and installed it for
> me.
Actually, I use `aptitude'. (blush) Yes, I know it crashes often,
but only *after* installation. I find it more convenient to
select several packages at once from list. Thus way I can easily search
all devel/ packages and install all Haskell packages :-).
"apt-get hugs hugs-doc haskell-doc haskell-mode ghc5 ghc5-doc"
and maybe even "apt-get ghc5-prof c2hs ghc5-libsrc"(these I haven't used yet).
ko...@icm.edu.pl
Did you use foldl or foldr? (I bumped into similar problem)
Malcolm Wallace
> haskell.org mentions a third haskell system (hbc?). any comments about
> that?
hbc was one of the first Haskell compilers, and for a long time
the best. However, it has not been actively maintained for
several years now, so although it is still perfectly good for
many purposes, small bugs are no longer fixed.
There is a (often forgotten) *Fourth* Haskell compiler - nhc98 -
which is actively maintained here at York. It produces better
code than Hugs, and is easier to install than ghc. It even has
an interactive mode that looks like Hugs. Overall it is a sort
of "middle" compiler, lying somewhere between Hugs and ghc on
most scales of measurements.
nhc98's big current advantage is its extra tracing and debugging tools.
Regards,
Malcolm
----------------------------------------- Malcolm...@cs.york.ac.uk
Alexander V. Voinov
Jerzy Karczmarczuk wrote:
> "Alexander V. Voinov" criticizes Hugs :
>
> > Not only speed. At my toy program it ran into a stack overflow around `take`ing
> > first 1000 or so elements of a lazy, computed on the fly list. The program was
> > really toy, it just applied a stupid pattern matching function to integers from
> > [0..].
>
> Are you sure?
>
> Increase your memory.
Which memory? I have 128M of RAM.
Ok, the program is (it differs from what I mentioned - because I forgot the details
(I could hardly increase _this_ memory, sorry :-) - but nothing illegal, right?):
module Main where
f x y | x < y = y - x
f x y = x - y
main = do
let y = foldl f 0 (take 1500 [1..])
putStrLn (show y)
ulimit in bash says 'unlimited'. And hugs says "ERROR - Control stack overflow". It
works ok on 1450.
Alexander
Alexander V. Voinov
ko...@icm.edu.pl wrote:
> Did you use foldl or foldr? (I bumped into similar problem)
Hmm. Doest this matter? But anyway much of the techniques suggested in the literature
relies upon higher-order functions of this kind. It would be pointless to use haskell
without all this.
I recall that in Arity/Prolog I could do fantastic things just in 64K of stack... :-(
Alexander
Alexander V. Voinov
Malcolm Wallace wrote:
> There is a (often forgotten) *Fourth* Haskell compiler - nhc98 -
> which is actively maintained here at York. It produces better
> code than Hugs, and is easier to install than ghc. It even has
> an interactive mode that looks like Hugs. Overall it is a sort
> of "middle" compiler, lying somewhere between Hugs and ghc on
> most scales of measurements.
In the 'future developments' section of nhc doc I read:
The implementation of GreenCard could be completed. Remaining
unimplemented features include named field syntax and failure
specifications.
In addition, the new primitive FFI still lacks dynamic imports and
exports,
which are fairly essential for callback-style GUI programming.
Does this mean that nhc is _completely_ unsuitable for GUI programming? Among
other things, I'd like to play more with the Fran-style of UI, popularized by
Hudak in "Haskell school of expression".
Alexander
Hans Aberg
<a...@quasar.ipa.nw.ru> wrote:
>At my toy program it ran into a stack overflow around `take`ing
>first 1000 or so elements of a lazy, computed on the fly list. The program was
>> Increase your memory.
>
>Which memory? I have 128M of RAM.
It is the parameter stack size that should be increased: Some Hugs
installations has this hardwired. On the Mac port, I eventually made an
adjustable. Under UNIX, this usually can be adjusted from the OS.
The way to analyze problems of this kind is to run it through the profile,
convert the output using hp2ps to get a PS file. A look at that output
will tell you where the problem is.
A fix might be to insert a strict evaluation somewhere.
The problem does not have anything with Hugs, or for that matter Haskell,
to do, because in all general purpose programming languages one can
produce a large stack by recursive function calls. Haskell and the
compilers/interpreters implementing it, make the problem more visible,
because it is easy to hit it via lazy evaluation.
Alexander V. Voinov
Hans Aberg wrote:
> The problem does not have anything with Hugs, or for that matter Haskell,
> to do, because in all general purpose programming languages one can
> produce a large stack by recursive function calls. Haskell and the
> compilers/interpreters implementing it, make the problem more visible,
> because it is easy to hit it via lazy evaluation.
But in imperative languages one uses recursion quite rarely, whereas in pure FP
it's the only mechanism to repeat a homogeneous sequence of operations. In Prolog,
and partially(?) in OCaml one can make use of tail recursion optimization, which
allows one to get into the field of _practical_ applications. Can this sort of
optimization be possible in a lazy language at all?
Alexander
Hans Aberg
Do not say that: I use it very frequently in C++. When programming with a
polymorphic variable, building closures etc, it pops up easily.
> whereas in pure FP
>it's the only mechanism to repeat a homogeneous sequence of operations.
FP is just more high level, making it more accessible. To some extent, the
language structure also makes you to use it even when not needed.
> In Prolog,
>and partially(?) in OCaml one can make use of tail recursion
optimization, >which
>allows one to get into the field of _practical_ applications. Can this sort of
>optimization be possible in a lazy language at all?
I'm not an expert on this and Haskell compiler internals, but there was a
thread about that some time ago, and the conclusion was (I think) that the
lazy requirement makes the interpretation of tail recursion different: If
the call is lazy, it is not possible to optimize it away like in a strict
language, because then it would not be a lazy evaluation.
But otherwise, all sorts of optimizations can be used.
Haskell does have features for strict evaluation. The state of the art
seems to be that a human must stand by and choose which lazy/strict is the
best choice.
The heap profiler, and other such debugger tools when and if they become
available, seems to be the way how to learn this type of programming.
This is just my impression -- I do not do much Haskell programming right now.
ko...@icm.edu.pl
> Hartmann Schaffer wrote:
>
>> haskell.org mentions a third haskell system (hbc?). any comments about
>> that?
>
> hbc was one of the first Haskell compilers, and for a long time
> the best. However, it has not been actively maintained for
> several years now, so although it is still perfectly good for
> many purposes, small bugs are no longer fixed.
Question aside:
Why is hbc no longer maintained? It seems strange if it was so good...
Did Main Hacker(L.A.?) got bored maintaining it?
ko...@icm.edu.pl
Hans Aberg wrote:
> In article <3B1FC1C9...@quasar.ipa.nw.ru>, "Alexander V. Voinov"
> <a...@quasar.ipa.nw.ru> wrote:
>>and partially(?) in OCaml one can make use of tail recursion
> optimization, >which
>>allows one to get into the field of _practical_ applications. Can this sort of
>>optimization be possible in a lazy language at all?
>
> I'm not an expert on this and Haskell compiler internals, but there was a
> thread about that some time ago, and the conclusion was (I think) that the
> lazy requirement makes the interpretation of tail recursion different: If
> the call is lazy, it is not possible to optimize it away like in a strict
> language, because then it would not be a lazy evaluation.
To clear it up :-)[hopefully] - let's look at foldl in lazy vs strict setting:
foldl f z [] = z
foldl f z (x:xs) = foldl f (f z x) xs
Strict language can compute a=(f z x) first, and then tail-call
foldl f a xs.
Lazy language(without optimization thanks to strictness analysis)
builds closure c=(f z x) and tail-calls foldl:
foldl f c xs.
See no problem(closures make heap to grow, but stack remains constant,
until you evaluate (f z x)). In practice decent compiler should detect,
when f is strict and evaluate foldl like in a strict language
['ghc5 -O' does, 'ghc5' without optimization fails :-)]
Even more interesting is the case of foldr:
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
In a strict functional language it is NOT a tail call.
In a lazy one it is something like tail call when f is not strict:
foldr builds closure c=(foldr f z xs) and then `tail-calls' f x c.
Stack will grow only when f decides to evaluate it's second argument.
Hope, it's apparent that need for non-tail calls arise from strictness,
and that tail-call issues look different in lazy than in strict setting.
Marcin 'Qrczak' Kowalczyk
> Why is hbc no longer maintained?
Did you look at its code? How much did you understand? :-)
> Did Main Hacker(L.A.?) got bored maintaining it?
AFAIK yes.
Jerzy Karczmarczuk
> Which memory? I have 128M of RAM.
(I suggested that this might be a problem with his overflows)
The H parameter when launching Hugs. I don't remember the default
but it was ALWAYS smaller than I needed.
Good luck.
> ko...@icm.edu.pl wrote:
>
> > Did you use foldl or foldr? (I bumped into similar problem)
>
> Hmm. Doest this matter? But anyway much of the techniques suggested in
> the literature relies upon higher-order functions of this kind.
> It would be pointless to use haskell without all this.
The memory usage of foldr and foldl is COMPLETELY different.
I believe that somebody should write once a tutorial on how to use
practically the co-recursion.
Hans Aberg adds:
> The problem does not have anything with Hugs, or for that matter Haskell,
> to do, because in all general purpose programming languages one can
> produce a large stack by recursive function calls. Haskell and the
> compilers/interpreters implementing it, make the problem more visible,
> because it is easy to hit it via lazy evaluation.
Often it is easier to see it when somebody uses foldl or other strict
functional to lazy data. My own problems with laziness was not the stack
overflow, but polluting the heap with incredibly long closures...
A contribution from Michal:
> Even more interesting is the case of foldr:
>
> foldr f z [] = z
> foldr f z (x:xs) = f x (foldr f z xs)
>
> In a strict functional language it is NOT a tail call.
> In a lazy one it is something like tail call when f is not strict:
> foldr builds closure c=(foldr f z xs) and then `tail-calls' f x c.
> Stack will grow only when f decides to evaluate it's second argument.
More concretely: If foldr produces a lazily, incrementally consumed
list (if it is a constructor) it has NOTHING TO DECIDE, it is the
consumer of its result which will re-launch foldr, and the stack will
NOT grow.
Alexander continues:
> But in imperative languages one uses recursion quite rarely, whereas in
> pure FP it's the only mechanism to repeat a homogeneous sequence of
> operations. In Prolog, and partially(?) in OCaml one can make use of tail
> recursion optimization, which allows one to get into the field of
> _practical_ applications. Can this sort of optimization be possible in a
> lazy language at all?
BUT IT IS DONE! It MUST be done, in Caml, in Scheme, etc., of course, but
in Haskell and Clean as well. In Prolog this is
sometimes dubious/impossible because of the backtracking.
Despite what Hans says in his later posting, the tail calls in a lazy
language are iteratively optimized as well, try to launch a "program"
[1 .. ]
what does it do according to you? It develops a lazy, tail-recursive
structure.
Anyway, nothing and nobody will save you if you use your recursion blindly.
Jerzy Karczmarczuk
Caen, France
Malcolm Wallace
> In addition, the new primitive FFI still lacks dynamic imports and
> exports, which are fairly essential for callback-style GUI programming.
>
> Does this mean that nhc is _completely_ unsuitable for GUI programming?
Currently, yes, nhc98 is unsuitable for GUI programming. This will
change, but not in the next few months. At some point, I want to
ensure that Manuel Chakravarty's Gtk+ binding for Haskell works
with nhc98. I have also not yet looked at the compatibility of Paul
Hudak's SoE Graphics (but that isn't GUI - it is more of a drawing
package isn't it?)
Regards,
Malcolm
----------------------------------------- Malcolm...@cs.york.ac.uk
Hans Aberg
<kar...@info.unicaen.fr> wrote:
>> But in imperative languages one uses recursion quite rarely, whereas in
>> pure FP it's the only mechanism to repeat a homogeneous sequence of
>> operations. In Prolog, and partially(?) in OCaml one can make use of tail
>> recursion optimization, which allows one to get into the field of
>> _practical_ applications. Can this sort of optimization be possible in a
>> lazy language at all?
>
>BUT IT IS DONE! It MUST be done, in Caml, in Scheme, etc., of course, but
>in Haskell and Clean as well. In Prolog this is
>sometimes dubious/impossible because of the backtracking.
>
>Despite what Hans says in his later posting, the tail calls in a lazy
>language are iteratively optimized as well, try to launch a "program"
>
>[1 .. ]
>
>what does it do according to you? It develops a lazy, tail-recursive
>structure.
I didn't say one doesn't do that optimization, only that someone said it
might turn out with a rather different interpretation in a lazy language;
I don't about the details.
As for the so called "tail recursive" engine, it is not an engine that
sits and looks for tail recursions and then removes them, but an evaluator
that happens to have the property that if the function called is tail
recursive, then it is removed.
One can play this game as follows: Suppose we program in C++, and have
int f(int x) {
...
return g(x);
}
Then we can remove the f function call when g is called by making an
evaluator that can accepts int or functions of type int (*)(int) as
arguments, and the new function will become
A f(int x) {
...
return g;
}
The evaluator will first pass x to f, and when it sees f is returning g,
it will combine g(x). So f becomes removed.
In effect, we made f to return a closure which the evaluator can handle
instead of calling g.
This is a very simple idea, but one can go very far with it: In fact, I
know that in Hugs, in order to bypass the C stack as much as possible, one
eventually implemented a mechanism where all function return values are
such covers. Thus the C stack should not grow much at all, but instead the
Hugs evaluator stack will grow.
So then it becomes difficult to keep track of what kind of optimizations
actually are being done: Is it the stack or the covers that are growing?
But otherwise, all sorts of optimizations are done. Strictness analysis is
one; if one knows all components are pure, then one can do lambda calculus
optimizations by rearranging the evaluation order, etc.