type safety (was Re: FAQ terminology harmonisation)

[Chris Pressey]

On Fri, 04 Apr 2003 18:12:23 +0100
Peter-Henry Mander <erlang@REDACTED> wrote:

> 
> I was thinking of something like this (not compiled or tested, sorry) 
> which I find kinda useful sometimes.
> 
> fn(#a_record{field=an_atom}) ->
>      %% do stuff specific to a record with field=an_atom...
> fn(Record=#a_record{field=Field}) ->
>      %% do stuff for other values of field...
> fn(Anything) ->
>      %% do anything... Probably shouldn't!
> 
> But I have a feeling we may be thinking of different purposes.

Yeah, I think it's more to do with the general feeling that pattern
matching and data abstraction are mutually opposed, as Claus pointed
out.  Which they are.  But they can be made to live together too.

To summarize:

It's obviously not a practical problem, more of a technicality.

If/when structs are added to Erlang, to address the shortcomings of
records, hopefully, they'll be opaque - they won't be confusable with
any other type, not even other structs.  We should be able to happily
match on them in case statements without wondering if they'll
accidentally trigger is_list.  And they'll still allow the coding style
you demonstrate, above.

Then, the programming rules should be amended to recommend that all
ADT's be represented, on the surface, as structs.  The internal
structure of the struct still shouldn't be visible outside the module
implementing the ADT, of course.

Then, we can call Erlang typesafe, without any guilt :)

-Chris