Serializing and deserializing objects

[Tobias Neumann]

For domains that can be coerced into InputForm one can

serialize like: str = unparse(x :: InputForm)

and deserialize like retract(interpret(parse(str)))$AnyFunctions1(target-type)

But already a Record can't be cast into InputForm, which leaves me

to manually deconstruct the record. This becomes more and more tedious, the

more nested your objects are.

One problem with 'interpret' of InputForm is that it doesn't know in advance

the target type.

I think it would be useful to have a new SerializationForm that allows

to save objects to String's and files (either human readable or binary).

Do you think that there is a place for that in FriCAS?

serialize: % -> String

deserialize: String -> %

I haven't given much thought so far about any issues with that.

Let me know what you think about this.

In that context: Right now FriCAS doesn't seem to have an output format 

to get a result in the interpreter that can be copy and pasted that into a new .input file,

such that it just works. One always has to manually add "_" line continuations,

add "*" for multiplications, fix "^", etc. An output format that can *mostly*

be copy and pasted into an .input file would be great, probably corresponding

to something like unparse(obj :: InputForm). I am surprised that Axiom didn't

come with such an output format. 

[Waldek Hebisch]

On Tue, Apr 13, 2021 at 02:57:00PM -0700, Tobias Neumann wrote:
> For domains that can be coerced into InputForm one can
> serialize like: str = unparse(x :: InputForm)
> and deserialize like
> retract(interpret(parse(str)))$AnyFunctions1(target-type)
>
> But already a Record can't be cast into InputForm, which leaves me
> to manually deconstruct the record. This becomes more and more tedious, the
> more nested your objects are.
>
> One problem with 'interpret' of InputForm is that it doesn't know in advance
> the target type.
>
> I think it would be useful to have a new SerializationForm that allows
> to save objects to String's and files (either human readable or binary).
> Do you think that there is a place for that in FriCAS?

Well, we have that: there is history mechanizm and 'Library' domain
to store objects in files.

--
Waldek Hebisch

[Tobias Neumann]

Well, we have that: there is history mechanizm and 'Library' domain
to store objects in files.

'Library' is quite amazing. I missed it in the book and the API when searching for "serialize".

It can even save streams; this is better than I had hoped for!

I also was not aware that )history does not just save the command history, but can save the whole environment using the same mechanism.

Good to realize that, thanks!