Arrays / collections with literal syntax - fixed size?

Are #(...) and {...} the only 2 short, non-message-passing syntaxes for
creating collections?

They both seem to yield Array, which apparently has a fixed size. I'm
curious about why the only (I think) convenient syntax for simple collection
usage has this restriction on what you can do with it.

And as far as I can tell, there is no similar convenient syntax for
dictionaries. Is that true?

I am trying to build up some simple declarative meta-data structures and
find a big jump in verbosity from simple syntax to constructing things by
message-passing.

Thanks - Sophie

>>>>> "itsme213" == itsme213  <[hidden email]> writes:

itsme213> Are #(...) and {...} the only 2 short, non-message-passing syntaxes
itsme213> for creating collections?

For compiling collections, yes.

itsme213> They both seem to yield Array, which apparently has a fixed
itsme213> size.

Yes, because those can't change during compilation.

itsme213>  I'm curious about why the only (I think) convenient syntax for
itsme213> simple collection usage has this restriction on what you can do with
itsme213> it.

Sent it an "as:" to change its shape:

  #(2 3 5 7) as: Set

itsme213> And as far as I can tell, there is no similar convenient syntax for
itsme213> dictionaries. Is that true?

  { #dog -> 'bark' . #cat -> 'meow' } as: Dictionary

Browse the Collection hierarchies from time to time.  Lots of good stuff in
there.  In your case, look at the "converting" protocols, and implementors
of #newFrom: (which #as: uses).

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

"Randal L. Schwartz" <[hidden email]> wrote in message
> itsme213> They both seem to yield Array, which apparently has a fixed
> itsme213> size.
>
> Yes, because those can't change during compilation.

Can't they be changed subsequently?

> In your case, look at the "converting" protocols, and implementors
> of #newFrom: (which #as: uses).

Thanks - Sophie

>>>>> "itsme213" == itsme213  <[hidden email]> writes:

itsme213> "Randal L. Schwartz" <[hidden email]> wrote in message
itsme213> They both seem to yield Array, which apparently has a fixed
itsme213> size.
>>
>> Yes, because those can't change during compilation.

itsme213> Can't they be changed subsequently?

The intent of an array is that it's readonly ("immutable").

And this belongs on -beginners, not -dev.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Randal L. Schwartz schrieb:
> The intent of an array is that it's readonly ("immutable").
>  
?

So why does "#(1 2 3) at: 1 put: 5; yourself" evaluate to "#(5 2 3)" ?

Instances of Array have fixed sizes, yes. But I would not say that makes
them readonly.

This works in Squeak too:
'Boy' at: 1 put: $T evaluates to 'Toy'

It won't work in (latest versions of) VisualWorks, where you have
immutable literal strings.
> And this belongs on -beginners, not -dev.
>  
I don't think so.

Alex

Right.

It's the fact that #(..) is a literal.
And modifying a literal is a bad practice, whatever the language.

However, { } is NOT a literal.
I hope the question raised by Sophie has been in the mind of whoever
introduced this extension: why favor a specific Collection subclass in
this case?
Well, the answer might be to maintain Smalltalk Core at a minimum. Since
Array already are necessary for the literal form...

Nicolas

Alexander Lazarevic' wrote:

"nice" <[hidden email]> wrote

> It's the fact that #(..) is a literal.
> And modifying a literal is a bad practice, whatever the language.
>
> However, { } is NOT a literal.

This seems like a reasonable argument for {...} to be a resizable
collection, while [...] is not.

A related minor question: why does
    #(a b c)
print as
    #(#a #b #c)
If it is a literal the first seems a more minimal default.

Such syntax questions seem out of place in Smalltalk's minimalist
philosophy. If they are not appropriate to this list, I apologize. I am
relatively new to Squeak/ST (played on its periphery in the past) and know
much of this is frozen, but to me a combination of some of:
 + ST keyword-message
 + some Ruby syntax conveniences ([],+,optional self...)
 + some form of namespaces (language or tool)
 + ST image and MC based development

would help light-weight DSL-ish usage a lot. Simply contrast:

  PWDisk on:
    (self data: theData
        footer: (OrderedCollection with: 1 with: 2))
vs.

  disk on: (data: theData footer: [1 2])

- Sophie

>>>>> "itsme213" == itsme213  <[hidden email]> writes:

itsme213>   PWDisk on:
itsme213>     (self data: theData
itsme213>         footer: (OrderedCollection with: 1 with: 2))
itsme213> vs.

What are "1" and "2"?  There's too much magic happening here.

That belongs behind a method, to make it hidden and subclassable:

PWDisk on: (self data: theData footer: self defaultFooter)

And even *that's* a bit too noisy for me.

Generally, if you hit parens, you're probably due for a refactoring.
Two sets of parens, definitely due.

#defaultFooter defined as

  ^{ 1 . 2 }

but even the 1 and 2 are mysterious constants there.  If they have
meaning, they should be constants or something:

  ^{ self beBold . self beCrazy }

or whatever the meanings are.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

> Right.
>
> It's the fact that #(..) is a literal.
> And modifying a literal is a bad practice, whatever the language.
Now I was under the impression, that a context had a copy of a compiled
method with copies of the literals, so that you could only modify the
copies but not the literals in the compiled method. But it seems not to
be that way:

Play class>>test
    "5 timesRepeat: [Transcript show: Play test printString; cr]"
    | a |
    a := #(1).
    a at: 1 put: ((a at: 1) + 1).
    ^ a

This is evil! :)

Alex

> Now I was under the impression, that a context had a copy of a compiled
> method with copies of the literals, so that you could only modify the
> copies but not the literals in the compiled method. But it seems not to
> be that way:

This would turn a simple message send to be incredibly expensive.

> This is evil! :)

I want an immutability flag in the object-header!

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

"Randal L. Schwartz" <[hidden email]> wrote

> itsme213>         footer: (OrderedCollection with: 1 with: 2))
>
> What are "1" and "2"?  There's too much magic happening here.

Replace them with anything else. The point was
  OrderedCollection with:.. vs. [ ... ]
or Dictionary ... or {..}asDictionary vs. {a=>b, c=>d}

All in the context of painless light-weight DSL-like expression. Even the
simple [optional "self"] makes quite a difference.

Don't misunderstand, I would find it hard to give up the ST image, Seaside
and kin, and their productivity.

> Generally, if you hit parens, you're probably due for a refactoring.
> Two sets of parens, definitely due.

Nice advice, thanks!

- Sophie

On 6-Jan-08, at 12:54 PM, Alexander Lazarevic' wrote:


Goodness me, wherever did you get that idea from? If we had to copy a  
CM and all its literals every time we activated a method it would  
certainly impact performance!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Aio, quantitas magna frumentorum est. = Yes,  
that is a very large amount of corn.

"Lukas Renggli" <[hidden email]> wrote in message
> I want an immutability flag in the object-header!

I think field immutability (instVars or indexedVars) is more fundamental.
Perhaps object immutability can be built on top of it?

Sophie

Of course, in Squeak, you can create your own variants using implicit
self, new literals, etc. Dig into Compiler-Kernel.

I was sitting with (I think) Rob Withers at the first CampSmalltalk
when Chris Grindstaff showed us how to add literal ByteArrays. I was
coming from VisualAge and it seemed important to me.

But, at the end of the week, it didn't seem it was worth sheparding
through Squeak Central (might have even been called the Squeak Team
back then). It was easier to just update the cross platform code for
the project to use non-literal byte arrays. (I think along the lines
of:

#() asByteArray

Getting anyone to use them is tricky because of the installed base. I
mean, Seaside doesn't use braces for compatibility with other
Smalltalks.

On Jan 6, 2008 3:38 PM, itsme213 <[hidden email]> wrote:

Lukas Renggli writes:
 > > Now I was under the impression, that a context had a copy of a compiled
 > > method with copies of the literals, so that you could only modify the
 > > copies but not the literals in the compiled method. But it seems not to
 > > be that way:
 >
 > This would turn a simple message send to be incredibly expensive.
 >
 > > This is evil! :)
 >
 > I want an immutability flag in the object-header!

It may be better to implement immutability inside the image using
immutable sub-classes and similar tricks to the write barriers for OO
DBs.

Doing so would allow the implementation to be optimised by all
optimisations that help for sends in general. Adding a immutability
flag would add another thing to check on every instance variable
write. Squeak's write barrier is expensive enough as it is.

Bryce

On 7-Jan-08, at 12:30 PM, <[hidden email]> wrote:

Eliot was working on an immutability bit in May. Generally speaking  
I'd be happy to support it in whatever way he did/does it. Never yet  
met anyone as good as him at working this stuff out.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Government organization

> Doing so would allow the implementation to be optimised by all
> optimisations that help for sends in general. Adding a immutability
> flag would add another thing to check on every instance variable
> write. Squeak's write barrier is expensive enough as it is.

It is not quite transparent, unfortunately.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch