Sounds like this might lead to a way to implement MVs in a less messy
way: make MV-promises distinguishable, so you can get the number of
values (MV = length of the list of values, otherwise 1). The problem
there is propagating the MV-ness when other promises wrap MV promises.
(The other
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
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
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
matth...@ccs.neu.edu wrote:
I would much prefer option 2. We don't want to be needlessly different than R.
One question we
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
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
matth...@ccs.neu.edu wrote:
He addresses the interaction between lazy (by-name)
On Thu, Jul 10, 2014 at 1:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I'm not sure whether to call it a bug or a limitation of `lazy`.
There is a borderline bug and a borderline premature optimization.
The bug is the way that multiple values are represented (and I'll write
more in a different
On Fri, Jul 11, 2014 at 1:41 AM, Stephen Chang stch...@ccs.neu.edu wrote:
Actually, this is a bug, because the expression in a single-argument
values call is forced prematurely.
IMO, the whole treatment of multiple values is a hack, for obvious
reasons. I was never happy with it, and debated
Both issues are really about the idea that lazy languages
delay the right-hand side of definitions until the program
has determined what is in demand (and what isn't).
1. As you point out (define x y) thus imposes a large cost
on lazy programs. But that's the whole point of laziness.
It is
I think the examples suggest that you don't need to track the multiple
values independently from each other but that you need to track the number
of values separately from what the values actually are.
Robby
On Sunday, July 13, 2014, Matthias Felleisen matth...@ccs.neu.edu wrote:
Both issues
Correct, that's what I mean by non-classical types.
On Jul 13, 2014, at 7:01 PM, Robby Findler wrote:
I think the examples suggest that you don't need to track the multiple values
independently from each other but that you need to track the number of values
separately from what the
I just sent a pull request : https://github.com/plt/racket/pull/727
I added a few simple test cases, but the interesting thing is that running
`./racket/bin/raco test pkgs/lazy` seems to pass even when I add a failing
test case such as `(! (eq? 1 2)) = #t`.
That same test will fail as expected
I merged. Thanks again!
the interesting thing is that running
`./racket/bin/raco test pkgs/lazy` seems to pass even when I add a
failing test case such as `(! (eq? 1 2)) = #t`.
That same test will fail as expected if I run it within drracket.
Thats because lazy currently doesn't use the test
You should probably change this so that drdr runs the right tests.
Changing the module+ main to module+ test is probably the way to go.
Robby
On Fri, Jul 11, 2014 at 5:02 PM, Stephen Chang stch...@ccs.neu.edu wrote:
I merged. Thanks again!
the interesting thing is that running
I'm not sure whether to call it a bug or a limitation of `lazy`.
The `lazy` language doesn't delay a reference to an identifier. As a
result,
(define x y)
(define y (list 1))
(car x)
fails. The case could be made that the right-hand side of the definition
of `x` should have been a lazy
Thank you for the in-depth analysis. Very interesting.
Following your reasoning, if I edit lazy.rkt and force `values` to use
`multiple-values` for the single entry case, the example that was
previously broken now works. (I just have no idea if this breaks something
else in the process.)
at
Actually, this is a bug, because the expression in a single-argument
values call is forced prematurely.
eg, This should not error:
- (let-values ([(x) (values (error a))]) 1)
; a [,bt for context]
Just like this does not error.
- (let-values ([(x y) (values (error a) (error b))]) 1)
1
Lazy
There are also Eli's class notes. I don't have a URL handy but I am sure if you
google Eli Barzilay and course you'll find his notes on the various levels
of lazy (plus homework assignments :-) -- Matthias
On Jul 10, 2014, at 6:41 PM, Stephen Chang wrote:
Actually, this is a bug,
It looks like he has taken those down. But I'm sure he would email a copy
if asked (the think is http://pl.barzilay.org/resources.html#classnotes btw)
On Thu, Jul 10, 2014 at 8:42 PM, Matthias Felleisen matth...@ccs.neu.edu
wrote:
There are also Eli's class notes. I don't have a URL handy but
Hello all,
I've been playing around with creating circular lists (and learning racket
which has been quite fun), but I'm stumped on why the lazy version of
letrec-values is not producing a promise like the lazy version of letrec
does. With the lazy letrec I can create circular lists, but with the
20 matches
Mail list logo
