[BUG] Error in acos

[rgizz]

Description

Error in acos method

Steps to Reproduce

[giz@daisy acos$ io
Io 20170906
Io> -1 acos
==> 0
Io>

Expected Behavior

==> 3.14159 // i.e., should ==> pi

Actual Behavior

==> 0

Code Example

See above

Error Output

Environment

[giz@daisy io$ io --version
Io Programming Language, v. 20170906

[giz@daisy io$ cat /etc/fedora-release
Fedora release 42 (Adams)
[giz@daisy io$

[pedro-w]

The code just calls the platform's acos

io/libs/iovm/source/IoNumber.c

Lines 562 to 568 in 264c53d

	IO_METHOD(IoNumber, acos) {
	/*doc Number acos
	Returns a number with the arc cosine of the receiver.
	*/
	return IONUMBER(acos(DATA(self)));
	}

I think the issue is that '-' doesn't bind as tightly as the message send.

-1 acos is interpreted as -(1 acos). Instead, (-1) acos seems to give the right answer. It's not specific to acos, try -1 print

I don't know if this is considered a bug or just part of the way io works.

[rgizz]

Thanks!  (-1) acos ==> 3.14159...  // Hurray! // print examples-1 print 1==> -1  // what I would expect (-1) print-1==> -1  Truth is, I don't know what the numbers 1 and -1 before the '==>' signify.  Bob On Monday, March 9, 2026, 10:12 AM, Peter Hull ***@***.***> wrote: pedro-w left a comment (IoLanguage/io#489) The code just calls the platform's acos https://github.com/IoLanguage/io/blob/264c53d027a67031ca478001a7d72f56eb977ec3/libs/iovm/source/IoNumber.c#L562-L568 I think the issue is that '-' doesn't bind as tightly as the message send.

…

-1 acos is interpreted as -(1 acos). Instead, (-1) acos seems to give the right answer. It's not specific to acos, try -1 print I don't know if this is considered a bug or just part of the way io works. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[pedro-w]

Truth is, I don't know what the numbers 1 and -1 before the '==>' signify.

-1 print means - (1 print)
(1 print) means send the print message to '1' ... which prints 1 on the screen and the value of that expression is the receiver (i.e. 1)
Then - 1 evaluates to 'minus 1'
Then the REPL shows '==>' and the final value of the expression (i.e. -1)

Think that's right, I did find it confusing at first, e.g.

"hello " .. "world" print

gives

world ==> hello world

[stevedekorte]

I can see how this would be confusing. We can adjust how operators are handled with the OperatorTable. What rules changes (if any) would you guys suggest? Would mirroring Javascript's rules be helpful?

[rgizz]

I quite appreciate your taking the trouble to explain; I see it now.  On Monday, March 9, 2026, 12:05 PM, Peter Hull ***@***.***> wrote: pedro-w left a comment (IoLanguage/io#489) Truth is, I don't know what the numbers 1 and -1 before the '==>' signify.

…

-1 print means - (1 print) (1 print) means send the print message to '1' ... which prints 1 on the screen and the value of that expression is the receiver (i.e. 1) Then - 1 evaluates to 'minus 1' Then the REPL shows '==>' and the final value of the expression (i.e. -1) Think that's right, I did find it confusing at first, e.g. "hello " .. "world" print gives world ==> hello world — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rgizz]

I tend to think that unary minus here should have a higher precedence than method application. For analogy, I looked at Smalltalk -- the Cuis implementation -- and it has that precedence. -1 arcCos --> 3.14159...Even with a space between the '-' and the '1' !!!  - 1 arcCos --> 3.14159...  I think such a precedence rule (speaking to the no-space '-1' case, not the spaced '- 1' case) would accord with the principle of least surprise. But I hesitate to suggest it for Io, being an FNG here, not knowing the work required, or the ramifications.   Bob On Monday, March 9, 2026, 12:11 PM, Steve Dekorte ***@***.***> wrote: stevedekorte left a comment (IoLanguage/io#489) I can see how this would be confusing. We can adjust how operators are handled with the OperatorTable. What rules changes (if any) would you guys suggest? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[stevedekorte]

My inclination has always been to require explicit parens for operators just as we do for methods, including for equality and assignment, but optional precedence (ie you can always use all the parens) with flexible operator table was a compromise. Now that we're doing some major changes, it might be a good time to change things. Given that Io is moving to either a stackless C interpreter compiled to WASM (with transparent JS bridge) or pure JS interpreter, maybe adopting some or most of JS's operator precedence rules makes sense. Thoughts?

[pedro-w]

Doing it without operator precedence is OK (it's the Smalltalk way although I think it's in the minority, ref )
However in this specific case maybe a negative number literal is something can be done by the lexical analyser? On the other hand if you had -x that would have to be a method call. Aargh, not sure what to say on this. Maybe it's just something everyone has to get wrong once...

io/libs/iovm/source/IoObject.c

Lines 1565 to 1573 in 264c53d

	IO_METHOD(IoObject, subtract) {
	/*doc Object -(aNumber)
	Returns the negative version of aNumber.
	Raises an exception if argument is not a number.
	*/
	IoNumber *num = IoMessage_locals_numberArgAt_(m, locals, 0);
	return IONUMBER(-IoNumber_asDouble(num));
	}