| 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 ...
Sorry to have been un-clear. By a first class abstraction I mean a value of
type
| is that clearer?
yes, thanks. I'm not quite sure whether it all means you think view patterns
are good; or that they would be good with a tweak; or that something else would
be better.
Do feel free to edit the wiki to articulate any design alternatives that you
think deserve consideration.
I'm not quite sure whether it all means you think view patterns are good; or that
they would be good with a tweak; or that something else would be better.
probably because my opinion has been changing;-) at first, I wasn't convinced,
now I think it depends on the details. as Mark said, such
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).
I'm somewhat surprised to read this. Between view patterns, lambda-match,
and Control.Monad.Match, I thought we were
On Jan 25, 2007, at 3:49 AM, Claus Reinke wrote:
but as far as Haskell is concerned, I am perhaps less radical in my
approach than Mark is: Haskellers have invested an awful lot of
work in those conventional patterns, in readibility, in
optimisations, and in linking them with other
Rene_de_Visser:
In my opinion, views are going to make more Haskell more complicated, and
from what I have seen so far, for little gain.
We need some kind of pattern extension *now* for bytestring
matching/views and bit parsing, though. Stuff that's used in large, real
world Haskell programs
