Opaque types

[Joachim Durchholz]

Chris Pressey wrote:
> 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.

Not a problem in practice - syntactically, a view would be the same as 
(or similar to) a function, and one can and must use the same rules.
In other words: if [.|.] is a list "view", you can't use it for 
something else; you'd probably use some other name for deconstructing a 
dictionary (yes, the example chosen above was unfortunate).

[snip discussion on more-or-less idiotic backwards compatibility issues 
- I'm sitting quite comfortably on both sides of the fence in this issue...]

Regards,
Jo