New Pharo Collections

Greetings to everyone. My name is Alexander Brenchev, and I want to tell you about my recent project, which will be my pre-bachelor work.

The goal of my project is to make a new collections for Pharo Smalltalk. We have a great plans about list of important collections, but we also need your opinion about them. So, feel free to make your suggestions about collections which you want to be implemented.

The project page is available here

Now I want to tell something about what I've done so far:

1)  A brief documentation about current collections hierarchy

2)  A workflow of developing new collections for Pharo

3) Little tutorial which describes how to bring new collections for Pharo

As you can see, PillarHub will be a platform for my blog, where I will tell you about my faults and victories.
I have no great results for now, but I've tested the main idea of collections development workflow, and now i am well-armed to make something that really matters. Stay tuned to PillarHub, ESUG and smalltalkhub to see the latest progress of the project.

Thanks everyone.

Sounds like a great idea for a project.

Off the top of my head, I would be interested in support for "slices" meaning taking being able to treat a subset of a larger OrderedCollection as its own OrderedCollection rather than using copyFrom:to: to create a duplicate object to work with.  It seems to me that this would be a more efficient method and should not be difficult to implement I think.

Le 16 déc. 2014 22:48, "dboeren" <[hidden email]> a écrit :.
> Off the top of my head, I would be interested in support for "slices"
> meaning taking being able to treat a subset of a larger OrderedCollection as
> its own OrderedCollection rather than using copyFrom:to: to create a
> duplicate object to work with.  It seems to me that this would be a more
> efficient method and should not be difficult to implement I think.

Here is an email I sent about that :

I see you are working on new collections for Pharo. That's great news,
I'm convinced we can do much better (even if what we already have is
already much better than what can be found in most other languages).
One thing you could work on is the notion of iterator. There are
plenty of ways to iterate over a collection:

1/ from the first to the last item
2/ from the last to the first
3/ from the 2nd item to the 5th
4/ only even items (2, 4, 6, ...)
5/ ...

Currently, we have to create new collections to iterate in strange
ways. For example, to iterate from the last to the first item, we
create a new collection by sending #reversed to the original
collection. I think that is bad because it creates a copy and that
should not be necessary. What we miss is the notion of iterator. An
iterator is an object that is specialized in iterating over any kind
of collection and has methods like #select:, #reject:, #allSatisfy:.
From a collection, you can access different kinds of iterators
(reusing the same ordering as before):

1/ aCollection iterator
2/ aCollection reverseIterator
3/ aCollection from: 2 to: 5
4/ aCollection iterator select: [ :each | each isEven ] --> that
returns an iterator as well, so you can call #select:/#reject:
multiple times without creating any intermediate collection
5/ ...

Lukas Renggli implemented a prototype that looks really nice but is
unfinished: http://source.lukas-renggli.ch/unsorted/Container-lr.7.mcz.

I think the notion of Sequences in Clojure is very related as well.
Sequence functions are very generic and can be applied to any kind of
collection. http://clojure.org/sequences

>The goal of my project is to make a new collections for Pharo Smalltalk.
>We have a great plans about list of important collections, but we also need your opinion about them.
>So, feel free to make your suggestions about collections which you want to be implemented.

The most important changes for me with collections have to do with the change from 32 to 64 bit.
When we'll be able to access more memory, it doesn't make sense any more to have a backing store
that is a single array.  The switching to a more advanced backing store can be done transparently
based on the size.

I'm also interested in hybrid forms of the classic data structures that take less memory.
There are several that normally waste much memory on pointers (binary trees, double linked list, tries)

And then of course a Judy Array.

Stephan

In the Design Pattern iterator there are some nice examples about iterators.

Stef

2014-12-17 7:42 GMT+01:00 Damien Cassou <[hidden email]>:

Le 16 déc. 2014 22:48, "dboeren" <[hidden email]> a écrit :.
> Off the top of my head, I would be interested in support for "slices"
> meaning taking being able to treat a subset of a larger OrderedCollection as
> its own OrderedCollection rather than using copyFrom:to: to create a
> duplicate object to work with.  It seems to me that this would be a more
> efficient method and should not be difficult to implement I think.

Here is an email I sent about that :

I see you are working on new collections for Pharo. That's great news,
I'm convinced we can do much better (even if what we already have is
already much better than what can be found in most other languages).
One thing you could work on is the notion of iterator. There are
plenty of ways to iterate over a collection:

1/ from the first to the last item
2/ from the last to the first
3/ from the 2nd item to the 5th
4/ only even items (2, 4, 6, ...)
5/ ...

Currently, we have to create new collections to iterate in strange
ways. For example, to iterate from the last to the first item, we
create a new collection by sending #reversed to the original
collection. I think that is bad because it creates a copy and that
should not be necessary.

I don't understand that example. #reverseDo: do not create a copy and do not send reversed. To iterate over items from last to first I always do, as recommended in Smalltalk best practice pattern:

mySequenceableCollection reverseDo: [:item | .. ].

#reverseDo: is implemented on SequenceableCollection but iterating from last to first item does not make sense in the case of non sequenceable collection.

 

What we miss is the notion of iterator. An
iterator is an object that is specialized in iterating over any kind
of collection and has methods like #select:, #reject:, #allSatisfy:.
>From a collection, you can access different kinds of iterators
(reusing the same ordering as before):

1/ aCollection iterator
2/ aCollection reverseIterator
3/ aCollection from: 2 to: 5
4/ aCollection iterator select: [ :each | each isEven ] --> that
returns an iterator as well, so you can call #select:/#reject:
multiple times without creating any intermediate collection
5/ ...

That makes sense and would be lovely. What is the syntax for multiple operations ? Have you already think and find something nice about it ?

aCollection iterator 

    select: [ :each | each isOdd ];

    reject: [ :each | each is isPrime ];

    iterate

???

Of course there are backward compatibility issue which needs to be very well adressed here or one would crash every single framework in the system.

Lukas Renggli implemented a prototype that looks really nice but is
unfinished: http://source.lukas-renggli.ch/unsorted/Container-lr.7.mcz.

I think the notion of Sequences in Clojure is very related as well.
Sequence functions are very generic and can be applied to any kind of
collection. http://clojure.org/sequences