Smalltalk › Pharo › Pharo Smalltalk Developers

block syntax experiments

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Francisco Garau-2

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

Peter Uhnak

Re: block syntax experiments

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

Ben Coman

Re: block syntax experiments

In reply to this post by Francisco Garau-2

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
<[hidden email]> 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

Jan Vrany

Re: block syntax experiments

In reply to this post by Peter Uhnak

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
>
>

Francisco Garau-2

Re: block syntax experiments

In reply to this post by Peter Uhnak

On 3 June 2015 at 02:16, Peter Uhnák <[hidden email]> 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

Francisco Garau-2

Re: block syntax experiments

In reply to this post by Ben Coman

On 3 June 2015 at 05:56, Ben Coman <[hidden email]> 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
<[hidden email]> 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

stepharo

Re: block syntax experiments

In reply to this post by Francisco Garau-2

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

Sean P. DeNigris

Re: block syntax experiments

Administrator

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

Sven Van Caekenberghe-2

Re: block syntax experiments

> On 03 Jun 2015, at 15:31, Sean P. DeNigris <[hidden email]> 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.
>

Ben Coman

Re: block syntax experiments

In reply to this post by Francisco Garau-2

On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau
<[hidden email]> wrote:

>
> On 3 June 2015 at 05:56, Ben Coman <[hidden email]> 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
>> <[hidden email]> 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
>>
>

Marcus Denker-4

Re: block syntax experiments

> On 03 Jun 2015, at 17:12, Ben Coman <[hidden email]> wrote:
>
> On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau
> <[hidden email]> wrote:
>>
>> On 3 June 2015 at 05:56, Ben Coman <[hidden email]> 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

Francisco Garau-2

Re: block syntax experiments

Is Coral using the Opal compiler for its syntax extensions?

- Francisco

> On 3 Jun 2015, at 16:21, Marcus Denker <[hidden email]> wrote:
>
>
>> On 03 Jun 2015, at 17:12, Ben Coman <[hidden email]> wrote:
>>
>> On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau
>> <[hidden email]> wrote:
>>>
>>>> On 3 June 2015 at 05:56, Ben Coman <[hidden email]> 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

Re: block syntax experiments

> 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 <[hidden email]> wrote:
>>
>>
>>> On 03 Jun 2015, at 17:12, Ben Coman <[hidden email]> wrote:
>>>
>>> On Wed, Jun 3, 2015 at 4:14 PM, Francisco Garau
>>> <[hidden email]> wrote:
>>>>> On 3 June 2015 at 05:56, Ben Coman <[hidden email]> 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
>>
>>
>

Sean P. DeNigris

Re: block syntax experiments

Administrator

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