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.
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?
>>> 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.
