Is this a bug?

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.

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

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.

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