yet again with the laziness
3 views
Skip to first unread message
Raoul Duke
Jun 8, 2009, 5:40:15 PM6/8/09
to CAL Language Discussion
hi,
i'm trying to grok what the state of the union is with haskell's laziness.
http://groups.google.com/group/comp.lang.functional/browse_thread/thread/403d55c415847fe8#
i'm guessing CAL could have similar questions / issues around it --
i'd appreciate any thoughts about how laziness + space usage play out
in CAL.
sincerely.
Luke
Jun 10, 2009, 4:59:30 AM6/10/09
to CAL Language Discussion
Hi Raoul,
Was waiting to see if you got any other takers, but here's my $0.02
worth...
I haven't read the entire thread you cite, but yes of course in
general many issues around laziness apply to CAL as they do to
Haskell.
Laziness (by default) is part of the operational semantics of the
language, and like all features of high-level languages the developer
needs to be aware of its effect on the code they write. A more minor
example of this is the use of the "+" concatenation operator on Java
strings, which causes a new String to be constructed as Java stings
are immutable. If you are not aware of the semantics of automatic
memory management in Java, String and '+', you could write a loop with
the + operator concatenating lots of strings, which would be
relatively inefficient, though it would work. The nature of this
example is somewhat different to laziness, but it serves to illustrate
how the developer rarely has a free ride if they want to have code
that is both correct and efficient when they are using a language that
is not a straightforward mapping to the underlying computing machinery
(e.g. x86 machine code).
IMO well written code makes appropriate judgements about laziness in
its local scope - which should be appropriate to the local logic/
algorithm and serve all uses of the function. In practice, in CAL,
this means controlling the laziness as appropriate, which in 'normal'
code means a pass through looking at adding 'plinging' to indicate to
the compiler where it is safe and indeed advantageous to forego the
default lazy evaluation.
In CAL, some kinds of code needs special attention too, especially in
functions that are handling foreign calls with side effects, though
here the issue is as much sequencing as it is laziness.
If you care about an algebraic style of programming and the ability in
general to abstract by composition, then laziness is a Very Good
Thing, as of course it allows code to maintain degrees of freedom
(i.e. the order of actual processing) until the real operating context
is known at runtime. This can allow the developer to create
components (functions) that are more operationally general. As usual,
there's a cost for ultimate freedom though ;-)
The very much related issue of space behaviour is certainly another
area that requires attention, especially in some kinds of code.
Again, the programmer is often given the impression that they have
much more work done from them in a high level language such as CAL or
Haskell (e.g. using fold over a list rather than the more verbose
primitive loop). Nevertheless, using the _wrong_ fold (i.e. without
understanding how the function will be expanded/reduced) is of course
going to cause space problems.
CAL has some diagnostic tools that allow you to trace expansion of
functional terms during evaluation. These can be useful in checking
space behaviour, and of course the effect of laziness.
On Jun 8, 2:40 pm, Raoul Duke <rao...@gmail.com> wrote:
> hi,
>
> i'm trying to grok what the state of the union is with haskell's laziness.
>
> http://groups.google.com/group/comp.lang.functional/browse_thread/thr...
Was waiting to see if you got any other takers, but here's my $0.02
worth...
I haven't read the entire thread you cite, but yes of course in
general many issues around laziness apply to CAL as they do to
Haskell.
Laziness (by default) is part of the operational semantics of the
language, and like all features of high-level languages the developer
needs to be aware of its effect on the code they write. A more minor
example of this is the use of the "+" concatenation operator on Java
strings, which causes a new String to be constructed as Java stings
are immutable. If you are not aware of the semantics of automatic
memory management in Java, String and '+', you could write a loop with
the + operator concatenating lots of strings, which would be
relatively inefficient, though it would work. The nature of this
example is somewhat different to laziness, but it serves to illustrate
how the developer rarely has a free ride if they want to have code
that is both correct and efficient when they are using a language that
is not a straightforward mapping to the underlying computing machinery
(e.g. x86 machine code).
IMO well written code makes appropriate judgements about laziness in
its local scope - which should be appropriate to the local logic/
algorithm and serve all uses of the function. In practice, in CAL,
this means controlling the laziness as appropriate, which in 'normal'
code means a pass through looking at adding 'plinging' to indicate to
the compiler where it is safe and indeed advantageous to forego the
default lazy evaluation.
In CAL, some kinds of code needs special attention too, especially in
functions that are handling foreign calls with side effects, though
here the issue is as much sequencing as it is laziness.
If you care about an algebraic style of programming and the ability in
general to abstract by composition, then laziness is a Very Good
Thing, as of course it allows code to maintain degrees of freedom
(i.e. the order of actual processing) until the real operating context
is known at runtime. This can allow the developer to create
components (functions) that are more operationally general. As usual,
there's a cost for ultimate freedom though ;-)
The very much related issue of space behaviour is certainly another
area that requires attention, especially in some kinds of code.
Again, the programmer is often given the impression that they have
much more work done from them in a high level language such as CAL or
Haskell (e.g. using fold over a list rather than the more verbose
primitive loop). Nevertheless, using the _wrong_ fold (i.e. without
understanding how the function will be expanded/reduced) is of course
going to cause space problems.
CAL has some diagnostic tools that allow you to trace expansion of
functional terms during evaluation. These can be useful in checking
space behaviour, and of course the effect of laziness.
On Jun 8, 2:40 pm, Raoul Duke <rao...@gmail.com> wrote:
> hi,
>
> i'm trying to grok what the state of the union is with haskell's laziness.
>
Raoul Duke
Jun 10, 2009, 1:52:35 PM6/10/09
to cal_la...@googlegroups.com
hi Luke,
> Was waiting to see if you got any other takers, but here's my $0.02
> worth...
Many thanks for the edification. I'm hoping to gradually get less
clueless about how laziness plays out in such languages. :-)
sincerely.
Reply all
Reply to author
Forward
0 new messages