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
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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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
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 ron@usmedrec.com 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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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
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.
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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
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
On 1 March 2013 15:39, Yoshiki Ohshima Yoshiki.Ohshima@acm.org 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
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 -
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
On Fri, Mar 1, 2013 at 3:16 PM, Levente Uzonyi leves@elte.hu 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?
On Fri, 1 Mar 2013, Yoshiki Ohshima wrote:
On Fri, Mar 1, 2013 at 3:16 PM, Levente Uzonyi leves@elte.hu 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
On Fri, Mar 1, 2013 at 7:05 AM, Frank Shearar frank.shearar@gmail.comwrote:
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 ron@usmedrec.com 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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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
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"?
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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
On 2013-03-01, at 16:48, Chris Muller asqueaker@gmail.com 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 -
+1 on all points.
Lou
On Fri, 1 Mar 2013 16:57:47 +0100, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-03-01, at 16:48, Chris Muller asqueaker@gmail.com 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:Lou@Keystone-Software.com http://www.Keystone-Software.com
On Fri, 1 Mar 2013, Bert Freudenberg wrote:
On 2013-03-01, at 16:48, Chris Muller asqueaker@gmail.com 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 -
On Fri, Mar 1, 2013 at 7:57 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 2013-03-01, at 16:48, Chris Muller asqueaker@gmail.com 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.
For me it's
(5) [:a :b| a+b]
;)
- Bert -
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"?
On 2013-03-01, at 17:00, Bob Arning arning315@comcast.net 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 -
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg
On 2013-03-01, at 17:00, Bob Arning arning315@comcast.net 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 -
On 3/1/2013 4:47 AM, Frank Shearar wrote:
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]
Not quite related, but in the VW/Squeak family, this is a valid symbol:
# "I like to comment symbols" a
Depending on the font you use, it can be difficult to tell the difference between these:
#""''
#'""'
John Brant
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
Chris Muller -
Eliot Miranda -
Frank Shearar -
Jecel Assumpcao Jr. -
John Brant -
Levente Uzonyi -
Louis LaBrunda -
Ron Teitelbaum -
Yoshiki Ohshima