dictionaries (was Re: new syntax - a provocation)

Joachim Durchholz joachim.durchholz@REDACTED
Mon Sep 29 13:42:19 CEST 2003

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 
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]->...

> 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...


More information about the erlang-questions mailing list