type safety (was Re: FAQ terminology harmonisation)
Fri Apr 4 02:38:18 CEST 2003
On Fri, 04 Apr 2003 00:28:09 +0100
"C.Reinke" <C.Reinke@REDACTED> wrote:
> > Because no matter how well I try to make it opaque, I can't.
Sorry if my tone came across as a bit curt, I was in a rush.
> While I don't disagree with the general message, you may be
> overly pessimistic about data abstraction.
Probably more pedantic than pessimistic. I'd like to be able to call
Erlang typesafe, but it's not quite there.
> In fact, I thought
> this was handled in the programming rules, but re-reading
> those after your message shows it isn't.
Half-way - it suggests all messages be sent as tagged tuples - I would
add that that should be extended to user-defined types as well.
(If we can't be opaque, we should at least be consistent.)
> The basic idea is that if there is one abstract type in the
> language, we might be able to build other abstractions on top
> of that. Functions fit that bill wonderfully (the only thing
> you can do with a function is to apply it). In particular,
> there is no need for a module implementing an abstract type
> to expose anything but the API functions.
I'm not sure that solves the problem - it just moves it from one
existing type to another (or, I don't follow you and you'll have to give
me an example.)
I think the problem is more with the pattern matching than the types.
In order to achieve type safety, I need to be able to construct a value
that does NOT match in any of the following assertions:
For this to be, I would need a facility to create an opaque type which
is not merely a subtype of one of those.
The *only* assertion that ought to be able to match it in a case (or
other) statement would be:
where T is the name of my type. THEN Erlang will be typesafe.
Of course, if structs were added *as a unique type*, i.e. NOT just
implemented as dicts or tuples, then
would work too.
Or, if it would not break existing code, the 3rd option would be to make
records opaque, i.e.:
(is_record(X, R) and is_tuple(X)) == false
More information about the erlang-questions