Re: Lisp Ruby Scheme

Andrew Reilly (andrew-newspost@xxxxxxxxxxxxxxxxxxxxx) wrote:

: > In Haskell however, where lists are lazily constructed by default, and
: > the compiler has the guarantee that no side-effects will happen during
: > sum, foo or bar, there is no reason for the compiler to actually
: > construct intermediate lists. It can produce efficient code from the
: > naive algorithm, code that never actually constructs a list, without any
: > risk of changing the semantics of the expression. (Because of the
: > non-strictness, the cells of the lists are even in the dumbest
: > interpreter only being constructed as they are being consumed and then
: > immediately thrown away: so why would a smart compiler make them ?)

: Perhaps they will, perhaps they won't. It doesn't seem too much of a
: stretch for a compiler (for any language) to be able to establish pure
: functional-ness of such leaf functions, at which point it is free to
: perform the same heroic optimization as the supposed Hascal compiler.

Pure functionality is not enough. You must also be sure that the input
will never be an endless list, that all separate operations will terminate,
and that no exceptions of any kind (e.g. integer division by zero) will
ever occur inside the "inner loops". In a lazy functional language on the
other hand, these conditions will not make the optimization in question
change the semantics of the expression, so you don't have to check.

I just wanted to make this point; I think I answered to most of your other
points in another sub-thread of this discussion (news propagation may
have been a bit slow for you) -- the part about the compiler not being
able to spot the idiom is handled by the extensibility of the optimization
phase by programmer-supplied templates in addition to the standard ones,
although I must admit I have not tried in which degree this will help for
the specific algorithm you mention.

I am now eagerly awaiting the first poster to say that macros are more
generic than these templates. I'll make him eat soup with an 85
components Swiss army knife instead of with a spoon. :-)

Dirk van Deun
--
Ceterum censeo Redmond delendum
.

Relevant Pages

  • Re: Just a bit of silliness
    ... But format strings could be eliminated completely: ... This would require a great deal of compiler support, ... parameter lists are declared explicitly, ... Since C doesn't have runtime type information, ...
    (comp.lang.c)
  • Re: More static type fun.
    ... > perception of how common runtime type errors are. ... to invest in unit tests to catch bugs and gotchas in my program would ... and about placating the compiler. ... > to explicitly tell the compiler that you want to use lists with more ...
    (comp.lang.lisp)
  • Aurora Beta 1
    ... The Aurora compiler has just been updated to Beta 1. ... non-indexed triangle lists. ... The ClassView pane in the IDE now does something. ...
    (comp.lang.misc)
  • Re: Symbols, metacircular evaluation, external representation.
    ... You could only use strings, and you would have to use parsers all the time. ... same kind of symbolic expressions, it's very easy to write functions ... writting a metacircular interpreter (or a lisp compiler), ... lists. ...
    (comp.lang.scheme)
  • Re: foreach enhancement
    ... > strong typing is not an option, and that optimization will not be able to ... > concerned with optimization of for loops and typing - since lists will be ... *very* different and the compiler itself will certainly be able to know the ...
    (microsoft.public.dotnet.languages.csharp)