Syntax changes
Waldek Hebisch
1) Allow blocks in braces -- currently supported in interpreter.
This means that braces will no longer work for sets.
2) Inside brackests and braces piles will be turned off.
Currently piles are turned off inside parenthesis. For
example currently Spad allows:
)abbrev package TTT999 TTT999
TTT999(): with (foo : Integer -> Integer) == add (
foo(x) == (
y := x + 5;
y
)
)
Or even:
)abbrev package TTT999 TTT999
TTT999(): with (foo : Integer -> Integer) == add (
foo(x) == (
y := x + 5;
y
)
)
After change the same will work with brackets and braces. Brackets
are especially important as they are used to initialize data
structure and for data structures pile rules lead to unnatural
layout.
3) Nopile mode for Spad parser: when in nopile mode parser will
require blocks in parenthesis or braces and semicolons to
separate statements. By default parser will be in pile mode.
4) Underscore before letter will be significant in identifier
name. That is 'important' and 'import_ant' will be
different identifiers.
Later I plan change interpreter to match. In particular it will
be no longer possible to use piles inside parenthesis (for example
as arguments to functions).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> I propose the following changes to Spad systax:
> 1) Allow blocks in braces -- currently supported in interpreter.
> This means that braces will no longer work for sets.
That sounds great. Thanks for working on this.
In fact, I'd even like nopile mode to be the default. :-)
> 3) Nopile mode for Spad parser: when in nopile mode parser will
> require blocks in parenthesis or braces and semicolons to
> separate statements. By default parser will be in pile mode.
How can I switch to nopile for the whole .spad file?
Do you have similar things in mind as #pile and #endpile in Aldor?
http://www.aldor.org/docs/HTML/chap4.html
> 4) Underscore before letter will be significant in identifier
> name. That is 'important' and 'import_ant' will be
> different identifiers.
At first I thought, it's bad to introduce an incompatible way to what
Aldor has, but in some way, your idea is better. There are files in the
Aldor library that use foo__bar names. That looks even uglier than just
one underscore. In fact, I don't want to see underscores at all in
identifiers unless they are necessary as in mod_+ .
The only question then is what happens later, when the accepted
characterset for identifiers becomes unicode? For which characters will
_ then be an escape character and for which not?
BTW, since you are working on the parser. Could you make +, *, etc.
behave like identifiers if they are a first letter, i.e.
*: (%, %) -> %
should work without writing _*.
Ralf
Ralf Hemmecke
>>> name. That is 'important' and 'import_ant' will be
>>> different identifiers.
> I'd rather have no underscores in identifiers. i.e., I'm against this
> change. _ should allways be the escape character, in my opinion.
I agree, Martin, in SPAD programs there should be no underscores.
But if SPAD should be able to link to other programs one should be able
to have a way to access external names. For example, how would you then
call a function from GMP, for example?
Ralf
Waldek Hebisch
>
> >> 4) Underscore before letter will be significant in identifier
> >> name. That is 'important' and 'import_ant' will be
> >> different identifiers.
>
> I'd rather have no underscores in identifiers. i.e., I'm against this
> change. _ should allways be the escape character, in my opinion.
>
You can have have underscores in identifiers _now_. Just current
semantics is bad: currently you may get unexpected clashes
because single underscore are ignored in comporison.
And underscore will continue to be escape -- the planned change
simply will simply prevent clashes between escaped and unescaped
identifiers (if both are legal).
To put it differently: current semantics is of little use and
surprising to people knowing other languages. For them
current behaviour looks like a bug. Given that it is possible
to fix this I do not see why insist of current broken
behaviour -- if _you_ do not want underscores do not use then.
But insiting that other folks do not use underscores is
just first step to convince them that they should not use
Spad at all.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> semantics is bad: currently you may get unexpected clashes
> because single underscore are ignored in comporison.
Waldek, there might be a little problem. We had that somewhere with the
delay function in SPAD. In Aldor I had to write _delay in order to mean
delay, because delay is a (unused) keyword in Aldor.
So the problem I see is suppose an external program uses and exports a
variable/function with name "repeat" how can SPAD then access that name?
Ralf
Ralf Hemmecke
What would happen with this behaviour after your change?
(1) -> 1_345 +5
(1) 1350
Type: PositiveInteger
Ralf
Waldek Hebisch
I planned change to identifiers, numbers should behave as before.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
Using "_repeat" -- to support such use leading underscore will not
appear in external name (to get one you need to double it, the
same as now).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> appear in external name (to get one you need to double it, the
> same as now).
Now the rule gets confusing to me. Underscores in front of a letter does
not make the underscore special, so the underscore remains in the
identifier.
This rule applied to _repeat give _repeat and not repeat as wanted.
I would rather understand that for such cases one would have to write
repeat_ in a spad program to refer to an external repeat.
Anyway, that actual bad thing is the choice of _ as an escape character.
But I would consider switching to \ instead of _ not to be a good
choice. There are quite nice operators like /\ and \/ that look quite
natural in a mathematical context. Well, we have no unicode yet.
Ralf
Ralf Hemmecke
>>
>> (1) 1350
>> Type: PositiveInteger
> I planned change to identifiers, numbers should behave as before.
OK, but then 1_2 = 12 but a_2 is not a2. In some sense I tend to agree
with Martin, that it is easier thinking if _ is always an escape
character and it would have to be escaped to lose its special meaning.
Ralf
Waldek Hebisch
> > Using "_repeat" -- to support such use leading underscore will not
> > appear in external name (to get one you need to double it, the
> > same as now).
>
> Now the rule gets confusing to me. Underscores in front of a letter does
> not make the underscore special, so the underscore remains in the
> identifier.
>
Underscores _inside_ identifiers which are otherwise useless will be
significant in comparizon (and in external names). In '_repeat'
underscore is _before_ identifier. In 'repeat_ ' underscore is
used to escape space.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> significant in comparizon (and in external names). In '_repeat'
> underscore is _before_ identifier. In 'repeat_ ' underscore is
> used to escape space.
Sorry to be so picky, but I do this to get the rules fixed to the last
point. And consider all cases.
What you write above means that
ab and a_b
are different whereas
ab and _ab
count as the same identifier.
Furthermore
ab_
is the same as the identifier that consists of 3 letters namely a, b and
a final space.
In order to access the external name '_ab' one would have to write __ab
(two underscores in front).
If the external identifier is '__ab' would I have to refer to it with 3
or 4 underscores in front of ab?
Would a_b̈́ be equal or unequal to a__b (both SPAD identifiers after your
change)? I.e is _ inside an identifier switching its class to letter
(not escape)? If not then a_b == a__b should be the case since I can
also have something like a_*b as an identifier. The * is as non-letter
as _. (And mod_* makes sense in my eyes.)
Am I right?
I was proposing the final underscore, since I don't think that spaces in
identifiers is a good idea. (Look at all the problems that occur with
spaces in unix filenames.)
Ralf
Martin Rubey
> Martin Rubey wrote:
>>
>> >> 4) Underscore before letter will be significant in identifier
>> >> name. That is 'important' and 'import_ant' will be
>> >> different identifiers.
>>
>> I'd rather have no underscores in identifiers. i.e., I'm against this
>> change. _ should allways be the escape character, in my opinion.
>>
>
> You can have have underscores in identifiers _now_. Just current
> semantics is bad: currently you may get unexpected clashes
> because single underscore are ignored in comporison.
I don't think that this should be unexpected. But how about emitting a
warning when escaping characters which do not need to be escaped?
Such a warning would also be useful in a different situation, namely
when fricas encounters
whitespace _ whitespace return.
> And underscore will continue to be escape -- the planned change
> simply will simply prevent clashes between escaped and unescaped
> identifiers (if both are legal).
Hm, but it seems to me that the meaning of _ will become dependend on
context, not only on the character that follows.
Please do not include this now.
Martin