January 2007 - Haskell-prime

Polymorphic Components
by Iavor Diatchki 06 Feb '07

06 Feb '07

Hello, I have written some notes about changes to Haskell 98 that are required to add the "polymorphic components" extension. The purpose of the notes is to enumerate all the details that need to be specified in the Haskell report. I don't have access to the haskell-prime wiki so I attached the notes to the ticke for polymorphic components: http://hackage.haskell.org/trac/haskell-prime/ticket/57 When there are different ways to do things I have tried to enumerate the alternatives and the PROPOSAL paragraph marks the choice that I favor. -Iavor

20 45

ADT views Re: [Haskell] Views in Haskell
by Bulat Ziganshin 03 Feb '07

03 Feb '07

Hello Simon, Monday, January 22, 2007, 5:57:27 PM, you wrote: > adding "view patterns" to Haskell. many of us was attracted to Haskell because it has clear and simple syntax. but many Hugs/GHC extensions done by independent developers differ in the syntax they used, because these developers either has their own taste or just don't bother with syntax issues. you may remember my examples of how the guards syntax may be reused for GADTs and class declarations: data T a = C1 a | Show a || C2 a | Read a instance Binary a | Storable a where ... but unfortunately we've finished with 3 different syntax for the same things i'm sorry for so big introduction but this shows why i don't like the *syntax* you've proposed. you wrote "The key feature of this proposal is its modesty, rather than its ambition..." that means that this proposal is great for you as implementor - you should write a minimal amount of code to add this to GHC. but let's look at this from viewpoint of one who learn and then use Haskell: first, he should learn two syntax to do matching instead of one. second, he should learn how to implement them both. third, he need to make decision of whether to provide abstract interface to his datatypes or not. if he make a bad decision, he will end either in rewriting lot of code (and change is not s///-style !) or having a lots of trivial definitions like data List a = Nil | Cons a (List a) nil Nil = Just Nil nil _ = Nothing cons (Cons a b) = Just (a,b) cons _ = Nothing then IDEs will automate this code generation and "refactoring" of code, etc, etc :) >On the other hand, view patterns can do arbitrary computation, >perhaps expensive. So it's good to have a syntactically-distinct >notation that reminds the programmer that some computation beyond >ordinary pattern matching may be going on. *you* said :) are you don't know that explicit control of generated code is "advantage" of low-level languages? we use higher-level languages exactly to avoid dealing with implementation details. as far as we can describe algorithm in some form understandable by computer, we are done. lazy evaluation, classes and even plain functions are the tools to describe algorithm without having any guarantees about its efficiency so, i propose to define views in a way that 1) preserves syntax compatibility with existing patterns 2) allow to define "class of views" to provide common interface to all sequences, for example 3) old-good guards may be used instead of Nothing to provide "backtacking" (are you don't think that we already have full Prolog power between "|" and "="? :) something like this: data Coord = Coord Float Float view of Coord = Polar Float Float where Polar r d = Coord (r*d) (r+d) -- construction Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y) -- matching f :: Coord -> Float f (Polar r _) = r f (Coord 0 0) = error "..." class ListLike c e where head :: c -> e tail :: c -> c class view of ListLike where Cons :: e -> e -> c Nil :: c instance ListLike [a] a where head (x:xs) = x tail (x:xs) = xs instance view ListLike [a] a where Cons x xs = x:xs -- for constructing new values using Cons (x:xs) = Cons x xs -- used to match Cons in patterns Nil = xs xs | null xs = Nil i know that this is longer way (and probably will be never implemented) but the language should remain orthogonal. otherwise it will dead in terrible tortures :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

6 11

RE: [Haskell] Views in Haskell
by Simon Peyton-Jones 31 Jan '07

31 Jan '07

[Redirecting to haskell-prime] | In the related work, the "Active Patterns" proposal by Palao et at is missing: | | http://portal.acm.org/citation.cfm?id=232641&coll=portal&dl=ACM | | I thought this work should be included in the list because, I believe, | they were the first to point out that computation should take place | before matching, which was not the case in Wadler's and Burton's | proposals? They also proposed types for patterns. Good point. I've added them. I think the Wadler/Burton stuff did allow for arbitrary computation; it's just that there was no way to do the value-input thing. (Pattern synonyms, on the other hand, do not.) Simon

4 4

[Haskell] Views in Haskell
by Mark Tullsen 30 Jan '07

30 Jan '07

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.

3 5

Re: [Haskell] Views in Haskell
by Claus Reinke 29 Jan '07

29 Jan '07

> http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns > >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? > - can this particular proposal be improved? IMHO, getting a handle on the ADT vs pattern matching issues is overdue, so thanks for raising this again. a few first comments: 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 view patterns), but not in others (general patterns). That is likely to be confusing. 2 view patterns nicely separate expressions in patterns from pattern variables. But I didn't realize at first that view patterns can be used nested inside other patterns. Yet this variable binding during nested matching is the essential contribution, and the only reason why the extra syntactic sugar is justified. Perhaps this point could be repeated and emphasized in "The proposal more formally", for people like me?-) 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. 4 whether to use view patterns inside ordinary patterns, or whether to build up patterns from abstract de-constructors (just as expressions are built from abstract constructors) may seem only a question of style. but if your aim is to encourage people to transition from exporting concrete data types to exporting abstract types only, the latter approach seems more consistent to me. In my example, a cons de-constructor would be as simple as -- the cons view of array lists is a higher-order pattern that takes -- patterns for the head and tail components, and applies them after -- checking whether the list parameter is a non-empty list consAP h t l = do { Match $ guard $ not (isNilA l); h (headA l); t (tailA l) } but that relies on the scoping of (simulated) logic variables, and it does not translate directly to your view patterns, as the h and t pattern parameters would have their own scope for their pattern variables. It would be instructive to have something equivalent to pattern constructors/abstract deconstructors for view patterns, if only to see whether view patterns can support a fully abstract style of nested matches easily. I am not entirely sure they do, but here is a first attempt: -- 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 wildP l = return () varP = return -- extract the head of the tail of the parameter list, if that list has two elements f (consP wildP (consP varP nilP) -> (_,(x,_))) = x It seems a bit awkward to have to specify the structure of the parameter twice, once to build up the pattern, then again to match sub-expressions to variables. but would this work in principle at least? 5 possible extension 1 smells of superfluous complexity. There is almost no gain compared to using tuples, but there's a lot to pay in added types and rules. 6 possible extension 2 seems a non-starter if we want compositional abstract patterns, and I certainly do want them. Imagine the example in (4) with explicit Maybe. Being able to have compositional abstract patterns would be the make-or-break criterion for me. Without them, new syntactic sugar wouldn't be justified, with them, their precise form is a matter of convenience. Claus

5 10

Views in Haskell
by Simon Peyton-Jones 27 Jan '07

27 Jan '07

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 wiki, which is world-editable. It's here http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns The wiki isn't a good place for to-and-fro debate, but it is a good way to capture design alternatives. If those with alternatives to propose would like to add them (in an even handed way needless to say) to the wiki page, that'd be good. Feel free to re-structure the text if that'd make it clearer. The big question is, as several people have observed, whether the (modest) gain is worth the (also modest) pain. If the proposal has merit, it is its extreme simplicity. There's no comparison with things like class aliases, which are a Much Bigger Deal on both those metrics. Simon

3 2

Re: [Haskell] Views in Haskell
by Mark Tullsen 25 Jan '07

25 Jan '07

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'd prefer to live without it; two reasons: 1) I'm a minimalist 2) I find that using my pattern combinators (http://citeseer.ist.psu.edu/tullsen00first.html) and do-notation I get by very well without using any of the advanced features of patterns. OK, I guess I'm a little biased. > - can this particular proposal be improved? I definitely agree with Claus's comment: > 5 possible extension 1 smells of superfluous complexity. There is almost no gain > compared to using tuples, but there's a lot to pay in added types and rules.m

1 0

Re: [Haskell] Views in Haskell
by Brian Hulley 24 Jan '07

24 Jan '07

Simon Peyton-Jones wrote: > > http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns > > 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? > - can this particular proposal be improved? Regarding the syntax, I don't like the use of ->, because I think it is confusing to write even -> n when even is the function itself. In all other places in Haskell, A -> B represents a function from A to B whereas in the proposal A -> B represents the function A applied to the thing currently being matched which may return a value wrapped up in Maybe which matches B. There are 2 things - the inconsistent use of -> and the implicit Maybe. I'd rather the Maybe was not implicit (as described in extension 2), and a more consistent syntax was found. 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) = ... f (prodSize ? = Big) = ... or simulating an n + k pattern: g (? - 3 = n) = ... or a function which checks its arg satisfies an arbitrary expression: h (? - (3 * ?) = 10) = ... or an "n+k" against the second element of a list j ( toList ? = (_ : (? - 3 = n : _))) = ... Regarding the problem itself, I'm still not sure why views are needed. For example in (f) above, why not just write as: f :: Product -> ... f prod = k (prodSize prod) where k = ... Best regards, Brian. -- http://www.metamilk.com

2 2

Re: [Haskell] Views in Haskell
by Ross Paterson 24 Jan '07

24 Jan '07

On Mon, Jan 22, 2007 at 02:57:27PM +0000, 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 of field matching (minus the data constructor), so you'd presumably want similar syntax for the two.

1 0

Re: [Haskell] Views in Haskell
by David Roundy 22 Jan '07

22 Jan '07

On Mon, Jan 22, 2007 at 02:57:27PM +0000, Simon Peyton-Jones wrote: > Dear Haskellers > > Provoked by a discussion with Don Syme, and after some helpful > conversations at POPL, I have finally written up a proposal for adding > "view patterns" to Haskell. We've wanted views for a long time, but they > have never made it, into GHC at any rate. 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 > > 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? > - can this particular proposal be improved? It looks pretty cool to me, and simple enough to be reasonable. One feature that would be particularly interesting would be to add some sort of annotation mechanism to describe a possible "complete" set of views (with respect to improving warnings about inexhaustive pattern matching). I wonder if you could have something like: data Foo = FooBar Bar | FooBaz Baz foobar :: Foo -> Maybe Bar foobaz :: Foo -> Maybe Baz {-# COMPREHENSIVE_VIEWS Foo : foobar, foobaz #-} which tells the compiler that for any Foo, one of foobar and foobaz will return a non-Nothing result. It'd allow us--at least in the simple views case--to retain the existing level of warnings, and ought also to be useful in somewhat trickier case as well. Another idea is whether the syntax could be extended to indicate a failure to match? This would actually be useful even without views, but it's particularly useful with views (and especially so in the context of the above warnings). I'd imagine something like (with stupidly chosen syntax of !!!) foo (_:_) = True foo _ = False foo' !!![] = True foo' _ = False Here I've defined two identical functions to describe what I mean by "!!!". I didn't gain anything in this case, but might gain some clarity if there are multiple constructors. But more to the point, if we're using views (of the vanilla Maybe-always variety), we could gain some efficiency this way. foo ([], view -> a, []) = foo1 a foo (x, !!! view ->, []) = foo2 x foo (_, view -> a, y) = foo3 a y This isn't a very good example, but the point is I'd like to be able to match on Nothing and get the same benefits you mention about the compiler being assumed to optimize by calling view only once. We could achieve this by reordering the patterns, but I believe (although I failed to come up with one above) that there are sets of pattern matches that aren't reducible in that way, which it'd be nice to be able to express succinctly by matching on failure to match a pattern. Maybe this should be foo (x, view /->, []) = foo2 x or something like that, to indicate failure, that view doesn't match? -- David Roundy Department of Physics Oregon State University _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0