Receiver.message with exprand not working
////////////////
rand(1000)///works
1000.rand///works
exprand(1,1000)///works
(1,1000).exprand///doesn't work
/////////////////////
Because (1, 1000) isn’t an object that can receive the message.
1.exprand(1000)
hjh
This is where I am at loss
exprand(1,100) works but writing it differently (1,100).exprand does not
Why is (1,100) all of a sudden an object t that can not receive it .?
You’ve quite misunderstood the syntax.
exprand(1, 1000) is “function-call syntax” for a method call.
In function-call syntax, the first thing inside parentheses is the receiver, and only the first thing.
So there is only one receiver in that expression, and the receiver is 1.
The remaining items inside parentheses are the arguments to the method call.
exprand(1, 1000) is another way to write 1.exprand(1000).
You happened to begin with a method that takes no arguments – there is only a receiver. From this, you reached the incorrect conclusion that, to convert function-call syntax into dot syntax, you should move the entire parenthesized block to the front.
But it’s only that first item that should move.
hjh
the syntax is Object.message(arguments)
so 1.rrand(100) for example.
You can also write the message first. in that case the syntax is message(Object, arguments)
so rrand(1,100)
parentheses which are not following a method or object name define an expression - that is they are evaluated. so (3 + 4).rand is effectively 7.rand.
but (1,100) can not be evaluated and will throw an error.
Ps. Sc has lot’s of syntax! Happily there’s a guide: https://doc.sccode.org/Reference/Syntax-Shortcuts.html
Some of it is case sensitive!
f(x, y) → x.f(y)
F(x, y) → F.new(x, y)
1 Like
Ok ,it’s starting to make sense
But why is exprand(1, 1000) is “function-call syntax” for a method call. ?
I thought functions were using { } ? , which I thought I finnaly understood
Like this
Duplicate the function of picking random number a hundred times , then sort and plot it
{(1000).rand}.dup(100).sort.plot
The term “function-call” here is referring to the superficial appearance of function calls in C, where it’s function_name(arguments...). It really doesn’t have anything to do with SC functions, ontologically. (Edit: I’ll add one other thing: in C, you call a function by writing the function name and the arguments – but in SC, you call a function by sending the function object the message value with the arguments. This is rather a large conceptual distinction. SC functions are one thing; SC method calls written in a syntax that looks like a C function call is a completely separate concept – that the two concepts use the word “function” should not be taken to imply any congruence between them.)
Incidentally this is all documented: Messages | SuperCollider 3.12.2 Help explains the three styles of method call (binary-infix, function style, and receiver style).
Note that in SC, everything except variable assignment is done by a method call. So every operation must have a receiver and a method selector (and, optionally, arguments). Just about every statement in SC has these elements (except trivial assignments like x = 1, where nothing is being called).
For fun, {(1000).rand}.dup(100).sort.plot could also be written like this:
plot(sort(dup({ 1000.rand }, 100)))
… where the function { 1000.rand } is the receiver of the message dup, and the result of this is the receiver of the sort message, and that result is the receiver of plot.
But pretty much every user on this forum (except maybe one) would find that to be a loss of readability, so it’s seldom written this way.
hjh