Differences between Spad and interpreter.
Waldek Hebisch
and interpreter smaller. Below few differences I
noticed:
Spad treats 'otherwise', 'when', 'exquo', 'div',
'suchthat', 'yield', 'leave', 'not', 'unless', 'until'
as keyword, interpreter not. 'otherwise', 'when', 'suchthat',
'yield', 'unless' are unused. Some day 'yield' will be
used for generators, so it makes sense to reserve it now
as keyword. But I would rather turn otherwise', 'when',
'suchthat' and 'unless' into normal identifiers.
'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.
'div' is strange: in algebra it is only used as
a name for divisors. Maybe we should make it into
ordinary name?
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.
Shoe treats 'cross', 'of', 'structure' as keywords.
Interpreter treats diffretly _ (escape) followed by space:
in spad it introduces space into name, but in interpreter
such spaces are ignored. This has also effect for line
continuation, interpreter ignores leading spaces on
contination lines.
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
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...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
> I would like to make syntactic differences between Spad
> and interpreter smaller.
> What do you think about following proposals:
>
> - make 'exquo' and 'yield' into keywords in interprter.
Yes. I assume that you mean to parse 'exquo' as a binary infix
operator in the interpreter?
I think it is unfortunate that as an operator that returns
Union(...,"failed") the name is irregular. Most such operators have
names like 'subtractIfCan' with 'IfCan' as a suffix. But 'quoIfCan'
seems awkward to me and I think it would be nicer to use a single
character marker similar to ! and ?. A name with a trailing % might
be suitably mnemonic for such "partial" operators. Then 'quo%' and
'subtract%' etc.
Of course an option to parse other binary operators in infix form
would also be nice.
> - make 'break', 'default', 'define', 'do', 'export',
> 'free', 'inline', 'local', 'macro', 'rule' into
> keywords in Spad
Yes. I thought 'macro' was already a keyword, no? Does Spad in FriCAS
allow parameters in macros?
> - turn 'otherwise', 'when', 'div', 'suchthat' and 'unless'
> into ordinary names
Yes.
> - turn 'cross' into keyword (it is currently used in
> algebra, so we would have to rename current uses, for
> example to vectorProduct)
Yes. What would be a typical usage of 'cross'? Do you also think of
adding Cross as a built-in type similar to Aldor?
> - eliminate special treatment of spaces after escape
> in interpreter
>
Yes.
> 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...
>
This sounds good to me.
Regards,
Bill Page.
Ralf Hemmecke
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
Ralf Hemmecke
> Union(...,"failed") the name is irregular. Most such operators have
> names like 'subtractIfCan' with 'IfCan' as a suffix. But 'quoIfCan'
> seems awkward to me and I think it would be nicer to use a single
> character marker similar to ! and ?. A name with a trailing % might
> be suitably mnemonic for such "partial" operators. Then 'quo%' and
> 'subtract%' etc.
Bill, isn't "operator" in SPAD just standing for an ordinary function
that can be used in infix form?
There is no reason that exquo would have to return Union(..., "failed").
For any operator foo one should be able to define something like
(x: X) foo (y: Y): Z == ....
for any types X,Y,Z.
Unfortunately, in SPAD, one still has to write extra parentheses.
((x: X) foo (y: Y)): Z == ....
to get the precedence right. :-(
Ralf
Bill Page
> Bill Page wrote:
>> I think it is unfortunate that as an operator that returns
>> Union(...,"failed") the name is irregular. Most such operators have
>> names like 'subtractIfCan' with 'IfCan' as a suffix. But 'quoIfCan'
>> seems awkward to me and I think it would be nicer to use a single
>> character marker similar to ! and ?. A name with a trailing % might
>> be suitably mnemonic for such "partial" operators. Then 'quo%' and
>> 'subtract%' etc.
>
> Bill, isn't "operator" in SPAD just standing for an ordinary function that
> can be used in infix form?
>
I can accept that as the intended meaning this this case.
> There is no reason that exquo would have to return Union(..., "failed").
I agree. My comment only concerns the current library convention
regarding names that end in 'IfCan'. It just so happens that all
except one implementation of exquo in the library does return this
sort of Union (aka. Maybe constructor).
> For any operator foo one should be able to define something like
>
> (x: X) foo (y: Y): Z == ....
>
> for any types X,Y,Z.
>
> Unfortunately, in SPAD, one still has to write extra parentheses.
>
> ((x: X) foo (y: Y)): Z == ....
>
> to get the precedence right. :-(
>
Yes, although in the current library code overloading is usually
avoided in a given context and so separately declaring the type of foo
is sufficient.
foo: (X,Y)->Z
x foo y == ...
The question is how to declare an arbitrary name (not already
built-in) as such an operator. Any such mechanism has to be outside
the Spad language as such so that parsing does not depend on context.
It seems strange to build an abbreviation as specific as 'exquo' into
the language. But since 'quo' is already built-in I suppose that a
name like 'quoIfCan' or 'quo%' might not be unexpected. If it were
possible to declare arbitrary names as infix operators then naming
could clearly remain as just a library convention.
Regards,
Bill Page.
Waldek Hebisch
>
> > Shoe treats 'cross', 'of', 'structure' as keywords.
>
> What exactly is cross for? Do you want to introduce Cross as a type in SPAD?
One possible use is for iteration over products -- in normal
itertion iterators go in parallel, 'cross' may build iterator
over product. That would need special type, in particular
something like Aldor Cross may be needed.
> > 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.
>
With yesterday interpreter rules this_ is_ one_ identifier
gives 'thisisoneidentifier'. Today atfer change you get
four separate identifiers: 'this ', 'is ', 'one ' and 'identifier'.
This is because I put multiple spaces and interpreter ignored
the whole sequence of spaces. Yesteday your example gave
'thisisoneidentifier', today 'this is one identifier'.
Yes, I hope nobody will use such identifires needlessly.
However, somtimes they may be useful. In 'tex.spad.pamphlet'
we have:
op = '_ => " \ "
This is IMHO sensible use: op is a symbol representing separator
between element. Space means that space should appear in
the output. Of course, one can write the able as:
op = " "::Symbol => " \ "
but I do not want to disallow first version.
However the other difference is that with yesterday rules code like:
if x then y_
else z
was read as:
if x then yelse z
that is interprter thought that you wrote 'yelse'. Trying to use
this would be IMHO very undesible.
> 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.
>
Plans yes. However currently in some places Spad compiler
automatically imports various domains. Without disabling
this automatic import the 'single function import' IMHO
make no sense. But currently algebra depends on this
automatic import. From point of view of a purist one
should disable automatic imports and fix algebra.
But ATM I am not sure what is the best way...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
do you see hope to weaken the precedence of : so that I would be able to
write
(x: X) foo (y: Y): Z == ....
instead of
((x: X) foo (y: Y)): Z == ....
?
Would I only have to change the value in s-parser.boot?
https://github.com/hemmecke/fricas-svn/blob/master/src/interp/s-parser.boot#L54
Is this file for the SPAD parser or also the parser for the Interpreter
language?
With which values could I experiment?
My guess would be that
[":", 1005, 1006]
should work, but I'm not sure.
Or maybe [":", 123, 123] so that it binds just a little higher than "=="?
Can you help?
Ralf
Waldek Hebisch
>
> Hi Waldek,
>
> do you see hope to weaken the precedence of : so that I would be able to
> write
>
> (x: X) foo (y: Y): Z == ....
>
> instead of
>
> ((x: X) foo (y: Y)): Z == ....
>
AFAICS now you can write:
(x: X foo y: Y): Z ==
I probably would like you precendence more then current one,
but other folks may have different opinions. And I a bit affraid
that this can have undesirable conseqences in other places.
> Would I only have to change the value in s-parser.boot?
>
> https://github.com/hemmecke/fricas-svn/blob/master/src/interp/s-parser.boot#L54
>
> Is this file for the SPAD parser or also the parser for the Interpreter
> language?
Currently only for Spad parser -- in interpreter precedences are
hardcoded.
>
> With which values could I experiment?
>
> My guess would be that
>
> [":", 1005, 1006]
>
> should work, but I'm not sure.
That is opposite of what you want, with such precedence you
would write:
(x :(X) foo y :(Y)) : Z
> Or maybe [":", 123, 123] so that it binds just a little higher than "=="?
>
Certainly bigger than precedence of ':='. Also unequal values
seem more reasonable: you want more on the left, while the
same on the right.
For experiments try:
)boot $RawParseOnly := true
this will print just the output of Spad parser (and you
can just have expression you want without other stuff).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Ralf Hemmecke wrote:
>>
>> Hi Waldek,
>>
>> do you see hope to weaken the precedence of : so that I would be
>> able to write
>>
>> (x: X) foo (y: Y): Z == ....
>>
>> instead of
>>
>> ((x: X) foo (y: Y)): Z == ....
>>
>
> AFAICS now you can write:
>
> (x: X foo y: Y): Z ==
>
> I probably would like you precendence more then current one, but
> other folks may have different opinions.
OK. But *who* are these people? In case someone strictly prefers the
current version, he/she should speak up *now*!
I really really want that change!
> And I a bit affraid that this can have undesirable conseqences in
> other places.
OK, maybe one has to modify some .spad files in certain places, but I'm
willing to do this on a branch and see how far I can get.
(Maybe I should first restart my testsuite stuff, though.)
>> Is this file for the SPAD parser or also the parser for the
>> Interpreter language?
>
> Currently only for Spad parser -- in interpreter precedences are
> hardcoded.
That's a pitty that it's hardcoded in the interpreter, but IIUC you
wanted the unify the parsers anyway, so it's only a matter of time.
>> With which values could I experiment? Or maybe [":", 123, 123] so
>> that it binds just a little higher than "=="?
> Certainly bigger than precedence of ':='.
Yes, of course.
> Also unequal values seem more reasonable: you want more on the left,
> while the same on the right.
I have no real idea what theas number actually mean wrt left and right.
I'll try [":", 130, 129].
> For experiments try:
>
> )boot $RawParseOnly := true
>
> this will print just the output of Spad parser (and you can just have
> expression you want without other stuff).
I don't really understand what you mean by that. Since the precedence
values are for spad, I expect the change only to be visible when I
compile a .spad file. You seem to say that I should do something else?
Or did you just mean
)boot $RawParseOnly := true
)compile somesimplecode.spad
?
Ralf
Bill Page
> On 01/10/2012 06:27 PM, Waldek Hebisch wrote:
>>
>> Ralf Hemmecke wrote:
>>>
>>> do you see hope to weaken the precedence of : so that I would be
>>> able to write
>>>
>>> (x: X) foo (y: Y): Z == ....
>>>
>>> instead of
>>>
>>> ((x: X) foo (y: Y)): Z == ....
>>>
>>
>> AFAICS now you can write:
>>
>> (x: X foo y: Y): Z ==
>>
>> I probably would like you precendence more then current one, but
>> other folks may have different opinions.
>
> OK. But *who* are these people? In case someone strictly prefers the
> current version, he/she should speak up *now*!
> I really really want that change!
>
Sorry, Ralf, but I am one who prefers it the way it is now. It seems
very natural to me that : binds very tightly. This looks nice, tidy
and Axiom-friendly (fewer parenthesis!) to me:
(x: X foo y: Y): Z == ...
I read the Z is the type of the function applied to the whole
expression inside ( ... ).
With this notation:
(x: X) foo (y: Y): Z ==
I (naturally?) focus on
(y: Y): Z
and wonder what this means. In Aldor I usually end up writing:
((x: X) foo (y: Y)): Z == ...
because it does not otherwise work the way I expect.
>
>> And I a bit affraid that this can have undesirable conseqences in
>> other places.
>
>
> OK, maybe one has to modify some .spad files in certain places,
> but I'm willing to do this on a branch and see how far I can get.
> (Maybe I should first restart my testsuite stuff, though.)
>
Why are you so motivated to make this change?
> ...
Regards,
Bill Page.
Ralf Hemmecke
> Why are you so motivated to make this change?
Good question. My first motivation is to make it compatible with Aldor.
Of course, that's a weak reason to make something compatible with a dead
language.
First of all, I agree that one might easily be misled to focus on
(y:Y):Z. But after a little thought and with the knowledge that : means
type annotation, what should (y:Y):Z actually be? y being of type Z?
Since two colons for one object make no sense, the initial focus is
rather natually ruled out.
Now let me invent a reason for why I find the Aldor way more attractive.
Look at
(a:%+b:%):%
(where I have deliberately removed spaces. It is quite hard for a human
to parse this correctly. I have to look for the top-level operator
inside the parentheses. Also
(a:SparseUnivariatPolynomial(Integer) *
b:Fraction(SparseUnivariatePolynomial Integer)):
Fraction(SparseUnivariatePolynomial Integer)
(a:SUP(Integer) * b:Fraction(SUP Integer)): Fraction(SUP Integer)
is not easy to parse.
In
(a:SUP(Integer)) * (b:Fraction(SUP Integer)): Fraction(SUP Integer)
I only have to look for an operator followed by an identifier, followed
by a colon.
Additionally, a quite personal reason (which doesn't count, I know).
Most code in the Algebra library doesn't use this full form of type
annotation (which I regret quite a lot). For me, however, having written
quite a number of Aldor lines, the Aldor way is so common, that I simply
don't want to change and I don't really like to edit my code in those
places if I move the code to SPAD form.
I guess, with you following OpenAxiom quite closely, OpenAxiom also
still has the original non-Aldor precedence.
Ralf
Current count for making it Aldor-like:
Pros: Waldek, Ralf
Cons: Bill