Abstract patterns

[Bjorn Gustavsson]

Actually, I think that you have answered that one yourself in a later email:   :-)

> In practice, once it has been decided to implement a feature, it will stay in
> the language forever, even if it is never optimized. Instances of features being
> *removed* from a programming language in the course of its incremental development
> are vanishingly rare. Partly this is because of backward compatibility, but
> mainly it is because the cost of retaining a feature is rather low.

That's why we think twice (or thrice) before actually starting to implement
a new feature. Also, we don't want to be stuck with (more) half-implemented
features, so if we are not sure that stage 3 would be enough or that we would
ever reach stage 5, we don't start.

Regarding abstract patterns, our decision was not to never implement it,
but to not implement it NOW.

/Bjorn

David Hopwood <david.nospam.hopwood@REDACTED> writes:

> Bjorn Gustavsson wrote:
> > If you tell me where I can find the latest version of the paper,
> > I'll have another look at it.
> > 
> > What I meant by the phrase "implement efficiently" is that performance
> > should be comparable to that of records. If that indeed would be possible
> > to achive without inlining, we would be more interested in implementing
>             ^^^^^^^^^^^^^^^^
> > abstract patterns.
> 
> This seems like an odd way of deciding whether and how to implement a
> language feature. The preferred process IMHO is something like:
> 
> 1. Design the feature, paying attention (among other criteria) to whether
>    it *would* be feasible to implement efficiently given a bit of effort.
> 2. Document the feature.
> 3. Implement the feature naively.
> 4. Gain experience with how people are using the feature, and a body of
>    code on which optimizations can be tested.
> 5. Optimize the implementation.
> 
> in that order.
> 
> -- 
> David Hopwood <david.nospam.hopwood@REDACTED>
> 

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB