If you take this program and fully-expand it in the macro stepper:
#lang racket
(struct posn (x y))
(define p1 (posn 1 2))
You see that the residual program has an application of the `posn1`
function, which is the hidden constructor. And indeed, the
fully-expanded program has a definition of `pos
I'm working on enhancing struct-info to carry field names as symbols to do nice
hygienic things:
http://lists.racket-lang.org/users/archive/2014-July/063271.html
I now see that struct-out always provides all field accessors in the static
struct-info associated with the struct identifier.
This m
On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson wrote:
> I'm working on enhancing struct-info to carry field names as symbols to do
> nice hygienic things:
>
> http://lists.racket-lang.org/users/archive/2014-July/063271.html
>
> I now see that struct-out always provides all field accessors in the
Code will break if it uses struct to produce structs, provides a renamed an
accessor function, and uses an unhygienic feature to name the field.
The features I know of are struct-copy, struct* match patterns, and
contract-out's struct form.
No one but me probably did this, and that's what led to
On 07/15/14 07:00, Matthew Flatt wrote:
The "gc" directory is Boehm's GC. We've modified it a little (grep for
"PLTSCHEME"), but we try not to maintain the GC itself, except to
upgrade every once in a while.
Sorry, I should to look the code before of to ask :) . I thought the
boehm gc version
Added!
At Tue, 8 Jul 2014 05:36:55 +0100, Matthew Flatt wrote:
> Hi Jan,
>
> That's a nice idea. Something similar --- but in a restricted form ---
> is used internally to implement various primitive events. I think I see
> how to generalize it to work with more arbitrary events and non-atomic
>
On Tue, Jul 15, 2014 at 10:12 AM, J. Ian Johnson wrote:
> Code will break if it uses struct to produce structs, provides a renamed an
> accessor function, and uses an unhygienic feature to name the field.
> The features I know of are struct-copy, struct* match patterns, and
> contract-out's stru
On Tue, 2014-07-15 at 15:46 +0100, Matthew Flatt wrote:
> Added!
Awesome! I officially owe you a beer.
_
Racket Developers list:
http://lists.racket-lang.org/dev
> I just don't think the additional line in that error message is very
> helpful, and it's already a long and scary error message.
Not that anyone asked for my opinion, but I agree.
Similarly, I wouldn't find it helpful if rackunit failure messages
added a caveat, "assuming the unit test isn't bu
9 matches
Mail list logo