On 12 Nov, 2005, at 13:58, felix winkelmann wrote:
I'm not sure how to proceed, though.
One approach would be to translate the binary output into a tagged/
marked-up format like *gasp* XML...
A sender would do something like write a tagged/marked-up (number-
>string n). What a receiver does with such a number too large or
too small for its native fixnum is up to it.
#;1> (string->number "230984203849023894")
2.30984203849024e+17
#;2> (use numbers)
; loading /usr/local/lib/chicken/numbers.scm ...
; loading /usr/local/lib/chicken/numbers-base.so ...
#;3> (string->number "230984203849023894")
230984203849023894
On the other hand, a markup language could tell the receiver that it
must maintain a certain precision or fail. Who knows what could
evolve?
Platform-independent serialization opens up a lot of possibilities
- on the other hand the serialization of procedures is highly
dependent of the compiler version and even optimization options...
You could keep the scheme source around and serialize that... That
presents lots of work for the receiver, but a memoization approach
could avoid recompilation of already-received procedures. This
seems to call for a globally unique ID for the serialized procedure,
and could be optimized with an ihave/sendme kind of dialogue.
s->r: i have someprocguid
r->s: i don't, so send it
s->r: <serialized procedure>
receiver may save the serialized procedure and its own compiled
version of it for future use, so that later:
s->r: i have someprocguid
r->s: i have it already
and thereby save the work of processing a serialized procedure.
This approach could be used for any serialized object, not just
procedures.
Finally, using a globally unique id has advantages in terms of
allowing for persistence and distribution.
Sean.
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
