binary selectors ambiguity and space

Nicolas,

On 15.05.2006 13:26, nicolas cellier wrote:
> user shall be kindly invited to, for code he has responsibility on.
> That is, when he accepts a method in a browser debugger or any other
> interactive text pane.
>
> But this turn out very annoying when you get warned 20 times or more that you
> should resolve ambiguity over wich you do not have control yet, for example
> when you try to load a package from SqueakMap or Monticello.

How often are cases like
  x+-1
while loading 'normal' packages?
If I've understood correctly
  x+-y
(only variables) would not make problems.

>
> This is why i propose the notification to raise a popup dialog only if
> Parser>>interactive answer true.

An idea:
Announcement of the strict behaviour some time ago: then package
maintainers can fix there packages (shouldn't be too hard ;-) ).

On 13.05.2006 02:10, nicolas cellier wrote:
nc>...
nc> Funny, in current 3.9 spaces are ignored:
nc> i have '1 +-   2' interpreted as (1) + (-2)

At least, if there should be a change in the semantics - for e.g.
allowing selector #+- in the case above -, it would be *much* better to
fail loading a package instead of loading it silently: otherwise the
code would just break at runtime!


Regards,
Stephan


>...

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

On 15.05.2006 20:25, I wrote:
>...

> On 13.05.2006 02:10, nicolas cellier wrote:
> nc>...
> nc> Funny, in current 3.9 spaces are ignored:
> nc> i have '1 +-   2' interpreted as (1) + (-2)
>
> At least, if there should be a change in the semantics - for e.g.
> allowing selector #+- in the case above -, it would be *much* better to
> fail loading a package instead of loading it silently: otherwise the
> code would just break at runtime!

After sending this comment I've seen, that this example is far from the
  x+-1
case: so for such a semantic change there should be
- an announcement,
- a code snippet for scanning the code for cases, where the semantics is
announced to be changed.

Since after changing the semantics this way, the above would not have
any ambiguity, and therefore it would be loaded smoothly...


Regards,
Stephan

>...

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

Le Lundi 15 Mai 2006 20:42, Stephan Rudlof a écrit :
Notification subclass: #PrefixUnarySelectorNotification
   instanceVariableNames: ''
   classVariableNames: ''
   poolDictionaries: ''
   category: 'Exceptions-Kernel'

Scanner>>primaryExpression
   hereType == #word
      ifTrue:
         [parseNode := self variable.
         (parseNode isUndefTemp and: [self interactive])
            ifTrue: [self queryUndefined].
         parseNode nowHasRef.
         ^ true].
   hereType == #leftBracket
      ifTrue:
         [self advance.
         self blockExpression.
         ^true].
   hereType == #leftBrace
      ifTrue:
         [self braceExpression.
         ^true].
   hereType == #leftParenthesis
      ifTrue:
         [self advance.
         self expression ifFalse: [^self expected: 'expression'].
         (self match: #rightParenthesis)
            ifFalse: [^self expected: 'right parenthesis'].
         ^true].
   (hereType == #string or: [hereType == #number or: [hereType == #literal]])
      ifTrue:
         [parseNode := encoder encodeLiteral: self advance.
         ^true].
   (here == #- and: [tokenType == #number])
      ifTrue:
         [self advance.
         "not very clean hack to check for space.
         beside, hereMark/prevMark are broken at end of stream"
         hereMark > (prevMark+1) ifTrue: [PrefixUnarySelectorNotification
               signal: '- is used as unary prefixed selector'].
         parseNode := encoder encodeLiteral: self advance negated.
         ^true].
   ^false


| report |
report := (String new: 128) writeStream.
Smalltalk keysAndValuesDo: [:name :cls |
   (cls isKindOf: Behavior)
      ifTrue: [(Array with: cls with: cls class)
         do: [:class | class selectorsDo: [:selector |
            [class compilerClass new
               parse: (class sourceCodeAt: selector)
               in: class notifying: nil]
            on: PrefixUnarySelectorNotification
            do: [:exc |
               report
                  print: class; nextPutAll: #'>>';
                  nextPutAll: selector; cr]]]]].
report contents inspect.

It was not that easy, because handling is done lately, with two tokens of
advance...
I didn't find anything in 3.9a7029... So, this must be quite unusual.
Would be funny to scan a Monticello repository or SqueakMap...
(above my skills).

Nicolas

Hello All,

I've just digged into
NCITS J20 DRAFT December, 1997 33 of ANSI Smalltalk Standard revision
1.9; in short:
- 'White space is allowed between the '-' and the <number>' for a
numeric literal; and
- 'If a negative <number literal> follows a binary selector there must
intervening white space.'

So your example

>>> On 13.05.2006 02:10, nicolas cellier wrote: nc>... nc> Funny, in
>>> current 3.9 spaces are ignored: nc> i have '1 +-   2' interpreted
>>> as (1) + (-2)
>>>...

is totally legal, but
  x+-1
should not be parsed as
  (x) + (-1)
. I'm interpreting the standard in this case - at least I think it can
be interpreted this way (see below for the definition of binary
operators) - as to parse it as
  (x) +- (1)
, +- being a binary selector.

We should follow the standard IMO, this means to allow
  x+-1
(here I have changed my mind after looking into it). In spite of this I
think it is not a good style to omit spaces here (and it gives a MNU
later, if +- is not defined)...

For points like
  0@-1
this could give the workaround of defining
  @-
as operator (and @+ , too) much sense, because after the standard 0@-1
could be parsed as
  (0) @- (1)
. Moreover a compile warning - 'Please insert spaces! This will be
parsed as ...; is this your intention?' or so - would make sense then
(since the extra message send here decreases performance).

Snippets from the standard draft:


Regards,
Stephan

PS: Nice that you already have code for finding critical cases.

On 15.05.2006 22:27, nicolas cellier wrote:
>...
--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

Hi language designers,

I tried a Unix command to find all one character binary selectors followed
immediately by a minus character:
        $ grep '[+/\\\*~<>=@%|&?!,]-' SourcesFile
       
The above beauty spotted nine occurrences in a Smalltalk-80 sources file from
April 1, 1983:

in Form>>shapeFill:interiorPoint:
        dirs <- Array with: 1@0 with: -1@0 with: 0@1 with: 0@-1.

in ListView>>deEmphasizeView
        aRectangle <- aRectangle insetOriginBy: 0@-1 cornerBy: 0@0
       
and seven occurrences in Cursor class>>initialize, similar to
        offset: -5@-7.

And, seeing this, I do not want to be forced by my proposal to enter a space
between @ and -. And I do not want to learn complicated rules when and where I
have to hit the space key. So, the best to do in this case is to keep it as it
is. At least I've learned from this thread why the minus character is special
cased in the syntax diagrams. Thanks to all of you for teaching me!

Greetings
Wolfgang
--
Weniger, aber besser.

Le Lundi 15 Mai 2006 23:31, Stephan Rudlof a écrit :
Very nice, but i just wonder how many Smalltalk are ANSI?
ST-80 no, VW3,5,7 no...
 * no - as second binary character, no space enforced
 * no space allowed between - and number
Squeak3.9 no...
 * no - as second binary character, no space enforced
GNU Smalltalk version 2.1.9 no...
 * no space allowed between - and number
VA, Smalltalk-X, Dolphin, any other ?

> So your example
>
> >>> On 13.05.2006 02:10, nicolas cellier wrote: nc>... nc> Funny, in
> >>> current 3.9 spaces are ignored: nc> i have '1 +-   2' interpreted
> >>> as (1) + (-2)
> >>>...
>
> is totally legal,

No, it should be interpreted (1) +- (2).
You must force a space between binary selector + and negated number -  2
But (1 +  -  2) should be interpreted (1)+(-2)

If we go for it, that's easy to implement, just have to change xBinary.
And we MUST also emit a warning in interactive parser.
Now, we're taking the compatibility risk if we follow ANSI...
@- at least is a necessary guard indeed...

I'am still in favour of compatibility, but ANSI has precedence over me i
guess.

>
> Regards,
> Stephan
>

Nicolas

Stephan Rudlof wrote:
> NCITS J20 DRAFT December, 1997 33 of ANSI Smalltalk Standard revision
> 1.9; in short:
> - 'White space is allowed between the '-' and the <number>' for a
> numeric literal; and
> - 'If a negative <number literal> follows a binary selector there must
> intervening white space.'

Just out of curiosity, which of the Smalltalks that claim to be ANSI
compliant actually implement the above? A dead giveaway would probably
be Number>>#@- (except that according to ANSI this requires spaces, too,
right? right??? ;-) so can anyone confirm which Smalltalks out there
actually compile according to those rules? Briefly checking VW shows it
doesn't, neither does Squeak. What about others?

Cheers,
   - Andreas

Le Mardi 16 Mai 2006 00:11, Andreas Raab a écrit :
For 1@-2, gnu-smalltalk 2.1.9 does interpret (1) @- (2)
But it cannot handle (-    1).

Nicolas

On 16.05.2006 00:10, nicolas cellier wrote:
Correct.

As longer I think about it, I'm more curious about allowing the space
between the negating - and the number...
One example: how to parse
  1 - 1
? From my interpretation of the standard (with the additional condition
of parsing from left to right) it should be parsed as
  (1) (-) (1)
: Puuh, this is exactly what happens :-) ;
but in the case (1 +  -  2) above the space before the 2 will be ignored
(not leading to a parse error), so the negation - binds from right to
left. So far so good. But this rule does *not* apply for the case of the
second + in (1 + + 2)...

Conclusion: the - is indeed very special.


Stephan

>...

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

Le Mardi 16 Mai 2006 00:11, Andreas Raab a écrit :
In ST/X 5.2.6
    1@-2 is interpreted (1) @ (-2)
But
    1@-  2 is interpreted (1) @- (2)

And (-  1) give a warning
error: non standard Squeak extension: space betwen sign and number.
But we can proceed and get (-1)

Well, not exactly ANSI, but very close to my interpretation...

Nicolas

On 16.05.2006 00:11, Andreas Raab wrote:
> A dead giveaway would probably
> be Number>>#@- (except that according to ANSI this requires spaces, too,
> right? right??? ;-)

My interpretation has been
1. parsing in principal goes from left to right,
2. there is one special case: the - binds from right to left, if it is
standing *alone* before a number,
3. in the case (0@-1) the - would be eaten by parsing the @- operator
while parsing from left to right (' binarySelector ::= binaryCharacter+
', allowing arbitrary many binary characters).

This is my interpretation... Any others?

Case 2. seen together with
4. binding of - from right to left does *not* apply, if a variable is
following,
5. + does not bind like -,
6. (1 - - 1) is allowed, but (1 + + 1) not,
makes it really very special.

Especially 6. feels odd to me.

Note: Squeak follows 6., but not 3..

To get 3. into the standard there would be a need for a further special
case @- before numbers related to the creation of Points AFAICS. But
Points are not covered by the standard.


Best regards,
Stephan

> so can anyone confirm which Smalltalks out there
> actually compile according to those rules? Briefly checking VW shows it
> doesn't, neither does Squeak. What about others?
>
> Cheers,
>    - Andreas
>
>

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

On 16.05.2006 01:39, nicolas cellier wrote:
>...
> In ST/X 5.2.6
>     1@-2 is interpreted (1) @ (-2)
> But
>     1@-  2 is interpreted (1) @- (2)
>
> And (-  1) give a warning
> error: non standard Squeak extension: space betwen sign and number.
                      ^^^^^^

ST/X has Sqeak extensions?

Stephan

> But we can proceed and get (-1)
>
> Well, not exactly ANSI, but very close to my interpretation...
>
> Nicolas
>
>
>

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

Hi,

in this thread, "theStandard" was mentioned now and then. Who is that strange
guy? Is it the one no one wants to hang around with? So they need to pay you for
talking to him? The one, who has stolen the left arrow assignment operator? Give
it back! The one who does not even know what a Point is? Even Euklid knew that,
2300 years ago! Or who does not know how to write a number? And who uses curses
like '!-@-!!!-&-+*' and calls it a binary selector?

Dear friends,
all I can say is:
beware of theStandard,
He is not nice. He is bad. And ugly.

Greetings,
Wolfgang

--
Weniger, aber besser.

Le Mardi 16 Mai 2006 00:11, Andreas Raab a écrit :
In Dolphin 5.1
    (1@-2) is (1) @ (-2)
    (1@-  2) is (1) @-  (2) unlike squeak
    (-   1) is (-1)

So far, haven't found any Smalltalk standard compliant...

Nicolas

you explained:
>Well, the *idea* was that you should not need spaces, and St-76, borrowing from
>APL, had a different character for the semantically different high-minus sign

What's so bad about needing spaces? After all, the space key is one of the
easiest to hit :-). And spaces are already required as separators between
keywords and argument names, aren't they?. It seems quite natural to require
spaces as separators between a binary selector and a "special character" like
minus.

Then you could get rid of the special treatment of the minus character. That is,

the minus character would be allowed as a second character of a binary selector.

On 5/17/06, Dan Ingalls <[hidden email]> wrote:

Duncan Mak wrote:

> I have always wondered why the standard image doesn't come with a next
> method and an increment method for Integers, where next would answer x
> + 1 and increment would set x to be x + 1.

The first is easy, but in my opinion does not add much value - "aNumber
next" does not help me understand the code better than "aNumber + 1"
does. And of course, it re-uses a selector which is already used in the
stream hierarchy and means something completely different.

The second one is not possible with Smalltalk's semantics. Messages are
sent to objects, not to variables. So whatever message you send to
variable x, it can't cause x to point to another object (with the
exception of #become: but that's a special case). Since numeric objects
are immutable, you need to have the assignment x := x+1 either
implicitly or explicitly somewhere.

I'd like to know concrete use cases where you would prefer an increment
method over an explicit x := x+1. My gut feeling is that such cases
probably could be handled even better by still other constructs (for
example, collections or streams), but of course this can't be said
generally for all cases.

Cheers,
Hans-Martin

On 5/17/06, Hans-Martin Mosner <[hidden email]> wrote:
>
> The first is easy, but in my opinion does not add much value - "aNumber
> next" does not help me understand the code better than "aNumber + 1"
> does. And of course, it re-uses a selector which is already used in the
> stream hierarchy and means something completely different.

I agree the name might not be the best. I think in  Ruby, they have 'succ'.

> The second one is not possible with Smalltalk's semantics. Messages are
> sent to objects, not to variables. So whatever message you send to
> variable x, it can't cause x to point to another object (with the
> exception of #become: but that's a special case). Since numeric objects
> are immutable, you need to have the assignment x := x+1 either
> implicitly or explicitly somewhere.

I was thinking of using become: to implement something like this, yeah.

> I'd like to know concrete use cases where you would prefer an increment
> method over an explicit x := x+1. My gut feeling is that such cases
> probably could be handled even better by still other constructs (for
> example, collections or streams), but of course this can't be said
> generally for all cases.

I think you're probably right, but still I think having a particular
message send for 'increment' is not a bad idea in general. I think
something like this is most often used when implementing some sort of
counter.

It is true that

    names select: [:each | each startsWith: 'a'] size

is more elegant than something like:

    names do: [:each | each startsWith: 'a' ifTrue: [count := count + 1]

 but what if you want to count multiple conditions in a single iteration?

Duncan.

Le Mercredi 17 Mai 2006 18:36, Duncan Mak a écrit :
become: Cannot work on Integer, and beware of side effects, value will change
also for every object pointing on it...

You can simulate this count++ like with an indirection (a special ValueHolder
subclass Counter) send the #increment message or whatever to the Counter, and
then retrieve its value, but i don't know if this is interesting, apart
sharing a common value between multiple objects

counter := Counter new.
names do: [:each | each startsWith: 'a' ifTrue: [count increment]].
^counter value

> It is true that
>
>     names select: [:each | each startsWith: 'a'] size
>
> is more elegant than something like:
>
>     names do: [:each | each startsWith: 'a' ifTrue: [count := count + 1]
>

And
     names count: [:each | each startsWith: 'a']

is even more efficient (does not create a copy of the collection)

>  but what if you want to count multiple conditions in a single iteration?
>
> Duncan.

Nicolas

On 5/17/06, nicolas cellier <[hidden email]> wrote:
>
> You can simulate this count++ like with an indirection (a special ValueHolder
> subclass Counter) send the #increment message or whatever to the Counter, and
> then retrieve its value, but i don't know if this is interesting, apart
> sharing a common value between multiple objects
>

Yeah, that's what I did (not exactly that, but close enough). I was
just hoping that there's a standard pre-packaged solution to this,
other than rolling my own.

> And
>   names count: [:each | each startsWith: 'a']
>
> is even more efficient (does not create a copy of the collection)
>

Ah fun. Learn something new every day. Thanks!

Duncan.