Ralf Hemmecke wrote:
> 
> The file msgdb.boot contains
> 
> =============================================
> sayBrightlyNT1(x, $fricasOutput) ==
>     if x then
>         ATOM(x) => brightPrint0(x)
>         brightPrint(x)
> 
> sayBrightly1(x, str) ==
>     if x then
>         sayBrightlyNT1(x, str)
>         TERPRI(str)
>         FORCE_-OUTPUT(str)
> 
> sayMSGNT(x) == sayBrightlyNT1(x, $algebraOutputStream)
> 
> sayHtml(x) == sayBrightly1(x, $htmlOutputStream)
> 
> sayMathML(x) == sayBrightly1(x, $mathmlOutputStream)
> 
> sayTeX(x) == sayBrightly1(x, $texOutputStream)
> ==============================================
> 
> Is there some magic working here?

Yes.  Boot '$...' variables are Lisp dynamic variables.
The line

sayBrightlyNT1(x, $fricasOutput) ==

means that when executing 'sayBrightlyNT1' the second
parameter to 'sayBrightlyNT1' will be assigned to
'$fricasOutput' and effect of this assignment will
be visible to all routines called from 'sayBrightlyNT1'.
In other words, the line above is an abbreviation
for the following:

sayBrightlyNT1(x, new_fricasOutput) ==
    UNWIND_-PROTECT(
       old_fricasOutput := $fricasOutput
       $fricasOutput := new_fricasOutput
       -- actual body of sayBrightlyNT1,
       $fricasOutput := old_fricasOutput)

Main point of this construct is that when
execution of 'sayBrightlyNT1' ends, old value
of '$fricasOutput' will be restored.  It does
not matter if execution of 'sayBrightlyNT1'
was interrupted due to error, value of
'$fricasOutput' should be correctly restored.

> The parameter $fricasOutput in
> sayBrightlyNT1 is not used. Does that mean that sayTeX is actually the
> same function as sayMathML?

No, see above.

> In fact, I have another problem.
> 
> (1) -> sayBrightlyNT1("\%abc",_$texOutputStream$Lisp)$Lisp
> %abc
> 
> Yes, the backslash is swallowed. In TexFormat it says:
> 
> https://github.com/fricas/fricas/blob/master/src/algebra//tex.spad#L261
>         -- Remark: for some reason, "\%" at the beginning
>         -- of a line has the "\" erased when printed
> and then some workaround code follows.
> 
> But the reason seem rather clear to me: the definition
> 
>   sayTeX(x) == sayBrightly1(x, $texOutputStream)
> 
> is wrong.
> 
> sayBrightly1 is implemented via brightPrint0 and this
> function tries to do fancy things (no matter whether $texFormatting is
> true or false).
> 
> https://github.com/fricas/fricas/blob/master/src/interp/msgdb.boot#L622
> 
> It's wrong. When I send a carefully assembled TeX string to the output
> stream, I want it to stay as it is. I don't want % or \ be interpreted
> in any way, since that has been done by TexFormat.
> 
> Better would perhaps be
> 
>   sayTeX(x) == sayString(x)
> 
> but since I don't understand how the different output streams
> $algebraOutputStream, $texOutputStream etc. get their data, that
> definition doesn't seem to be fully correct.
> 
> What should we do about it? I definitely don't want to keep this remark
> https://github.com/fricas/fricas/blob/master/src/algebra//tex.spad#L261
> in the code, because it's a workaround for something unnecessary.

Well, we need to untangle usage of streams first.  Currently
we have a lot of redirections in various ways.  Some redirections
probably are useless or evan harmful.  But most is necessary to
ensure that output goes to correct stream.  This redirection
code is tangled with low level formatting code.  I started
cleaning up stream code in 2007, but soon I have found more
pressing needs...


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

Reply via email to