[Replying privately as not totally thought through] Proposal sounds like its ok, but does it deal with package imports, especially for things like map and reduce operations?
To be a bit more specific my plan for aldor is to 1) introduce 'import from F', where F is a domain or package constructor. 2) drop the requirement for function return types to be specified. Peter On Tue, 10 Jul 2018, 17:35 Waldek Hebisch, <hebi...@math.uni.wroc.pl> wrote: > 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 fricas-devel+unsubscr...@googlegroups.com. > To post to this group, send email to fricas-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/fricas-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
