Opaque types (was: dictionaries, was: new syntax - a provocation)

[Joachim Durchholz]

Chris Pressey wrote:
> Joachim Durchholz <joachim.durchholz@REDACTED> wrote:
> 
>> 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.

The key is that the designer of the type defines in which ways it should
be taken apart.

For example, a Customer data type could have different "views":
   Customer_by_address (Name, Nr, Street, Town, ...)
   Customer_by_standing (Name, Nr, ABC)
   Customer_by_history (Name, Nr, Transaction_List)
The nice thing here would be that it would be possible to extend the
Customer data type without having to rewrite all the code that does
pattern matching on Customer data, as long as the new data didn't show
up in the new views.

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

Well, that's what I meant.
I think :-)

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

Not idiots. Just programmers who have to make everyday compromises
between quality and time-to-market.

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

Well, language tuning has never been a particularly rewarding job...

Regards,
Jo