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

[Robby Findler]

Oh, right! Thanks! I'll push something that explicitly mentions underscore
and adjust the elses to use underscores.

Robby


On Sat, May 4, 2013 at 9:09 PM, Greg Hendershott
wrote:

> There will be people who see the long BNF for match in the Reference,
> and flee to the Guide to try to learn by example instead. Even when
> they later do read the Reference carefully, they'll be left with first
> impressions of idioms from the Guide.
>
> (I might be one of those people. Cough.)
>
> The Guide  uses `else`
> in a couple examples.
>
> Also, I somehow got the idea that `(var x)` was the only way to do
> what `else` can do by accident. So I don't _think_ I have any code
> that's buggy this way, or, which would break if the change were made,
> either way. I think.
>
> Until I saw your email I didn't appreciate why it would make sense to
> use `_`. Going forward I will.
>
>
> On Fri, May 3, 2013 at 9:39 AM, 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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Robby Findler]

On Sat, May 4, 2013 at 9:04 PM, Jon Zeppieri  wrote:

> On Sat, May 4, 2013 at 9:46 PM, John Gateley  wrote:
> >
> >
> > On 5/4/2013 8:26 PM, Robby Findler wrote:
> >> Some characters have the equal? implies eq? property (the ASCII ones and
> >> maybe a few more, I'm not sure) and some don't (#\λ for example).
> >
> >
> > Excellent point, and now I understand your efficiency comment better.
> > There's a definite parallel between bignums and multi-byte characters.
>
> I disagree. There is a parallel between fixnums and characters,
> multi-byte or not, because char->integer always returns a fixnum and
> integer->char is only defined on a subset of the fixnums.
>
> However, I don't think this is any kind of knock-down argument in
> favor of eq?-ness for characters. It's just a nice-to-have.
>
>
FWIW, I think that if you had real code that would benefit from this it
would be more compelling; our nice-to-have list is already pretty long. :)


> Robby, after looking at the macros in scheme.h, I understand now why
> it would be a big job. I hadn't realized that all of the unique
> objects (like null, EOF, void, and so forth) were all represented as
> pointers to statically allocated structs. So there's a basic
> assumption that if a value doesn't satisfy SCHEME_INTP(), then it's a
> pointer.
>

Yeah, and don't forget the JIT, too

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

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

[Greg Hendershott]

There will be people who see the long BNF for match in the Reference,
and flee to the Guide to try to learn by example instead. Even when
they later do read the Reference carefully, they'll be left with first
impressions of idioms from the Guide.

(I might be one of those people. Cough.)

The Guide  uses `else`
in a couple examples.

Also, I somehow got the idea that `(var x)` was the only way to do
what `else` can do by accident. So I don't _think_ I have any code
that's buggy this way, or, which would break if the change were made,
either way. I think.

Until I saw your email I didn't appreciate why it would make sense to
use `_`. Going forward I will.


On Fri, May 3, 2013 at 9:39 AM, 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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Jon Zeppieri]

On Sat, May 4, 2013 at 9:46 PM, John Gateley  wrote:
>
>
> On 5/4/2013 8:26 PM, Robby Findler wrote:
>> Some characters have the equal? implies eq? property (the ASCII ones and
>> maybe a few more, I'm not sure) and some don't (#\λ for example).
>
>
> Excellent point, and now I understand your efficiency comment better.
> There's a definite parallel between bignums and multi-byte characters.

I disagree. There is a parallel between fixnums and characters,
multi-byte or not, because char->integer always returns a fixnum and
integer->char is only defined on a subset of the fixnums.

However, I don't think this is any kind of knock-down argument in
favor of eq?-ness for characters. It's just a nice-to-have.

Robby, after looking at the macros in scheme.h, I understand now why
it would be a big job. I hadn't realized that all of the unique
objects (like null, EOF, void, and so forth) were all represented as
pointers to statically allocated structs. So there's a basic
assumption that if a value doesn't satisfy SCHEME_INTP(), then it's a
pointer.

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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[John Gateley]

On 5/4/2013 8:26 PM, Robby Findler wrote:


But chars are not mutable so the rule "mutate one and change the other"
doesn't apply. So they might be eq? or might not. Similarly with
numbers. In the case of numbers with the current Racket, if you have an
exact integer that is close enough to zero, then the same value
(according to equal? (and 3rd grade math class))  will be eq?, but exact
integers that are far enough from zero will be equal? without being eq?.

Some characters have the equal? implies eq? property (the ASCII ones and
maybe a few more, I'm not sure) and some don't (#\λ for example).


Excellent point, and now I understand your efficiency comment better.
There's a definite parallel between bignums and multi-byte characters.



No worries! And being racketeer is more of a state of mind than any
great expertise, IMO. Your name has come up in my hearing before and I,
for one, would be delighted to consider you a racketeer.


Thank you very kindly. I've been having a great time seeing what has
changed, there are some very cool things going on, very creative
and forward looking.

John

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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Greg Hendershott]

I think this is a great idea.

When I learned Scheme a few years ago, the prospect of juggling three
kinds of equality was a surprise.

I felt like Kevin Kline's character in A Fish Called Wanda, who kept
asking, "What was the middle one?"

It turned out only two have really mattered practically, for me. It
probably would have helped me if the docs said, "Tip: You may never
use eqv and friends".

Even better would be eliminating "the middle one".


On Sat, May 4, 2013 at 11:57 AM, Jon Zeppieri  wrote:
> Since incompatible future changes seem to be coming up a lot, I
> thought I'd add one more. What do the members of this list think of
> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
> etc.)?
>
> (Along with this change, it would be nice if characters could all be
> immediately represented, so that those with equal code points would be
> eq? RIght now, all unicode code points can be encoded in 22 bits, I
> think. I'm not so familiar with racket's current representation of
> characters, but I figure that they could easily be fit into a single
> machine word on 64-bit builds. I don't know how difficult it would be
> on 32-bit builds. And, of course, there's no guarantee that the number
> of code points won't increase significantly.)
>
> Alternatively (and following Sam's line of thought from [1]), eqv?
> could be extended to cover all of racket's immutable data structures.
> In this case eqv? should also be made generic so that user-defined
> immutable data structures can use it, as well.
>
>
> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Robby Findler]

On Sat, May 4, 2013 at 8:17 PM, John Gateley  wrote:

> From the docs:
>
> >>>
> An impersonator is a wrapper for a value where the wrapper redirects some
> of the value’s operations. Impersonators apply only to procedures,
> structures for which an accessor or mutator is available, structure types,
> hash tables, vectors, boxes, and prompt tags. An impersonator is equal? to
> the original value, but not eq? to the original value.
> <<<
>
> This is what I was saying below: chaperoned or impersonated objects
> are equal? but not eq?. If two objects really are the same - defined
> as side-effecting one also side-effects the other - then they are
> eq? as well as equal?
>
>
If you take this definition of "same" (mutating one mutates the other),
then I think chaperoned values have to qualify, but they won't be eq?.

Here's an example:

#lang racket
(define v1 (make-vector 10 0))
(define (do-nothing-interpose-proc v i o) o)
(define v2 (chaperone-vector v1 do-nothing-interpose-proc
do-nothing-interpose-proc))
(eq? v1 v2) ;; = #f
(vector-ref v1 2) ;; = 0
(vector-set! v2 2 11)
(vector-ref v1 2) ;; = 11




> Chars don't have accessors or mutators, so should be eq?.
>
>
But chars are not mutable so the rule "mutate one and change the other"
doesn't apply. So they might be eq? or might not. Similarly with numbers.
In the case of numbers with the current Racket, if you have an exact
integer that is close enough to zero, then the same value (according to
equal? (and 3rd grade math class))  will be eq?, but exact integers that
are far enough from zero will be equal? without being eq?.

Some characters have the equal? implies eq? property (the ASCII ones and
maybe a few more, I'm not sure) and some don't (#\λ for example).


> Again, just my 2cents. I'm not a racket expert (racketeer?)
>
>
No worries! And being racketeer is more of a state of mind than any great
expertise, IMO. Your name has come up in my hearing before and I, for one,
would be delighted to consider you a racketeer.

Robby


> John
>
>
>
> On 5/4/2013 7:50 PM, Eric Dobson wrote:
>
>> The mutability argument does not hold in Racket. non eq? things can be
>> mutated and affect each other using chaperones and impersonators.
>>
>> On Sat, May 4, 2013 at 5:27 PM, John Gateley  wrote:
>>
>>> Personal opinion: performance is a dangerous motivator. Yes, it is
>>> a necessity, but it is often abused as a reason to do something.
>>>
>>> There's a semantic difference between eq? and equal? from the point
>>> of view of mutability. Two objects are eq? if modifying one also
>>> modifies the other. They are equal? but not eq? if they are the
>>> "same", but modifying one will not modify the other.
>>>
>>> I know I'm in a minority here, but I like mutable objects, and
>>> this distinction between eq? and equal? is important.
>>>
>>> For characters, the mutability argument fails: I don't think
>>> characters, even multi-byte characters, should be mutable.
>>> Thus, they should be eq?.
>>>
>>> Just my 2 cents,
>>>
>>> John
>>>
>>>
>>> On 5/4/2013 12:06 PM, Robby Findler wrote:
>>>

 Well, I'm not sure that I buy that motivation, since I think decisions
 about what should be eq? to what should be driven by performance (and
 eq? should only be used for performance) but lets put that aside.

 There are some unused bits in Racket's runtime representation of values,
 namely when a value's bit representation ends in 10, we know that it
 isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer
 (since pointers have end with 00 (at least)), so I think that means that
 we could have all of the unicode code points represented in a way that
 requires no allocation (currently, iiuc, the ASCII characters are just
 pre-allocated at the runtime startup; they require no allocation because
 you always just get the same pointer).

 This is a pretty big change, however, so I'm not sure it would be worth
 it.

 Robby



 On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri >>> > wrote:

  Something about my response below has been bothering me, and I
 think
  I know what it is: the correspondence between characters and the
  fixnums that represent their code points seems -- how to put it? --
  more complete if it extends to their equality predicates. So, yeah,
  in addition to performance, there's an aesthetic motivation, too.

  On May 4, 2013, at 12:03 PM, Jon Zeppieri >>>  > wrote:

   > Just for performance. No other reason.
   >
   > -Jon
   >
   > On Sat, May 4, 2013 at 12:01 PM, Robby Findler
   > >>>  >
 wrote:
   >> I'm curious: why do you want all characters to be eq? to each
  other instead
   >> of just equal??
   >>
   >> Robby
>>

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[John Gateley]

From the docs:

>>>
An impersonator is a wrapper for a value where the wrapper redirects 
some of the value’s operations. Impersonators apply only to procedures, 
structures for which an accessor or mutator is available, structure 
types, hash tables, vectors, boxes, and prompt tags. An impersonator is 
equal? to the original value, but not eq? to the original value.

<<<

This is what I was saying below: chaperoned or impersonated objects
are equal? but not eq?. If two objects really are the same - defined
as side-effecting one also side-effects the other - then they are
eq? as well as equal?

Chars don't have accessors or mutators, so should be eq?.

Again, just my 2cents. I'm not a racket expert (racketeer?)

John


On 5/4/2013 7:50 PM, Eric Dobson wrote:

The mutability argument does not hold in Racket. non eq? things can be
mutated and affect each other using chaperones and impersonators.

On Sat, May 4, 2013 at 5:27 PM, John Gateley  wrote:

Personal opinion: performance is a dangerous motivator. Yes, it is
a necessity, but it is often abused as a reason to do something.

There's a semantic difference between eq? and equal? from the point
of view of mutability. Two objects are eq? if modifying one also
modifies the other. They are equal? but not eq? if they are the
"same", but modifying one will not modify the other.

I know I'm in a minority here, but I like mutable objects, and
this distinction between eq? and equal? is important.

For characters, the mutability argument fails: I don't think
characters, even multi-byte characters, should be mutable.
Thus, they should be eq?.

Just my 2 cents,

John


On 5/4/2013 12:06 PM, Robby Findler wrote:


Well, I'm not sure that I buy that motivation, since I think decisions
about what should be eq? to what should be driven by performance (and
eq? should only be used for performance) but lets put that aside.

There are some unused bits in Racket's runtime representation of values,
namely when a value's bit representation ends in 10, we know that it
isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer
(since pointers have end with 00 (at least)), so I think that means that
we could have all of the unicode code points represented in a way that
requires no allocation (currently, iiuc, the ASCII characters are just
pre-allocated at the runtime startup; they require no allocation because
you always just get the same pointer).

This is a pretty big change, however, so I'm not sure it would be worth
it.

Robby



On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri mailto:zeppi...@gmail.com>> wrote:

 Something about my response below has been bothering me, and I think
 I know what it is: the correspondence between characters and the
 fixnums that represent their code points seems -- how to put it? --
 more complete if it extends to their equality predicates. So, yeah,
 in addition to performance, there's an aesthetic motivation, too.

 On May 4, 2013, at 12:03 PM, Jon Zeppieri mailto:zeppi...@gmail.com>> wrote:

  > Just for performance. No other reason.
  >
  > -Jon
  >
  > On Sat, May 4, 2013 at 12:01 PM, Robby Findler
  > mailto:ro...@eecs.northwestern.edu>> wrote:
  >> I'm curious: why do you want all characters to be eq? to each
 other instead
  >> of just equal??
  >>
  >> Robby
  >>
  >>
  >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri
 mailto:zeppi...@gmail.com>> wrote:
  >>>
  >>> Since incompatible future changes seem to be coming up a lot, I
  >>> thought I'd add one more. What do the members of this list think
of
  >>> removing eqv? all of its associated machinery (e.g., memv,
hasheqv,
  >>> etc.)?
  >>>
  >>> (Along with this change, it would be nice if characters could
 all be
  >>> immediately represented, so that those with equal code points
 would be
  >>> eq? RIght now, all unicode code points can be encoded in 22 bits,
I
  >>> think. I'm not so familiar with racket's current representation
of
  >>> characters, but I figure that they could easily be fit into a
 single
  >>> machine word on 64-bit builds. I don't know how difficult it
 would be
  >>> on 32-bit builds. And, of course, there's no guarantee that the
 number
  >>> of code points won't increase significantly.)
  >>>
  >>> Alternatively (and following Sam's line of thought from [1]),
eqv?
  >>> could be extended to cover all of racket's immutable data
 structures.
  >>> In this case eqv? should also be made generic so that
user-defined
  >>> immutable data structures can use it, as well.
  >>>
  >>>
  >>> [1]
 http://lists.racket-lang.org/users/archive/2013-April/057510.html
  >>> _
  >>>  Racket Developers list:
  >>> http://lists.racket-lang.org/dev
  >>
  >>




_
Racket Developers list:
http://lis

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Eric Dobson]

The mutability argument does not hold in Racket. non eq? things can be
mutated and affect each other using chaperones and impersonators.

On Sat, May 4, 2013 at 5:27 PM, John Gateley  wrote:
> Personal opinion: performance is a dangerous motivator. Yes, it is
> a necessity, but it is often abused as a reason to do something.
>
> There's a semantic difference between eq? and equal? from the point
> of view of mutability. Two objects are eq? if modifying one also
> modifies the other. They are equal? but not eq? if they are the
> "same", but modifying one will not modify the other.
>
> I know I'm in a minority here, but I like mutable objects, and
> this distinction between eq? and equal? is important.
>
> For characters, the mutability argument fails: I don't think
> characters, even multi-byte characters, should be mutable.
> Thus, they should be eq?.
>
> Just my 2 cents,
>
> John
>
>
> On 5/4/2013 12:06 PM, Robby Findler wrote:
>>
>> Well, I'm not sure that I buy that motivation, since I think decisions
>> about what should be eq? to what should be driven by performance (and
>> eq? should only be used for performance) but lets put that aside.
>>
>> There are some unused bits in Racket's runtime representation of values,
>> namely when a value's bit representation ends in 10, we know that it
>> isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer
>> (since pointers have end with 00 (at least)), so I think that means that
>> we could have all of the unicode code points represented in a way that
>> requires no allocation (currently, iiuc, the ASCII characters are just
>> pre-allocated at the runtime startup; they require no allocation because
>> you always just get the same pointer).
>>
>> This is a pretty big change, however, so I'm not sure it would be worth
>> it.
>>
>> Robby
>>
>>
>>
>> On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri > > wrote:
>>
>> Something about my response below has been bothering me, and I think
>> I know what it is: the correspondence between characters and the
>> fixnums that represent their code points seems -- how to put it? --
>> more complete if it extends to their equality predicates. So, yeah,
>> in addition to performance, there's an aesthetic motivation, too.
>>
>> On May 4, 2013, at 12:03 PM, Jon Zeppieri > > wrote:
>>
>>  > Just for performance. No other reason.
>>  >
>>  > -Jon
>>  >
>>  > On Sat, May 4, 2013 at 12:01 PM, Robby Findler
>>  > > > wrote:
>>  >> I'm curious: why do you want all characters to be eq? to each
>> other instead
>>  >> of just equal??
>>  >>
>>  >> Robby
>>  >>
>>  >>
>>  >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri
>> mailto:zeppi...@gmail.com>> wrote:
>>  >>>
>>  >>> Since incompatible future changes seem to be coming up a lot, I
>>  >>> thought I'd add one more. What do the members of this list think
>> of
>>  >>> removing eqv? all of its associated machinery (e.g., memv,
>> hasheqv,
>>  >>> etc.)?
>>  >>>
>>  >>> (Along with this change, it would be nice if characters could
>> all be
>>  >>> immediately represented, so that those with equal code points
>> would be
>>  >>> eq? RIght now, all unicode code points can be encoded in 22 bits,
>> I
>>  >>> think. I'm not so familiar with racket's current representation
>> of
>>  >>> characters, but I figure that they could easily be fit into a
>> single
>>  >>> machine word on 64-bit builds. I don't know how difficult it
>> would be
>>  >>> on 32-bit builds. And, of course, there's no guarantee that the
>> number
>>  >>> of code points won't increase significantly.)
>>  >>>
>>  >>> Alternatively (and following Sam's line of thought from [1]),
>> eqv?
>>  >>> could be extended to cover all of racket's immutable data
>> structures.
>>  >>> In this case eqv? should also be made generic so that
>> user-defined
>>  >>> immutable data structures can use it, as well.
>>  >>>
>>  >>>
>>  >>> [1]
>> http://lists.racket-lang.org/users/archive/2013-April/057510.html
>>  >>> _
>>  >>>  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] racket2 suggestion: removing (or extending) eqv?

[John Gateley]

Personal opinion: performance is a dangerous motivator. Yes, it is
a necessity, but it is often abused as a reason to do something.

There's a semantic difference between eq? and equal? from the point
of view of mutability. Two objects are eq? if modifying one also
modifies the other. They are equal? but not eq? if they are the
"same", but modifying one will not modify the other.

I know I'm in a minority here, but I like mutable objects, and
this distinction between eq? and equal? is important.

For characters, the mutability argument fails: I don't think
characters, even multi-byte characters, should be mutable.
Thus, they should be eq?.

Just my 2 cents,

John

On 5/4/2013 12:06 PM, Robby Findler wrote:

Well, I'm not sure that I buy that motivation, since I think decisions
about what should be eq? to what should be driven by performance (and
eq? should only be used for performance) but lets put that aside.

There are some unused bits in Racket's runtime representation of values,
namely when a value's bit representation ends in 10, we know that it
isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer
(since pointers have end with 00 (at least)), so I think that means that
we could have all of the unicode code points represented in a way that
requires no allocation (currently, iiuc, the ASCII characters are just
pre-allocated at the runtime startup; they require no allocation because
you always just get the same pointer).

This is a pretty big change, however, so I'm not sure it would be worth it.

Robby



On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri mailto:zeppi...@gmail.com>> wrote:

Something about my response below has been bothering me, and I think
I know what it is: the correspondence between characters and the
fixnums that represent their code points seems -- how to put it? --
more complete if it extends to their equality predicates. So, yeah,
in addition to performance, there's an aesthetic motivation, too.

On May 4, 2013, at 12:03 PM, Jon Zeppieri mailto:zeppi...@gmail.com>> wrote:

 > Just for performance. No other reason.
 >
 > -Jon
 >
 > On Sat, May 4, 2013 at 12:01 PM, Robby Findler
 > mailto:ro...@eecs.northwestern.edu>> wrote:
 >> I'm curious: why do you want all characters to be eq? to each
other instead
 >> of just equal??
 >>
 >> Robby
 >>
 >>
 >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri
mailto:zeppi...@gmail.com>> wrote:
 >>>
 >>> Since incompatible future changes seem to be coming up a lot, I
 >>> thought I'd add one more. What do the members of this list think of
 >>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
 >>> etc.)?
 >>>
 >>> (Along with this change, it would be nice if characters could
all be
 >>> immediately represented, so that those with equal code points
would be
 >>> eq? RIght now, all unicode code points can be encoded in 22 bits, I
 >>> think. I'm not so familiar with racket's current representation of
 >>> characters, but I figure that they could easily be fit into a
single
 >>> machine word on 64-bit builds. I don't know how difficult it
would be
 >>> on 32-bit builds. And, of course, there's no guarantee that the
number
 >>> of code points won't increase significantly.)
 >>>
 >>> Alternatively (and following Sam's line of thought from [1]), eqv?
 >>> could be extended to cover all of racket's immutable data
structures.
 >>> In this case eqv? should also be made generic so that user-defined
 >>> immutable data structures can use it, as well.
 >>>
 >>>
 >>> [1]
http://lists.racket-lang.org/users/archive/2013-April/057510.html
 >>> _
 >>>  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] racket2 suggestion: removing (or extending) eqv?

[Eli Barzilay]

Three hours ago, Jon Zeppieri wrote:
> Since incompatible future changes seem to be coming up a lot, I
> thought I'd add one more. What do the members of this list think of
> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
> etc.)?

+1, but unrelated to performance or whatever: I always viewed `eqv?'
as some kind of a semi-efficient-but-try-to-do-the-right-thing tool,
or perhaps as a tool that is kind of like `eq?' but more robust wrt
semantics (for some vague meaning of "semantics").  Without some
standard to think about, and without worrying about other
implementations, is there some use for `eqv?' that doesn't fit `eq?'
or `equal?'?

-- 
  ((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?

[Asumu Takikawa]

On 2013-05-04 10:36:14 -0500, Robby Findler wrote:
>The racket2 wiki currently says "try this out" so I guess it isn't
>something people believe will definitely be better, but something to
>explore.

FWIW, Clojure uses keywords for `else` so there is some experience
there:
  http://clojuredocs.org/clojure_core/clojure.core/cond

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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Robby Findler]

Well, I'm not sure that I buy that motivation, since I think decisions
about what should be eq? to what should be driven by performance (and eq?
should only be used for performance) but lets put that aside.

There are some unused bits in Racket's runtime representation of values,
namely when a value's bit representation ends in 10, we know that it isn't
a fixnum (since it doesn't end with 1) and that it isn't a pointer (since
pointers have end with 00 (at least)), so I think that means that we could
have all of the unicode code points represented in a way that requires no
allocation (currently, iiuc, the ASCII characters are just pre-allocated at
the runtime startup; they require no allocation because you always just get
the same pointer).

This is a pretty big change, however, so I'm not sure it would be worth it.

Robby



On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri  wrote:

> Something about my response below has been bothering me, and I think I
> know what it is: the correspondence between characters and the fixnums that
> represent their code points seems -- how to put it? -- more complete if it
> extends to their equality predicates. So, yeah, in addition to performance,
> there's an aesthetic motivation, too.
>
> On May 4, 2013, at 12:03 PM, Jon Zeppieri  wrote:
>
> > Just for performance. No other reason.
> >
> > -Jon
> >
> > On Sat, May 4, 2013 at 12:01 PM, Robby Findler
> >  wrote:
> >> I'm curious: why do you want all characters to be eq? to each other
> instead
> >> of just equal??
> >>
> >> Robby
> >>
> >>
> >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri 
> wrote:
> >>>
> >>> Since incompatible future changes seem to be coming up a lot, I
> >>> thought I'd add one more. What do the members of this list think of
> >>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
> >>> etc.)?
> >>>
> >>> (Along with this change, it would be nice if characters could all be
> >>> immediately represented, so that those with equal code points would be
> >>> eq? RIght now, all unicode code points can be encoded in 22 bits, I
> >>> think. I'm not so familiar with racket's current representation of
> >>> characters, but I figure that they could easily be fit into a single
> >>> machine word on 64-bit builds. I don't know how difficult it would be
> >>> on 32-bit builds. And, of course, there's no guarantee that the number
> >>> of code points won't increase significantly.)
> >>>
> >>> Alternatively (and following Sam's line of thought from [1]), eqv?
> >>> could be extended to cover all of racket's immutable data structures.
> >>> In this case eqv? should also be made generic so that user-defined
> >>> immutable data structures can use it, as well.
> >>>
> >>>
> >>> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
> >>> _
> >>>  Racket Developers list:
> >>>  http://lists.racket-lang.org/dev
> >>
> >>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Jon Zeppieri]

Something about my response below has been bothering me, and I think I know 
what it is: the correspondence between characters and the fixnums that 
represent their code points seems -- how to put it? -- more complete if it 
extends to their equality predicates. So, yeah, in addition to performance, 
there's an aesthetic motivation, too.

On May 4, 2013, at 12:03 PM, Jon Zeppieri  wrote:

> Just for performance. No other reason.
> 
> -Jon
> 
> On Sat, May 4, 2013 at 12:01 PM, Robby Findler
>  wrote:
>> I'm curious: why do you want all characters to be eq? to each other instead
>> of just equal??
>> 
>> Robby
>> 
>> 
>> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri  wrote:
>>> 
>>> Since incompatible future changes seem to be coming up a lot, I
>>> thought I'd add one more. What do the members of this list think of
>>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
>>> etc.)?
>>> 
>>> (Along with this change, it would be nice if characters could all be
>>> immediately represented, so that those with equal code points would be
>>> eq? RIght now, all unicode code points can be encoded in 22 bits, I
>>> think. I'm not so familiar with racket's current representation of
>>> characters, but I figure that they could easily be fit into a single
>>> machine word on 64-bit builds. I don't know how difficult it would be
>>> on 32-bit builds. And, of course, there's no guarantee that the number
>>> of code points won't increase significantly.)
>>> 
>>> Alternatively (and following Sam's line of thought from [1]), eqv?
>>> could be extended to cover all of racket's immutable data structures.
>>> In this case eqv? should also be made generic so that user-defined
>>> immutable data structures can use it, as well.
>>> 
>>> 
>>> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
>>> _
>>>  Racket Developers list:
>>>  http://lists.racket-lang.org/dev
>> 
>> 

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

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Jon Zeppieri]

Just for performance. No other reason.

-Jon

On Sat, May 4, 2013 at 12:01 PM, Robby Findler
 wrote:
> I'm curious: why do you want all characters to be eq? to each other instead
> of just equal??
>
> Robby
>
>
> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri  wrote:
>>
>> Since incompatible future changes seem to be coming up a lot, I
>> thought I'd add one more. What do the members of this list think of
>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
>> etc.)?
>>
>> (Along with this change, it would be nice if characters could all be
>> immediately represented, so that those with equal code points would be
>> eq? RIght now, all unicode code points can be encoded in 22 bits, I
>> think. I'm not so familiar with racket's current representation of
>> characters, but I figure that they could easily be fit into a single
>> machine word on 64-bit builds. I don't know how difficult it would be
>> on 32-bit builds. And, of course, there's no guarantee that the number
>> of code points won't increase significantly.)
>>
>> Alternatively (and following Sam's line of thought from [1]), eqv?
>> could be extended to cover all of racket's immutable data structures.
>> In this case eqv? should also be made generic so that user-defined
>> immutable data structures can use it, as well.
>>
>>
>> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] racket2 suggestion: removing (or extending) eqv?

[Robby Findler]

I'm curious: why do you want all characters to be eq? to each other instead
of just equal??

Robby


On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri  wrote:

> Since incompatible future changes seem to be coming up a lot, I
> thought I'd add one more. What do the members of this list think of
> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
> etc.)?
>
> (Along with this change, it would be nice if characters could all be
> immediately represented, so that those with equal code points would be
> eq? RIght now, all unicode code points can be encoded in 22 bits, I
> think. I'm not so familiar with racket's current representation of
> characters, but I figure that they could easily be fit into a single
> machine word on 64-bit builds. I don't know how difficult it would be
> on 32-bit builds. And, of course, there's no guarantee that the number
> of code points won't increase significantly.)
>
> Alternatively (and following Sam's line of thought from [1]), eqv?
> could be extended to cover all of racket's immutable data structures.
> In this case eqv? should also be made generic so that user-defined
> immutable data structures can use it, as well.
>
>
> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] racket2 suggestion: removing (or extending) eqv?

[Jon Zeppieri]

Since incompatible future changes seem to be coming up a lot, I
thought I'd add one more. What do the members of this list think of
removing eqv? all of its associated machinery (e.g., memv, hasheqv,
etc.)?

(Along with this change, it would be nice if characters could all be
immediately represented, so that those with equal code points would be
eq? RIght now, all unicode code points can be encoded in 22 bits, I
think. I'm not so familiar with racket's current representation of
characters, but I figure that they could easily be fit into a single
machine word on 64-bit builds. I don't know how difficult it would be
on 32-bit builds. And, of course, there's no guarantee that the number
of code points won't increase significantly.)

Alternatively (and following Sam's line of thought from [1]), eqv?
could be extended to cover all of racket's immutable data structures.
In this case eqv? should also be made generic so that user-defined
immutable data structures can use it, as well.


[1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

[Robby Findler]

I think the bad property is the shadowing of the "else" identifier and
Matthew's point is that one way to avoid that is to not use an identifier
at all.

The racket2 wiki currently says "try this out" so I guess it isn't
something people believe will definitely be better, but something to
explore.

Robby


On Sat, May 4, 2013 at 10:33 AM, Laurent  wrote:

> (that was assuming Ryan's assertion that "[...]Matthew say that he would
> have used a keyword for `else` in `cond` if he had it to do over again",
> which seem to mean that even in Racket2 Matthew would prefer `#:else' over
> `[else ...]' ?)
>
>
> On Sat, May 4, 2013 at 5:14 PM, Laurent  wrote:
>
>> Matthew,
>> Out of curiosity, could you explain why you'd prefer #:else everywhere
>> instead of [else ...] ?
>> Would such an #:else allow for multi-line bodies?
>>
>>
>> On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt  wrote:
>>
>>> At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
>>> > On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt 
>>> wrote:
>>> >
>>> > > At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
>>> > > > 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...]
>>> > >
>>> > > Well, Ian provided an example from real code, right? Ian is willing
>>> to
>>> > > change his code, but the code sounds real.
>>> > >
>>> > > There's also the use in `unparse-pattern' in Redex. Maybe that's the
>>> > > troublesome one that Robby has in mind changing (or he would be happy
>>> > > to change it, obviously), but it's another real example.
>>> > >
>>> > >
>>> > No, that was not the example. The code I sent at the beginning of the
>>> > thread was an adjusted version of the bug that hid in Redex for,
>>> roughly,
>>> > months. It was a real bug and caused real problems and we knew
>>> something
>>> > was wrong but didn't find it for some time.
>>> >
>>> > In other words, this isn't some made-up, code cleanliness-based
>>> request.
>>>
>>> Yes, I understand that you faced a real bug. I hedged above on
>>> `unparse-pattern' not to suggest that your actual bug was
>>> uninteresting, but to suggest that I might misunderstand the
>>> relationship between the bug and the current state of our repository.
>>>
>>> All else being equal, I'm definitely in favor of a change to a sensible
>>> `else' for `match'. The "else" that isn't equal, however, is backward
>>> compatibility, and I think we're at the right point in our development
>>> cycle to defer backward incompatibilities to the next language ---
>>> hence my vote to defer.
>>>
>>> _
>>>   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 was assuming Ryan's assertion that "[...]Matthew say that he would
have used a keyword for `else` in `cond` if he had it to do over again",
which seem to mean that even in Racket2 Matthew would prefer `#:else' over
`[else ...]' ?)


On Sat, May 4, 2013 at 5:14 PM, Laurent  wrote:

> Matthew,
> Out of curiosity, could you explain why you'd prefer #:else everywhere
> instead of [else ...] ?
> Would such an #:else allow for multi-line bodies?
>
>
> On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt  wrote:
>
>> At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
>> > On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt 
>> wrote:
>> >
>> > > At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
>> > > > 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...]
>> > >
>> > > Well, Ian provided an example from real code, right? Ian is willing to
>> > > change his code, but the code sounds real.
>> > >
>> > > There's also the use in `unparse-pattern' in Redex. Maybe that's the
>> > > troublesome one that Robby has in mind changing (or he would be happy
>> > > to change it, obviously), but it's another real example.
>> > >
>> > >
>> > No, that was not the example. The code I sent at the beginning of the
>> > thread was an adjusted version of the bug that hid in Redex for,
>> roughly,
>> > months. It was a real bug and caused real problems and we knew something
>> > was wrong but didn't find it for some time.
>> >
>> > In other words, this isn't some made-up, code cleanliness-based request.
>>
>> Yes, I understand that you faced a real bug. I hedged above on
>> `unparse-pattern' not to suggest that your actual bug was
>> uninteresting, but to suggest that I might misunderstand the
>> relationship between the bug and the current state of our repository.
>>
>> All else being equal, I'm definitely in favor of a change to a sensible
>> `else' for `match'. The "else" that isn't equal, however, is backward
>> compatibility, and I think we're at the right point in our development
>> cycle to defer backward incompatibilities to the next language ---
>> hence my vote to defer.
>>
>> _
>>   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]

Okay, makes sense. Lets leave it alone.

Robby


On Sat, May 4, 2013 at 10:06 AM, Matthew Flatt  wrote:

> At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
> > On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt 
> wrote:
> >
> > > At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
> > > > 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...]
> > >
> > > Well, Ian provided an example from real code, right? Ian is willing to
> > > change his code, but the code sounds real.
> > >
> > > There's also the use in `unparse-pattern' in Redex. Maybe that's the
> > > troublesome one that Robby has in mind changing (or he would be happy
> > > to change it, obviously), but it's another real example.
> > >
> > >
> > No, that was not the example. The code I sent at the beginning of the
> > thread was an adjusted version of the bug that hid in Redex for, roughly,
> > months. It was a real bug and caused real problems and we knew something
> > was wrong but didn't find it for some time.
> >
> > In other words, this isn't some made-up, code cleanliness-based request.
>
> Yes, I understand that you faced a real bug. I hedged above on
> `unparse-pattern' not to suggest that your actual bug was
> uninteresting, but to suggest that I might misunderstand the
> relationship between the bug and the current state of our repository.
>
> All else being equal, I'm definitely in favor of a change to a sensible
> `else' for `match'. The "else" that isn't equal, however, is backward
> compatibility, and I think we're at the right point in our development
> cycle to defer backward incompatibilities to the next language ---
> hence my vote to defer.
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

[Laurent]

Matthew,
Out of curiosity, could you explain why you'd prefer #:else everywhere
instead of [else ...] ?
Would such an #:else allow for multi-line bodies?


On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt  wrote:

> At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
> > On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt 
> wrote:
> >
> > > At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
> > > > 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...]
> > >
> > > Well, Ian provided an example from real code, right? Ian is willing to
> > > change his code, but the code sounds real.
> > >
> > > There's also the use in `unparse-pattern' in Redex. Maybe that's the
> > > troublesome one that Robby has in mind changing (or he would be happy
> > > to change it, obviously), but it's another real example.
> > >
> > >
> > No, that was not the example. The code I sent at the beginning of the
> > thread was an adjusted version of the bug that hid in Redex for, roughly,
> > months. It was a real bug and caused real problems and we knew something
> > was wrong but didn't find it for some time.
> >
> > In other words, this isn't some made-up, code cleanliness-based request.
>
> Yes, I understand that you faced a real bug. I hedged above on
> `unparse-pattern' not to suggest that your actual bug was
> uninteresting, but to suggest that I might misunderstand the
> relationship between the bug and the current state of our repository.
>
> All else being equal, I'm definitely in favor of a change to a sensible
> `else' for `match'. The "else" that isn't equal, however, is backward
> compatibility, and I think we're at the right point in our development
> cycle to defer backward incompatibilities to the next language ---
> hence my vote to defer.
>
> _
>   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?

[Matthew Flatt]

At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
> On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt  wrote:
> 
> > At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
> > > 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...]
> >
> > Well, Ian provided an example from real code, right? Ian is willing to
> > change his code, but the code sounds real.
> >
> > There's also the use in `unparse-pattern' in Redex. Maybe that's the
> > troublesome one that Robby has in mind changing (or he would be happy
> > to change it, obviously), but it's another real example.
> >
> >
> No, that was not the example. The code I sent at the beginning of the
> thread was an adjusted version of the bug that hid in Redex for, roughly,
> months. It was a real bug and caused real problems and we knew something
> was wrong but didn't find it for some time.
> 
> In other words, this isn't some made-up, code cleanliness-based request.

Yes, I understand that you faced a real bug. I hedged above on
`unparse-pattern' not to suggest that your actual bug was
uninteresting, but to suggest that I might misunderstand the
relationship between the bug and the current state of our repository.

All else being equal, I'm definitely in favor of a change to a sensible
`else' for `match'. The "else" that isn't equal, however, is backward
compatibility, and I think we're at the right point in our development
cycle to defer backward incompatibilities to the next language ---
hence my vote to defer.

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

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

[Robby Findler]

On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt  wrote:

> At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
> > 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...]
>
> Well, Ian provided an example from real code, right? Ian is willing to
> change his code, but the code sounds real.
>
> There's also the use in `unparse-pattern' in Redex. Maybe that's the
> troublesome one that Robby has in mind changing (or he would be happy
> to change it, obviously), but it's another real example.
>
>
No, that was not the example. The code I sent at the beginning of the
thread was an adjusted version of the bug that hid in Redex for, roughly,
months. It was a real bug and caused real problems and we knew something
was wrong but didn't find it for some time.

In other words, this isn't some made-up, code cleanliness-based request.

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

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

[Matthew Flatt]

At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
> 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...]

Well, Ian provided an example from real code, right? Ian is willing to
change his code, but the code sounds real.

There's also the use in `unparse-pattern' in Redex. Maybe that's the
troublesome one that Robby has in mind changing (or he would be happy
to change it, obviously), but it's another real example.

Given these examples from the code we know, I reluctantly vote against
the change, due to concerns with backward compatibility --- and, yes,
from the sense that these issues are better addressed via `racket2'.

Meanwhile, it might be worth adding support for `#:else' to `cond',
`case', and `match'. That would be backward compatible, and we could
see whether we like it enough to do things that way in `racket2'.

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