Re: [racket-users] TR for fast manipulation of C data

Just so you know, typed/racket/no-check is not a typed language -- everything is turned off except the syntax. Sam On Sep 18, 2017 1:38 AM, "'John Clements' via users-redirect" < us...@plt-scheme.org> wrote: > Thanks to all of you; with casts changed to asserts, the use of > unsafe-vector

Re: [racket-users] TR for fast manipulation of C data

> On Sep 18, 2017, at 4:52 AM, Sam Tobin-Hochstadt wrote: > > Just so you know, typed/racket/no-check is not a typed language -- everything > is turned off except the syntax. Right; I wanted to try disabling contract checking per Robby’s suggestion, and I figured that

Re: [racket-users] TR for fast manipulation of C data

— I wonder if a slightly different choice of data representation could reduce the load on boundary crossing too. — And perhaps we can add 16bit data one day. > On Sep 18, 2017, at 12:28 PM, 'John Clements' via users-redirect > wrote: > > >> On Sep 18, 2017, at 4:52

Re: [racket-users] syntax-parse attributes in macro-generated macros

On 09/17/2017 01:00 AM, Philip McGrath wrote: [...] I have a macro like `example-macro`, but more complicated and with many, many more potential keyword arguments, so I wanted to write a macro that would let me define `example-macro` with a more declarative syntax, like this:

Re: [racket-users] syntax-parse attributes in macro-generated macros

Thanks, that was more obvious than I expected. Aside from improving readability, the definition and use combined of the macro-defining version comes out to about 40% of the original in terms of lines of code, and it was trivial to have the same macro also expand into a seperate submodule to