Smalltalk › Squeak › Squeak - Dev

Block argument syntax

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Frank Shearar-3

Block argument syntax

I was rather surprised to learn that the following is valid syntax:

[ : x | x + 1]

(Note the space before the argument name.)

In fact, this is too:

[ : "This is a really long comment in a very, very strange place.
It makes it very hard to see that the : before this comment turns the
token after this comment into a block argument." x | x + 1]

Is that intentional? Does ANSI Smalltalk define it?

frank

Ron Teitelbaum

RE: Block argument syntax

Hi Frank,

I know this is true for a number of Smalltalk implementations. I found it
very surprising also. Someone I worked with always formatted their code
this way. He said it made it easier to double click and highlight the
variable. I wasn't sure that was enough reason to do it but he did.

Ron

> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Frank Shearar
>
> I was rather surprised to learn that the following is valid syntax:
>
> [ : x | x + 1]
>
> (Note the space before the argument name.)
>
> In fact, this is too:
>
> [ : "This is a really long comment in a very, very strange place.
> It makes it very hard to see that the : before this comment turns the

token after
> this comment into a block argument." x | x + 1]
>
> Is that intentional? Does ANSI Smalltalk define it?
>
> frank
>

Frank Shearar-3

Re: Block argument syntax

Hi Ron,

Oh dear. Here I was hoping it was just a Squeak bug, because that
would be easy to fix. You can't define a method "foo : arg" after all;
the : is part of the selector.

I stumbled upon this because I noticed that Haskell's type identifiers
- like "add :: Int -> Int -> Int" are very nearly valid Smalltalk.
It's just the "::" that's not valid because we don't permit :s in
binary selectors.

frank

On 1 March 2013 14:48, Ron Teitelbaum <[hidden email]> wrote:

> Hi Frank,
>
> I know this is true for a number of Smalltalk implementations. I found it
> very surprising also. Someone I worked with always formatted their code
> this way. He said it made it easier to double click and highlight the
> variable. I wasn't sure that was enough reason to do it but he did.
>
> Ron
>
>> From: [hidden email] [mailto:squeak-dev-
>> [hidden email]] On Behalf Of Frank Shearar
>>
>> I was rather surprised to learn that the following is valid syntax:
>>
>> [ : x | x + 1]
>>
>> (Note the space before the argument name.)
>>
>> In fact, this is too:
>>
>> [ : "This is a really long comment in a very, very strange place.
>> It makes it very hard to see that the : before this comment turns the
> token after
>> this comment into a block argument." x | x + 1]
>>
>> Is that intentional? Does ANSI Smalltalk define it?
>>
>> frank
>>
>
>
>

Yoshiki Ohshima-3

Re: Block argument syntax

I believe I have seen Dan Ingalls posted about the syntax here
before... The essence of the message was that a block is still like a
method, and they kind of have keyword message pattern, except that the
keyword part is null (0-length) string. In this regard, allowing
spaces after a colon follows the principle.

I thought that why we don't allow keywords longer than 0, actually.
One could say:

[keyword1: arg1 keyword2: arg2 | ...]

to annotate each parameter of a block.

--
-- Yoshiki

Ron Teitelbaum

RE: Block argument syntax

> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Yoshiki Ohshima
>
> I believe I have seen Dan Ingalls posted about the syntax here before...
The
> essence of the message was that a block is still like a method, and they
kind of
> have keyword message pattern, except that the keyword part is null
(0-length)
> string. In this regard, allowing spaces after a colon follows the
principle.
>
> I thought that why we don't allow keywords longer than 0, actually.
> One could say:
>
> [keyword1: arg1 keyword2: arg2 | ...]
>
> to annotate each parameter of a block.

Never heard that explanation. That makes perfect sense! Learn something
every day. Thanks!

Ron

>
> --
> -- Yoshiki
>

Chris Muller-3

Re: Block argument syntax

In reply to this post by Ron Teitelbaum

> I know this is true for a number of Smalltalk implementations. I found it
> very surprising also. Someone I worked with always formatted their code
> this way. He said it made it easier to double click and highlight the
> variable. I wasn't sure that was enough reason to do it but he did.

So, score +1 for ": x" but ":x" is still left with a score of 0. What
is the advantage of writing ":x"?

Ron Teitelbaum

RE: Block argument syntax

> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Chris Muller

> > I know this is true for a number of Smalltalk implementations. I
> > found it very surprising also. Someone I worked with always formatted
> > their code this way. He said it made it easier to double click and
> > highlight the variable. I wasn't sure that was enough reason to do it but he
> did.
>
> So, score +1 for ": x" but ":x" is still left with a score of 0. What is the advantage
> of writing ":x"?
>

Probably just the way I learned. I bet it's done that way in the checkbook example. I think it was VisualWorks. Just tried to find it but couldn't. So +1 for habit, and it's one less space to type :).

BTW I do write | temp1 temp2 | instead of |temp1 temp2| so -1 for consistency!

Ron

Bert Freudenberg

Re: Block argument syntax

In reply to this post by Chris Muller-3

On 2013-03-01, at 16:48, Chris Muller <[hidden email]> wrote:

>> I know this is true for a number of Smalltalk implementations. I found it
>> very surprising also. Someone I worked with always formatted their code
>> this way. He said it made it easier to double click and highlight the
>> variable. I wasn't sure that was enough reason to do it but he did.
>
> So, score +1 for ": x" but ":x" is still left with a score of 0. What
> is the advantage of writing ":x"?

One char less. Better visual grouping of multiple arguments.

(1) [:a :b|a+b]
(2) [:a :b | a + b]
(3) [ :a :b | a + b ]
(4) [ : a : b | a + b ]

In my eyes, (2) is the best compromise between conciseness and readability.

- Bert -

Bob Arning-2

Re: Block argument syntax

In reply to this post by Chris Muller-3

You don't need to look too far to see folks who preferred

1 to: length do:[:i|

Fewer keystrokes, maybe?

On 3/1/13 10:48 AM, Chris Muller wrote:

I know this is true for a number of Smalltalk implementations.  I found it
very surprising also.  Someone I worked with always formatted their code
this way.  He said it made it easier to double click and highlight the
variable.  I wasn't sure that was enough reason to do it but he did.

So, score +1 for ": x" but ":x" is still left with a score of 0.  What
is the advantage of writing ":x"?

Bert Freudenberg

Re: Block argument syntax

On 2013-03-01, at 17:00, Bob Arning <[hidden email]> wrote:

> You don't need to look too far to see folks who preferred
>
> 1 to: length do:[:i|
>
> Fewer keystrokes, maybe?

That's the #1 thing I didn't like about Andreas' code ;)

- Bert -

Louis LaBrunda

Re: Re: Block argument syntax

In reply to this post by Bert Freudenberg

+1 on all points.

Lou

On Fri, 1 Mar 2013 16:57:47 +0100, Bert Freudenberg <[hidden email]>
wrote:

>
>On 2013-03-01, at 16:48, Chris Muller <[hidden email]> wrote:
>
>>> I know this is true for a number of Smalltalk implementations. I found it
>>> very surprising also. Someone I worked with always formatted their code
>>> this way. He said it made it easier to double click and highlight the
>>> variable. I wasn't sure that was enough reason to do it but he did.
>>
>> So, score +1 for ": x" but ":x" is still left with a score of 0. What
>> is the advantage of writing ":x"?
>
>One char less. Better visual grouping of multiple arguments.
>
>(1) [:a :b|a+b]
>(2) [:a :b | a + b]
>(3) [ :a :b | a + b ]
>(4) [ : a : b | a + b ]
>
>In my eyes, (2) is the best compromise between conciseness and readability.
>
>- Bert -
>
>
>

-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

Ron Teitelbaum

RE: Block argument syntax

In reply to this post by Bert Freudenberg

> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Bert Freudenberg
>
> On 2013-03-01, at 17:00, Bob Arning <[hidden email]> wrote:
>
> > You don't need to look too far to see folks who preferred
> >
> > 1 to: length do:[:i|

That does look pretty extreme. You know it's habit more than anything. I
would only go as far as: do: [:i |

> >
> > Fewer keystrokes, maybe?
>
> That's the #1 thing I didn't like about Andreas' code ;)

:) I can hear him arguing now that there is "nothing wrong with that, it's
all just bookkeeping, the real work happens later.".

>
> - Bert -
>
>

Jecel Assumpcao Jr

Re: Block argument syntax

In reply to this post by Yoshiki Ohshima-3

Just a quick reminder that this part of Smalltalk syntax came from Logo.
There you define a new function as

to spiral :length :angle

and most implementations (if not all) are ok with spaces between the ":"
and the argument names. This was an attempt to make the declaration
reflect usage (C style), where

"x means the symbol "x"
x means the function named "x"
thing "x means the value of the variable named "x"
:x is syntatic sugar for the previous case

In Smalltalk-72 and -74 the last option was also used in code, but that
got dropped in -76 and only the block declarations stayed unchanged all
the way to -80.

-- Jecel

Frank Shearar-3

Re: Block argument syntax

In reply to this post by Yoshiki Ohshima-3

On 1 March 2013 15:39, Yoshiki Ohshima <[hidden email]> wrote:

> I believe I have seen Dan Ingalls posted about the syntax here
> before... The essence of the message was that a block is still like a
> method, and they kind of have keyword message pattern, except that the
> keyword part is null (0-length) string. In this regard, allowing
> spaces after a colon follows the principle.
>
> I thought that why we don't allow keywords longer than 0, actually.
> One could say:
>
> [keyword1: arg1 keyword2: arg2 | ...]
>
> to annotate each parameter of a block.

That actually makes a lot of sense. It's like an anonymous selector.

I'm still not going to write [ : x | x ] though! Ugly! Odd that in
heading on 15 years of looking at Smalltalk, and reading Smalltalk
Best Practice Patterns I've never seen it before.

frank

> --
> -- Yoshiki
>

Bert Freudenberg

Re: Block argument syntax

Here's an additional idea - using "empty" keywords for optional method arguments (from http://piumarta.com/pepsi/pepsi.html):

3.4 Method definitions

Methods are just 'named blocks', tied to a particular prototype only by permitting direct access to the state within that prototype. (Therein lies yet another reason to abolish direct access to state.) This is reflected in the syntax of the top-level form for adding methods (named blocks) to a prototype:

name pattern [ statements ]

where name identifies a prototype object (defined as described above), pattern looks (more or less) like a Smallalk-80 message pattern, and statements is a block (notice the brackets) providing the behaviour for the method. The pattern component can be a unary, binary or keyword message pattern.

Extensions to Smalltalk's fixed-arity messages include additional and variadic formal arguments. Additional formal arguments for unary and keyword selectors are written like block arguments and can appear before or after the initial opening bracket. For example, two additional formal arguments could be written

name selector :arg1 :arg2 [ statements ]
name selector [ :arg1 :arg2 | statements ]

(where selector is a unary or keyword selector). Unary or keyword message sends can pass additional actual arguments by prefixing each additional argument with a colon. To ask the receiver to add two numbers:

Object add :x :y
[
  ^x + y
]

[
  | sum |
  sum := self add :3 :4.
]

Variadic arguments can be attached to unary or keyword methods. This is indicated by an ellipsis in the message pattern immediately following the last named argument. The pattern for unary and keyword syntax therefore also includes:

name unarySelector ... [ statements ]
name keywords: arguments ... [ statements ]

(Simply for lack of time, there is currently no friendly syntax to recover the 'rest' arguments within the body of a message. Wizards, however, can easily recover these arguments by writing some low-level magic inside a method body.)

- Bert -

Levente Uzonyi-2

Re: Block argument syntax

In reply to this post by Yoshiki Ohshima-3

On Fri, 1 Mar 2013, Yoshiki Ohshima wrote:

> I believe I have seen Dan Ingalls posted about the syntax here
> before... The essence of the message was that a block is still like a
> method, and they kind of have keyword message pattern, except that the
> keyword part is null (0-length) string. In this regard, allowing
> spaces after a colon follows the principle.

That's pretty cool and exactly what I always thought about it, but I still
couldn't find a good reason for the | at the end of the block signature.
Without it blocks could be parsed just like methods, (probably) making the
parser simpler:

array collect: [ :each
each * each ]

Levente

>
> I thought that why we don't allow keywords longer than 0, actually.
> One could say:
>
> [keyword1: arg1 keyword2: arg2 | ...]
>
> to annotate each parameter of a block.
>
> --
> -- Yoshiki
>
>

Levente Uzonyi-2

Re: Block argument syntax

In reply to this post by Bert Freudenberg

On Fri, 1 Mar 2013, Bert Freudenberg wrote:

>
> On 2013-03-01, at 16:48, Chris Muller <[hidden email]> wrote:
>
>>> I know this is true for a number of Smalltalk implementations. I found it
>>> very surprising also. Someone I worked with always formatted their code
>>> this way. He said it made it easier to double click and highlight the
>>> variable. I wasn't sure that was enough reason to do it but he did.
>>
>> So, score +1 for ": x" but ":x" is still left with a score of 0. What
>> is the advantage of writing ":x"?
>
> One char less. Better visual grouping of multiple arguments.
>
> (1) [:a :b|a+b]
> (2) [:a :b | a + b]
> (3) [ :a :b | a + b ]
> (4) [ : a : b | a + b ]
>
> In my eyes, (2) is the best compromise between conciseness and readability.

I prefer (3), but (4) doesn't look bad either. (1) and (2) are less
readable for me.

It's funny that one can't write [:a:b|a+b], because the parser expects a
white space after the argument name.

Levente

>
> - Bert -
>
>
>
>

Yoshiki Ohshima-3

Re: Block argument syntax

In reply to this post by Levente Uzonyi-2

On Fri, Mar 1, 2013 at 3:16 PM, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 1 Mar 2013, Yoshiki Ohshima wrote:
>
>> I believe I have seen Dan Ingalls posted about the syntax here
>> before... The essence of the message was that a block is still like a
>> method, and they kind of have keyword message pattern, except that the
>> keyword part is null (0-length) string. In this regard, allowing
>> spaces after a colon follows the principle.
>
>
> That's pretty cool and exactly what I always thought about it, but I still
> couldn't find a good reason for the | at the end of the block signature.
> Without it blocks could be parsed just like methods, (probably) making the
> parser simpler:
>
> array collect: [ :each
> each * each ]

But a pair of vertical bars may follow the last argument name, so the
parser would have to check it, no?

--
-- Yoshiki

Levente Uzonyi-2

Re: Block argument syntax

On Fri, 1 Mar 2013, Yoshiki Ohshima wrote:

> On Fri, Mar 1, 2013 at 3:16 PM, Levente Uzonyi <[hidden email]> wrote:
>> On Fri, 1 Mar 2013, Yoshiki Ohshima wrote:
>>
>>> I believe I have seen Dan Ingalls posted about the syntax here
>>> before... The essence of the message was that a block is still like a
>>> method, and they kind of have keyword message pattern, except that the
>>> keyword part is null (0-length) string. In this regard, allowing
>>> spaces after a colon follows the principle.
>>
>>
>> That's pretty cool and exactly what I always thought about it, but I still
>> couldn't find a good reason for the | at the end of the block signature.
>> Without it blocks could be parsed just like methods, (probably) making the
>> parser simpler:
>>
>> array collect: [ :each
>> each * each ]
>
> But a pair of vertical bars may follow the last argument name, so the
> parser would have to check it, no?

Of course, but it has to do that for methods too:

square: each

^each * each

vs

[ :each

each * each ]

and

square: each

| result |
result := each * each
^result

vs

[ :each

| result |
result := each * each.
result ]

Levente

>
> --
> -- Yoshiki
>
>

Eliot Miranda-2

Re: Block argument syntax

In reply to this post by Frank Shearar-3

On Fri, Mar 1, 2013 at 7:05 AM, Frank Shearar <[hidden email]> wrote:

Hi Ron,

Oh dear. Here I was hoping it was just a Squeak bug, because that
would be easy to fix. You can't define a method "foo : arg" after all;
the : is part of the selector.

But you can define foo:arg. The point is that the : is part of the selector, and whitespace after the colon and before the formal variable is allowed. So [:a:b:c| is analogous to a selector :::. It's more obvious if one writes _: a _: b _: c, etc. This syntax was thought about carefully.

BTW, you can also define a method that looks like

"comment" foo ^self

I stumbled upon this because I noticed that Haskell's type identifiers
- like "add :: Int -> Int -> Int" are very nearly valid Smalltalk.
It's just the "::" that's not valid because we don't permit :s in
binary selectors.

frank

On 1 March 2013 14:48, Ron Teitelbaum <[hidden email]> wrote:
> Hi Frank,
>
> I know this is true for a number of Smalltalk implementations. I found it
> very surprising also. Someone I worked with always formatted their code
> this way. He said it made it easier to double click and highlight the
> variable. I wasn't sure that was enough reason to do it but he did.
>
> Ron
>
>> From: [hidden email] [mailto:[hidden email]
>> [hidden email]] On Behalf Of Frank Shearar
>>
>> I was rather surprised to learn that the following is valid syntax:
>>
>> [ : x | x + 1]
>>
>> (Note the space before the argument name.)
>>
>> In fact, this is too:
>>
>> [ : "This is a really long comment in a very, very strange place.
>> It makes it very hard to see that the : before this comment turns the
> token after
>> this comment into a block argument." x | x + 1]
>>
>> Is that intentional? Does ANSI Smalltalk define it?
>>
>> frank
>>
>
>
>

--
best,

Eliot