[racket] lazy letrec-values

Oh, I see.

An yep: minimizing those differences (or, rather, keeping only the
"essential" ones) is the intuition behind my preference for option #2.
FWIW.

Robby

On Mon, Jul 14, 2014 at 6:23 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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
>