Example A-SIGNATURES Re: A Way to express Standard multi-argument Method Signatures in Smalltalk Re: [ANSI-Smalltalk] Next STEPs

[Eliot Miranda]

On Wed, Mar 12, 2008 at 5:53 PM, Panu Logic <panulogic at gmail.com> wrote:

>  Eliot Miranda wrote:
>
> ....  in (I think) ObjectWorks 2.3 ParcPlace changed it to
>      #(nil true false foo) = (Array with: nil with: true with: false with:
> #foo).
>
> Its generally more useful that way.  I (and I suspect plenty of others)
> find the extra #'s annoying noise that detracts from readablity.  The
> inconsistency is livable with since it is more convenient and there are only
> three exceptions.
>
>
> Three exceptions is  lot,  I think.
>

I think its only one exception that applies to three objects.  nil true
false self super and thisContext are all exceptions anyway because they're
pseudo-variables, not actual variables.  But generally as things go the
number of exceptions in Smalltalk is relatively small (arguably tiny).  In
practice (something a standard must be cognizant of) the literal array
exception for nil, true and false has caused no complaint I'm aware of in
the two decades its been in effect.



>     Consider instead this way of creating
> non-literal lists,  or  Arrays, with  the "Association Syntax":
>
> * nil  ->  true  -> false  -> #foo.*
>
> This creates a tree of Associations -  which really is a LINKED LIST!
> No special rules of evaluation, apart from standard ST-80  are required.
>
>
>
> The same pattern can be applied also to create "straight" Arrays
> or whatever  data-structures on the fly.  For instance we could define
> the method*  #<-*  for Object  so that
>
> *(nil  <-  true  <-  false  <-  #foo)    =
> (OrderedCollection with: nil with: true with: false with #foo)   *.
>
> The difference between the left- and right side above
> is that
> 1.  "( nil  <-  true  <-  false  <-  #foo) " is shorter
> 2.  We can create Collections  of arbitrary length this way:
> 3. We can decide whether to use a variable or a literal for
>      any part of the expression:
>
> #foo <-  foo <- 123 <-  nil  <-  "true"  <-  #false  <-  #foo <-  nil  <-
> true  <-  false  <-  foo
>

But these are not literals, they are expressions.


> POINT:  Smalltalk (-standard) does not *need* a syntax for creating
> Arrays
> with non-literal elements.  Why?  Because BINARY OPERATORS can be
> utilized and redefined as needed to construct arbitrary data-structures.
>

The experience with Java has been that the lack of a literal form for array
data results in bloat and slow start-up.  There is an alternative which has
significant downsides.

Compile-time evaluation of "literal expressions"
- what context is the expression evaluated in?
- what happens to side-effects? (the system can't easily limit side-effects)
- what happens if the context changes after the code is compiled? (how to
keep it up to date)

Adaptive optimizers don't solve the problem because they only optimize
oft-run code and by definition initialization code (which is a major client
of literal arrays) isn't oft-run.

So while the language may not need literal arrays, in practice they more
than carry their weight.

-Panu Viljamaa
>
> -- Utilize the Power of Smalltalk!
>
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080314/61a2b40a/attachment.html