Bill Page wrote:
>
> On 24 March 2014 21:33, Waldek Hebisch <[email protected]> wrote:
> > Bill Page wrote:
> >>
> >> Here is a patch to the FriCAS plugin that I just submitted to TeXmacs.
> >> I have also attached a patch to the texmacs output formatter for
> >> FriCAS to render the TeXmacs symbol <mapsto> for the FriCAS +-> arrow.
> >
> > It is an interesting hack. However, AFAICS the patch depends on
> > FriCAS doing no escaping in the output. Consider the following
> >
> > s := id::String
> > #s
> > s(2)
> > "< some literal string from input file"
> > id([1, 2]) -- make scripted symbol
> >
> > where 'id' is some special Texmacs symbol.
>
> An example from TeXmacs is attached to this email.
>
> > Good input translation
> > make sure that things stay consistent, that is conversion
> > to string produces string containing given symbol, etc.
>
> Yes perhaps that may be an issue. As you can see the current TeXmacs
> interface does display the string as containing just one TeXmacs
> symbol but of course indexing into the string produces characters from
> the TeXmacs encoded name for the symbol. This might seem inconsistent
> but it is quite easy to explain and understand. All we have to do is
> remind people is that TeXmacs symbols are actually multi-character
> symbols in FriCAS. This isn't such an odd idea to TeXmacs users since
> they can in fact key the symbol in exactly this way. And practically
> speaking how ofter do we really need that a symbol convert to a one
> character string?
People build composite names attaching suffix to a stem. Sometimes
they need to go back to the stem. If stem consists of one
character they may just take first character of composite name
and assume that they get what they want.
> The only way I can see to prevent that is to actually re-code the
> TeXmacs symbols into utf-8 characters (where that is possible). Since
> we can handle utf-8 in FriCAS that might be a good idea. It is
> something we can try but at first attempt I found TeXmacs rather
> unfriendly to utf8 encoding. It might require someone with a little
> more knowledge of TeXmacs internals.
I am affraid that bigger problem is caused by fonts. AFAICS, you
have "the same" character coded in differnt fonst via appropriate
prefix. Currently FriCAS has no way to attach font information
to characters (or symbols). We could do such thing similarly
to "scripts": effectively via appropriate mangling of symbol
name. Alternatively, we could take advantage of Lisp property
list and use it to attach arbitrary information to symbols.
In this case we probably would be forced to use uninterned symbols,
which would require adjustment in other parts of FriCAS.
Anyway, at some moment we will have a way to represent faces
and then Texmacs interace will have to convert between Texmacs
and FriCAS form.
>
> > Producing for example TeX or MathML form inside Texmacs
> > session should give sensible results.
>
> ??? What purpose would TeX and MathML serve inside TeXmacs?
Why not? User may want programtically generate TeX or MathML
documents and if Texmacs aspires to be preferable interface
it should allow to do so.
> >> One problem that I am having right now is the display of SPAD compiler
> >> output from the ')compile' command in TeXmacs. It seems like we may
> >> not have the appropriate iohooks in place to demarc the output in such
> >> a way that TeXmacs can synchronize and format it properly.
> >
> > IIRC there are no iohooks specific to compiler.
> >
>
>
> How difficult would it be to add the same iohooks to the compiler
> output that we already have in the interpreter output?
Depends on what exactly you need. There is toplevel ')compile'
handling which may produce some error messages, but when
arguments are OK it dispatches to proper compiler. For
Spad top function is 'compileSpad2Cmd'. At start it prints
message like:
Compiling FriCAS source code from file
/mnt/lv3/fricas/axp19/pp1/pp4/OFTOOL.spad using old system
compiler.
we could easily add a hook before this message.
Compilation is split into phases: reading and tokenizing,
forming piles, parsing, proper Spad compilation and
Lisp compilation. Parsing and proper Spad compilation
works on single toplevel pile at a time (such pile
correspond to a single constructor). The reading and
tokenizing work on the whole file, but is lazy way:
once a pile is complete is is passed the next stage.
For each constructor we get one or two (in case of
category with default implementations) Lisp files
to compile.
We could easily add iohooks around existing stages
and hook at the end of whole compilation. There is
a glitch however: compilation may end up with an
error, then control is passed to toplevel. If we
add hooks inside normal program code, they will
be skipped in case of error. We can add hooks in
such a way that they will be run in error case too,
but in the past I noticed that construct that I used
to accomplish that interfered with debugging. So
there is some work to do to have precise hooks at
the end without lessening debugging capabilities.
It should be relatively easy to add a general hook
saying that there was error exit to toplevel.
--
Waldek Hebisch
[email protected]
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
