Default view patterns

[ksf]

as useful for code like  http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699#a10699 : Provide a unified left-hand interface for [] and Seq with the same syntax as current lists.

[simonpj]

You are making a feature request, but I was unable to determine what the feature is that you want. Would you like to update the description above to be 100% explicit?

Simon

[ksf]

Erm yes. The idea is to desugar

foo Bar = baz

into

foo (view -> Bar) = baz

, "view" being a member of a magic typeclass types have to instantiate to be eligible for this transformation. The rationale is to make the syntax as free of clutter as is the case with matching on plain constructors, to facilitate usage of view patterns and abstraction from concrete representations.

[simonpj]

Aha. Yes, see  http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns, the section "Implicit View patterns".

There's a syntactic question about whether the implicit view should be totally silent, or signalled by some syntax. In the above writeup, the suggestion is to write

  foo (->Bar) = baz

Simon

[simonmar]

Feature requests are unmilestoned until we decide to do them. This is also a task that a contributor could tackle.

[NeilMitchell]

I think that totally implicit view patterns, as suggested by the original poster, is probably a bad idea. Are tickets left open for feature suggestions that the GHC developers don't consider to be a good idea? It gives the impression that the GHC team supports the feature, and if the idea really is a bad one, then the bug will be open forever.

I do think the signalled view patterns would be quite nice - I've written up my thoughts on view patterns here:  http://neilmitchell.blogspot.com/2009/11/reviewing-view-patterns.html

[simonmar]

On the policy issue: if it's clear an idea is bad, then we should close the ticket, yes. On this particular issue it looks like there is some support for the idea, if not in the exact form suggested by the original submitter. Could someone familiar with the details update the ticket?

[ksf]

Well, I think that totally implicit view patterns are probably a very good idea, because they reduce the syntactic overhead of abstraction (I'm going to pretend to be able to override (:) for the sake of argument):

foo (x:xs) = x + length xs

vs.

foo (-> (x:xs)) = x + length' xs

vs. 

foo xs = head' xs + length' (tail' xs)

Consider parsing libraries: Only uu-parsinglib and Parsec (>=3) support matching on arbitrary left-disectable sequences, while certainly every parsing library could do that. I think the main reason for this is the clarity and ease of matching on (:). While # 2 does certainly look more idiomatic than # 3, I fear it would still not be enough to foster wide-spread adoption of such abstraction. Even now, uu-parsinglib and Parsec3 come with separate uncons classes. The same argument applies to [Char] vs. ByteString? vs. Data.Text vs. Seq Char: gazillions of functions could work on all of them, and most likely being made to work (with a bit of luck) just by adding an -X flag (I'm in the "safe Haskell by throwing typeclasses at it"-camp).

As I can't see any instance where # 1 and # 2 would differ in anything but how often the method "view" can be captured, I certainly prefer the # 1 for its clarity:

Providing two language options -- e.g. -XViewPatters and -XImplicitViews -- might not only help avoiding Wadler's Law and offload the discussion to what's common usage after some time, but also provide a graceful update path for code that already has "view" in scope: -XViewPatters would only capture it with explitit -> Syntax, -XImplicitViews always. In any case, if things won't work out, you'll get a type error.

[NeilMitchell]

There is a design for ViewPatterns using the (-> ...) syntax, which has not yet been implemented. There is not a design for implicit view patterns. How do you declare what becomes an implicit view pattern? Do you declare them with the pattern keyword? Can you export/import/qualify them? Can you have higher-order patterns? Do they interact with typing? Can you add guards to these patterns? Can you overload these implicit patterns? Lots of decisions need to be made before people get to the implementation stage, so this isn't really a fixable ticket. [I'm not asking to answers for all these questions - that's not really the point, I'm more illustrating that it's probably not at the stage where this can be "fixed". I suggest discussing the options on haskell-cafe@ for a good long time first, then trying to tempt a compiler hacker.]