block syntax experiments
Hello, I'd like to make some syntax changes that would make block evaluation more legible. Currently we define and evaluate blocks like this: inc := [ : x | x + 1 ]. (inc value: 3) = 4. addTo := [ : x : y | x + y ]. (addTo value: 3 value: 4) = 7. But I would like them to be defined like this: [ inc: x | x + 1 ]. (inc: 3) = 4 [add: x to: y | x + y ]. (add: 3 to: 4) = 7. What do you think? Is it feasible? I presume it's Opal where I should start looking at implementing this changes, but any hints/suggestions are welcomed. Cheers, Francisco
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
But you still need to have the block saved in a variable. You cannot pollute global namespace with names of parameters within the block, not to mention the fact that most blocks in the system have same parameter names. Now while the idea seems interesting; I cannot imagine how it would work in practice. Imagine collection's "do:" method explicitly stating the name of the argument, which would force me to name it in such and such way which would actually impair the readability. I am sure others will have different opinions. However if you want to try it out, you should apart from Opal have to look also at AST-Core since you are changing syntax. Also I am thinking that combination of variable name + named arguments could perhaps be done purely with overriding doesNotUnderstand: method in BlockClosure and calling value:value: internally. (Or even cull:cull:, but form what I've heard that has some dire performance issues); this could perhaps even solve my comment about enforced naming. Peter
On Wed, 2015-06-03 at 03:16 +0200, Peter Uhnák wrote:
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
Francisco, Interesting. Looks handy, too :-) But I found the syntax bit confusing as it looks like that the block is created and never stored. Maybe add:to:= [:x :y | x + y ] add: 3 to: 4 I'm not terribly happy with that either, but...
But you still need to have the block saved in a variable. You cannot pollute global namespace with names of parameters within the block, not to mention the fact that most blocks in the system have same parameter names.
Now while the idea seems interesting; I cannot imagine how it would work in practice. Imagine collection's "do:" method explicitly stating the name of the argument, which would force me to name it in such and such way which would actually impair the readability. I am sure others will have different opinions.
This is handy when one needs to define a method-local function sort of things. I do that often using the variable + value:value: syntax but it's ugly and not intention revealing (unless you're really used to this idiom)
However if you want to try it out, you should apart from Opal have to look also at AST-Core since you are changing syntax.
Also I am thinking that combination of variable name + named arguments could perhaps be done purely with overriding doesNotUnderstand: method in BlockClosure and calling value:value: internally. (Or even cull:cull:, but form what I've heard that has some dire performance issues); this could perhaps even solve my comment about enforced naming.
Using a doesNotUnderstand: here would have performance problems. (unless Cog does something super-smart) Jan
Peter
On 3 June 2015 at 02:16, Peter Uhnák <i.uhnak@gmail.com> wrote:
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
But you still need to have the block saved in a variable. You cannot pollute global namespace with names of parameters within the block,
The block would still be saved in a variable -- I see that happening behind the scenes. In other words, you would have something like this: [ inc: x | x + 1 ]. (inc: 3) = 4. inc class = BlockClosure [add: x to: y | x + y ]. (add: 3 to: 4) = 7. addto class = BlockClosure not to mention the fact that most blocks in the system have same parameter
names. Now while the idea seems interesting; I cannot imagine how it would work in practice. Imagine collection's "do:" method explicitly stating the name of the argument, which would force me to name it in such and such way which would actually impair the readability.
I don't see that problem, as anonymous blocks would remain the same as now. You will still have this: (1 to: 5) do: [ :x | x + 1 ] My extensions are syntactic sugar to store and evaluate a block. They wouldn't help in a case like this: Point class >> incBlock ^[: x | x + 1] b := Point incBlock. I am sure others will have different opinions.
However if you want to try it out, you should apart from Opal have to look also at AST-Core since you are changing syntax.
Thanks for the pointers.
Also I am thinking that combination of variable name + named arguments
could perhaps be done purely with overriding doesNotUnderstand: method in BlockClosure and calling value:value: internally. (Or even cull:cull:, but form what I've heard that has some dire performance issues); this could perhaps even solve my comment about enforced naming.
Peter
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing. How about something that gives more feeling of inserting... add <-- 3 , 4. add <<< 3 , 4. add <<: 3 <<: 4. add @:3 @:4. cheers -ben On Wed, Jun 3, 2015 at 8:17 AM, Francisco Garau <francisco.garau@gmail.com> wrote:
Hello,
I'd like to make some syntax changes that would make block evaluation more legible.
Currently we define and evaluate blocks like this:
inc := [ : x | x + 1 ]. (inc value: 3) = 4. addTo := [ : x : y | x + y ]. (addTo value: 3 value: 4) = 7.
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
I presume it's Opal where I should start looking at implementing this changes, but any hints/suggestions are welcomed.
Cheers, Francisco
On 3 June 2015 at 05:56, Ben Coman <btc@openinworld.com> wrote:
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing.
That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block. It's a bit heretic, but the more I think, the more I like it.
How about something that gives more feeling of inserting... add <-- 3 , 4. add <<< 3 , 4. add <<: 3 <<: 4. add @:3 @:4.
cheers -ben
On Wed, Jun 3, 2015 at 8:17 AM, Francisco Garau <francisco.garau@gmail.com> wrote:
Hello,
I'd like to make some syntax changes that would make block evaluation more legible.
Currently we define and evaluate blocks like this:
inc := [ : x | x + 1 ]. (inc value: 3) = 4. addTo := [ : x : y | x + y ]. (addTo value: 3 value: 4) = 7.
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
I presume it's Opal where I should start looking at implementing this changes, but any hints/suggestions are welcomed.
Cheers, Francisco
On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
On 3 June 2015 at 05:56, Ben Coman <btc@openinworld.com> wrote:
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing.
That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block.
It's a bit heretic, but the more I think, the more I like it.
Well, if its an itch you need to scratch, go ahead :) But it might be a struggle to get the community to accept it into Pharo, and hence possibly a maintenance burden for you each Pharo release. cheers -ben
How about something that gives more feeling of inserting... add <-- 3 , 4. add <<< 3 , 4. add <<: 3 <<: 4. add @:3 @:4.
cheers -ben
On Wed, Jun 3, 2015 at 8:17 AM, Francisco Garau <francisco.garau@gmail.com> wrote:
Hello,
I'd like to make some syntax changes that would make block evaluation more legible.
Currently we define and evaluate blocks like this:
inc := [ : x | x + 1 ]. (inc value: 3) = 4. addTo := [ : x : y | x + y ]. (addTo value: 3 value: 4) = 7.
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
I presume it's Opal where I should start looking at implementing this changes, but any hints/suggestions are welcomed.
Cheers, Francisco
On 03 Jun 2015, at 17:12, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
On 3 June 2015 at 05:56, Ben Coman <btc@openinworld.com> wrote:
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing.
That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block.
It's a bit heretic, but the more I think, the more I like it.
Well, if its an itch you need to scratch, go ahead :) But it might be a struggle to get the community to accept it into Pharo, and hence possibly a maintenance burden for you each Pharo release.
It would make a nice tutorial how to hack the compiler for experiments⦠Marcus
Is Coral using the Opal compiler for its syntax extensions? - Francisco
On 3 Jun 2015, at 16:21, Marcus Denker <marcus.denker@inria.fr> wrote:
On 03 Jun 2015, at 17:12, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
On 3 June 2015 at 05:56, Ben Coman <btc@openinworld.com> wrote:
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing.
That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block.
It's a bit heretic, but the more I think, the more I like it.
Well, if its an itch you need to scratch, go ahead :) But it might be a struggle to get the community to accept it into Pharo, and hence possibly a maintenance burden for you each Pharo release.
It would make a nice tutorial how to hack the compiler for experimentsâ¦
Marcus
Is Coral using the Opal compiler for its syntax extensions? it extends petitParser. Now the challenges of Coral are not in the syntax. But How can we call system call, how can we manipule OS variable. How can we edit a "script" and debug it inside the image and publish it as a dead file.
Remember Coral is not about forcing us to edit in vim, but to have a living scripts that we be debugged and published as dead files or zombified on demand. Stef
- Francisco
On 3 Jun 2015, at 16:21, Marcus Denker <marcus.denker@inria.fr> wrote:
On 03 Jun 2015, at 17:12, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
On 3 June 2015 at 05:56, Ben Coman <btc@openinworld.com> wrote:
I think that would confuse me, and maybe break syntax highlighting. It *looks* like a message send to nothing.
That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block.
It's a bit heretic, but the more I think, the more I like it. Well, if its an itch you need to scratch, go ahead :) But it might be a struggle to get the community to accept it into Pharo, and hence possibly a maintenance burden for you each Pharo release. It would make a nice tutorial how to hack the compiler for experimentsâ¦
Marcus
stepharo wrote
Remember Coral is not about forcing us to edit in vim, but to have a living scripts that we be debugged and published as dead files or zombified on demand.
That sounds reeeally interesting! I never understood that before. I heard that Coral was obsolete because the important parts were integrated as the command line handlers... ----- Cheers, Sean -- View this message in context: http://forum.world.st/block-syntax-experiments-tp4830097p4830418.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
my impression is that we can focus on better improvements with larger impact,. Le 3/6/15 02:17, Francisco Garau a écrit :
Hello,
I'd like to make some syntax changes that would make block evaluation more legible.
Currently we define and evaluate blocks like this:
inc := [ : x | x + 1 ]. (inc value: 3) = 4. addTo := [ : x : y | x + y ]. (addTo value: 3 value: 4) = 7.
But I would like them to be defined like this:
[ inc: x | x + 1 ]. (inc: 3) = 4
[add: x to: y | x + y ]. (add: 3 to: 4) = 7.
What do you think? Is it feasible?
I presume it's Opal where I should start looking at implementing this changes, but any hints/suggestions are welcomed.
Cheers, Francisco
stepharo wrote
my impression is that we can focus on better improvements with larger impact.
+1,000,000. What makes Smalltalk as a language interesting is that, like Lisp, it's one of the few languages where you can fit the entire language on a napkin. I would think extreeeemely hard about the benefits before adding more syntax. If we wanted syntax at the expense of simplicity and uniformity, we'd be using Ruby ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/block-syntax-experiments-tp4830097p4830230.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 03 Jun 2015, at 15:31, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
my impression is that we can focus on better improvements with larger impact.
+1,000,000. What makes Smalltalk as a language interesting is that, like Lisp, it's one of the few languages where you can fit the entire language on a napkin. I would think extreeeemely hard about the benefits before adding more syntax. If we wanted syntax at the expense of simplicity and uniformity, we'd be using Ruby ;)
Amen.
----- Cheers, Sean -- View this message in context: http://forum.world.st/block-syntax-experiments-tp4830097p4830230.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (8)
-
Ben Coman -
Francisco Garau -
Jan Vrany -
Marcus Denker -
Peter Uhnák -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe