Message identifiers and io hooks

3 views
Skip to first unread message

Waldek Hebisch

unread,
Apr 14, 2026, 10:35:02 AM (3 days ago) Apr 14
to fricas...@googlegroups.com
After recent changes most message identifiers serve no useful
purpose for FriCAS itself. They are passes to 'ioHook' and
in principle various interfaces can use them.

Managing identifiers requires some effort and I would prefer
to remove them. Looking at jFriCAS I see that it uses few
message identifiers: S2GL0012, S2GL0013, S2GL0014, S2GL0016.
efricas uses S2GL0012 S2GL0013 S2GL0014. I am not sure
what is used by Sage interface and Texmacs, but probably
the same.

One possible way to proceed is to keep used identifiers and
say pass a fake identifier for all unused cases. Another
possibility is to replace used cases by separate hooks and
no longer pass identifiers to hooks. The first way would be
almost invisible to clients (of course once we identify all
identifiers used by the clients). Second one would give
nicer program structure, but means that all clients need
change. That probably would need some transition period,
keeping identifiers in transition period for benefit of
older clients.

Opinions?

--
Waldek Hebisch

Martin R

unread,
Apr 14, 2026, 11:20:06 AM (3 days ago) Apr 14
to FriCAS - computer algebra system
As far as I know (so, 99.9% sure), sagemath does not depend on them.

In principle, I do like the idea of identifiers, because it means that once can change the message (e.g., to fix a typo or make styling uniform) without changing semantics.  However, if managing them is an effort, it is probably not worth it.


Martin

Ralf Hemmecke

unread,
Apr 14, 2026, 4:34:52 PM (2 days ago) Apr 14
to fricas...@googlegroups.com
On 4/14/26 16:34, Waldek Hebisch wrote:
> After recent changes most message identifiers serve no useful
> purpose for FriCAS itself. They are passes to 'ioHook' and
> in principle various interfaces can use them.

Oh, for jfricas we have in webspad.lisp the following.


(setf |$ioHook|
(lambda (x &optional args)
(cond
((eq x '|startAlgebraOutput|) (ws-fmt "BEG:Algebra"))
((eq x '|endOfAlgebraOutput|) (ws-fmt "END:Algebra"))
((eq x '|startPatternMsg|) (ws-fmt "BEG:ERROR"))
((eq x '|endPatternMsg|) (ws-fmt "END:ERROR"))
((eq x '|startKeyedMsg|)
(cond
((eq (car args) 'S2GL0012) (ws-fmt "BEG:Type"))
((eq (car args) 'S2GL0013) (ws-fmt "BEG:Time"))
((eq (car args) 'S2GL0014) (ws-fmt "BEG:TypeTime"))
((eq (car args) 'S2GL0016) (ws-fmt "BEG:Storage"))
('T (ws-fmt "BEG:KeyedMsg"))))
((eq x '|endOfKeyedMsg|)
(cond
((eq (car args) 'S2GL0012) (ws-fmt "END:Type"))
((eq (car args) 'S2GL0013) (ws-fmt "END:Time"))
((eq (car args) 'S2GL0014) (ws-fmt "END:TypeTime"))
((eq (car args) 'S2GL0016) (ws-fmt "END:Storage"))
('T (ws-fmt "END:KeyedMsg"))))
)))


If, instead of sub-conditioning |startKeyedMsg| we would simply get
|startTimeMsg|, |startTypeMsg|, |startStorageMsg|, and the respective
end tags, then changing jfricas would not be soo difficult.
However, I am not sure in which way you want to redesign these message
identifiers.

We anyway have to release a new jfricas with a new FriCAS release.
In that, we will take care of working for the older FriCAS code and the
newer code. We are just not yet sure what is the best way to distinguish
old-fricas from new-fricas. We cannot simply rely on the version string,
since it should also work for people who compile any intermediate
version from the git-repo. At the moment we are thinking about checking
existence of |mkOutputConsoleStream|.
So if it is easily recognizable for jfricas, what the underlying fricas
features are, we do not need backward compatibility wrt. message
identifiers.

Note that we currently (mis-)use the storage message to extract the
|$IOindex|, i.e., the step number, from the output.
If I can cat the message numbers from multiline input/multiline output
reliably, that would be cool.

Actually, I don't care much about what exact structure you find best for
FriCAS, the easier the better. I mostly care to be able to have jfricas
running with the same functionality (or even better). In other words, I
am interested in having begin/end ioHooks for any output, even error
messages.

I haven't thought about it, but jfricas will anyway be lost, if for some
weird reason ends up in the lisp debugger.

Ralf
Reply all
Reply to author
Forward
0 new messages