records as s-expressions

records as s-expressions

[Thamer Al-Harbash]

Would there be any interest in accepting a patch which makes
records print out as s-expressions so they are more easily
serialized?

I ask because vectors are great to dump to a file and then just
load and evaluate. I'd like to do the same with my records but
cannot since records don't keep any type information when they
are written out and the interpreter does not recognize:

            #<foo-record foo: bar>

Would this break any standards or cause backward compatibility
problems?

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
                    "HLAGHLHALUAG (KTHANX)"


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Marius Vollmer]

Thamer Al-Harbash <tmh@whitefang.com> writes:

> Would there be any interest in accepting a patch which makes
> records print out as s-expressions so they are more easily
> serialized?

Yes!

> Would this break any standards or cause backward compatibility
> problems?

Depends on your implementation...

I see two choices: follow Common Lisp and use #S(<type> ...), or
follow SRFI-10 and use something like #,(record <type> ...).  I don't
think there is any SRFI that specifies a concrete read syntax for
records.

We already use #s for uniform arrays, but overwrite it when (srfi
srfi-4) is loaded...  #S is free, tho.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> I see two choices: follow Common Lisp and use #S(<type> ...), or
> follow SRFI-10 and use something like #,(record <type> ...).  I don't
> think there is any SRFI that specifies a concrete read syntax for
> records.

And I suppose the third and most painful, though possibly most broadly
useful option (if you're feeling really ambitious) might be to try and
come up with a suitable SRFI.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Thamer Al-Harbash]

On Tue, 7 Oct 2003, Marius Vollmer wrote:

Thanks Rob and Marius for your earlier comments.

> Depends on your implementation...

I planned the way I want to implement it today and would like to
know if there are any objections to my thoughts below.

> I see two choices: follow Common Lisp and use #S(<type> ...), or
> follow SRFI-10 and use something like #,(record <type> ...).  I don't
> think there is any SRFI that specifies a concrete read syntax for
> records.
>
> We already use #s for uniform arrays, but overwrite it when (srfi
> srfi-4) is loaded...  #S is free, tho.

Would it be reasonable to just use (read-hash-extend) to hook
into the existing reader, and as well as modify existing
boot-9.scm code cause records to (display) as #S(...)?

If I went with the SRFI-10 solution I'd be implementing this as a
(record-serialize) (record-unserialize) which seem a bit less
Schemeish to me.

If there's no objections to this I should be able to write it
Real Soon Now with minimal hassle.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Marius Vollmer]

Thamer Al-Harbash <tmh@whitefang.com> writes:

> Would it be reasonable to just use (read-hash-extend) to hook
> into the existing reader, and as well as modify existing
> boot-9.scm code cause records to (display) as #S(...)?

Yes.

One other thing that just occured to me: how does 'read' find the
record creator from the type name?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Thamer Al-Harbash]

On Thu, 16 Oct 2003, Marius Vollmer wrote:

> Yes.
>
> One other thing that just occured to me: how does 'read' find the
> record creator from the type name?

Good point. I can't see how this would work by putting it in the
reader. Here's the real problem though:

Currently a record of type "foobar" with two fields "foo" and
"bar" will print as such:

#<foobar foo: 1 bar: 2>

The problem here is that you cannot tell the whether those datums
hold strings or numerics:

guile> ((record-constructor (make-record-type "foobar" '(foo bar))) 1 2)
#<foobar foo: 1 bar: 2>

guile> ((record-constructor (make-record-type "foobar" '(foo bar))) "1" "2")
#<foobar foo: 1 bar: 2>

The simple solution is to store type information as a symbol so
this distinction can be made:

#<foobar foo: type-string: 1 bar: type-string: 2>

This should be enough for me to create the record type, and a
constructor in the hash extension hook.

However a problem occurs when dealing with SMOBs or types which
(read) cannot convert properly. How is this dealt with in data
types like arrays? If I print an array, which contains smobs or
records, from the REPL, how is it converted back when (read) gets
it again?

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Thamer Al-Harbash]

On Thu, 16 Oct 2003, Thamer Al-Harbash wrote:

> However a problem occurs when dealing with SMOBs or types which
> (read) cannot convert properly. How is this dealt with in data
> types like arrays? If I print an array, which contains smobs or
> records, from the REPL, how is it converted back when (read) gets
> it again?

I should add that these aren't dealt with right now. Writing back
an array with a record inside of it of course results in an error
because #< is an unknown object which isn't handled.

The only way to make everything serializable is to force SMOBs to
have a read routine associated with them even if they don't do
anything to avoid errors.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Marius Vollmer]

Thamer Al-Harbash <tmh@whitefang.com> writes:

> On Thu, 16 Oct 2003, Marius Vollmer wrote:
>
>> Yes.
>>
>> One other thing that just occured to me: how does 'read' find the
>> record creator from the type name?
>
> Good point. I can't see how this would work by putting it in the
> reader.

Me neither.  We can't easily solve the general problem (writing _all_
record types in a readable way by default), but we could make it easy
for the user to implement readable writing for selected record types.

Something like this:

  (define r (make-record-type foo '(a b) readable-record-printer))
  (register-record-reader 'foo foo)

where readable-record-printer will print a record as

  #,(foo a: ... b: ...)

and register-record-reader will use define-reader-ctor to be able to
read the record back in.

> Here's the real problem though:

That's not serious: this only happens because the default record
printer uses display instead of write.

> However a problem occurs when dealing with SMOBs or types which
> (read) cannot convert properly.  How is this dealt with in data
> types like arrays? If I print an array, which contains smobs or
> records, from the REPL, how is it converted back when (read) gets it
> again?

This is a separate problem; we don't need to solve it right now.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Neil Jerram]

>>>>> "Thamer" == Thamer Al-Harbash <tmh@whitefang.com> writes:

    Thamer> The simple solution is to store type information as a symbol so
    Thamer> this distinction can be made:

    Thamer> #<foobar foo: type-string: 1 bar: type-string: 2>

This won't work.  (Or, more precisely, to make it work would be
arbitrarily complex.)  Consider, for example, if the arg is a list of
<strings or integers>, or a list of lists of <strings or integers>,
and so on.  Type must be implicit in the printed form.

        Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> Something like this:
>
>   (define r (make-record-type foo '(a b) readable-record-printer))
>   (register-record-reader 'foo foo)

Is there any reaon that make-record-type should not automatically
register the type name for reading as well as printing?


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Rob Browning]

Thamer Al-Harbash <tmh@whitefang.com> writes:

> Would it be reasonable to just use (read-hash-extend) to hook
> into the existing reader, and as well as modify existing
> boot-9.scm code cause records to (display) as #S(...)?
>
> If I went with the SRFI-10 solution I'd be implementing this as a
> (record-serialize) (record-unserialize) which seem a bit less
> Schemeish to me.

I think I might rather go with the SRFI since that means any records
written have a much greater possibility of being able to be parsed by
other schemes, or at least a much greater possibility that other
schemes can be taught how to parse them without modifying the
implementation, and unless we're going to try to come up with some
kind of record standard, it might even make sense to use something
like #,(scmrec ...), that's more guile-specific than "record".

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Thamer Al-Harbash]

On Thu, 16 Oct 2003, Neil Jerram wrote:

> This won't work.  (Or, more precisely, to make it work would be
> arbitrarily complex.)  Consider, for example, if the arg is a list of
> <strings or integers>, or a list of lists of <strings or integers>,
> and so on.  Type must be implicit in the printed form.

I understand, and thanks for pointing it out. The only way to
implement this is to (write) each field and expect the (read) to
parse it back properly.

I should have thought of this clearer solution earlier.

This doesn't solve the SMOB-in-a-record problem but that's not in
the scope of this feature.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Thamer Al-Harbash <tmh@whitefang.com> writes:
    >> Would it be reasonable to just use (read-hash-extend) to hook
    >> into the existing reader, and as well as modify existing
    >> boot-9.scm code cause records to (display) as #S(...)?
    >> 
    >> If I went with the SRFI-10 solution I'd be implementing this as a
    >> (record-serialize) (record-unserialize) which seem a bit less
    >> Schemeish to me.

    Rob> I think I might rather go with the SRFI since that means any
    Rob> records written have a much greater possibility of being able
    Rob> to be parsed by other schemes, [...]

I agree with Rob.  Remember that the only cleverness required here is
to construct the reread record properly at _read_ time; if it was OK
for construction to be delayed until evaluation, then records could be
printed simply as whatever Scheme functional expression is needed to
create a record (e.g. `(record-constructor <type> <args>)).

So the problem is construction at read time, and this is exactly what
SRFI-10 is designed to do.  As regards convenience of usage, I think
the details of the mechanism can all be hidden from the user inside
`write', either using GOOPS, or by hacking the C code for write.  I
don't see a need for explicit record-serialize/record-unserialize
calls.

Best regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: records as s-expressions

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> Marius Vollmer <mvo@zagadka.de> wrote:
>> Something like this:
>>
>>   (define r (make-record-type foo '(a b) readable-record-printer))
>>   (register-record-reader 'foo foo)
>
> Is there any reaon that make-record-type should not automatically
> register the type name for reading as well as printing?

Hmm, the only reason I can think of is that record type names are not
necessarily unique right now.  But they wont magically become unique
when we print them readably...  So yes, I think we can make records
print readably by default.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel