slices (was: objectification)

Jecel Assumpcao Jr jecel at merlintec.com
Wed Jul 10 21:08:53 UTC 2002


On Wednesday 10 July 2002 04:51, David Simmons wrote:
> Ok. You've certainly peeked my curiosity. Let's establish a little
> common ground for talking slice features in scripting applications
> here...
>
> a) Are you familiar with the (Smalltalk-style-variant) F-Script
> [http://www.fscript.org/] on the MacOS?

No.... wait... ok, the @ thing is exactly what I was talking about. I 
might want to send a message to all elements of a slice (color: 'blue', 
for example) and F-script can do this and far more.

One difference between my idea for slices and what they did is that I 
wanted to keep track of an object's origin like this

   a := #(1 2 3 4).
   b := #(5 6 7 8).
   |s| := a[2:3],b[2:3].  "concatenation of two slices"
   s := 9. "now a is #(1 9 9 4) and b is #(5 9 9 8)"

Perhaps this is overkill?

> b) Python (or) Ruby slices?
> ===

Nope.... ok, Python looks like Lua in this regard.... Ruby's slice! to 
delete things is interesting. A little better than ZX81 Basic, of 
course, but F-Script is more like what I was looking for.

> I thought/think that the SmallScript slice form is fully objectified.
> Although probably presented too little to clarify the point.
>
> For slices to be objectified (to me) means that:
>
> 1. The slice operations need to be an ordinary message form. Where
> the dimensions and parameters can have any designed arity (arg-count)
> just like keyword-messages. Thus any class can define its own meaning
> for the slice message.

Yes, this is what you showed in your previous message.

> 2. The language allows for var-arg (aka optional-args). So that we
> can define a generic slice message that is the "default" handler for
> all higher-arity (higher-arg) forms. But, since it is only a default,
> we can override it with explicit forms where we want to. This allows
> us to have just one method handle everything for a given class if we
> want to.

Ok, lot's of people hate #value:value:value: as well ;-)

> 3. We have mixins/interfaces so we can define all the array-slice
> message behavior/forms in a single mixin with "concrete" methods that
> implement all the behavior. This allows us to mixin in that
> implementation with any class we want to have support array-slice
> protocol -- without needing to write an methods on that class.

Great!

> 4. We can define new classes at will. So we are free to define an
> <ArraySlice> class that represents the result of sending a
> array-slice message to a given class that chooses to construct one
> and return it.

This was what I meant by "objectified". Since you only defined methods 
but not classes in your previous examples I thought you didn't have 
this capability.

> 5. We allow optional typing with multi-method overloading. Which
> means that we can specialize messages with the "same" name, but
> writing versions of them which differ "only" in their argument types.
> Thus we can write array-slice methods that accept other slices, or
> values, etc.

There are some people trying to build prototype based language (slightly 
inspired on Cecil) with this as their central concept:

   http://tunes.org/~eihrul/pmd.pdf

> Class name: ArraySlice extends: IndexedCollection
> {
> 	...
> 	"presume we have written appropriate protocol"
> }
>
> Method behavior: IndexedCollection [
> [a:b]()
> 	^ArraySlice on: self start: a end: b
> ]

Right, if you can define a method for the notation there is no reason 
why the method can't create and return a new object. Certainly if my 
idea was possible in regular Smalltalk it would be even simpler in 
SmallScript. I simply didn't think that this was the style you wanted.

> Method behavior: IndexedCollection [<'cloning'>
> [<ArraySlice>slice]()
> 	^ArraySlice on: self start: slice.start end: slice.end
> ]

Eh? Ok, this makes sense unless you come from an APL (or F-script, it 
seems) background. In that case you might want instead

        ^ArraySlice on: self withIndexes: slice elements

> Eval [
>
> 	|slice| := {3,4,5}[2:3].
> 	|
> 	|slice2| := someCollection[slice].
>
> 	"or equivalently, since #::[<>]() is aliased to #at:"
> 	slice2 := someCollection at: slice.
> ]

This would be the same as someCollection[2:3], right? My idea would 
result in someCollection[4,5]. I am not sure which is less confusing.

> Does this cover the "objectification" were you looking for?
>
> Making slice facilities useful in SmallScript is important.
> Understanding what you are looking for helps.

By defining classes you can certainly do all that I imagined. The slice 
objects can also act as proxies and resend messages to all their 
elements, which is one thing that I want to do a lot.

My interest is exposing this at the GUI level. So slices certainly must 
be an object if they are to have a visual representation. Then you can 
create a slice on all even numbered headers in a text and then send the 
message #bold to them. Oh, I know that the "right" way to do this is to 
structure the objects so there would be one style object representing 
all even numbered headers and then we could send #bold to it. But in 
practice no matter how we organize things we will need to talk about 
collections of things that don't fit into our plans. So I want slices.

> P.S., SmallScript's selector namespace modularization allows more
> than one slice system to coexist transparently in a single running
> program/image.

I just looked at the squeak modules list archive and it seems that this 
kind of thing will have to be solved here as well.

-- Jecel



More information about the Squeak-dev mailing list