)lib and domain variables

[Ralf Hemmecke]

Obviously, ")lib FOO" does more than I would have expected.

I realized that after

setFormat!(FormatMathJax)$JFriCASSupport
)lib FOO

there was no MathJax output anymore.

The reason seems to be that ")lib FOO" clears domain variables.
That, is of course problematic for the domain that switches on/off the
output in my new formatting framework.

Not over problematic since FormattedOutput might be handled otherwise in
the future, but still I was surprised that loading code for another
domain/package would have effect on other domains.

Ralf

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

FormattedOutput: Exports == Implementation where
OFC ==> OutputFormatterCategory
Exports ==> OFC with
setFormats!: List OFC -> Void
++ \spad{setFormats!(l)} takes a list \spad{l} of formatters and
++ sets this for future output in a session.
Implementation ==> add
Rep ==> Record(out: OutputForm, step: Integer)
import from Rep
rep x ==> (x@%) pretend Rep
per x ==> (x@Rep) pretend %

formatters: Reference List OFC := ref empty()

setFormats!(l: List OFC): Void == setelt!(formatters, l)

convert(e: OutputForm, n: Integer): % == per [e, n]

display(x: %): Void ==
for F in deref formatters repeat
display(convert(rep(x).out, rep(x).step)$F)$F

[Waldek Hebisch]

On Tue, Oct 06, 2020 at 01:11:26PM +0200, Ralf Hemmecke wrote:
> Obviously, ")lib FOO" does more than I would have expected.
>
> I realized that after
>
> setFormat!(FormatMathJax)$JFriCASSupport
> )lib FOO
>
> there was no MathJax output anymore.
>
> The reason seems to be that ")lib FOO" clears domain variables.
> That, is of course problematic for the domain that switches on/off the
> output in my new formatting framework.
>
> Not over problematic since FormattedOutput might be handled otherwise in
> the future, but still I was surprised that loading code for another
> domain/package would have effect on other domains.

Well, normal situation during developement is reloading, that
is replacing old version of domain by new. In such case we
want to get rid of all references to old domain. This is
done by clearing all domain variables. Such behaviour is
necessary for reloading because currently we have no way
of tracking dependencies so need to clear all variables.
OTOH for most domains this is not a problem because domains
are functional and after reinitialization we get them
in the same state as before.

Clearly, for replacing Boot code by Spad we need domains
which will preserve values of variables. My current
idea is to have list of "system" domains which do not
reference much outside and for which variables are
preserved (which is how Boot works).

--
Waldek Hebisch

[Ralf Hemmecke]

> Clearly, for replacing Boot code by Spad we need domains
> which will preserve values of variables. My current
> idea is to have list of "system" domains which do not
> reference much outside and for which variables are
> preserved (which is how Boot works).

Well, the whole thing is only a problem for advanced users who actually
do use )lib and )compile. I understand, that you would like system
domains (sounds like "runtime support domains"). Such a distinction I
can support, but otherwise I do not like much that there are two
different kinds of domains.

In fact, when you introduce runtime-support stuff, it would make sense
to clean up the library by moving all $Lisp calls out and rather provide
a domain/package "RuntimeSupport" with a clear and sufficient API so
that nobody has to call any foo$Lisp anymore.

Ralf

[Waldek Hebisch]

On Tue, Oct 06, 2020 at 05:16:20PM +0200, Ralf Hemmecke wrote:
> > Clearly, for replacing Boot code by Spad we need domains
> > which will preserve values of variables. My current
> > idea is to have list of "system" domains which do not
> > reference much outside and for which variables are
> > preserved (which is how Boot works).
>
> Well, the whole thing is only a problem for advanced users who actually
> do use )lib and )compile. I understand, that you would like system
> domains (sounds like "runtime support domains"). Such a distinction I
> can support, but otherwise I do not like much that there are two
> different kinds of domains.

It is easy to specify that system should have various "good"
features. Unfortunately, we may end up either with unimplementable
specification or with something that is extremaly hard to
implement. So we need to comprimise implementing "good"
feature that we can implement and living with things that
are hard to fix. I consider ability to do incremantal
developement as essential. Once we have this there is
problem what will happen with variables...

Well, low level domains by very nature must be different
from normal domain. When you do Spad function call
there is _runtime_ search to find corresponding routine.
Clearly seach routine will do its own functions calls.
If such calls were handled in general way we would have
infinite recursion...

I must admit that currently I plan to have parameterless
system domains. In such case search for right function
can be done at compile time. Also, for parameterless
domains variables can be stored outside domain vector,
so that the survive ')lib' without any extra effort.

> In fact, when you introduce runtime-support stuff, it would make sense
> to clean up the library by moving all $Lisp calls out and rather provide
> a domain/package "RuntimeSupport" with a clear and sufficient API so
> that nobody has to call any foo$Lisp anymore.

Yes. More precisily, some $Lisp calls call Boot code, that
should go to low level Spad domain. Remaining calls are
primitives. It make sense to create pseudo-domain say
'Builtin' and modify complier so that calls to that
domain work in expected way. OTOH open-ended interface
to other languages is useful, but I do not want to
insist that the other language is Lisp.

--
Waldek Hebisch

[Ralf Hemmecke]

> I must admit that currently I plan to have parameterless
> system domains. In such case search for right function
> can be done at compile time. Also, for parameterless
> domains variables can be stored outside domain vector,
> so that the survive ')lib' without any extra effort.

OK, that would be sufficient as FormattetOutut comes without parameters.
I guess, it would still be a problem, since the variable here contains
pointers to other domains that might change their address, right?

Ralf