[racket] lazy letrec-values

He addresses the interaction between lazy (by-name) and strict modules. 
I am asking what the relationship is between 

 (module a racket ...)

and 

 (module a lazy/racket ...) 

or what it should be. Presumably we should be able to switch the 
module's language (as we do for R and TR) and be able to predict
something about the behavior. 

-- Matthias







On Jul 14, 2014, at 7:17 PM, Robby Findler wrote:

> Doesn't Jacob's dissertation give us some guidance on the question
> you're asking?
> 
> (I too prefer option #2.)
> 
> Robby
> 
> On Mon, Jul 14, 2014 at 3:37 PM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> I would much prefer option 2. We don't want to be needlessly different than R.
>> 
>> One question we may wish to consider is what the semantic relationship is between LR and R. This one was easy for TR and R. Here, I am not sure what to say (exactly) but figuring this out, would help a lot getting a handle on LR's design principles.
>> 
>> -- Matthias
>> 
>> 
>> 
>> 
>> 
>> On Jul 14, 2014, at 1:09 PM, Stephen Chang <stchang at ccs.neu.edu> wrote:
>> 
>>> The problem was that the values constructor in Lazy Racket had two
>>> different semantics, depending on the number of arguments, but the
>>> extractors (ie let-values and friends) only handled the latter. We
>>> should decide on one consistent behavior, mv's should either behave
>>> like:
>>> 
>>> 1) tuples in a lazy language, or
>>> 2) racket values
>>> 
>>> LR mv's already mostly behave like #1, and not like racket values. For
>>> example, (values 1 2) returns a multiple-values struct instance that
>>> can be passed around before extracting the values, something you
>>> cannot do in Racket. So it seems odd to me to enforce the Racket-like
>>> values behavior for only single-value values. The patch just makes all
>>> mv's consistently have the #1 behavior.
>>> 
>>>> but now you get a different kind of
>>>> breakage where
>>>> 
>>>> (let-values ([(x) (values (error "a"))]) 1)
>>>> (let-values ([(x)         (error "a") ]) 1)
>>>> 
>>>> are not the same.
>>> 
>>> If we want behavior #1, then these should not be the same, since you
>>> have to force down "one level" to get the shape, as Robby mentioned.
>>> 
>>> If we want #2, the Racket-values behavior, then it seems to me like
>>> the right thing to do is to use !values everywhere instead of !. I
>>> understand not wanting to do so since it adds an extra check for every
>>> force, but since lazy Racket is not really performant enough for
>>> practical use, maybe this doesn't matter?
>>> 
>>> 
>>> 
>>>> More than that, the hack of dealing with multiple
>>>> values is at such a (bad) level, that it's possible that the patch would
>>>> break code that assumes that `E' is equivalent to (values E).
>>>> 
>>>> A more proper way to deal with `*-values' constructs would be for the
>>>> macro to treat a case of != 0 values differently from a single value, so
>>>> the force that breaks the above is not done.  That is, this kind of
>>>> change would make these two:
>>>> 
>>>>> (let-values ([(x) (values (error "poof"))]) 1)
>>>>   1 ; `values' doesn't wrap, but (x) means no !-ing
>>>>> (let-values ([(x y) (values (error "poof"))]) 1)
>>>>   poof ; since now there are (x y) so the macro !s the RHS
>>>> 
>>>> This is clearly not great either, but I think that overall it would be
>>>> more consistent.  (But of course it's not a 10-second fix.)
>>>> 
>>>> (A much better way to deal with MVs is to have "TLR" (= TR+LR).)
>>>> 
>>>> --
>>>>         ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>>>                   http://barzilay.org/                   Maze is Life!
>>> ____________________
>>> Racket Users list:
>>> http://lists.racket-lang.org/users
>> 
>> 
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/users