dictionaries (was Re: new syntax - a provocation)

[Chris Pressey]

On Mon, 29 Sep 2003 13:42:19 +0200
Joachim Durchholz <joachim.durchholz@REDACTED> wrote:

> Chris Pressey wrote:
>  > Richard A. O'Keefe wrote:
> >>If you change it to use a new primitive data structure,
> >>THAT WILL BE AN INCOMPATIBLE CHANGE.  That's not my suggestion at
> >all.
> > 
> > It will *not* be an incompatible change.  The man page clearly
> > states:
> > 
> > "Dict implements a Key - Value dictionary. The representation of a
> > dictionary is not defined."
> > 
> > Therefore, the representation may be changed.  Any code that relies
> > on a particular representation is *already broken*.  This is the
> > very essence of why anyone would even consider establishing a
> > contract like this in the first place.
> 
> Um... while I agree that any code that relies on the internal 
> implementation should be considered broken, there's still the question
> whether those bugs should be exposed or covered.
> Personally, I think it's a case of "never change a running system",
> but anybody's mileage may vary, and I'm certainly in no position to
> advise one way or the other.
> 
> However, I do think that the discussion exposes clearly why opaque
> data types are important: if the dict implementation hadn't exposed
> its internals, there would be no possibility of client code relying on
> those internals, and the entire discussion would not have started in
> the first place.

Yes.  Definately.

> Personally, I think that opaque data types should also interact with 
> pattern matching, i.e. there should also be "deconstructors". For 
> example, the Dictionary type should have something like a [H|R] 
> "destructor" that gave me the first pair (H) and the rest of the 
> dictionary (R), so that I can pattern match as in [(Key,
> Value)|R]->...

Well - maybe, but I don't see how it really fits in with the opacity -
if you're not supposed to know anything about the structure of some
value, then you probably shouldn't be taking it apart yourself, even in
an abstract way.

It would be better to let the type's interface take it apart for you -
and yes, better still if that could be integrated with pattern matching
(like if the type could describe how it is to behave during a pattern
matching operation) - but that might open a whole new can of worms with
types having "surface representations" (where, say, a dictionary, or an
employee, *looks* like, say, a list, w.r.t. pattern matching, but has
some completely other representation internally.)  That sounds both
extremely clever, and like a breeding ground for confusion.  Who was it
that said data abstraction and pattern matching are polar opposites...?

> > Not that there is any reason to make another module!  The bottom
> > line is that Ericsson can make whatever changes they want to the
> > dict module- so long as it continues to do what it says it does -
> > and because they had the foresight to include those magic words "The
> > representation of a dictionary is not defined" in the man page, no
> > one has *any* right to complain when it's no longer a tuple like
> > {dict,Size,Etc,Etc,Etc}.
> 
> The issue isn't complaints. The issue is how much software will break 
> (hopefully little), how much effort it will take to fix it (which is a
> question of how easy it is to find code that makes assumptions on 
> internals), and what consequences the uncaught bugs will have (which
> is something that's quite difficult to predict).
> The complaints won't be about dict, they will be about misbehaving AXP
> switches and similar stuff...

My guess would be that there would be none... but perhaps I have an
unwarranted amount of faith in the idea that the great majority of paid
Erlang programmers aren't idiots.

At any rate, if something explicitly undefined, like the representation
of dicts, can't change, then I'm afraid we'll have to completely give up
Joe's ideal of throwing other stuff (like records) out of Erlang, once
better things are added.  It will simply never happen.  More incentive
to start fresh with a completely new language, probably.

> Regards,
> Jo

-Chris