Re: lazy-let & loop

Hi Sam,

> > Your proposal introduces a new approach to scoping: Have the scope
> > depend on whether the access to a variable is a read or a write
> > access.
> 
> Not really - it merely allows control over binding activation.
> ...
> This activates the binding and assigns the inner binding to 1+outer.

This is nearly as bad. If we have a scoping problem in LOOP, the "solution"
to rebind the variable with initially the same value looks really like a
makeshift, and the "at the first SETQ" rule will not do what you expected
when the code flow is not linear (which can happen, given that the LOOP
macro is reshuffling user-provided forms).

The way to proceed, IMO, is to pursue Jörg's "About how to initialize in LOOP"
thought.

> > Instead, maybe we should provide explicit control of the environment in
> > which a form will be evaluated/compiled. For example:
> >
> >   (let ((a 1))
> >     (environment-let env-with-a
> >       (let ((b 2))
> >         (in-enviroment env-with-a (list a b)))))
> 
> (declare (name-environment env-with-a))
> 
> and
> 
> (declare (use-environment env-with-a))
> 
> looks better to me.

But code walkers usually ignore declarations, which they are allowed to do,
per CLHS 3.3.1.

> >> The problem with loop is that under certain circumstances we separate
> >> initializing and binding of a variable.
> >
> > This is not a problem by itself. It is explicitly allowed by CLHS
> > 6.1.1.4 "Implementations can interleave the setting of initial values
> > with the bindings."
> 
> If I understand you correctly, this merely implies that the naive user
> expectations are not guaranteed. Sure. Why not give them what they want
> if we can though?
> ...
> I am trying to implement "naive user expectations" (as long as they are
> conforming, of course).

If it is easy to do without introducing user-visible bugs or de-optimizations,
I am all for implementing "naive user expectations". (Recall that the
rationale for LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE was
to allow implementations to optimize, according to Kent Pitman.)

In this case, however, Jörg's summary indicates that there are some
constraints, and there is no clear winner among the proposals he has
investigated so far.

Bruno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel