Re: Creating collections - dynamic list operator {...}

"Randy A. Ynchausti" <[hidden email]> wrote in message
news:L0d16.1916$[hidden email]... problem
> seems to boil down to two issues:
>
> 1) find the objects that you want to put in the collection
>
> 2) put the objects in the collection.
>
> Because of the explosive combination of possible senarios, my point was
that
> in some cases, the simplest approach is the first example you proposed.
> However, if you put bounding limits around issue 1 and 2, then there are
> many other solutions that might be more straightforward and simple.
Below,
> you have proposed one possible refactoring which in some circumstances may
> result in more straightforward and simple code.  However, I do not think
it
Do you have a suggestion as to how or what might be changed or done
differently. When I originally designed the {...} operator for QKS
Smalltalk-91 I chose an approach that was almost identically to that by
which blocks are generated.

It had the merits that it made it a relatively trivial extension in a
Smalltalk compiler to extend the block-style lexer/parser and code generator
to support dynamic lists <List>.

It also has a form that is both easy to implement in the virtual machine and
allows for "optimizing" creation (or even avoiding it) of the <List>
instance in some important scenarios. By the way, as a matter of clarity,
the <Array> and <OrderedCollection> classes in QKS Smalltalk are actually
just aliases for the <List> class.

Over the years, our frameworks and other code have used this operator
extensively. We've got over 80MB of framework sources from our different
platforms/versions and it has been heavily used. It been very popular among
SmalltalkAgents users, and it has shown itself to be exceptionally useful
within our internal use of it as well.

The {...} operator was added to squeak by a very active user of QKS
Smalltalk who had been using extensively within SmalltalkAgents for MacOS.
When it was added to squeak, they relaxed the syntax from the original QKS
form to allow #, delimited arguments (which I had originally opposed in QKS
Smalltalk).

QKS Smalltalk had required arguments to be delimited by periods "." because
I didn't want to exclude the #, binary selector from statement expressions.
I really thrashed over that when I originally designed it because I kept
finding myself naturally wanting to allow "," delimiter. When I was
designing the SmallScript language, I finally gave in and decided to also
support the "," as an additional delimiter.

 From some of the squeak discussions I've read regarding that operator, it
has not been officially "blessed" as being squeak Smalltlak and some of the
squeak central related comments have perhaps suggested that it not be used.

Given that contrast to QKS experience with it, and your misgivings, I'm very
interested in understanding more on your and other Smalltalker's views and
other possible solutions for the features it provides.

Thanks,

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> Regards,
>
> Randy
>
>

David,

Costas' question was:

> > > >> I am trying to find an easier way to express the following
construct
As I stated earlier, this problem (finding an easier way to express the
construct) seems to boil down to two issues:

1) find the objects that you want to put in the collection

2) put the objects in the collection.

( Please forgive me for not including the construction of the new collection
in this issue list.  It just didn't seem to be that important. )

Existing methods that seem to convey the spirit of a solution to the problem
are:

    Collection>>select:
    Collection>>reject:
    Collection>>collect:
    Collection>>detect:
    Collection>>inject:into:

However and as you know, they operate on a collection.  Since the problem is
trying to find an easier syntax for creating a collection with a general
number and type of objects as its members, this family of methods is not
appropriate.

Costa proposed:

> > > As a matter of fact I am proposing that the best way is to have this
> > > message sent to a BlockClosure  using  a message similar to #value.
> > > The block will then return the answer of each statement to an array
> > > the way Squeak does.
> > >
> > > For example:
> > >
> > > userInfo := [user. password. level. 100. #system. Date today. #(read
> > > write)] arrayValues.

The problem with this approach is that block closures now have significantly
different behavior opening a Pandora's box of additional problems -- mostly
for the would-be and average Smalltalk developer.  To me the expense
outweighs the benefit.

> Do you have a suggestion as to how or what might be changed or done
> differently. When I originally designed the {...} operator for QKS
> Smalltalk-91 I chose an approach that was almost identically to that by
> which blocks are generated.

I provided one such suggestion to Costas -- extend the Collection>>with:...
family of methods.  That is about as simple as it gets.  Okay, so you don't
like typing "with:" -- then implement a method "<-" that recursively
evaluates or double dispatches the statements, evaluates them, and addes the
returned objects as elements to the new collection.  I have additional
ideas, but I am trying to be brief in making my "misgivings" clear to you.
Obviously, there is a practical limit to the syntax's of these
incantations -- as well as the syntax that Costas proposed.  However, I am
not opposed to a new Smalltalk syntax that does this construction --
possibly as you suggest above.  But for my development dollar, I want all
code to be simple, direct, and easy to read.  If a new Smalltalk syntax can
be found that expresses the idea of evaluating statements and adding the
return elements to a newly constructed collection, I am all for it.  The
curly brace, however, does conflict with namespace usages in VisualWorks.

[snip]

> From some of the squeak discussions I've read regarding that operator, it
> has not been officially "blessed" as being squeak Smalltlak and some of
the
> squeak central related comments have perhaps suggested that it not be
used.

I have not read any of those comments.  However, I would not recommend
Costas' proposed syntax be used.

> Given that contrast to QKS experience with it, and your misgivings,
> I'm very interested in understanding more on your and other Smalltalker's
views and
> other possible solutions for the features it provides.

Any new syntax that does not confuse the existing operation of block
closures, that is simple, direct, and more quickly understood by the
beginning and average Smalltalker is okay by me.  That is not what the block
closure approach provides.  QKS seems to have implemented something that has
been used -- I have proposed implementing new behaviors that provide this --
but for me, if it is not simple, direct, easy to understand, and maintains
the intuitive integrity of Smalltalk -- the cost/benefit ratio will not be
favorable.

Regards,

Randy

"Randy A. Ynchausti" <[hidden email]> wrote in message
news:4Pj16.1$[hidden email]... collection
> in this issue list.  It just didn't seem to be that important. )
>
> Existing methods that seem to convey the spirit of a solution to the
problem
> are:
>
>     Collection>>select:
>     Collection>>reject:
>     Collection>>collect:
>     Collection>>detect:
>     Collection>>inject:into:
>
> However and as you know, they operate on a collection.  Since the problem
is significantly
> different behavior opening a Pandora's box of additional problems --
mostly
> for the would-be and average Smalltalk developer.  To me the expense
> outweighs the benefit.
>
> > Do you have a suggestion as to how or what might be changed or done
> > differently. When I originally designed the {...} operator for QKS
> > Smalltalk-91 I chose an approach that was almost identically to that by
> > which blocks are generated.
>
> I provided one such suggestion to Costas -- extend the
Collection>>with:...
> family of methods.  That is about as simple as it gets.  Okay, so you
don't
> like typing "with:" -- then implement a method "<-" that recursively
> evaluates or double dispatches the statements, evaluates them, and addes
the
> returned objects as elements to the new collection.  I have additional
> ideas, but I am trying to be brief in making my "misgivings" clear to you.
> Obviously, there is a practical limit to the syntax's of these
> incantations -- as well as the syntax that Costas proposed.  However, I am
> not opposed to a new Smalltalk syntax that does this construction --
> possibly as you suggest above.  But for my development dollar, I want all
> code to be simple, direct, and easy to read.  If a new Smalltalk syntax
can
> be found that expresses the idea of evaluating statements and adding the
> return elements to a newly constructed collection, I am all for it.  The
> curly brace, however, does conflict with namespace usages in VisualWorks.

Thanks Randy,

This feedback is great.

I don't think there is a conflict with VW. I talked to Eliot Miranda early
on when they (VW team) were exploring namespaces and parcels; I have also
talked more recently with Eliot on this topic at CS1. My understanding is
that the namespace system relies on #{...} form which has a "#" to
distinguish it from {..}.

The #{...} expression syntax was used in QKS (SmalltalkAgents) Smalltalk for
GUID's. SmallScript uses this for general path expressions. At CampSmalltalk
One, Eliot and I discussed VW use of #{...} for paths and we resolved the
potential conflict. I extended the syntax in SmallScript to unify the VW
path form with QKS GUID form; the result is now a general path expression
that supports UUID's as part of a dynamic path expression.

There are other syntax forms like #[...] in VW that are used to create
static <ByteStorage> structures. QKS Smalltalk has a very different meaning
for that syntax. I never found a need for the pattern so QKS Smalltalk has
no operator for  <ByteStorage> declarations; we just convert <String>
instances with base 2, base 16, base 35 encoding, or other packed and/or
encrypted forms.

The #[...] form is used in QKS Smalltalk for executing/generating compile
time expressions (and as of SmallScript/v4-AOS I deprecated its other use as
a form of assertion). Dolphin Smalltalk has a similar construct for
declaring static/compile-time expressions.

I have pretty strong feelings about blocks and their semantic importance
within Smalltalk. I find that other uses of #[...] muddle the significance
of the very similar block operator form. I.e., its use for creating literals
like <ByteStorage> or a dynamic collection as Costas suggested (Not to
mention the significant semantic/syntactic language issues of using [...]
as... for dynamically creating collections).
--------

The {...} operator is used in a variety of places, including QKS Smalltalk
exception syntax.

    [
        "Try block expressions here"
    ]
    on: {EClass, ETypeX, 17, ...} do: [:signal|
    ];
    on: 'foo' do: [:signal|
    ];
    on: SomeClass "on class or kind-of instances" do: [:signal|
    ];
    ifCurtailed: [:unwindSignal|
    ];
    finally: [:unwindSignal|
    ];
    try.

The QKS compilers optimize exception guards so NO blocks are ever created
and exception handlers effectively cost nothing until an exception occurs.
Even when an exception is raised, the full (SEH) structured exception
handling built into the AOS VM Platform provides (low/cost) efficient
exception handling that is integrated with host and C++ services.

The basic QKS cascading exception syntax form predates the ANSI standard
which does not allow cascading (combining cases). The ANSI standard requires
that tryBlocks be triggered on each of those messages. Which means that for
compatibility, even though the "try" is the trigger for the tryBlock.

The use of "try" is actually optional. QKS Smalltalk compilers always
inline/optimize exception guards so the ";" cascading does not require the
"try". The compiler recognizes the exception messages and "logically"
triggers the tryBlock on the occurence of the last cascaded message. This
compiler "cheat" has to be allowed to enable the ANSI forms to work properly
in QKS Smalltalk.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> [snip]
>
> > From some of the squeak discussions I've read regarding that operator,
it Smalltalker's
> views and
> > other possible solutions for the features it provides.
>
> Any new syntax that does not confuse the existing operation of block
> closures, that is simple, direct, and more quickly understood by the
> beginning and average Smalltalker is okay by me.  That is not what the
block
> closure approach provides.  QKS seems to have implemented something that
has
> been used -- I have proposed implementing new behaviors that provide
this --
> but for me, if it is not simple, direct, easy to understand, and maintains
> the intuitive integrity of Smalltalk -- the cost/benefit ratio will not be
> favorable.
>
> Regards,
>
> Randy
>
>

David Simmons wrote:
>
> The {...} operator is used in a variety of places, including QKS Smalltalk
> exception syntax.
>
>     [
>         "Try block expressions here"
>     ]
>     on: {EClass, ETypeX, 17, ...} do: [:signal|
>     ];
[... more cascading...]


In VisualWorks the exception classes implement the comma to create an
exception collection so in the specific case of exceptions the curly
braces can be dropped:


    [
        "Try block expressions here"
    ]
    on: EClass, ETypeX , ... do: [:signal|
    ];





Reinout
-------

"Reinout Heeck" <[hidden email]> wrote in message
news:[hidden email]...
> David Simmons wrote:
> >
> > The {...} operator is used in a variety of places, including QKS
Smalltalk
That format is supported by the QKS compilers. However, what may not have
been clear from my previous post is that the AOS Platform Object Model, and
therefore SmallScript and QKS Smalltalk, allow you to catch (or throw) ANY
kind of object within a tryBlock guard.

Which means that, semantically, the generalization of sending the #, message
will not work. (See the string example below). Although, in reality, the
compiler recognizes tryBlocks and their exception guard messages, so it
actually does (special-case) support the #, syntax like the {,} form.

As with the compiler's (special-case) ";" cascade support not requiring a
#try message, the compiler has to support the #, case in order to support
the ANSI specified syntax.

    "" For example, we can throw <10>
    [
        10 throw.
    ]
    on: {10, 19, -3} do: [:signal|

        ...
    ];
    on: {'Error 1'. 'Error 2'} do: [:signal|
    ];
    on: 'Error 3', ('Bogus - concatenation not intended' $-
                   "this is actually one string within the
                    parenthesis. The compiler supports such
                    static string concatenation to enable
                    breaking long strings or character patterns
                    up into multiple lines"
                   ' but would be performed') do: [:signal|
    ];
    on: {anObject, [:signal| "custom filter #1 here" ]} do: [:signal|
    ];
    on: [:signal| "custom filter #2 here" ] do: [:signal|
    ];
    ...

Keep in mind that the AOS Platform exception handling system can process
anything as an exception. That means exceptions thrown by external code
(C++,etc.) or by the OS (memory access faults, etc). The AOS Platform is
designed to enable supporting languages with exception semantics like C++
where any kind of object can be thrown and handled.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
>
>
> Reinout
> -------

"Bonz" <[hidden email]> wrote in message news:[hidden email]...
> > When I originally designed the {...} operator for QKS Smalltalk-91
> > I chose an approach that was almost identically to that by
> > which blocks are generated.
>
> In adding it to GNU Smalltalk, I used the different approach I showed in
my other messages.  But indeed the code that parses it is much similar to
the one that
> parses blocks, and the code that compiles it reminds the one generated for
#whileTrue/#whileFalse/#repeat.
>
> The implementation is indeed simple.  A few months ago, in a morning I
changed the C lexer/parser/compiler, the Smalltalk lexer/parser/compiler,
the interpreter, and
> the JIT!

Excellent! I'm hoping/guessing those changes back are now in the GNU
Smalltalk distribution?

>
> I use it little, because large arrays are often symptoms that refactory is
needed but when I do I find it extremely compact, useful and clear (e.g. in
> implementations of #anythingWith:with:...).

That sounds very similar to my experience with it.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> I didn't know that {...} originated in QKS; adding it to VisualWorks would
cover the most used VMs (and the most used VM in particular).

"Brian Gridley" <[hidden email]> wrote:

Thank you on this great idea. It's what I am looking for. And if I may
take it one step further. How about making a subclass of
OrderedCollection calling it OC and add a class side &.

& newObject
        ^self new add: newObject; yourself.

Then we could use:

aColl:= OC & user & password &  level & 100 & #system1 & Date today &
#(#read, #write).

Costas

> >If the issue is primarily readability and keystroke count (both near and
> >dear to me), the following method could be added to any collection that
> >implements add:
> >& newObject
> >     self add: newObject.
> >     ^self
> >Thus you can write:
> >    OrderedCollection new
> >        & user & password &  level & 100 & #system1 & Date today &
#(#read
No offence guys but that looks strange to me. That's nothing more than my
own opinion , but still...
Do you really think that "OC & user & password &  level & 100 & #system1 &
Date today & #(#read #write)" looks ok ?
Someone already mentioned that Smalltalk was about being a pure english
without those cryptic structures. Let's not forget about that please.
Consider following code as _readable_ even by non-smalltalkers ( I already
asked some 100% non-programmers what do they think and everyone could tell
what that code does ):
******************
OrderedCollection new
    add: user;
    add: password;
    add: level;
    add: 100;
    add: #system;
    add: Date today;
    add: #(#read, #write);
    yourself
******************
Does it really seem to be more readable or it's just me ? Don't forget that
your &&& example does exactly the same , but doubles number of message
sends. In my opinion this thread was extremely interesting from theoretical
point of view, but now people really seem to start using these techniques...
which is kinda strange :)

Please feel free to correct me - it's all about trying to find the best
solution rather than trying to prove something.

-Boris

"Boris Popov" <[hidden email]> wrote:

Boris,

Yep it's getting long and is interesting.

You are right about the English. But even with English we have
abbreviations for commonly used phrases and idioms. Its just less
typing and sometimes more concise and easier to express one's self.

For example in English and Smalltalk when we want to add numbers we
use the + instead or - sign instead of add and minus. When we make
lists we usually write (3 apples, 10  tomatoes, 5 cucumbers)

Basically I was looking for an alternative. And I think it has come
very close barring syntax additions (ala Squeak). And one does not
have to use it.

You know maybe the & is not a good choice. . And maybe OC is a bad
name for a class. How about List << and the comma.

aColl:= List << user , password ,  level , 100 , #system1, Date today
, #(#read #write).

And the 64 millisecond question is to ask programmers what they would
prefer to type and read. And is the above really weird?

The extra execution downside you point out is minimal and can probably
be overcome with some smart coding.

>Please feel free to correct me - it's all about trying to find the best
>solution rather than trying to prove something.

Agreed

Costas

Ok... Let's not get into details of naming the class. In the perfect
solution you would probably want to extend exisiting Collection protocol to
make the creation of any kind of collection possible from the very
beginning. And having comma instead of & is just a matter of personal
opinions.

> And the 64 millisecond question is to ask programmers what they would
> prefer to type and read. And is the above really weird?

The above is not as weird as & version , but still... :) Personally I don't
feel that I spend too much time on typing. You know what I mean. One more
point why I love Smalltalk - not too much typing at all... Me being lazy to
type makes me think twice before I write something more than 5 lines of
code.... And if we are talking about practical side of the story , situation
where you would need to create big collections like that from stand-alone
objects would be considered at least strange by me. It's one of those
"warnings" when I start thinking about design flaws. I may be wrong about
this , and I would love to see your real life examples where you would want
to create such collections (thnx)...
I am not sure whether I express myself exactly the way I feel (english is my
second language) , but I hope you understand what I mean by all this... :)

> The extra execution downside you point out is minimal and can probably
> be overcome with some smart coding.

Yeah... Message sends overhead was kinda lame reason anyway... :)

-Boris

On Wed, 3 Jan 2001, Costas Menico wrote:

> "Boris Popov" <[hidden email]> wrote:
[snip] [snip]
> You know maybe the & is not a good choice. . And maybe OC is a bad
> name for a class. How about List << and the comma.
>
> aColl:= List << user , password ,  level , 100 , #system1, Date today
> , #(#read #write).
[snip]

If we're doing a survey I *know* I vastly prefer the former, even putting
aside the weirdness of the overriding of #<< and #,. (In general, I'm
finding myself not a big fan of #, and, indeed, of string
concatination. Even putting aside efficiency issues I'm starting to prefer
things like:
        String streamContents: [:strm |
                strm nextPutAll: 'The first bit';
                     nextPutAll: someStringContainingVariable;
                     nextPut: Character cr;
                     nextPutAll: self someStringReturningMethod].

Now, I *will* say that do tend to put concatinations on some of these
lines, for example:

                ... nextPutAll: '<li>', self rowOne, '<li>';
                        nextPutAll: '<li>', self rowTwo, '<li>'; ...

(Increadibly artificial example of course. My point being that I don't
mind using #, where it "feels" more like an excape character ina
literal.)

This is not to say that I don't concat strings right and left, just that
in a lot of cirucmstances I go through the extra effort of using a stream
because it's just cleaner.

OTOH, I wouldn't mind a simple macro that took a series of concatinations
and generated the above. I'm in favor of saving typing, just not at the
expense of readibility.

I also think that the verbose forms are easier to modify. <shrug/>

Cheers,
Bijan Parsia.

I very much agree with what Boris (and Bijan later) said, but there is one
point Costas mentioned I just can't resist commenting on.

>> You are right about the English. But even with English we have
>> abbreviations for commonly used phrases and idioms. Its just less
>> typing and sometimes more concise and easier to express one's self.
>>
>> For example in English and Smalltalk when we want to add numbers we
>> use the + instead or - sign instead of add and minus. When we make
>> lists we usually write (3 apples, 10  tomatoes, 5 cucumbers)

The issue with all the "abbreviations" here is language vs slang.
Unabbreviated things are the language and are understood by anyone who
speaks the language (and in case of Smalltalk this often means by those who
speak English rather than those who speak Smalltalk).  Abbreviations are
slang and are understood only by speakers of a certain group that has
adopted that particular abbreviation.  This makes them automatically less
useful than the equivalent non-slang expressions because the audience that
can understand the latter is wider.

In your examples, +, - and a comma only look like abbreviations but are
really language, not slang.  Try to find a literate person who wouldn't know
what + or a comma stand for.  Most of the non-word selectors that are common
across all Smalltalk dialect are of this kind.  Selectors that are not part
of "normal" English, for example #-> and #>> are not found in all dialects
precisely for the reason that different groups of people did not find them
all that intuitive to give up readability for.

Now if we must have some alphabet soup kind of solution for creating Arrays
(though as I argued before if you have to create "templatized" you are
likely to have a problem in your design), I would prefer the brace
constructor because its "slang rating" is much lower than that of the things
like "Foo << bar & quux" and it fits into the language model much nicer.
Its concept is immediately recognized as a dynamic counterpart of the
literal array constructor, so it is easy to understand what it does.  Its
shape resembles that of a block so it is easy to understand how it works.
Even from the pragmatic point of view, in case of keyword messages used to
create elements of the array, it is more resilient to errors and more
readable: "List << (self foo: foo) & bar" needs parentheses or it breaks the
whole thing.

Cheers,

--Vassili

"Vassili Bykov" <[hidden email]> wrote:

I disagree and I am not asking to add slang and eliminate classic
language.

Maybe its high time though that 1Smalltalk started recognizing some
slang as part of the language. A language evolves because of need. I
can imagine at some point in history arguing how bad it is to use +
and - to add up your dough. Accounting must have been hell.

Fortunately and wisely the original designers recognized this and
allowed us to define new "slang" with Smalltalk. So now that I can do
what I need  I am happy. I will add some slang to my repertoire coz
<g> I think it makes my code more visual and concise and less error
prone.

And if it gets used enough then, hey, slang turns into mainstream.
Yipee!  With today's English Shakespeare would have a fit. Thank God
he ain't around to see it.

And I disagree that this is alphabet soup. The alphabet doesn't even
contain symbols.  Maybe you meant ASCII soup?

I didn't think this thread would go so long. I am afraid to ask
anything more complicated now ;). So how about implementing multiple
inheritance?. (just kidding, please don't answer)

Regards,

Costas