Re: [racket-dev] else clauses: possible change to match?

[Eli Barzilay]

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 have a much more relaxed policy about
breaking compatibility in cases like this: so far there was no real
code found that uses the feature, but there is one instance of code
that would get fixed by the change...]

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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 we should be focused on going first (notably the package
>>> system).
>>>
>>
>> +1, since the "damage" would be that people will need to convert uses
>> `match', but that'll be minor compared to `cond'.
>>
>
> +1, same reasons.
>
> When I don't use match for a while, the first time I use it, I almost
> always write [else ...] as the last clause. Then I catch myself and replace
> `else' with `_'.
>
> I started being careful about catch-all cases in `match' when I wrote an
> expression similar to this:
>
>   (match a
> [(list x)  #t]
> [else  (case (first a)
>  [(6)  #f]
>  [else  #t])])
>
> got this error:
>
>   case: bad syntax (not a datum sequence) in: else
>
> and was completely baffled for a long time.
>
>  A few minutes ago, 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
>>> have done it too. This could annoy them.
>>>
>>
>> Do you have an actual use that would *break*?  That is, something like
>>
>>  (match x ... [else else])
>>
>
> I'll bet almost every use of just `else' as a pattern in the wild doesn't
> have `else' in the body because it's intended to be a catch-all case. If it
> does have `else' in the body, it's almost certainly in a `cond' or a
> `case', which is either an error or hideous style.
>
>
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)

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Neil Toronto]

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).


+1, since the "damage" would be that people will need to convert uses
`match', but that'll be minor compared to `cond'.


+1, same reasons.

When I don't use match for a while, the first time I use it, I almost 
always write [else ...] as the last clause. Then I catch myself and 
replace `else' with `_'.


I started being careful about catch-all cases in `match' when I wrote an 
expression similar to this:


  (match a
[(list x)  #t]
[else  (case (first a)
 [(6)  #f]
 [else  #t])])

got this error:

  case: bad syntax (not a datum sequence) in: else

and was completely baffled for a long time.


A few minutes ago, 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
have done it too. This could annoy them.


Do you have an actual use that would *break*?  That is, something like

 (match x ... [else else])


I'll bet almost every use of just `else' as a pattern in the wild 
doesn't have `else' in the body because it's intended to be a catch-all 
case. If it does have `else' in the body, it's almost certainly in a 
`cond' or a `case', which is either an error or hideous style.


Neil ⊥

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Vincent St-Amour]

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 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 think that introduces another race condition.
> > > 
> > > If the thread is forced before the `pset!', then `force' would
> > > return #f (line 107 of racket/promise.rkt), since the value inside
> > > the `promise/thread' is not a thread.
> > 
> > But this can't happen because `delay/thread' won't return with the
> > broken promise until after the `pset!' fixed it.
> > 
> > (Even code in the input thunk will not be able to try to force itself
> > without having itself accessible as a value.)
> 
> Makes sense. I'll give it a try.
> 
> Vincent

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Vincent St-Amour]

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-running-thread (thread (λ() ...same...
> > > p))
> > 
> > I think that introduces another race condition.
> > 
> > If the thread is forced before the `pset!', then `force' would
> > return #f (line 107 of racket/promise.rkt), since the value inside
> > the `promise/thread' is not a thread.
> 
> But this can't happen because `delay/thread' won't return with the
> broken promise until after the `pset!' fixed it.
> 
> (Even code in the input thunk will not be able to try to force itself
> without having itself accessible as a value.)

Makes sense. I'll give it a try.

Vincent

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Robby Findler]

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 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 construct.
> >
> > At Fri, 03 May 2013 11:45:38 -0400, 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-exception-handler
> > >(lambda (e) (pset! p (make-reraise e)) (kill-thread
> > > (current-thread)))
> > >(lambda () (pset! p (call-with-values thunk list)
> > > (define p
> > >   (make-promise/thread
> > >(make-running-thread
> > > (object-name thunk)
> > > (thread run
> > > p))
> > >
> > > `run' depends on `p', and vice versa. The `run' thread may start
> > > executing *before* `p' is actually defined. This causes `pset!' (which
> > > is just promise mutation) to mutate `#', which raises an
> > > exception[1]. The exception handler then calls `pset!' again, which
> > > raises an exception, and kills the thread without setting the promise's
> > > value.
> > >
> > > Our solution is to have `run' block on a channel until `p' is fully
> > > initialized. I'll push the fix.
> > >
> > > Vincent
> > >
> > >
> > > [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
> > > actual exception. The thread gets killed some other way.
> > >
> > >
> > > At Thu, 2 May 2013 22:27:14 -0400,
> > > Asumu Takikawa wrote:
> > > >
> > > > On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
> > > > > This produces a promise error on every third or fifth run or so
> for me.
> > > > > Commenting out the #:when line makes it work, very oddly.
> > > >
> > > > Tried it on another machine, the #:when line didn't matter there.
> Also,
> > > > I can reproduce this more reliably on a machine with fewer cores.
> > > >
> > > > Cheers,
> > > > Asumu
> > > > _
> > > >   Racket Developers list:
> > > >   http://lists.racket-lang.org/dev
> > > _
> > >   Racket Developers list:
> > >   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Eli Barzilay]

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 think that introduces another race condition.
> 
> If the thread is forced before the `pset!', then `force' would
> return #f (line 107 of racket/promise.rkt), since the value inside
> the `promise/thread' is not a thread.

But this can't happen because `delay/thread' won't return with the
broken promise until after the `pset!' fixed it.

(Even code in the input thunk will not be able to try to force itself
without having itself accessible as a value.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Vincent St-Amour]

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 construct.
> 
> At Fri, 03 May 2013 11:45:38 -0400, 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-exception-handler
> >(lambda (e) (pset! p (make-reraise e)) (kill-thread 
> > (current-thread)))
> >(lambda () (pset! p (call-with-values thunk list)
> > (define p
> >   (make-promise/thread
> >(make-running-thread
> > (object-name thunk)
> > (thread run
> > p))
> > 
> > `run' depends on `p', and vice versa. The `run' thread may start
> > executing *before* `p' is actually defined. This causes `pset!' (which
> > is just promise mutation) to mutate `#', which raises an
> > exception[1]. The exception handler then calls `pset!' again, which
> > raises an exception, and kills the thread without setting the promise's
> > value.
> > 
> > Our solution is to have `run' block on a channel until `p' is fully
> > initialized. I'll push the fix.
> > 
> > Vincent
> > 
> > 
> > [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
> > actual exception. The thread gets killed some other way.
> > 
> > 
> > At Thu, 2 May 2013 22:27:14 -0400,
> > Asumu Takikawa wrote:
> > > 
> > > On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
> > > > This produces a promise error on every third or fifth run or so for me.
> > > > Commenting out the #:when line makes it work, very oddly.
> > > 
> > > Tried it on another machine, the #:when line didn't matter there. Also,
> > > I can reproduce this more reliably on a machine with fewer cores.
> > > 
> > > Cheers,
> > > Asumu
> > > _
> > >   Racket Developers list:
> > >   http://lists.racket-lang.org/dev
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Vincent St-Amour]

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 thunk)
> >   (let ()
> > (define (run)
> >   (call-with-exception-handler
> >(lambda (e) (pset! p (make-reraise e)) (kill-thread 
> > (current-thread)))
> >(lambda () (pset! p (call-with-values thunk list)
> > (define p
> >   (make-promise/thread
> >(make-running-thread
> > (object-name thunk)
> > (thread run
> > p))
> > [...]
> > Our solution is to have `run' block on a channel until `p' is fully
> > initialized. I'll push the fix.
> 
> I haven't looked at the code recently, but I think that something
> along these lines can work instead of some explicit syncing:
> 
> (define (delay/thread thunk)
>   (let ()
> (define p (make-promise/thread #f))
> (pset! p (make-running-thread (thread (λ() ...same...
> p))

I think that introduces another race condition.

If the thread is forced before the `pset!', then `force' would return #f
(line 107 of racket/promise.rkt), since the value inside the `promise/thread'
is not a thread.

Vincent

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Matthew Flatt]

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. 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)) (kill-thread 
> (current-thread)))
>(lambda () (pset! p (call-with-values thunk list)
> (define p
>   (make-promise/thread
>(make-running-thread
> (object-name thunk)
> (thread run
> p))
> 
> `run' depends on `p', and vice versa. The `run' thread may start
> executing *before* `p' is actually defined. This causes `pset!' (which
> is just promise mutation) to mutate `#', which raises an
> exception[1]. The exception handler then calls `pset!' again, which
> raises an exception, and kills the thread without setting the promise's
> value.
> 
> Our solution is to have `run' block on a channel until `p' is fully
> initialized. I'll push the fix.
> 
> Vincent
> 
> 
> [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
> actual exception. The thread gets killed some other way.
> 
> 
> At Thu, 2 May 2013 22:27:14 -0400,
> Asumu Takikawa wrote:
> > 
> > On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
> > > This produces a promise error on every third or fifth run or so for me.
> > > Commenting out the #:when line makes it work, very oddly.
> > 
> > Tried it on another machine, the #:when line didn't matter there. Also,
> > I can reproduce this more reliably on a machine with fewer cores.
> > 
> > Cheers,
> > Asumu
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Eli Barzilay]

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-exception-handler
>(lambda (e) (pset! p (make-reraise e)) (kill-thread 
> (current-thread)))
>(lambda () (pset! p (call-with-values thunk list)
> (define p
>   (make-promise/thread
>(make-running-thread
> (object-name thunk)
> (thread run
> p))
> [...]
> Our solution is to have `run' block on a channel until `p' is fully
> initialized. I'll push the fix.

I haven't looked at the code recently, but I think that something
along these lines can work instead of some explicit syncing:

(define (delay/thread thunk)
  (let ()
(define p (make-promise/thread #f))
(pset! p (make-running-thread (thread (λ() ...same...
p))


-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR tests sometimes fail with a promise error

[Vincent St-Amour]

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)) (kill-thread 
(current-thread)))
   (lambda () (pset! p (call-with-values thunk list)
(define p
  (make-promise/thread
   (make-running-thread
(object-name thunk)
(thread run
p))

`run' depends on `p', and vice versa. The `run' thread may start
executing *before* `p' is actually defined. This causes `pset!' (which
is just promise mutation) to mutate `#', which raises an
exception[1]. The exception handler then calls `pset!' again, which
raises an exception, and kills the thread without setting the promise's
value.

Our solution is to have `run' block on a channel until `p' is fully
initialized. I'll push the fix.

Vincent


[1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
actual exception. The thread gets killed some other way.


At Thu, 2 May 2013 22:27:14 -0400,
Asumu Takikawa wrote:
> 
> On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
> > This produces a promise error on every third or fifth run or so for me.
> > Commenting out the #:when line makes it work, very oddly.
> 
> Tried it on another machine, the #:when line didn't matter there. Also,
> I can reproduce this more reliably on a machine with fewer cores.
> 
> Cheers,
> Asumu
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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 it as
> the entire pattern. For example, the following should be an illegal use of
> else:
>
>   (match x [(list 'if test then else) ___])
>
> Right?
>
> (BTW, I may have written exactly the code above. I need to check.)
>
>
I would not midn if that bound 'else' as a variable.

The only change I'd request is that when 'else' is the entire pattern,
since that's the situation that's confusing to people not language lawyers.

Robby



> Ryan
>
>
>  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
>> 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 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: [racket-dev] else clauses: possible change to match?
>>
>>
>> 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?
>>
>>
>>
>> Robby
>>
>> On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote:
>>
>>
>> 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, 2013 at 10:42 AM, Robby Findler
>> < ro...@eecs.northwestern.edu  > wrote:
>>  > 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
>>  >> < ro...@eecs.northwestern.edu  > 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 trouble than it is worth, due to backwards compatibility
>> concerns,
>>  >> > which is why I think it is worth raising here to see what
>> others think.
>>  >>
>>  >> I'm happy to make this change to `match`, except that I've heard
>>  >> Matthew say that he would have used a keyword for `else` in
>> `cond` if
>>  >> he had it to do over again, and I wouldn't want to change one
>> way, and
>>  >> then change back.
>>  >>
>>  >> Sam
>>
>> _
>>Racket Developers list:
>> http://lists.racket-lang.org/**dev 
>>
>>
>>
>> _
>>Racket Developers list:
>>http://lists.racket-lang.org/**dev 
>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Ryan Culpepper]

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 illegal 
use of else:


  (match x [(list 'if test then else) ___])

Right?

(BTW, I may have written exactly the code above. I need to check.)

Ryan



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
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 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] else clauses: possible change to match?


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?



Robby

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote:


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, 2013 at 10:42 AM, Robby Findler
< ro...@eecs.northwestern.edu  > wrote:
 > 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
 >> < ro...@eecs.northwestern.edu  > 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 trouble than it is worth, due to backwards compatibility
concerns,
 >> > which is why I think it is worth raising here to see what
others think.
 >>
 >> I'm happy to make this change to `match`, except that I've heard
 >> Matthew say that he would have used a keyword for `else` in
`cond` if
 >> he had it to do over again, and I wouldn't want to change one
way, and
 >> then change back.
 >>
 >> Sam

_
   Racket Developers list:
http://lists.racket-lang.org/dev



_
   Racket Developers list:
   http://lists.racket-lang.org/dev



_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[J. Ian Johnson]

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 in ~a" else '#,stx)])]))

A macro is easy enough to change. I'm not saying to stay the backwards 
incompatible change because of me (and I don't use "else" like this anymore). 
I'm just noting that this seems like a plausible pattern out there.

-Ian
- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "Robby Findler" , dev@racket-lang.org, "Sam 
Tobin-Hochstadt" 
Sent: Friday, May 3, 2013 11:12:34 AM GMT -05:00 US/Canada Eastern
Subject: Re: else clauses: possible change to match?

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 have done it too. 
This could annoy them. 
-Ian 
- Original Message - 
From: "Robby Findler" < ro...@eecs.northwestern.edu > 
To: "Sam Tobin-Hochstadt" < sa...@ccs.neu.edu > 
Cc: dev@racket-lang.org 
Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] else clauses: possible change to match? 


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? 



Robby 

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 


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, 2013 at 10:42 AM, Robby Findler 
< ro...@eecs.northwestern.edu > wrote: 
> 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 
>> < ro...@eecs.northwestern.edu > 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 trouble than it is worth, due to backwards compatibility concerns, 
>> > which is why I think it is worth raising here to see what others think. 
>> 
>> I'm happy to make this change to `match`, except that I've heard 
>> Matthew say that he would have used a keyword for `else` in `cond` if 
>> he had it to do over again, and I wouldn't want to change one way, and 
>> then change back. 
>> 
>> Sam 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Eli Barzilay]

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 people will need to convert uses
`match', but that'll be minor compared to `cond'.


A few minutes ago, 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
> have done it too. This could annoy them.

Do you have an actual use that would *break*?  That is, something like

(match x ... [else else])

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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 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 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] else clauses: possible change to match?
>
>
> 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?
>
>
>
> Robby
>
> On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote:
>
>
> 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, 2013 at 10:42 AM, Robby Findler
> < ro...@eecs.northwestern.edu  > wrote:
> > 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
> >> < ro...@eecs.northwestern.edu  > 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 trouble than it is worth, due to backwards compatibility
> concerns,
> >> > which is why I think it is worth raising here to see what others
> think.
> >>
> >> I'm happy to make this change to `match`, except that I've heard
> >> Matthew say that he would have used a keyword for `else` in `cond` if
> >> he had it to do over again, and I wouldn't want to change one way, and
> >> then change back.
> >>
> >> Sam
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[J. Ian Johnson]

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 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] else clauses: possible change to match?


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? 



Robby 

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 


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, 2013 at 10:42 AM, Robby Findler 
< ro...@eecs.northwestern.edu > wrote: 
> 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 
>> < ro...@eecs.northwestern.edu > 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 trouble than it is worth, due to backwards compatibility concerns, 
>> > which is why I think it is worth raising here to see what others think. 
>> 
>> I'm happy to make this change to `match`, except that I've heard 
>> Matthew say that he would have used a keyword for `else` in `cond` if 
>> he had it to do over again, and I wouldn't want to change one way, and 
>> then change back. 
>> 
>> Sam 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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?

Robby

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote:

> 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, 2013 at 10:42 AM, Robby Findler
> > wrote:
> > 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:
> >> >
> >> > 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 trouble than it is worth, due to backwards compatibility
> concerns,
> >> > which is why I think it is worth raising here to see what others
> think.
> >>
> >> I'm happy to make this change to `match`, except that I've heard
> >> Matthew say that he would have used a keyword for `else` in `cond` if
> >> he had it to do over again, and I wouldn't want to change one way, and
> >> then change back.
> >>
> >> Sam
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Sam Tobin-Hochstadt]

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, 2013 at 10:42 AM, Robby Findler
 wrote:
> 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:
>> >
>> > 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 trouble than it is worth, due to backwards compatibility concerns,
>> > which is why I think it is worth raising here to see what others think.
>>
>> I'm happy to make this change to `match`, except that I've heard
>> Matthew say that he would have used a keyword for `else` in `cond` if
>> he had it to do over again, and I wouldn't want to change one way, and
>> then change back.
>>
>> Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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:
> >
> > 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 trouble than it is worth, due to backwards compatibility concerns,
> > which is why I think it is worth raising here to see what others think.
>
> I'm happy to make this change to `match`, except that I've heard
> Matthew say that he would have used a keyword for `else` in `cond` if
> he had it to do over again, and I wouldn't want to change one way, and
> then change back.
>
> Sam
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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 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 around the epsilons) for a
> change in else/match too, as I hardly see someone binding else in match
> intentionally, and hoping to get away with it.
> At best, some old buggy programs will magically start working ;)
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Sam Tobin-Hochstadt]

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 trouble than it is worth, due to backwards compatibility concerns,
> which is why I think it is worth raising here to see what others think.

I'm happy to make this change to `match`, except that I've heard
Matthew say that he would have used a keyword for `else` in `cond` if
he had it to do over again, and I wouldn't want to change one way, and
then change back.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Laurent]

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 around the epsilons) for a
change in else/match too, as I hardly see someone binding else in match
intentionally, and hoping to get away with it.
At best, some old buggy programs will magically start working ;)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Robby Findler]

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 like warnings that are basically admitting
weaknesses in the language design Of course, changing a core thing like
that may be more trouble than it is worth, due to backwards compatibility
concerns, which is why I think it is worth raising here to see what others
think.

Alternatively, we could revisit 'else' in racket2 and leave racket alone.

Robby

On Friday, May 3, 2013, Laurent wrote:

> 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 reason
> for that?)
>
> Laurent
>
>
> On Fri, May 3, 2013 at 3:39 PM, Robby Findler 
>  'ro...@eecs.northwestern.edu');>
> > wrote:
>
>> [ 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
>>   [`(λ (,x) ,e)
>>(loop e)]
>>   [`(,e1 ,e2)
>>(loop e1)
>>(loop e2)]
>>   [(? symbol?) (void)]
>>   [else
>>(cond
>>  [(member e literals)
>>   (void)]
>>  [else
>>   (set! literals (cons e literals))])]))
>>   literals)
>>
>> (module+ test
>>   (require rackunit)
>>   (check-equal? (find-literals '(λ (x) x)) '())
>>   (check-equal? (find-literals '((λ (x) x) 1)) '(1))
>>   (check-equal? (find-literals '((λ (x) x) #f)) '(#f)))
>>
>>
>> Hint: the last test case fails. Second hint: if you switch it to use
>> sets, it starts working. Third hint: this isn't about lists. :)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The bug is that 'else' is treated as a variable in match, so it gets
>> bound to #f, which shadows the else in the cond which  is confusing.
>>
>>  So, how about making match treat else specially?
>>
>>
>> I don't ask this completely from outer space; there was a bug in Redex's
>> random generation that was caused exactly by this shadowing of else.
>>
>> Robby
>>
>>
>>
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[Laurent]

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 reason for
that?)

Laurent


On Fri, May 3, 2013 at 3:39 PM, Robby Findler
wrote:

> [ 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
>   [`(λ (,x) ,e)
>(loop e)]
>   [`(,e1 ,e2)
>(loop e1)
>(loop e2)]
>   [(? symbol?) (void)]
>   [else
>(cond
>  [(member e literals)
>   (void)]
>  [else
>   (set! literals (cons e literals))])]))
>   literals)
>
> (module+ test
>   (require rackunit)
>   (check-equal? (find-literals '(λ (x) x)) '())
>   (check-equal? (find-literals '((λ (x) x) 1)) '(1))
>   (check-equal? (find-literals '((λ (x) x) #f)) '(#f)))
>
>
> Hint: the last test case fails. Second hint: if you switch it to use sets,
> it starts working. Third hint: this isn't about lists. :)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The bug is that 'else' is treated as a variable in match, so it gets bound
> to #f, which shadows the else in the cond which  is confusing.
>
>  So, how about making match treat else specially?
>
>
> I don't ask this completely from outer space; there was a bug in Redex's
> random generation that was caused exactly by this shadowing of else.
>
> Robby
>
>
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] else clauses: possible change to match?

[Robby Findler]

[ 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
  [`(λ (,x) ,e)
   (loop e)]
  [`(,e1 ,e2)
   (loop e1)
   (loop e2)]
  [(? symbol?) (void)]
  [else
   (cond
 [(member e literals)
  (void)]
 [else
  (set! literals (cons e literals))])]))
  literals)

(module+ test
  (require rackunit)
  (check-equal? (find-literals '(λ (x) x)) '())
  (check-equal? (find-literals '((λ (x) x) 1)) '(1))
  (check-equal? (find-literals '((λ (x) x) #f)) '(#f)))


Hint: the last test case fails. Second hint: if you switch it to use sets,
it starts working. Third hint: this isn't about lists. :)

































The bug is that 'else' is treated as a variable in match, so it gets bound
to #f, which shadows the else in the cond which  is confusing.

So, how about making match treat else specially?


I don't ask this completely from outer space; there was a bug in Redex's
random generation that was caused exactly by this shadowing of else.

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev