On Jan 22, 2007, at 6:57 AM, Simon Peyton-Jones wrote:
> I'm thinking of implementing it in GHC, so I'd be interested in
feedback of the form
>- how desirable is it to have a feature of this general form?
While it looks like a useful extension with a lot of bang for the buck,
I think I
I am having a hard time figuring out what views gain you, if anything.
If you know from the start you want abstract deconstructors, then you
can do that now and it has never been an issue, just mechanical and
verbose:
> date Term = Ap Term Term | Let Id Term Term
>
> fromAp :: Term -> Maybe (Te
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
On Wed, 24 Jan 2007, Claus Reinke wrote:
> the alternative I'm aiming for, as exhibited in the consP example, would be
> to build patterns systematically from view patterns used as abstract
> de-constructors, composed in the same way as one would compose the
> abstract constructors to build the ab
I don't think view patterns are non-linear at all! They are just as linear as Haskell's
existing patterns. Definitely no implicit use of equality, for example.
interesting point. the left-hand sides are non-linear, in that variables may appear
several times, but the context distinguishes betw
| 1 I am a bit concerned about the use of non-linear patterns in your examples.
| There are good arguments for non-linear patterns, and Haskellers have
made good
| arguments against non-linear patterns. But you seem to suggest allowing
non-linear
| patterns in some cases (related to v
There's been lots of interesting feedback about the views proposal -- thank you.
Many of the suggestions amount to plausible design alternatives. If I do all
the editing, I'll just become a bottleneck, and I'm more than usually
snowed-under at the moment. So I've moved the Wiki page to the GHC
In my opinion, views are going to make more Haskell more complicated, and
from what I have seen so far, for little gain.
Maybe a poll should be made to see what features the average Haskeller feels
the most in need of. Or what their greatest problems are.
Going by the traffic over the previous
-- abstract list deconstructors / list pattern constructors
-- (consP takes h/t sub-patterns as parameters)
consP h t l = do { guard $ not (null l); hr <- h (head l); tr <- t (tail l);
return (hr,tr) }
nilP l = do { guard $ null l; return () }
-- wildcard and variable patterns
On Mon, Jan 22, 2007 at 02:57:27PM +, Simon Peyton-Jones wrote:
> This proposal is a very lightweight (and hence, I hope, cost-effective)
> proposal for a view-like mechanism.
>
> http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns
This could be considered a generalization
On Wednesday, January 24, 2007 10:02 AM, Dinko Tenev wrote:
On 1/24/07, Brian Hulley <[EMAIL PROTECTED]> wrote:
A possible syntax could represent the
value being matched explicitly, say using ? to represent the value
currently
being matched, then the pattern could be written as an equation:
On 1/24/07, Brian Hulley <[EMAIL PROTECTED]> wrote:
A possible syntax could represent the
value being matched explicitly, say using ? to represent the value
currently
being matched, then the pattern could be written as an equation:
f (prodSize ? = Small) = ...
f (prodSize ? = Medium) =
12 matches
Mail list logo
