Re: [racket-dev] else clauses: possible change to match?
More generally, the role of `else' in `cond' is to select a particular production in the grammar of `cond' clauses, and keywords are normally the right way to do that in Racket. Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. At Sat, 4 May 2013 10:36:14 -0500, Robby Findler wrote: 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 laurent.ors...@gmail.com 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 laurent.ors...@gmail.com 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 mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu 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?
As a generalization, maybe Racket2 could keep the invariant `#:else' is
the absorbing (default) case of any multi-arm form ?
On Sun, May 5, 2013 at 4:30 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
More generally, the role of `else' in `cond' is to select a particular
production in the grammar of `cond' clauses, and keywords are normally
the right way to do that in Racket. Keywords are normally right because
they are syntactically distinct from expressions --- and so using a
keyword avoids various potential ambiguities and sources of confusion.
At Sat, 4 May 2013 10:36:14 -0500, Robby Findler wrote:
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 laurent.ors...@gmail.com
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 laurent.ors...@gmail.com
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 mfl...@cs.utah.edu
wrote:
At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu
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
[racket-dev] Racket2 suggestion: Attaching properties to operators
Speaking of invariants, from time to time I would like Racket to know some properties about its usual operators, so that some usual treatments get simplified and can be easily generalized. For example, considering group theory, properties like 'identity-element', 'absorbing-elements', 'inverse-operator', 'commutative?', 'associative?' and such could be attached to operators like `+', `*', `max', `string-append', `hc-append', etc. Forms like `for/op' could use this information to know how to loop and accumulate, and even possibly to optimize the code, even for newly created operators. In the simple case of + and such, one also only needs to define the binary operator, and the multi-argument procedure can be generated automatically. Of course it needs not be tied to group/category/mathematical theory. It can be about whatever is useful. It's only an idea, in case this resonates for someone. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
C++ has tried this tack for some time. I can see doing for built-ins but how would you go about programmer-created operations? Trust the programmer? -- Matthias On May 5, 2013, at 11:00 AM, Laurent wrote: Speaking of invariants, from time to time I would like Racket to know some properties about its usual operators, so that some usual treatments get simplified and can be easily generalized. For example, considering group theory, properties like 'identity-element', 'absorbing-elements', 'inverse-operator', 'commutative?', 'associative?' and such could be attached to operators like `+', `*', `max', `string-append', `hc-append', etc. Forms like `for/op' could use this information to know how to loop and accumulate, and even possibly to optimize the code, even for newly created operators. In the simple case of + and such, one also only needs to define the binary operator, and the multi-argument procedure can be generated automatically. Of course it needs not be tied to group/category/mathematical theory. It can be about whatever is useful. It's only an idea, in case this resonates for someone. Laurent _ 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?
Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. Isn't this only true for default bindings of #%datum? It seems like macros which assume this lose compatibility with #langs that allow keywords as expressions. I'm not sure whether we want to support that or not, but it seems wrong to say that they are syntatically distinct from expressions. On Sun, May 5, 2013 at 9:03 AM, Eli Barzilay e...@barzilay.org wrote: [shuffled] Yesterday, Matthew Flatt wrote: 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'. 1. Doesn't that make an argument against using traditional keywords? Perhaps it's a point for having more symbolic comparisons for keywords? (I'm not objecting to keywords -- just trying to figure out the implications of such a move.) IOW, if all such things switched to #:keywords, what would be a good use case for identifiers? 2. Can we also think of a better keyword syntax in racket2 if it's going to be used more? IIRC, the main arguments against `foo:' or `:foo' were existing code, but existing code will need to be modified... 3. And a side-comment: I hope that there will be something better than actual `racket2' used in code... Maybe rename the current one to `racket1' and possibly have code in packages use that unless it's declared new somehow? (The following is all filed under a non-important comment.) 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. IIUC, Ian said that he doesn't actually use that code, and the redex use is exactly what would get unbroken (I think, I didn't look at the code). I'm just saying that there are cases where it's worth breaking strict compatibility if it fixes more code than it breaks -- having (+ 1 2) = 4 is an exaggerated case of this, and relying on `else' being bound seems like it's closer to that end. Especially given that (match x ... [else ... else ...]) would usually be a quick unbound identifier error. (And BTW, I think that `match' is also an exceptional example in how this will go: (let ([else 1]) (match x [else ...])) which is a little more confusing than the same with `cond'.) -- ((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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
On May 5, 2013, at 12:51 PM, Laurent wrote: On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: C++ has tried this tack for some time. Sounds like it has failed then. I can see doing for built-ins but how would you go about programmer-created operations? Trust the programmer? -- Matthias Well, I guess some checks can be added, but I don't see the difference between attaching bad properties to a newly created operator and defining a buggy procedure. I think it is one thing to say (define (fahrenheit-celsius f) 32) and another to attach associative to the floating-point + operator. Since we all write examples first and translate then into test suites before we code, finding a bug in fahrenheit-celsius is straightforward and supported by our support mechanisms. If you don't trust your tests, attach contracts to your procedures because they generalize tests in a natural way. Finding bugs in false claims about functions is much less supported at the moment. Perhaps random testing or model checking or something like that may help along here. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
Each existing properties can come with a batch of generic test to test some usual corner cases, to check that property holds. It would indeed be easier if some elements of the domain/range could be given (or an automatic generator). Random testing would be good, but I don't think it's necessary to impose this constraint to have good assurance that the operator is well defined. Do you know why C++ has stopped pursuing this idea by any chance? On Sun, May 5, 2013 at 6:58 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 5, 2013, at 12:51 PM, Laurent wrote: On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: C++ has tried this tack for some time. Sounds like it has failed then. I can see doing for built-ins but how would you go about programmer-created operations? Trust the programmer? -- Matthias Well, I guess some checks can be added, but I don't see the difference between attaching bad properties to a newly created operator and defining a buggy procedure. I think it is one thing to say (define (fahrenheit-celsius f) 32) and another to attach associative to the floating-point + operator. Since we all write examples first and translate then into test suites before we code, finding a bug in fahrenheit-celsius is straightforward and supported by our support mechanisms. If you don't trust your tests, attach contracts to your procedures because they generalize tests in a natural way. Finding bugs in false claims about functions is much less supported at the moment. Perhaps random testing or model checking or something like that may help along here. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
On May 5, 2013, at 1:12 PM, Laurent wrote: Do you know why C++ has stopped pursuing this idea by any chance? No, and they may have more work going on besides standard work. It's worth reading up on it if you're interested. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
Would you happen to have a reference on that? On Sun, May 5, 2013 at 7:15 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 5, 2013, at 1:12 PM, Laurent wrote: Do you know why C++ has stopped pursuing this idea by any chance? No, and they may have more work going on besides standard work. It's worth reading up on it if you're interested. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/05/2013 12:49 PM, Eric Dobson wrote: Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. Isn't this only true for default bindings of #%datum? It seems like macros which assume this lose compatibility with #langs that allow keywords as expressions. I'm not sure whether we want to support that or not, but it seems wrong to say that they are syntatically distinct from expressions. I think it goes the other way around: we want keywords not be be expressions, so we would discourage languages from defining #%datum macros that accept them. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
Isn't it true that Eiffel does compiler transforms given that a user has proven their operators associative/commutative, etc? -Ian - Original Message - From: Laurent laurent.ors...@gmail.com To: Matthias Felleisen matth...@ccs.neu.edu Cc: dev@racket-lang.org Sent: Sunday, May 5, 2013 1:28:59 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Racket2 suggestion: Attaching properties to operators ...or keywords that would simplify my search. Don't take too much time digging old references that will not be much more than informative to me. On Sun, May 5, 2013 at 7:16 PM, Laurent laurent.ors...@gmail.com wrote: Would you happen to have a reference on that? On Sun, May 5, 2013 at 7:15 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On May 5, 2013, at 1:12 PM, Laurent wrote: Do you know why C++ has stopped pursuing this idea by any chance? No, and they may have more work going on besides standard work. It's worth reading up on it if you're interested. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] stypes.h + 3M woes
When I try to make a hole in the enumeration defined in stypes.h (by explicitly setting the value of a member), I get a segfault in the 3m build, though not the cgc one. Depending on where I place the hole, I've seen different stack traces. If I place the new tag before the _rt_ tags, then I get: #0 0x7fff886d9db0 in bzero$VARIANT$sse42 () #1 0x00010030d5ea in malloc_pages () at vm_osx.c:185 #2 0x000100314106 in allocate_big (request_size_bytes=32807, type=0) at newgc.c:974 #3 0x000100314e08 in GC_malloc_weak_array (size_in_bytes=16384, replace_val=0x0) at newgc.c:1463 If I place it after (which is where I want to place it), I get: #0 0x in ?? () #1 0x000100310e9f in repair_heap [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:4171 #2 0x000100310e9f in garbage_collect (gc=0x7fff5fbf7c00, force_full=5339440, switching_master=1606384640, lmi=0x7fff5fbf7c00) at newgc.c:4753 #3 0x00010031487a in scheme_get_thread_local_variables [inlined] () at /Users/jaz/src/racket/src/racket/include/schthread.h:1283 #4 0x00010031487a in allocate_slowpath [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:1289 #5 0x00010031487a in allocate (request_size=4300306736, type=1606384720) at newgc.c:1348 #6 0x0001002ad122 in scheme_make_stx_w_offset (val=0x102a00300, src=0x1003b10b8, props=0x1003b10b8, line=-1, col=-1, pos=1553, span=140734799772896) at syntax.c:577 I noticed that gc2.h's description of GC_init_type_tags() mentions that the count parameter will always be less than 256, and I wondered if that could be causing a problem, because I was trying to create a type tag with a value of 512. However, the comment appears to be wrong, because stypes.h currently defines tags up to 259 (_scheme_last_type_ == 260), and it looks like _scheme_last_type_ is used as the count param in salloc.c. Is there some other limit (aside from the limit of Scheme_Type itself, which is defined as a short, so that's at least 16 bits)? Or is there an assumption that the enumeration is dense? Or something else? -Jon _ Racket Developers list: http://lists.racket-lang.org/dev
