<div dir="ltr">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.<br>
</div><div class="gmail_extra"><br clear="all"><div>Carl Eastlund</div>
<br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 7:31 AM, Carl Eastlund <span dir="ltr"><<a href="mailto:cce@ccs.neu.edu" target="_blank">cce@ccs.neu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>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.)<br>
<br></div>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.<br>
<br>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.<br>
<br></div><div>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.<br>
</div><div><br></div><div>Thanks to anyone [especially if your name is Matthew Flatt] who can give this all a look!<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>
<div><div><br><div>Carl Eastlund</div>
</div></div></div></font></span></div>
</blockquote></div><br></div>