<div dir="ltr"><div><div>These seem great.  I&#39;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&#39;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&#39;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&#39;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&#39;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&#39;t want to allow these things for some reason, I&#39;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-&gt;syntax and syntax-&gt;datum &quot;permeate&quot; 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 &quot;syntax-permeable&quot; structs?  This isn&#39;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!<br></div><div><div><div><br><div>Carl Eastlund</div>
</div></div></div></div>