[9fans] hoc's behaviour, unary operators

[9fans] hoc's behaviour, unary operators

[Rudolf Sykora]

Hello

why
1+-2
is ok for the 'hoc' command, while both
1--2
1-+2
produce a syntax error?
(If spaces are added as in
1- -2
1- +2,
hoc is fine with the former but still rejects the latter...)

Thanks
Ruda

Re: [9fans] hoc's behaviour, unary operators

[Rudolf Sykora]

PS.: While 'bc' is not any better in this, 'maxima' gets it wright.
(Both in linux.)

Re: [9fans] hoc's behaviour, unary operators

[Jorden Mauro]

Look under the production for expr in /sys/src/cmd/hoc/hoc.y

Looks like the unary plus problem would be a one-line fix. The -- with no space
may be harder to fix.

On Fri, Oct 30, 2009 at 11:44 AM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> PS.: While 'bc' is not any better in this, 'maxima' gets it wright.
> (Both in linux.)
>
>

Re: [9fans] hoc's behaviour, unary operators

[Rudolf Sykora]

2009/10/30 Jorden Mauro <jrm8005@gmail.com>:
> Look under the production for expr in /sys/src/cmd/hoc/hoc.y
>
> Looks like the unary plus problem would be a one-line fix. The -- with no space
> may be harder to fix.

Thanks, I will.

Nonetheless, the problem, as I am thinking about it now, could
possibly (also) be connected to ++ and -- operators, as in
a++, a--
where 'a' is some variable.
Although the meaning for e.g.
a--b
is still only one, i.e.
a - (-b),
(a-- b wouldn't make sense) it probably can't (can it?) be parsed
simply with yacc...

Ruda

Re: [9fans] hoc's behaviour, unary operators

[Martin Neubauer]

* Jorden Mauro (jrm8005@gmail.com) wrote:
> The -- with no space may be harder to fix.
More importantly, it actually is a syntax error. Consider:

1-(-2)	//Add 2 to 1
1--	//Decrement 1, how?
--2	//Decrement 2, how?
1--2	//Decrement 1? Decrement 2? How?

Re: [9fans] hoc's behaviour, unary operators

[Martin Neubauer]

* Rudolf Sykora (rudolf.sykora@gmail.com) wrote:
> (a-- b wouldn't make sense) it probably can't (can it?) be parsed
> simply with yacc...
I don't see why it would be impossible. Just introduce a binary --
operator (cf. -1 vs. 1-2). Whether it's worth it...

Re: [9fans] hoc's behaviour, unary operators

[Rudolf Sykora]

2009/10/30 Martin Neubauer <m.ne@gmx.net>:
> * Rudolf Sykora (rudolf.sykora@gmail.com) wrote:
>> (a-- b wouldn't make sense) it probably can't (can it?) be parsed
>> simply with yacc...
> I don't see why it would be impossible. Just introduce a binary --
> operator (cf. -1 vs. 1-2). Whether it's worth it...

Yes, probably you're right that it can be done. At least partially.

First, '+-' and '-+' situation should be handled (unary '+' introduced).
Then:
The yylex() function in hoc.y returns an 'INC' token for '++' and a
'DEC' for '--'.
So if one adds a binary INC and DEC, changes the priority
appropriately, it could work...
BUT there are more complicated cases:

Python handles correctly e.g. 2-----7, 2+-+-7, 2+++-7,...
C-compiler that I use in my linux, gcc, is ok for a+-b and a-+b, also
for a+-+-b, but not for a++b or a--b or any alike.

>From these more complicated examples like 2----7, I am getting an
impression that it'd be better to not produce tokens like INC & DEC in
the (which must then be decomposed into effectively unary operators),
but to only have '+' and '-' tokens and work with them somehow...

Ok. I wrote this because I was suprised that something I had expected
just doesn't work in the way.
I don't think I am capable of actually changing the lexer & parser of
hoc, but if I try and succeed, I'll tell you.

Thanks
Ruda

Re: [9fans] hoc's behaviour, unary operators

[Dennis Ritchie]

"erik quanstrom" <quanstro@quanstro.net> wrote in message
news:332ccdbfcadf7769acbbd00931f5cde4@brasstown.quanstro.net...
...
> therefore the string "a++b" can't be valid, since the tokens
> the parser sees are "a" INC "b".  that's not kosher c.  way
> back when in primoridal c, there were no seperate tokens
> for INC and DEC, they were productions in the parser and
> goofiness like you describe was allowed.

No, in fact even in primordial C ++ -- were indeed separate tokens.
However,  in several early versions =+ and =-  [sic] etc. were
two tokens each, then adjoined by the parser.

  Dennis

Re: [9fans] hoc's behaviour, unary operators

[Rudolf Sykora]

2009/10/30 erik quanstrom <quanstro@quanstro.net>:
>> Python handles correctly e.g. 2-----7, 2+-+-7, 2+++-7,...
>> C-compiler that I use in my linux, gcc, is ok for a+-b and a-+b, also
>> for a+-+-b, but not for a++b or a--b or any alike.
>
> you're confusing tokens and productions.  the c tokenizer
> has the following rules
> --      ->      DEC
> ++      ->      INC
> +       ->      PLUS
> -       ->      MINUS
>
> therefore the string "a++b" can't be valid, since the tokens
> the parser sees are "a" INC "b".  that's not kosher c.  way
> back when in primoridal c, there were no seperate tokens
> for INC and DEC, they were productions in the parser and
> goofiness like you describe was allowed.

Well, for exactly this reason I said I wouldn't produce INC & DEC
tokens in the lexer.
a++b would then be translated by the parser to a + (+b), since this
would be the only sensible meaning (a INC b doesn't work).
The same would be for any NUMBERS. These can't be ++ or --; there the
+ & - would only be unary +,- operators.
This would give sence to anything like 2++7, 2--+7, where only numbers appear.
I formerly thought that INC & DEC could be somehow elegantly
reconciled even with operations on variables (like a++b above). But
a+++b (where we would have to decide), and more importantly --b shows
it can't be done. This took me some time to realize. Thus for NUMBERS
the goal of reading complicated things could be achieved. For
variables not, unless INC and DEC disappear (they are not in python or
maxima). Now, the question is whether it's worth changing the
behaviour for number expressions...

This is the analysis for which I was looking. That's the reason I
started this thread. It's only after I know the details that I decide
what to do.

> also, this is a very long discussion for a one-line fix.

There are much longer much less fruitful (for me) threads all around.
And neither you explained, just submitted a patch. Thanks for it, but
first I needed to know WHY it is that I can't read expressions that
are ok elsewhere.

Thanks
Ruda

Re: [9fans] hoc's behaviour, unary operators

[matt]

>
>i'll leave as an excersize why k&r thought that making --
>and ++ tokens was worth while.
>
>
>
did DEC make them do it so they could issue trademark infringement
lawsuits for copying the instruction mnemonic?

Re: [9fans] hoc's behaviour, unary operators

[erik quanstrom]

> Python handles correctly e.g. 2-----7, 2+-+-7, 2+++-7,...
> C-compiler that I use in my linux, gcc, is ok for a+-b and a-+b, also
> for a+-+-b, but not for a++b or a--b or any alike.

you're confusing tokens and productions.  the c tokenizer
has the following rules
--	-> 	DEC
++	->	INC
+	->	PLUS
-	->	MINUS

therefore the string "a++b" can't be valid, since the tokens
the parser sees are "a" INC "b".  that's not kosher c.  way
back when in primoridal c, there were no seperate tokens
for INC and DEC, they were productions in the parser and
goofiness like you describe was allowed.

i'll leave as an excersize why k&r thought that making --
and ++ tokens was worth while.

also, this is a very long discussion for a one-line fix.  if
you care, please apply this largely do-nothing patch to
your hoc:

; diffy -c /sys/src/cmd/hoc/hoc.y
/n/dump/2009/1030/sys/src/cmd/hoc/hoc.y:98,103 - /sys/src/cmd/hoc/hoc.y:98,104
  	| expr '%' expr	{ code(mod); }
  	| expr '^' expr	{ code (power); }
  	| '-' expr   %prec UNARYMINUS   { $$=$2; code(negate); }
+ 	| '+' expr   %prec UNARYMINUS   { $$=$2; }
  	| expr GT expr	{ code(gt); }
  	| expr GE expr	{ code(ge); }
  	| expr LT expr	{ code(lt); }

- erik