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
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
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',
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
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
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?
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
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:
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
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
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
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:
12 matches
Mail list logo
