A few minutes ago, Robby Findler wrote:
>
> FWIW, this was the bug in redex that prompted me to send this
> message (it was there for some time since it wasn't a syntax error
> it was similar in spirit to the code I posted; things broke
> when #f was an argument)
[I think that it's good to h
On Friday, May 3, 2013, Neil Toronto wrote:
> On 05/03/2013 09:12 AM, Eli Barzilay wrote:
>
>> A few minutes ago, Robby Findler wrote:
>>
>>> Given that we don't yet even have a prototype of racket2, I'm going
>>> to guess that "near" isn't all that near. IMO, there are other big
>>> things that w
On 05/03/2013 09:12 AM, Eli Barzilay wrote:
A few minutes ago, Robby Findler wrote:
Given that we don't yet even have a prototype of racket2, I'm going
to guess that "near" isn't all that near. IMO, there are other big
things that we should be focused on going first (notably the package
system).
I tried your suggestion, and it doesn't fix the original bug.
I'll stick with the semaphores solution.
Vincent
At Fri, 03 May 2013 13:13:45 -0400,
Vincent St-Amour wrote:
>
> At Fri, 3 May 2013 12:17:46 -0400,
> Eli Barzilay wrote:
> >
> > A few minutes ago, Vincent St-Amour wrote:
> > > At
At Fri, 3 May 2013 12:17:46 -0400,
Eli Barzilay wrote:
>
> A few minutes ago, Vincent St-Amour wrote:
> > At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote:
> > > (define (delay/thread thunk)
> > > (let ()
> > > (define p (make-promise/thread #f))
> > > (pset! p (make
Yes (I wrote this privately to Vincent too).
Also, it has the advantage of being clear that you're not sending any
meaningful values (for future maintainers of this code).
Robby
On Fri, May 3, 2013 at 11:06 AM, Vincent St-Amour wrote:
> Sounds good, I'll use a semaphore.
>
> Vincent
>
>
> At F
A few minutes ago, Vincent St-Amour wrote:
> At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote:
> > (define (delay/thread thunk)
> > (let ()
> > (define p (make-promise/thread #f))
> > (pset! p (make-running-thread (thread (λ() ...same...
> > p))
>
> I thi
Sounds good, I'll use a semaphore.
Vincent
At Fri, 3 May 2013 09:58:25 -0600,
Matthew Flatt wrote:
>
> Thanks for tracking this down!
>
> In case you mean a channel in the sense of `make-channel', I recommend
> a semaphore, instead, since a semaphore is the lightest-weight
> synchronization co
At Fri, 3 May 2013 11:56:02 -0400,
Eli Barzilay wrote:
>
> A few minutes ago, Vincent St-Amour wrote:
> > Sam, Asumu and I found and fixed the bug. Here's the problem in a
> > nutshell.
> >
> > This is the implementation of `delay/thread' from racket/promise.
> >
> > (define (delay/thread th
Thanks for tracking this down!
In case you mean a channel in the sense of `make-channel', I recommend
a semaphore, instead, since a semaphore is the lightest-weight
synchronization construct.
At Fri, 03 May 2013 11:45:38 -0400, Vincent St-Amour wrote:
> Sam, Asumu and I found and fixed the bug. H
A few minutes ago, Vincent St-Amour wrote:
> Sam, Asumu and I found and fixed the bug. Here's the problem in a
> nutshell.
>
> This is the implementation of `delay/thread' from racket/promise.
>
> (define (delay/thread thunk)
> (let ()
> (define (run)
> (call-with-exce
Sam, Asumu and I found and fixed the bug. Here's the problem in a
nutshell.
This is the implementation of `delay/thread' from racket/promise.
(define (delay/thread thunk)
(let ()
(define (run)
(call-with-exception-handler
(lambda (e) (pset! p (make-reraise e
On Friday, May 3, 2013, Ryan Culpepper wrote:
> On 05/03/2013 11:12 AM, Robby Findler wrote:
>
>> Can you point to some examples?
>>
>> Note that you can still use else, as long as you don't refer to it as a
>> variable.
>>
>
> Just to check: If match treats else specially, it should only accept i
On 05/03/2013 11:12 AM, Robby Findler wrote:
Can you point to some examples?
Note that you can still use else, as long as you don't refer to it as a
variable.
Just to check: If match treats else specially, it should only accept it
as the entire pattern. For example, the following should be an
Nothing readily available. I commonly use a shimmed match that gives better
match failure errors that help me pinpoint a problem (though it's not for
everyone):
(define-syntax (matche stx)
(syntax-case stx () [(_ e [p rhs] ...) #`(matche e [p rhs ...] [else (error
'bad-match "~a didn't match i
A few minutes ago, Robby Findler wrote:
> Given that we don't yet even have a prototype of racket2, I'm going
> to guess that "near" isn't all that near. IMO, there are other big
> things that we should be focused on going first (notably the package
> system).
+1, since the "damage" would be that
Can you point to some examples?
Note that you can still use else, as long as you don't refer to it as a
variable.
On Friday, May 3, 2013, J. Ian Johnson wrote:
> I've used else as a catch-all binding in match. Yes, it's not the best
> practice, but I think since I've done it, other people must h
I've used else as a catch-all binding in match. Yes, it's not the best
practice, but I think since I've done it, other people must have done it too.
This could annoy them.
-Ian
- Original Message -
From: "Robby Findler"
To: "Sam Tobin-Hochstadt"
Cc: dev@racket-lang.org
Sent: Friday, May
Given that we don't yet even have a prototype of racket2, I'm going to
guess that "near" isn't all that near. IMO, there are other big things that
we should be focused on going first (notably the package system).
Just to check again: Is no one concerned with the backwards incompatibility
issue?
R
Right, I agree with this. My question is basically: are we going to,
in the reasonably near future, be encouraging people to program in a
`#lang racket2` where `cond` works differently, in which case it
doesn't seem worth it to change `match`. Otherwise, I'll do this now.
Sam
On Fri, May 3, 201
Cond's else cannot change. I agree that that's what I would change if I
could have it back to do it over, but we cannot.
That's the way to perhaps be thinking about racket2, tho.
Robby
On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote:
> On Fri, May 3, 2013 at 10:22 AM, Robby Findler
> > wrote:
That's my take too, but we should really be careful about changes at this
level.
Robby
On Friday, May 3, 2013, Laurent wrote:
>
> On Fri, May 3, 2013 at 4:22 PM, Robby Findler
> 'ro...@eecs.northwestern.edu');>
> > wrote:
>
>> I don't like warnings that are basically admitting weaknesses in th
On Fri, May 3, 2013 at 10:22 AM, Robby Findler
wrote:
>
> For this kind of thing, my preference would be to change match than to issue
> a warning. I don't like warnings that are basically admitting weaknesses in
> the language design Of course, changing a core thing like that may be
> more tr
On Fri, May 3, 2013 at 4:22 PM, Robby Findler
wrote:
> I don't like warnings that are basically admitting weaknesses in the
> language design
Ah, that's the answer my subconscious was seeking when I wondered about
Racket warnings. Good point!
FWIW, I'd vote (with my voting weight being arou
We do have warnings for things like the optimizer detecting a bad
application of a function, for example, but they go into the logger and you
have to say the magic words (open sesame?) to get them out.
For this kind of thing, my preference would be to change match than to
issue a warning. I don't
That one is twisted indeed, if you forget about how `else' must be written
in `match' (which I had, not using match too much).
I was thinking about issuing a warning when a syntax-parameter gets
shadowed (if that is even catchable).
Then suddenly I realized Racket doesn't do warnings. (Is there a r
[ for those that just want to see what I'm getting at, scroll to the end ]
While the docs are clear (enough) on this point, I think it can be quite
confusing. See if you spot the bug in this program:
#lang racket
(define (find-literals e)
(define literals '())
(let loop ([e e])
(match e
27 matches
Mail list logo
