Is this a bug?

Questions
#1

Hi there,
I think sclang returns an error when parsing the following code:

(
"1234".postln
("4567").postln
)

However, it will return the following result:

1234
1234
-> 1234

Is this intentional? It makes it hard to debug long code because I often misspell things.

The result is the same in SC3.13.0 on MacOS and Windows, and unSC3.11.2 on Linux.

#2

Ahh, yes, some of supercolliderā€™s ā€˜ergonomicā€™ features make debugging hard.

This is what you have actually writtenā€¦

"1234".postln("4567").postln

The first postln is called with ā€œ4567ā€ as an argument (which is ignored), then ā€œ1234ā€ is returned, and postln called on that again.

Its not intentional, just a consequence of not needed brackets to call a function.

1 Like
#3

Thanks for letting me know the reason!
However, it seems very strange to me, and I hope sclang returns a warning or an error when this case happens.

#4

It couldnā€™t be detected in the parser because itā€™s a syntactically valid expression.

It would be possible to make postXX methods throw an error if any argument is passed in, with the caveats 1/ postf expects argument(s) and 2/ it would rule out potential future usages with arguments (which donā€™t exist at this time, so, itā€™s only a hypothetical concern).

Incidentally, the sclang code style guide recommends omitting the semicolon at the end of a function, to identify its return value. I tend to ignore that recommendation for the reason you discovered ā€“ itā€™s too easy to forget to add the semicolon back in when adding statements at the end of the function.

In any case, itā€™s a tricky problem ā€“ if we talk instead about another method (like round) where an argument is optional, then thereā€™s really nothing that can be done to warn about missing semicolons.

Also, I tend to get tripped up by this one:

(
    a: { ... function-y stuff ... }  // forgot comma
    b: { ... function-y stuff ... }
)

This complains that ā€œa Function does not understand ā€˜bā€™ā€ā€¦ but for instance { ... } round: { ... } is a valid way to create a binary operator function. So thereā€™s nothing that can be done to reduce the confusion, without dropping a supported syntax.

hjh

1 Like