Opened 5 years ago

Last modified 13 months ago

#3583 new feature request

Default view patterns

Reported by: ksf Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.10.4
Keywords: Cc: illissius@…, hackage.haskell.org@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Moderate (less than a day)
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Change History (12)

comment:1 Changed 5 years ago by simonpj

  • Difficulty set to Unknown

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

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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

comment:4 Changed 4 years ago by igloo

  • Milestone set to 6.14.1

comment:5 Changed 4 years ago by simonmar

  • Difficulty changed from Unknown to Moderate (1 day)
  • Milestone changed from 6.14.1 to _|_

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

comment:6 Changed 4 years ago by simonmar

  • Difficulty changed from Moderate (1 day) to Moderate (less than a day)

comment:7 Changed 4 years ago by NeilMitchell

  • Type of failure set to None/Unknown

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

comment:8 Changed 4 years ago by 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?

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by 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.]

comment:11 Changed 4 years ago by illissius

  • Cc illissius@… added

comment:12 Changed 13 months ago by liyang

  • Cc hackage.haskell.org@… added
Note: See TracTickets for help on using tickets.