|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
[GHC] #3583: Default view patterns#3583: Default view patterns
-----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: 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 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (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. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (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 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: Unknown => Moderate (1 day) * milestone: 6.14.1 => _|_ Comment: Feature requests are unmilestoned until we decide to do them. This is also a task that a contributor could tackle. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
-----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by NeilMitchell): * failure: => None/Unknown Comment: 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 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
-----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (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? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
-----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (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. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
|
Re: [GHC] #3583: Default view patterns#3583: Default view patterns
-----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (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.] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3583#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@... http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
| Free embeddable forum powered by Nabble | Forum Help |