[racket-dev] Cross-phase persistent modules

On further inspection, it looks like the grammar for cross-phase persistent
modules is not clear about where cross-expr is required and where more
general exprs are allowed.  The define-values form requires cross-expr,
which makes sense.  The #%plain-lambda and case-lambda forms appear to
permit general expressions, which also makes sense -- since cross-phase
persistent modules can't run these procedures, they might as well be able
to do whatever they want.  But the arguments of cons, list,
make-struct-type, and make-struct-type-property are documented as expr
rather than cross-expr, and that doesn't make a lot of sense.  Presumably
these should be restricted to cross-expr as well.

Carl Eastlund


On Fri, Apr 5, 2013 at 7:31 AM, Carl Eastlund <cce at ccs.neu.edu> wrote:

> These seem great.  I'd like to build a macro that defines cross-phase
> persistent structures, so that I can make structs that can be quoted in
> syntax reliably.  For that, I'd like a little more built-in support.
> (Ultimately, if struct from racket/base supported a
> #:cross-phase-persistent option that automatically defined a submodule,
> that would be perfect---but whoever implements a tool like that is going to
> need or at least want extra support, too.)
>
> Most importantly, as far as I can tell, cross-phase persistent modules are
> currently an internal silent heuristic for turning modules into persistent
> ones.  I'd really like a way to explicitly declare that I want a module to
> be persistent across phases.  This mechanism should report an error if the
> module cannot be made persistent.  Right now, I just have to guess and
> hope.  I can write my own mechanism that checks the documented structure
> against my fully-expanded module, but if I get something wrong or the
> documentation is wrong, my error-reporting mechanism might not line up with
> reality.
>
> Secondly, the criteria for a persistent module is a bit idiosyncratic.
> For instance, top-level constants (those defined outside of function
> bodies) can be constructed by quoting numbers, booleans, symbols, strings,
> and byte strings, and by using the functions cons and list.  I don't know
> why a persistent module cannot quote a character, regular expression, empty
> list, immutable cons, immutable vector, immutable box, immutable hash
> table, or immutable prefab structure.  Oh, and going down the Datatypes
> reference, I forgot keywords.  If we're special casing both cons and list,
> personally I would at least add list*, and possibly more of the tools
> allowed in setup/infotab (reverse, append, car, cdr), and possibly all the
> basic constructors and possibly selectors for our primitive, immutable
> datatypes.  If we don't want to allow these things for some reason, I'd
> argue that even cons and list might not be necessary and we could restrict
> the whole thing to just quote.
>
> Thirdly, one of the nice things about dealing with syntax objects is how
> datum->syntax and syntax->datum "permeate" the values they encounter --
> lists, vectors, prefab structs, etc.  Is it possible to do the same with
> transparent structs if they are defined in cross-phase persistent modules?
> Is there any way to detect that?  If so, it would make adding new kinds of
> syntax values a lot nicer.  Or maybe if we had a prop:syntax / gen:syntax
> that supported to-syntax and to-datum operations, so we could implement our
> own "syntax-permeable" structs?  This isn't directly related to cross-phase
> persistent modules, but their existence makes this feature more desirable
> than it has been previously.
>
> Thanks to anyone [especially if your name is Matthew Flatt] who can give
> this all a look!
>
> Carl Eastlund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130405/cad23391/attachment.html>