Kinds of containers

[Russel Winder via Digitalmars-d]

On Wed, 2015-10-21 at 14:06 +0000, Jonathan M Davis via Digitalmars-d wrote:
> 
[…]
> > 1. Functional containers.
> 
> I fully expect that these have their place, but I honestly have 
> no idea what they would be. When I've used functional languages, 
> I've only ever found these attributes to be a royal pain to deal 
> with, not a benefit. From what I've seen, containers are the sort 
> of thing that almost always always need to be mutable to be of 
> any real benefit. Upon occasion, constructing a container up 
> front and then never tweaking it after that is useful, but that's 
> pretty rare from what I've seen.
> 
> The only cases that I can think of where this could be really 
> beneficial would be something like strings, and we're using 
> arrays for those currently (though they are arguably functional 
> containers given that they have immutable elements).

I am confused as to why you would find these functional/persistent data
structures to be a problem in functional languages. The whole point of them
is they can be easily shared without any locks. In effect each amendment of
the structure creates a fork (effectively a copy but without the copy bit)
of it. This goes hand in hand with the functional, and especially tail
recursive computational model.

The Groovy team is currently debating adding persistent data structures to
the Groovy armoury. Clojure and Scala have had persistent data structures
for ages. The Clojure ones are really good. The Scala ones have some issues
so there is currently discussion of a third rewrite.

> > 2. Reference containers.
> 
> These are where it's at IMHO. 99.999999% this is what makes sense.

Except in a concurrent and parallel world! For big mutable data structures
you end up creating agents (or so we can use hyper trendy nomenclature,
pico-services) to avoid messing around with locks, mutexes, etc. the use of
which generally kills performance.

> > 3. Eager value containers.
> 
> 
[…]

As noted in an earlier email, I am not yes convinced by this one.

> > 4. Copy-on-write containers.
> 
> This could be interesting for some applications (probably more so 
> than functional containers), but I would expect that it would 
> only really be useful for very specific containers. I certainly 
> wouldn't want to end up with a copy of my vector or list because 
> I added a value to it. COW for strings makes a lot of sense, 
> because they don't tend to get mutated much (which is also why 
> string is immutable(char)[]). But since we're already using 
> arrays for strings, a COW string would then be for special cases 
> only.

I'd say the opposite. I would suggest that persistent/functional data
structures would be more generally useful than COW ones.  

> Overall, I think that we should focus on getting good reference 
> containers while leaving the door open for cool stuff from the 
> other container types. It's the reference containers that most 
> programs are going to need, whereas I expect that the others are 
> more likely to be nice-to-haves for a minority of applications 
> and outright useless for the majority.

I am not convinced by this argument. Yes these are the type of containers
C++/D/… programmers are used to and have a lot of code using, but are they
really the ones that should be used. Experience from Clojure and Scala is
that persistent/functional data structures lead to much nicer/easier
concurrent and parallel code. 


-- 
Russel.
=============================================================================
Dr Russel Winder     t:+44 20 7585 2200   voip:sip:
russel.winder at ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel at winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151021/9fc9d7be/attachment.sig>