interpret-block

[Ralf Hemmecke]

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?

Ralf

=============================================================

;;; interpret-block takes a code string that is interpreted as if it
;;; comes from a .input file.
(DEFUN |interpret-block| (|code|)
(PROG (|$ncMsgList| |$erMsgToss| |$lastPos| |$EchoLines| |st|)
(DECLARE (SPECIAL |$ncMsgList| |$erMsgToss| |$lastPos| |$EchoLines|))
(RETURN
(PROGN
(SETQ |$EchoLines| NIL)
(SETQ |$lastPos| |$nopos|)
(SETQ |$erMsgToss| NIL)
(SETQ |$ncMsgList| NIL)
(SETQ |st| (MAKE-STRING-INPUT-STREAM |code|))
(|intloopInclude0| |st| '|webspad| 0)))))

[Waldek Hebisch]

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

[Ralf Hemmecke]

> Except of name, that is '-' in the name it looks fine as short-term
> solution.

Yes, I understand your wish. I don't care much about any name here.

> For longer term, I would like to change file input machinery quite a
> lot. First, get rid of 'intloopInclude0' and friends.

OK. Then it is maybe better just to wait for you to clean things up.
I don't need that function desparately. Just thought it would be a good
addition to FriCAS itself.

If you start working on this project, please keep in mind that we
synchronize this with jfricas so that old jfricas versions can perhaps
still run on top of a newer FriCAS release. That's, of course, not
absolutely necessary, but I would of course like to get notified and
have an appropriate replacement for jfricas, in case you change the
current code.

> 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.

Maybe I do not fully understand all of this renaming, but I as long as
it is invisible to SPAD programming, anything that helps you getting
things more straight is OK.
With respect to jfricas, it is only important that we can somehow make
this frontend nicely working even after your changes, so would be good
to send pull requests or develop in a branch.
Otherwise feel free in whatever needs to be done.

> feel that there is important to have your new formatters and jfricas
> in good shape.

Several people now seemed to have tried jFriCAS and FormatMathJax, I use
it quite a lot without big issues. Pretty stable.

The only issues I see is with Format1D (maybe also Format2D). I still
count them as experimental. For example, I get

(5) -> true

"true"

Type: Boolean


i.e. with quotation marks when I switch on Format1D. I would like to
wait for more people to comment on other issues, before I take a closer
look. However, I think the problem is how boolean values are stored in
OutputForm

(3) -> symbol?(true::OutputForm pretend SExpression)

(3) false
Type:
Boolean
(4) -> string?(true::OutputForm pretend SExpression)

(4) true
Type:
Boolean

However, maybe I was "overambitious".


(6) -> "x"

"_"x_""

Type: String




Ralf