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 <c...@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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
