Peter Broadbery wrote:
>
> A second issue is that Aldor is much stricter about imports and function
> declarations. I have a set of changes that may help to address these, but
> there is a bit more to do. If there's anyone who wants to help with these,
> it would be appreciated.
Just a comment: current Spad compiler essentially imports every
domain that is sees: types of function arguments, type of value,
etc. This is creasy, because set of visible functions depends
on exact computation path taken in the compiler -- slight change
to compiler code and suddenly something does not compile
because needed domain is not longer visible.
I would like to have well-defined systematic handling of visiblity.
ATM I am not sure if I like Aldor way. IIUC the afficial Aldor
statement is that one has to explicitely import everything.
This is simple to implement and clear, but may be restritive
in practice (I do not not how restrictive). At theoretical
level I considered different approach: compile first treating
everyting from library as visible and then reject that types
which are "unjustified". Namely, some things are visible,
those are "justified". Given justified function with argument a
of type T, function from T used as last step of computation of
a is justified too. Similarly, when f comes from T, argument
of f is justified and of type T, then f is justified too.
Theoreticaly it looks nice, while more complex than expicit
imports is still reasonably easy to describe. I guess that
implementation should not be very hard. I am not sure
how it work in practice.
Anyway, in current algebra I have added several expicit imports
to I plan to add more.
Concerning function signatures, recently I improved capability
of Spad to infer signatures so that one can give only minimal
information needed to choose correct signature. OTOH Spad
produces warning when there is more than one possible
signature and I added explicit declarations to disambiguate
all cases that used to produce warnings.
There is tiny difference between user (Spad programmer) convenience
and sloppy coding, but while I would like to make Spad coding
more convenient I am commited to remiving/fixing sloppy code
from FriCAS library.
--
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
