3 ms·

Looks very nice! Though the discrimination between intending or not is done based on whether the previous action mutates the object (no new intend) or creates o

by jussir 15y ago

Looks very nice! Though the discrimination between intending or not is done based on whether the previous action mutates the object (no new intend) or creates or returns different object (new intend), right? This is something that can't be known on the language level unless there's a specific syntax for it, which doesn't seem to be possible for Javascript based languages (e.g. https://github.com/jashkenas/coffee-script/issues/1738 https://github.com/jashkenas/coffee-script/issues/1738).

raganwald 15y ago
My point is that if I owned the parser, I would ignore what the function returns and send the message to the previous receiver when multiple message inocations are indented in parallel. Here's an example using functions that both return a value and have a side-effect: ['foo', ['bar']] .pop() .pop() Would return 'foo' if I owned the parser, while: ['foo', ['bar']] .pop() .pop() ...would return 'bar'. You can infer from his what happens to the niial array in terms of side effects. My suggestion is that "chaining" method calls is a syntax issue and not a function issue, and that writing functions tonreturn a certain thing just to cater to how you like to write programs is hacking around a missing language feature. pop() is a great example. Why shouldn't pop return the receiver? The first example makes sense, you ought to be able to chain calls to pop(). Then again, why shouldn't pop() return what it pops? You ought to be able to pop something and use it, just like the second example. Baking chaining into what functions return forces the function author to choose On behalf of the function user. I do not blame people for doing this in a language lacking thenproper syntax, but given how much people do this, it seems worth considering for people writing new langauges or new syntaxes for existing languages.

by jussir 15y ago

raganwald 15y ago

My point is that if I owned the parser, I would ignore what the function returns and send the message to the previous receiver when multiple message inocations are indented in parallel. Here's an example using functions that both return a value and have a side-effect: ['foo', ['bar']] .pop() .pop() Would return 'foo' if I owned the parser, while: ['foo', ['bar']] .pop() .pop() ...would return 'bar'. You can infer from his what happens to the niial array in terms of side effects. My suggestion is that "chaining" method calls is a syntax issue and not a function issue, and that writing functions tonreturn a certain thing just to cater to how you like to write programs is hacking around a missing language feature. pop() is a great example. Why shouldn't pop return the receiver? The first example makes sense, you ought to be able to chain calls to pop(). Then again, why shouldn't pop() return what it pops? You ought to be able to pop something and use it, just like the second example. Baking chaining into what functions return forces the function author to choose On behalf of the function user. I do not blame people for doing this in a language lacking thenproper syntax, but given how much people do this, it seems worth considering for people writing new langauges or new syntaxes for existing languages.