🚀 go-pugleaf

In article <1990Jun5.175706.415@newcastle.ac.uk>, I wrote:
>
> The picture is surely just those functions that can take the data type
> as an argument, and those that can return the data type as a result.

A reply suggested that constructors had to be visible for pattern
matching.  Perhaps I misunderstand, but what I thought goes on is:

Given a set S of values, we want to select a subset that satisfies
given constraints on the possible values of constituents.  So we
use the functions defined in the axioms of the ADT to construct
an element from value ranges and variables, and unify this with
the elements of S, selecting those elements for which the
unification succeeds.  In this way, given the set
        {0,succ(0),succ(succ(0))}
and the pattern
        succ(x)
we select the subset
        {succ(0) where x=0, succ(succ(0)) where x=succ(0)}.

If the argument now is that we want to hide the succ operation
and change the syntactic representation of the values (so succ(0)=1)
then of course we cannot construct patterns from components; but then
we cannot construct *any* values from components (eg you can't make
a tree without a cons).  So this would only seem to apply to
read-only databases, and I don't understand what any of this
has to do with implementation details.

If this is what Phil Wadler's views are about, fine.

Brian Boutel said:
> Views were considered for inclusion in Haskell, but dropped when we
> found some awkward consequences that we did not want to deal with
> without first gaining more experience with their use.

I'm interested.
-----------------------------------------------------------------------------
 Chris.Holt@newcastle.ac.uk      Computing Lab, U of Newcastle upon Tyne, UK
-----------------------------------------------------------------------------
 "...for where we are is here, And where here is, must we ever be."