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

[Chris Pressey]

On Mon, 29 Sep 2003 18:36:02 +0200
Joachim Durchholz <joachim.durchholz@REDACTED> wrote:

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

Well, it's a very intriguing idea, but I'm still a bit trepidacious.

The thing is, currently if you have code like

  function(A=[H|T]) -> ...

you know for certain that A *is* a list.  Now if other data types can
match [H|T], A could be, well, anything.

That's maybe not a practical problem though, and I definately like the
general idea.  I'll try to give it some thought.

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

Granted it's not solely idiocy that can lead to idiotic code.

It still seems like the *oddest* corner to cut, though.  I could *maybe*
see the following code written in an outright panic:

  case A of
    L when is_list(L) ->
      something;
    D={dict, _, _, _, _, _, _, _, _} ->
      something_else
  end.

But that's fairly easy to find and fix, like:

  is_dict(D) ->
    case catch dict:to_list(D) of
      L when is_list(L) ->
        true;
      {'EXIT',{badarg,_}} ->
        false
    end.
  ...
  IsDictA = is_dict(A),
  case A of
    L when is_list(L) ->
      something;
    D when IsDictA ->
      something_else
  end.

The other point I'd like to make about this is that if the stability of
your system is this crucial, like, say, a running carrier-class switch,
you should probably *not* be upgrading your language/platform version at
*all*, except for critical bugfixes.

If backwards-compatibility really *is* sacred, then all effort spent on
toothless futureproofing (like in dict, lib, io's ~n, etc) is completely
wasted, because there won't *be* any future changes to proof *against*. 

Such effort would be better put to use providing a strictly-bugfix
branch of Erlang/OTP IMHO.

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

No rest for the wicked :)

> Regards,
> Jo

-Chris