[Haskell-cafe] Comparison with Clean?

[Bryce Bockman]

I was trying to draw an analogy between imperitive and functional language 
development over time.  In both cases we seem to have a progression 
towards More complicated type systems etc.  That was really my only point.
To say C is to Imperative languages as Scheme is to functional languages 
does not say that C is as expressive as any functional language.
Of course, I should have known that such a comparison would be disturbing 
to those on this list.

On Wed, 4 May 2005 karczma at info.unicaen.fr wrote:

> Bryce Bockman writes: 
> I would rather not compare Scheme to "C".
> C is a fixed-syntax language, the "lack of fanciness" is *rigidity*.
> Scheme is infinitely extensible, don't say that its *syntax* is simple
> just because you have its "Cambridge-Polish" notation, 
> parenthesed/prefixed. 
> Just look at the syntax of DO, of classes, units, etc. in DrScheme, just
> try to imagine the power of a *general* macro-expander, very far from 
> cpp... 
>> Scheme is strict, so it lacks some of the flexibility (and drawbacks) 
>> that come from Laziness, but in the book they teach you how to build a 
>> Lazy version of Scheme, which is instructive in understanding what's 
>> really going on in Lazy evaluation.


I'm confused by you're sentence: 
>
> Applicative protocol is not normal protocol, the reduction is,
> as it is.

Are you saying that Lazy is not the same as normal order evaluation?  My 
point was that in SICP in addition to the Applicative Order interpereter.
They also show how one could go about building a Normal Order version. 
Are Normal Order evaluation and Laziness totally different?  Again I'm 
just learning here.

> On the other hand, it is relatively easy to make lazy constructs,
> streams based on explicit, user-controllable thunks, since you can of
> course construct dynamically functional objects.
> This does not necessarily tell you what is the *real* implementation of
> laziness in Haskell, and even less in Clean; "manual thunks" are possibly
> different from a specific graph reduction strategy implemented by a lazy
> language compiler. You will learn something anyway, but perhaps something
> different.

Okay.  That much is clear.  My next question would be is there a SICP 
level text that could teach one how to build a lazy 
(compiler/interpereter) in the way that Haskell does it?

Thanks,
Bryce