On Fri, 19 Feb 2021 at 09:48, Ralf Hemmecke <[email protected]> wrote: > > >> "/mnt/lv3/fricas/axp19/pp1/algreduc2/RDEEFX3a.as", line 36: > >> ei_int : (Z, F, F, SE) -> PSOL2 > >> ......^ > >> [L36 C7] #1 (Warning) Escape character ignored. Do you mean '__'? > >> > > This is just a warning, in first pass of checking Spad code we > > probably can ignore warnings. > > Ooops. Yes, indeed. However, it gives different identifiers in Aldor and > SPAD. In Aldor ei_int is the same as eiint. >
This has always struck me as a bit of a misfeature; It may be better if the lexer was modified to treat '_' as a normal character within identifiers. > > OTOH this is important feature > > for mixed-language code. In Lisp camelCase is not practical, > > From primitives.lisp ... > > (defun |STR_to_CHAR_fun| (s) > > As far as I understand it would be perfectly fine to use |CamelCase| > identifiers in Lisp. So, yes, I agree that there are different naming > conventions in Lisp and Aldor/SPAD, but I don't think that in a > multi-language system (where one language (SPAD) is the main language > and all the others are helper languages that implement the underlying > system) > one must unify the naming conventions. > > That said, yes, let's ignore the underscore warnings in an approach to > bring the full library to Aldor. > > > Yes, I know this. One point of this excercise was to see how many > > explicit imports I would need. It was disappointing that other > > problems apparently dwarfed issue with imports. > > One way to avoid most of the explicit imports is to always add the type > to a variable when you first assign it. > That has two (at least for me) important aspects. > > (1) Readers of the code explicitly see what the type of the variable is > and don't have to figure it out from the context --- that's sometimes > not so easy. (Maybe that can some day be relaxed, if we have editors > that show the type of an expression when your mouse hovers over it.) > We are potentially quite close to this for Aldor - a lot of the groundwork has been done, but not there yet. > (2) In Aldor 'a: A' means also an implicit 'import from A'. Aldor has :* > for avoiding this implicit import. See Section 8.13 of the Aldor User Guide. > > If there is too much in scope one has to help the compiler in certain > places to disambiguate function calls with the same name and argument > types. But that is easy with $ and @. Actually, Aldor is quite good in > selecting the right function if it can figure out enough type > information from the context. > > > IIUC Aldor does not suport "failed" (with Spad notation) as a type, > > which leads to massive source changes (this is in the language > > differences page). > Aldor does allow 'Union(a: T, failed?: 'failed'), which might be similar enough. Tangentially, what would be the issues with switching the algebra code to use Partial instead of the Union? Peter -- 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/CAK%3DmBN_BdyEwsd-Vt%2BsLJTkB-DS5A%3Do2JxLTvLK8H3Si0xRBjQ%40mail.gmail.com.
