[plt-scheme] Letrect (was blah. units)

On Thu, 31 Oct 2002, Jerzy Karczmarczuk wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> 
> 
> Zbyszek Jurkiewicz says that in my example, (cadr y), where:
> 
> >>(define y
> >>   (letrec ((x (cons 1 x))) x)
> >>)
> 
> > 
> >...you get what you pay for.  Scheme is not lazy, so there 
> > is no appropriate behaviour here.  One cannot signal unbound
> > variable error here, because x is bound.  There is some
> > discussion of this in SICP in connection with internal DEFINEs.
> 
> 
> > If you introduce laziness here, you would get problems with 
> > assignments (or its newer verision known as object-oriented
> > programming).
> 
> 
> I am sorry, but this has no compulsory relation to laziness. If
> in one place you say explicitly that in letrec the definiens and
> the definiendum belong to the same environment, and then you admit
> that the only place where this work is where definiens is "lazy"
> in the sense that it postpones the evaluation (lambda form contains
> only the reference to the possible bindings of "x"), then you
> might sleep well, but you make such perverts as myself unhappy.
> 
> A cyclic list is not a lazy construct. You might implement it
> differently: binding "x" to <undefined> if you wish, reassign it,
> but then replace all the internal occurrences of x in the data
> structure with the assigned value. An intelligent SECD compiler
> may do that.
> 
> I do not claim that it would be a Good Thing, but, please, dont
> tell me that it breaks any rules of "classical" strict programming.
> 
> Jerzy Karczmarczuk
> 

Of course it does not, but how do you like this code

(letrec ((foo (begin (set! a ...) <some expression>))
         (bar (begin (set! b ...) <some expression>))
  ....)

I would not program this way, but it is perfectly legal in Scheme.
Question is: when the assignment should occur and in what order?
Once, when working on the implementation of Scheme, I tried to analyze
all possibilities there (we had streams in the dialect) and only got
more and more frustrated.

Nobody was able to make clear definition what should happen (one
can always make sequence of side-effects longer and longer).

There is a paper J.Sargeant "Uniting Functional and Object-Oriented
Programming" (LNCS 742), which finally supported my belief that some
compromise is necessary here.  Simply, I cannot see a solution nice
from the theoretic point of view, practical enough to be useful
and accepting assignments etc.  For some time we have to live
with this.

Best regards,

Zbyszek Jurkiewicz