On Sun, 21 Feb 2021 at 19:19, Ralf Hemmecke <[email protected]> wrote: > > > > On 21.02.21 18:53, Peter Broadbery wrote: > > 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. > > BTW, I never said that I like double underscores in identifiers. I just > think that we should rather stick with using CamelCase identifiers in > Aldor/SPAD code and not being driven by naming conventions in other > languages (neither Lisp nor C). > > If you like then change the Aldor lexer. I find it then just a little > annoying that the underscore is no longer an escape character in all > situations. >
The plan would be that the underscore would only be an escape character within an identifier if it changed the treatment of the following character. So _+ would be an identifier called '+', mod_+ would be 'mod+' (as today), but foo_bar would be 'foo_bar'. Calls to lisp hyphenated names would still need underscores, so 'read_-byte', etc > Long time ago I also heard Stephen Watt thinking aloud to change the > escape character from underscore to something else. I would also be open > to that, but have no good suggestion for another escape character. > There are, however identifiers like ts_v_+ in FriCAS or mod_+ in Aldor, > that rely on _ being an escape character and would probably look strange > with another escape character. > > The backslash would be fine if we didn't have identifiers like /\ and > \/. However, if the character set for identifiers would be extended to > unicode, then backslash would be OK. Unicode identifiers would also > allow for more operation symbols like > > Unicode Character 'CIRCLED PLUS' (U+2295). > > and more. (Well... hopefully that doesn't start the discussion about > SemiGroup vs. AbelianSemiGroup again.) > > > >> 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.) > > Peter, that would be great, but I fear that doesn't make everyone happy > since it requires a certain editor with your plugin, right? > The certain editor would be intellij. I like it, at least for certain types of work. Others will have other opinions, and as with vi & emacs, each to their own. > >>> 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? > > I would love to see such a change and I would happily help in this > endeavour. > > Ralf > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/7fee7312-a143-8cf9-92d2-b194e30d2e10%40hemmecke.org. -- 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-BPWXktmrMMadSJCFjdXJf_8obVAnNzmzwWn8W4-o2Sw%40mail.gmail.com.
