> 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
--
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/28bcc183-0113-f2fd-3da2-01af1f1178ef%40hemmecke.org.
