Design #1546: Improve 'describe' or 'print' for a function - CoCoA-5 - CoCoA Project

Design #1546

Improve 'describe' or 'print' for a function

Added by Julian Danner over 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Anna Maria Bigatti

Category:

CoCoA-5 function: new

Target version:

CoCoA-5.4.0

Start date:

04 Dec 2020

Due date:

% Done:

100%

Estimated time:

2.89 h

Spent time:

2.90 h

Description

Hi,
sadly CoCoA does not offer a (nice) way to save objects (rings, polys, lists,...) in such a way that they can be loaded later on.
But it is possible to write most of my objects using Sprint to a file in such a way that using source on that file reconstructs these objects, e.g. lists of integers, polynomials (after corr rings are generated, etc). This, however, does not at all work for (local) functions, as Sprint only prints out <function>.

While describe prints out a description of the function which I need, it is not possible to get that output as it is directly printed in the console and returned as a string.
My proposal is to change describe to a function that actually returns the description as a string. Then one can still write describe(foo); to get a description of foo, but then one could also store the description in a variable, or even print it to a chosen output-device. Then the function foo could be reconstructed without problems. (Or is there some other function, that serves this purpose, but I do not know?)

As an example, I would like to save it as follows:

foo:=func(t) /* do stuff with t */ return t; endfunc;

O:=OpenOFile("path/to/file");
println "foo:=", describe(foo), ";" on O;
close(D);

and load it with

source "path/to/file";

The only support that is dropped in this way is that describe foo; (without parenthesis) would not work any more, but that is -- I think -- not too much of a trouble.

In any case, a real support for saving objects would be much nicer ;)

Related issues

History

#1 Updated by John Abbott over 3 years ago

Category set to CoCoA-5 function: new
Target version set to CoCoA-5.4.2

I have had a (not so) quick look at the code involved.
describe like all CoCoA commands returns no value, and this cannot easily be changed.

A reasonable suggestion could be to make a describe ... on variant, much like print...on.

#2 Updated by Anna Maria Bigatti over 3 years ago

Tracker changed from Bug to Design
Subject changed from Improve 'describe' to Improve 'describe' or 'print'
% Done changed from 0 to 10

Julian Danner wrote:

sadly CoCoA does not offer a (nice) way to save objects (rings, polys, lists,...) in such a way that they can be loaded later on.

We used to have this (a long long time ago) but it seemed it was faster to recompute the objects, in many cases, and there is also the risk of loading malformed objects (which makes parsing and interpreting a nightmare, and also using the loaded data potentially risky), and we realized the reading the printed object was the safest solution.
That said, reading a very long polynomial can be quite slow, and maybe we should offer a way to read a "sorted polynomial".

But it is possible to write most of my objects using Sprint to a file in such a way that using source on that file reconstructs these objects, e.g. lists of integers, polynomials (after corr rings are generated, etc).

I would use directly print ... on ...
(I see sprint as a "buffer", for example if I need to know the lenght of the printed object before I actually print it)

This, however, does not at all work for (local) functions, as Sprint only prints out <function>.
While describe prints out a description of the function which I need, it is not possible to get that output as it is directly printed in the console and returned as a string.

describe has actually another meaning: print a richer descpription of the object, which is not necessarily readable. Example: describe CurrentRing;

But you have a point: describe is currently ;-) the only way to have the code for a function, so we should think about this point. Maybe we could have print/print .. on .. actually printing the function.
That should be an easy fix, and it would make printing functions aligned with printing other objects.

John Abbott wrote:

A reasonable suggestion could be to make a describe ... on variant, much like print...on.

This is a good idea (even though, for this issue, about printing functions, I'd rather change print).
Should also consider all "print only" functions and offer a way to print on file/device. Which are they? (indent is one)

#3 Updated by Julian Danner over 3 years ago

Anna Maria Bigatti wrote:

Julian Danner wrote:

sadly CoCoA does not offer a (nice) way to save objects (rings, polys, lists,...) in such a way that they can be loaded later on.

We used to have this (a long long time ago) but it seemed it was faster to recompute the objects, in many cases, and there is also the risk of loading malformed objects (which makes parsing and interpreting a nightmare, and also using the loaded data potentially risky), and we realized the reading the printed object was the safest solution.
That said, reading a very long polynomial can be quite slow, and maybe we should offer a way to read a "sorted polynomial".

Hmm, not too sure about the timing issues. In my case I have a large lookup-table that involves many (long) computations with which my final algorithm is extremely fast. However, computing this table takes several days. As of now, loading this table takes less than 30secs, so this is quite acceptable.
But, yeah I guess its safer to recompute the results instead of saving and loading them.
Still an optimized 'loading' function for polynomials in standard representation would be highly appreciated!

But it is possible to write most of my objects using Sprint to a file in such a way that using source on that file reconstructs these objects, e.g. lists of integers, polynomials (after corr rings are generated, etc).

I would use directly print ... on ...
(I see sprint as a "buffer", for example if I need to know the lenght of the printed object before I actually print it)

Well yes, I also use print ... on ... but in combination with sprint which I just noticed is actually not necessary here... thanks! ;)

This, however, does not at all work for (local) functions, as Sprint only prints out <function>.
While describe prints out a description of the function which I need, it is not possible to get that output as it is directly printed in the console and returned as a string.

describe has actually another meaning: print a richer descpription of the object, which is not necessarily readable. Example: describe CurrentRing;

But you have a point: describe is currently ;-) the only way to have the code for a function, so we should think about this point. Maybe we could have print/print .. on .. actually printing the function.
That should be an easy fix, and it would make printing functions aligned with printing other objects.

Yeah, that's the reason I tried to use describe to get the function body.
Actually, I would prefer a function that returns a string containing the body of the function, then one does not need an output device first to just get the string. This could, for instance, be done by sprint. (But still, I think printing a function with print ... on ... should return the function-body.)