"David N. Smith (IBM)" dnsmith@watson.ibm.com pointed out: HeadMorph>>addSpikyHair | hair | hair _ PolygonMorph vertices: {83@3. 81@30. 91@27. 111@23. 97@32. 112@37. 99@45. 114@52. ... }
Anyone who wants to simplify the parser by eliminating {...} could simplify it still further by eliminating #(...) as well. After all, #(...) can be eliminated just like {...}.
It has always seemed a shame that there was no way to get a Point into a literal array. It could be done: where <number> is allowed, allow <number>@<number>. That would be a special case, but the whole of #(...) is a special case. I agree that {...} is useful.
{e1. ... . en} is equivalent to (OrderedCollection new "note no semicolon" add: (e1); ... add: (en); asArray) so it obviously CAN be eliminated. That doesn't mean it should be. #@ can be eliminated too: aNumber @ anotherNumber is equivalent to Point x: aNumber y: anotherNumber. That doesn't mean #@ should be eliminated.
The practical questions are - would eliminating this feature save more code in the parser and elsewhere than it would cost in all the code using it (remember, not all such code is known to SqC or anyone else)
- is ideological purity worth the loss of clarity?
- would it be feasible to make {} support a module?
At 8:49 +0200 9/30/01, ducasse stephane wrote: >#() is necessary because it is compiled statically and cannot not be >simulated by other construct. Storing #() in Stack frame is not really goo >but this is an implementation aspect. This is false. Any use of # can be eliminated by adding a class variable and a class method using lazy initialisation. For example, #( abc 'abc' 4 3.4 $r ) can be written as MyClass literal27 where MyClass class>>literal27 literal27 ifNil: [ literal27 := (OrderedCollection new add: 'abc' asSymbol; add: 'abc'; add: 4; add: 3.4; add: $r; asArray)]. ^literal27
Come to think of it, we could eliminate $r and 'abc' too: 'abc' is (String fromPacked: 6382179) allButFirst $r is Character value: 114.
So #(abc 'abc' 4 3.4 $r) can, by reductio ad absurdum, be replaced by MyClass class>>literal27 literal27 ifNil: [ literal27 := (OrderedCollection new add: (String fromPacked: 6382179) allButFirst asSymbol; add: (String fromPacked: 6382179) allButFirst; add: 4; add: 3.4; add: (Character value: 114); asArray)]. ^literal27
without any non-numeric literals at all.
This is hardly less ridiculous than removing {}.
I agree that {...} is useful.
{e1. ... . en} is equivalent to (OrderedCollection new "note no semicolon" add: (e1); ... add: (en); asArray) so it obviously CAN be eliminated. That doesn't mean it should be. #@ can be eliminated too: aNumber @ anotherNumber is equivalent to Point x: aNumber y: anotherNumber. That doesn't mean #@ should be eliminated.
There is a big different @ is a message not a parsed construct with specific rules!!!!!
The practical questions are
- would eliminating this feature save more code in the parser and elsewhere
than it would cost in all the code using it (remember, not all such code is known to SqC or anyone else)
I could remove it!
- is ideological purity worth the loss of clarity?
Sure else Smalltalk would be like Java
- would it be feasible to make {} support a module?
At 8:49 +0200 9/30/01, ducasse stephane wrote:
#() is necessary because it is compiled statically and cannot not be simulated by other construct. Storing #() in Stack frame is not really goo but this is an implementation aspect.
This is false. Any use of # can be eliminated by adding a class variable and a class method using lazy initialisation. For example, #( abc 'abc' 4 3.4 $r )
This is not my point. I was just saying that storing #() in stake frame can lead to strange error.
can be written as MyClass literal27 where MyClass class>>literal27 literal27 ifNil: [ literal27 := (OrderedCollection new add: 'abc' asSymbol; add: 'abc'; add: 4; add: 3.4; add: $r; asArray)]. ^literal27
Come to think of it, we could eliminate $r and 'abc' too: 'abc' is (String fromPacked: 6382179) allButFirst $r is Character value: 114.
I'm really sorry to see the level of the discussion
I will never read your email anymore!!!
Bye
On Monday, October 1, 2001, at 02:33 AM, ducasse stephane wrote:
I'm really sorry to see the level of the discussion
I will never read your email anymore!!!
Bye
Sad.
I haven't seen this sort of reply in a list of grown-ups for some time. Stephane's initial proposal was certainly written in at least as provocative a tone as was Richard's reply, but neither message was wholly out-of-line. Certainly nothing that would rise to the level of justifying a form of censorship, private or otherwise, and to ignore substantive responses.
Whether due to a language barrier or not, Stephane must appreciate that the tone of his messages invite such scrutiny and the tone of responses such as Richard's. While he may not have intended to provoke, the messages appeared provocative. Perhaps this will help him to understand the tone of some of the responses.
Back to the merits, I share David's sense that {} is quite convenient, and would miss it. Of course it isn't necessary, as Stephane observes. However, neither do I perceive Stephane's sense that they are fundamentally flawed, requiring that they be purged from the compiler. (On the other hand, Dijkstra fan that I am, I also missed losing the form of multiple assignment permitted in earlier images, using "{a. b. c} := {exp1. exp2. exp3}".)
squeak-dev@lists.squeakfoundation.org