[Haskell] Views in Haskell

[Mark Tullsen]

Sorry to enter the discussion a little late ...

First, I'm not clear what Simon meant by "first class abstractions"  
in this comment

> Several proposals suggest first class abstractions rather that  
> first-class patterns. Here are the ones I know of ...

Second, I completely agree with Claus in his comment here that my  
"First Class Patterns"
paper is definitely related to, and not orthogonal to view patterns:

   The "big idea" of my paper was to stop the growing complexity of  
the pattern-language
   of Haskell.  The idea was to use the abstraction capabilities of  
the language along
   with some simple syntactic sugar to give us 'pattern omnipotence'.

   However, my approach could be seen as orthogonal in that I did not  
propose
   to change Haskell patterns.  Instead, I suggested some additional  
syntax that could
   serve as a replacement for complicated uses of patterns.

Strangely, for other reasons, I'm planning, within a week or so, to  
start implementing
the "pattern-binder" syntax I discussed in the paper (either in GHC  
or as a pre-processor).

- Mark

Claus Reinke wrote:
> 3 what you call first class abstractions are not entirely  
> orthogonal to view patterns.
>     taking Tullsen's and my own proposal as examples:
>
> - the way patterns and alternatives are handled needs to fit  
> together. that doesn't
>     seem to be a problem since your and our proposals agree on  
> using what I call
>     a monadic data parsing framework (using a MonadPlus such as  
> Maybe to handle
>     pattern match failure and alternatives)
>
> - all three proposals have discussed how to handle patterns as  
> well. For Tullsen,
>     that is central to his proposal, for me, it was only one of the  
> more advanced
>     examples because I wanted to focus on match alternatives first.
>
>     Tullsen first builds his pattern combinators, then outlines a  
> point-free style that
>     avoids the need for pattern variables althogether but does not  
> seem to scale well,
>     then suggests syntactic sugar for translating patterns with  
> variables into applications
>     of his combinators. So that last part is closely related to, if  
> different from, your
>     proposal.
>
>     In my example, I build up patterns from de-constructors (which  
> use tests and
>     selectors), so that a cons pattern takes a head pattern and a  
> tail pattern as
>     parameters and applies them to the head and tail if it is  
> applied to a non-empty
>     list. To handle variables, I use an old trick from the early  
> functional logic
>     languages, namely that logic variables can be passed unbound,  
> then bound to
>     values later, just what we need for pattern variables. Since  
> Haskell doesn't
>     have logic variables, I have to simulate them, which is the  
> only awkward bit
>     of the example:
>     http://www.haskell.org/pipermail/haskell-prime/2006-November/ 
> 001915.html
>
>  as long as Haskell doesn't support logic variables, some syntactic  
> sugar for
>  variables in nested patterns, such as Tullsen's or your's, is  
> probably inevitable.