[plt-scheme] create complex object @ compile time but made available @ run time?
On Jun 13, 2007, at 10:42 AM, Jens Axel Søgaard wrote:
> Ryan Culpepper wrote:
>
>> The code you gave uses 'print-convert' (lib "pconvert.ss") to generate
>> the syntax that would recreate the structure at run-time. It will
>> usually work for simple structures. But here are some problems that
>> you
>> may encounter if you use that method for interesting values:
>> First, 'print-convert' produces uncompilable code (containing '...')
>> when it can't convert a value. This happens for procedures, structs it
>> cannot inspect, etc.
>> Second, 'print-convert' leaves syntax objects unconverted and
>> unquoted.
>> When you use 'datum->syntax-object' on an S-expression that contains
>> embedded syntax objects, it doesn't quote them with an "extra layer"
>> of
>> syntaxness; it stops and leaves them intact. Here's what happens to
>> the
>> following value on the 'print-convert' trip:
>> (list #'(+ 1 2)) ;; a list containing a single syntax object
>> --print-convert-->
>> `(,#'(+ 1 2))
>> --datum->syntax-object-->
>> #'`(,(+ 1 2))
>> --eval-->
>> (list 3)
>> These effects can be truly baffling, especially if evaluating the
>> "expression" causes an error.
>
> Nice examples.
>
>> The only truly safe way I know of transferring values across phases is
>> to write your own 'X->X-syntax' serializer.
>
> Would it be possible to use print-convert as a starting point,
> and write a "syntax-convert"? Where one assumes that structure
> names bound in the syntax environment match names bound in the
> runtime environment?
Changing the 'print-convert-hook' to reject unserializable values
instead of putting in uncompilable code should help with problem 1.
Traversing the result of 'print-convert' and wrapping 'quote-syntax'
around any syntax objects should fix problem 2.
There's another problem in that the constructor name that
'print-convert' guesses for structures may be unavailable in the
current context, or it may be renamed to something else, or it might
mean different things in different phases. You said that you're willing
to take that as an assumption, and if so, I think that exhausts my
warnings about 'print-convert'.
I think you could check some of those assumptions using the static
struct information, but it's rather complicated, and it might not be
complete.
Ryan