bug#11198: problems reading data with a "read-hash-extend" registered reader

[Mark H Weaver]

Klaus Stehle <address@hidden> writes:
> On Wed, 11 Apr 2012, Mark H Weaver wrote:
>> address@hidden (Ludovic Courtès) writes:
>> > Klaus Stehle <address@hidden> skribis:
>> >
>> >> (read-hash-extend #\R read-R)
>> >
>> > Unlike previous versions, Guile 2.0 has distinct compilation and
>> > run-time phases.  Here you probably want the reader extension to become
>> > effective at compile-time (when compiling), and at evaluation-time (when
>> > interpreting the code):
>> >
>> >   (eval-when (compile eval)
>> >     (read-hash-extend #\R read-R))
>> 
>> I don't think this will be sufficient by itself, because 'read-R' will
>> not yet be bound at compile time.  You also need to define 'read-R'
>> within the 'eval-when', and everything else that's needed to run
>> 'read-R'.
>
> You are right. But now the record type is unknown at compile time.
> So I also wrap the define-record-type expression into an 'eval-when'.
>
> Then we arrive at the same error message which is displayed when
> typing the #R-expression interactively:
>
> => ERROR: build-constant-store: unrecognized object
> => #<my-record one: "bla" two: "bobo">
>
> This error message is not very informative. And in spite of an error the
> record is built! You can see it in the error message but you can't use it.

I see now that this is a limitation of our compiler.  It serializes all
literals, and does not know how to serialize records.  The relevant
procedure 'build-constant-store' is in (language glil compile-assembly).

It is not obvious how to fix this.  The tricky part is how to serialize
the identity of the struct-vtable.  The best approach that comes to mind
is to serialize the identifier (syntax-object) of the module variable
that holds the record type descriptor.  These identifiers are already
being serialized within the compiled macros.  However, this approach
can only work for records defined at top-level.

What do you think?

      Mark