On 07/10/2018 06:35 PM, Waldek Hebisch wrote: > 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.
Isn't it also the case that suddenly something doesn't compile anymore only because there is a new domain (automatically imported) that exports the similar functionality so that now a function that does not explicitly state from which package/domain it should be called. What I definitely don't want is that a .spad file cannot be compiled anymore only because someone added another .spad file. For that reason, I'm very much in favour of giving the programmer full control of what is imported and what is not visible. As far as I remember, if I write x: T := foo(...) then T will be imported. Giving explicit types is not necessarily a bad thing. The names of variables are not always so telling that code becomes easy to read. Peter once suggested to let an IDE show the type of a variable in a pop-up bubble when hovering with the cursor over that variable. That would be great. But I definitely don't want to just hide the type. Just my 2 cents. Ralf -- 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.
