On Sun, Jul 10, 2022 at 07:59:08PM +0100, Paul Onions wrote:
> On 10 Jul 2022, at 14:28, Waldek Hebisch <[email protected]>
> wrote:
> >
> > ...
> >
> > However, 'showSummary' really expects a Spad type. In
> > my example type expression works because arguments
> > are evaluated by Boot before calling 'showSummary'.
> > 'showSummary' will work with many unevaluated type
> > expressions but using it in such way really is abuse
> > and will fail in corner cases.
> >
> > At Spad level one could do:
> >
> > show_imp_summary(t : Type) : Void == showSummary(t)$Lisp
> >
> > (wrapping it in appropriate package).
>
> Okay, looks like the SPAD route is the most robust route and so should be the
> route I take. It’s a bit annoying because I was hoping to use Boot/Lisp, but
> only because I can then do “background” queries from Frimacs without
> upsetting the prompt number in the REPL.
>
> I don’t suppose there’s an easy way to freeze the prompt number for a single
> SPAD evaluation?
Hmm, if you do:
)boot parseAndEvalToString('"1 + 1")
the effect is to execute what is in argument given to parseAndEvalToString,
but without change to step number. Changes to variables and
functions definitions are still visible. If you wish better isolation
from current computation you could use frames. Unfortunately
the interace to frame machinery is somewhat clumsy, to make
it easier to use we probably could add frame stack, so that
one would be able to push current frame on the stack, do some
computations in new frame and then pop frame from stack to
restore user state.
> > Big (and still not full resolved) trouble with type
> > expressions is that there may be type errors inside
> > type expression. So we can not depend on type
> > expression being well-formed and we can not use
> > normal type rules to exclude wrong stuff.
> > Related trouble is that Boot code in several
> > places passes junk to various routines. Due
> > to small number of checks junk goes trough
> > and in simple cases look "working". But there
> > a lot of work to make our type machinery
> > really robust.
>
> For me the Boot codebase is difficult to understand because it looks like a
> big, amorphous collection of functions. I get lost, not knowing which way is
> up, or down. Maybe it would benefit by introducing some kind of module
> structure, with well-defined interfaces to limit cross-module linkage? Just
> something as simple as Common Lisp’s package system perhaps?
Well, James Davenport said about interpreter code: "it is a mess".
Lack of packages is just small part of the problem.
ATM main main tools is 'grep', it allows to find out uses/users
of given routine. You will see that routines are divided
thematically between files (there is Spad compiler group,
browser group, Aldor interface group, runtime support group,
utilities and interpreter proper). OTOH there were several
transitions and there are still traces of old things.
And structure is logical from historical point of view,
but subotimal for current use.
--
Waldek Hebisch
--
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/20220710202904.GA8555%40fricas.math.uni.wroc.pl.
