[ANSI-Smalltalk] re: array creation syntax
John Dougan
jdougan at acm.org
Tue Mar 25 02:07:18 GMT 2008
There is a small piece missing from the history here that makes the
brace syntax make more sense. Up until Squeak 2.0, there was a
provision in Squeak to have a brace array as an lval in an assignment as
a form of multiple value return. For example:
{a . b} := aPoint xyArray.
where
Point>>xyArray
^{ x . y}
Some people feel that this reads better than:
aPoint xyBlock: [ :x :y | a := x. b:= y]
This is (as Eliot will recognize) essentially a very cut down version of
tuples and destructuring bind as implemented in a number of functional
languages. Gilad Bracha (Eliot's boss) wrote on such things on his blog
at http://gbracha.blogspot.com/2007/02/tuples.html and that post is
worth reviewing. He unfortunately abuses the term "literal" in the post,
as the brace syntax is better describes as a constructor that is
evaluated at run time.
Cheers,
-- John
Eliot Miranda wrote:
>
>
> On Mon, Mar 24, 2008 at 6:18 PM, Andres Valloud
> <andres.valloud at gmail.com <mailto:andres.valloud at gmail.com>> wrote:
>
> Eliot,
>
> Re: the Bezier2Segment... if I remember correctly, the {} syntax
> creates a literal at compile time. Is that so? Or is the array
> created every time execution goes over {}?
>
> In the case of Bezier2Segment, what I think is at times missing
> from consideration is what is usually done with such arrays... do:
> aBlock? Because if so, it would be cheaper (and *sometimes*
> clearer) to do:
>
> Bezier2Segment>>ellipseSegmentsDo: aBlock
>
> aBlock
> value: seg1a;
> value: seg1b;
> value: seg2a;
> value: seg2b;
> value: seg3a;
> value: seg3b;
> value: seg4a;
> value: seg4b
>
>
> Um, semicolons aren't what you mean. You want a
> Closure>>value:value:value:value:value:value:value:value: method
> (right?), and there isn't one. You have to use valueWithArguments:.
> But there isn't even an ArrayedCollection
> class>>with:with:with:with:with:with:with:with: method to construct
> one with(*). So once again a brace construct is the most convenient
> way to implement
> Closure>>value:value:value:value:value:value:value:value:.
>
> (*) at least you can write ArrayedCollection
> class>>with:with:with:with:with:with:with:with:. You can't write
> Closure>>value:value:value:value:value:value:value:value:value:
> directly because it would be a primitive and either an 8-arg primitive
> may not be available or a varargs primitive may not accept more than 3
> arguments. If you write it in terms of valueWithArguments: you still
> need Array class>>with:with:with:with:with:with:with:with: to
> construct the argument vector (or of course the convenient brace
> construct).
>
> One could further wonder why are there so many of these seg*
> things floating around...
>
>
> Because sometimes things come in octets...
>
>
>
> Just my opinion though,
> Andres.
>
>
>
> On Mon, Mar 24, 2008 at 6:09 PM, Eliot Miranda
> <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>
>
>
> On Sat, Mar 22, 2008 at 1:44 PM, Andres Valloud
> <andres.valloud at gmail.com <mailto:andres.valloud at gmail.com>>
> wrote:
>
> I think something that is being left unaddressed is
> whether using literal arrays that allow code expressions
> (e.g.: the brace syntax in Squeak) is a good practice or
> not. In my experience, I have not felt the need for such
> things, but maybe I have not been exposed to particular
> circumstances in which they become useful. Does anybody
> have some slam dunk examples that can be shared so that we
> can evaluate this better?
>
>
> Just open any recent Squeak image and broseer senders of
> #braceArray, e.g. the last line of
> Bezier2Segment>>makeEllipseSegments: aRectangle in Squeak V3.9
> reads
>
> ^{seg1a. seg1b. seg2a. seg2b. seg3a. seg3b. seg4a. seg4b}
>
> instead of
> ^(Array with: seg1a with: seg1b with: seg2a with: seg2b),
> (Array with: seg3a with: seg3b with: seg4a with: seg4b)
>
> BTW, the first example tat comes up in my image contains:
> {'zip'.'sar'.'pr'. 'mcz'. '*'} includes: suffix
> which is better written as
> #('zip' 'sar' 'pr' 'mcz' '*') includes: suffix
> so one can argue that it can be confusing for some to have two
> apparently similar constructs. But in my experience {}
> carries its weight (and there's no doubt that #() does).
>
>
>
> Andres.
>
> On Tue, Mar 18, 2008 at 9:57 AM, Eliot Miranda
> <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>>
> wrote:
>
> On Mon, Mar 17, 2008 at 2:11 PM, Craig Latta
> <craig at netjam.org <mailto:craig at netjam.org>> wrote:
>
>
> > Defining new language elements is hard. The
> worst that could happen
> > to this project, is to have extremely long
> threads with no conclusion
> > as on the Squeak list.
>
> Indeed, although for what it's worth there's
> no lingering debate
> there on this particular issue[1]. ;)
>
>
> -C
>
> [1]
>
> Namely, the short form of...
>
> Array with: #foo with: #bar
>
> is...
>
> #(foo bar)
>
> as in Smalltalk-80, and the short form of...
>
> Array with: #foo with: true
>
> is...
>
> {#foo. true}
>
>
> Well, in Squeak 3.9 I get
>
> Welcome to the finale version of 3.9 of 7 of November 2006
> #(nil true false foo) collect: [:ea| ea class]
> {UndefinedObject . True . False . ByteSymbol}
> #(nil true false foo) printString '#(nil true false #foo)'
>
> But I suspect the appropriate standard use of
> curly brackets
> across multiple dialects is a whole other morass. :)
>
>
> Having been living with Squeak for a while now I
> really, really like the curly brace syntax. I also
> note that it doesn't conflict with e.g. VisualWorks
> use of #{name} for binding references. So I have a
> strong personal preference for it, but that's just
> personal.
>
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> <mailto:ANSI-Smalltalk at lists.openskills.org>
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> <mailto:ANSI-Smalltalk at lists.openskills.org>
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> <mailto:ANSI-Smalltalk at lists.openskills.org>
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> <mailto:ANSI-Smalltalk at lists.openskills.org>
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
--
John Dougan
jdougan at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080324/949ced4f/attachment.html
More information about the ANSI-Smalltalk
mailing list