On Sat, Apr 03, 2021 at 01:07:39AM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
>
> during our work on jfricas, we first had a version that needed the
> filesystem in order to interpret a Jupyter cell with multiline FriCAS
> input. Code was first written to a temporary .input file and then read
> back for interpretation.
>
> The problem was where to save that temporary file until I realized that
> one can easily tweak the )read routine and give it the lines from memory
> instead of reading it from the filesystem. The result is the function
> "interpret-block" in webspad.lisp.
>
> https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp#L101
> (attached below)
>
> I think that function should rather live inside FriCAS itself (chose a
> name that you like).
>
> For my day-to-day work I use the axiom-environment of Paul Onions.
> https://bitbucket.org/pdo/axiom-environment/src/master/
> I guess that Frontend would also benefit from that function.
>
> What do you think? Should a prepare a pull-request?
Sorry for silence on this. Except of name, that is '-'
in the name it looks fine as short-term solution. Concerning
name, it makes sense to call such function from Boot
and as I wrote for such functions I really like to
use the same name in both languages.
For longer term, I would like to change file input machinery
quite a lot. First, get rid of 'intloopInclude0' and
friends. Probably use 'U32Vector' (or Boot equivalent)
instead of strings. In particluar do all input at binary
level and handle UTF-8 on FriCAS side (that should give
better speed and get rid of troubles due to locale settings).
It is hard to give timing for larger change: assuming that
during implementation there are no unexpected problems
actual coding can be done in few days. But few free
days in sequence are not so easy to spare. And
"no unexpected problems" means that before coding I
need good design first. Now I have most aspect of
design in my head, but there are some corner cases of
pile handling that should be worked out first. Also,
there is question of how much renaming should we have?
Currently, scanner produces one set of symbols. Spad
parser uses different symbols, so there is renaming
stage here. Spad compiler uses yet another set of
symbols, with renaming (and some other transformations)
done on 'postpar.boot' and 'parse.boot'. "Interpreter"
contains its own parser and compiler, using quite
different data structures than Spad compiler. Ideally,
if we need renaming it should be done in scanner and
the same symbols should be used in later stages.
But that means that changes to input reading and
scanner should be coordinated with other changes.
Back to the point: your routine is useful in short
and possibly medium terms (depending how long it
will take to implement bigger changes). I admit
that there is bunch of possible short term changes
that I decided to postpone past current release.
For this release I feel that there is important
to have your new formatters and jfricas in good
shape. So IMO the main issue is what is more
convenient for jfricas. Assuming that you handle
jfricas part (if needed), please go on.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210403005838.GB34724%40math.uni.wroc.pl.
