>> "/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.
> 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.)
(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).
Yes, true. Honestly, I don't like "failed" or Union(X, "failed") very
much. (In particular the double quotes are confusing.) I better liked
the Partial(X) construction in the Aldor library. And certainly such
Partial domain can be programmed and used in SPAD that's not a big deal.
So we could slowly replace Union(X,"failed") by Parial(X) and still have
running SPAD code.
Furthermore, in you code I had to replace
for k in rest(lk) repeat
...
is?(tk, EXP) => "iterate"
...
for k in rest(lk) repeat
...
is?(tk, EXP) => iterate
...
The error message
"/home/hemmecke/backup/git/qeta/tmp/RDEEFX3a.as", line 80:
is?(tk, EXP) => "iterate"
............................^
[L80 C29] #2 (Error) (After Macro Expansion) Have determined 2 possible
types for the expression.
Meaning 1: Symbol
Meaning 2: String
Expanded expression was: "iterate"
does not explicitly say why this is a problem, but I guess it is,
because Aldor want ONE type for the block following the 'repeat' keyword.
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/963e1805-2491-6bc2-74da-6b4f7ea79121%40hemmecke.org.
