Before I go into detail... My general wish is to be compatible with
Aldor so it would IMHO make sense to use
http://www.aldor.org/docs/HTML/chap4.html#3
as an orientation (or rather http://aldor.org/docs/aldorug.pdf), but of
course, since Aldor is no longer developed, improvements are welcome.
On 01/06/2012 11:24 PM, Waldek Hebisch wrote:
'exquo' has several uses in algebra as operator. Currently
interprter treats it as a normal function. I think
in interpreter we should also make it into operator.
exquo is not an operator in Aldor. I don't really care whether or not it
is in SPAD/Interpreter. It should be the same kind, of course.
'div' is strange: in algebra it is only used as
a name for divisors. Maybe we should make it into
ordinary name?
OK for me. div is not special in Aldor.
Interpreter treats 'break', 'default', 'define', 'do', 'export',
'free', 'inline', 'local', 'macro', 'rule' as keywords,
but they are not keywords in Spad. 'macro' and 'break'
are handled specialy in Spad, but probably we should turn
all of them into keywords.
Maybe you can additionally reserve all the other Aldor-keywords, that
are not yet keywords in SPAD/Interpreter?
Do you actually see a keyword in SPAD or the interpreter that is not an
Aldor keyword.
Do you see operators in SPAD/Interpreter that are not operators on
Aldor? Could you reserve missing operators (if there are some missing)?
Shoe treats 'cross', 'of', 'structure' as keywords.
What exactly is cross for? Do you want to introduce Cross as a type in SPAD?
Interpreter treats diffretly _ (escape) followed by space:
in spad it introduces space into name,
I hope nobody will ever use a name like
this_ is_ one_ identifier
I rather think that the above should be 4 identifiers and a trailing _
should be counted either as a single _ or simply by ignored.
but in interpreter such spaces are ignored.
That's also unintuitive. Such uses should simply be forbidden for the
sake of readability of a program.
This has also effect for line
continuation, interpreter ignores leading spaces on
contination lines.
I would be happier, if (in case there must be pile mode) it works like
in python, i.e. one could enter multiline functions in a natural way.
OK, that's probably another issue.
What do you think about following proposals:
- make 'exquo' and 'yield' into keywords in interprter.
- make 'break', 'default', 'define', 'do', 'export',
'free', 'inline', 'local', 'macro', 'rule' into
keywords in Spad
- turn 'otherwise', 'when', 'div', 'suchthat' and 'unless'
into ordinary names
- turn 'cross' into keyword (it is currently used in
algebra, so we would have to rename current uses, for
example to vectorProduct)
- eliminate special treatment of spaces after escape
in interpreter
OK for all.
BTW: This is just one part of differences. Eventually
I would like to use the same compiler for interpeter and
Spad (the only difference would be that interpeter should
be more forgiving for type errors (by automatically
inserting coercions). As first step I would like to
use the same scanner for Spad and interpreter. In
principle scanner could have two "modes", one for
Spad and one for interpreter. But using the same
rules is better...
Your plan is very welcome. In fact, if one could control (in the
interpreter) what the search space for the coercion functions is that
would be wonderful.
In fact, I thinnk, like in Aldor it should be possible (in Spad and
interpreter) to just import a single function from some domain like
import foo: % -> % from DomX
Do you have any plan to enable this? I think I've see the
"import from ..." form in OpenAxiom code so maybe Gaby could point to
the particular patches that enable such a feature.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
