I overlooked the crucial line of the second stack trace. The
fixup_table and mark_table fields of the NewGC each allocate space for
512 function pointers, indexed by type tag (I think). So, when I tried
to create a tag with 512 as it's value, I ended up writing outside of
the array bounds. Maybe th
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:
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"
To: "Matthias Felleisen"
Cc: dev@racket-lang.org
Sent: Sunday, May 5, 2013 1:28:59 PM GMT -05:00 US/Canada Eastern
Sub
...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 wrote:
> Would you happen to have a reference on that?
>
>
> On Sun, May 5, 2013 at 7:15 PM, Matthias Felleise
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 wh
Would you happen to have a reference on that?
On Sun, May 5, 2013 at 7:15 PM, Matthias Felleisen 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'
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.r
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 12:51 PM, Laurent wrote:
> On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen
> 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 p
On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen 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
> 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
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
> prope
[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 u
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-ope
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 wrote:
> More generally, the role of `else' in `cond' is to select a particular
> production in the grammar of `cond' claus
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 va
16 matches
Mail list logo
