F# active patterns versus GHC's view
When I first read about active patterns in F#, I found it really cool idea, since it allows creating fake data constructors that can be used for pattern matching, giving many views to a single piece of data, and allowing backwards compatibility when you completely change or hide a data structure. So for example one could define a Polar pattern and a Rect pattern that give different views of a Complex number, e.g (pseudo code follows) pattern Polar c = (mag c, phase c) pattern Rect c = (real c, imag c) This seems handy: polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) However, I think it is flawed, since the following case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!" seems like valid code but does not make any sense. So I think the GHC extension of view patterns is better than the active patterns in F#? A good coding style is to provide constructor functions and hide data constructors. But then one looses the ability to perform pattern matching, which is so cool in Haskell. Would I have to conclude that it would be good coding style to use view patterns as much as possible in Haskell, creating auxiliary data constructors to expose the "public members" of the hidden data constructors?
I've often thought having constructor "views" would be handy.
data Foo = Foo A B C D E F G H I
view Bar = (Foo A _ C _ _ _ G _ I) => Bar A C G I
This does bring up problems with case alternatives though.
I think the correct answer for these kinds of views is with the record
pattern matching syntax, though, I wish there was a more terse way to notate
it.
data Foo = {
a :: A,
b :: B,
c :: C,
d :: D,
e :: E,
f :: F,
g :: G
}
f (Foo {a = var_a, g = var_g}) = ...
/jve
2009/1/15 Peter Verswyvelen
When I first read about active patterns in F#, I found it really cool idea, since it allows creating fake data constructors that can be used for pattern matching, giving many views to a single piece of data, and allowing backwards compatibility when you completely change or hide a data structure. So for example one could define a Polar pattern and a Rect pattern that give different views of a Complex number, e.g (pseudo code follows)
pattern Polar c = (mag c, phase c) pattern Rect c = (real c, imag c)
This seems handy:
polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2)
However, I think it is flawed, since the following
case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!"
seems like valid code but does not make any sense.
So I think the GHC extension of view patterns is better than the active patterns in F#?
A good coding style is to provide constructor functions and hide data constructors. But then one looses the ability to perform pattern matching, which is so cool in Haskell. Would I have to conclude that it would be good coding style to use view patterns as much as possible in Haskell, creating auxiliary data constructors to expose the "public members" of the hidden data constructors?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
If you don't mind using GHC extensions (which in a view pattern thread
probably isn't much of a stretch to assume :) ), there's always record
punning (-XNamedFieldPuns):
data Foo = { [snip] }
f (Foo { a, g }) = ...
2009/1/15 John Van Enk
I've often thought having constructor "views" would be handy. data Foo = Foo A B C D E F G H I view Bar = (Foo A _ C _ _ _ G _ I) => Bar A C G I This does bring up problems with case alternatives though. I think the correct answer for these kinds of views is with the record pattern matching syntax, though, I wish there was a more terse way to notate it. data Foo = { a :: A, b :: B, c :: C, d :: D, e :: E, f :: F, g :: G } f (Foo {a = var_a, g = var_g}) = ... /jve
2009/1/15 Peter Verswyvelen
When I first read about active patterns in F#, I found it really cool idea, since it allows creating fake data constructors that can be used for pattern matching, giving many views to a single piece of data, and allowing backwards compatibility when you completely change or hide a data structure. So for example one could define a Polar pattern and a Rect pattern that give different views of a Complex number, e.g (pseudo code follows) pattern Polar c = (mag c, phase c) pattern Rect c = (real c, imag c) This seems handy: polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) However, I think it is flawed, since the following case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!" seems like valid code but does not make any sense. So I think the GHC extension of view patterns is better than the active patterns in F#? A good coding style is to provide constructor functions and hide data constructors. But then one looses the ability to perform pattern matching, which is so cool in Haskell. Would I have to conclude that it would be good coding style to use view patterns as much as possible in Haskell, creating auxiliary data constructors to expose the "public members" of the hidden data constructors?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
2009/1/15 Peter Verswyvelen
When I first read about active patterns in F#, I found it really cool idea, since it allows creating fake data constructors that can be used for pattern matching, giving many views to a single piece of data, and allowing backwards compatibility when you completely change or hide a data structure. So for example one could define a Polar pattern and a Rect pattern that give different views of a Complex number, e.g (pseudo code follows)
pattern Polar c = (mag c, phase c) pattern Rect c = (real c, imag c)
This seems handy:
polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2)
However, I think it is flawed, since the following
case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!"
seems like valid code but does not make any sense.
I think it's okay, given that we understand the meanings involved. To me it makes about as much sense as this; case c of x -> "it's x!" y -> "it's y!" Which is just wrong code. Maybe the capital letters on Polar and Rect are the confusing bit? Luke
Hi Luke,
On Fri, Jan 16, 2009 at 2:31 AM, Luke Palmer
However, I think it is flawed, since the following
case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!"
seems like valid code but does not make any sense.
I think it's okay, given that we understand the meanings involved. To me it makes about as much sense as this;
case c of x -> "it's x!" y -> "it's y!"
Which is just wrong code.
Okay, so you're saying that these mistakes can't occur since the it will give a syntax error? Fair point. Maybe the capital letters on Polar and Rect are the confusing bit?
I don't think so since that is the whole point of Active Patterns in F#. Suppose you initially made something like: data Bla = Dog Int | Cat Float and a lot of clients of your code us the Dog and Cat data constructors everywhere. After a while you decide that you need to change the Bla data type, maybe give Dog more fields, maybe completely redesign it, maybe not exposing it, but you want to keep existing code backwards compatible. With F# you can write Active Patterns for the old Dog and Cat constructors, so all existing code remains compatible. At least that is the way I understand it, but I have not actually worked yet with Active Patterns, will do so soon :)
2009/1/16 Peter Verswyvelen
[...]
After a while you decide that you need to change the Bla data type, maybe give Dog more fields, maybe completely redesign it, maybe not exposing it, but you want to keep existing code backwards compatible. With F# you can write Active Patterns for the old Dog and Cat constructors, so all existing code remains compatible. At least that is the way I understand it, but I have not actually worked yet with Active Patterns, will do so soon :)
You get something similar with the record syntax (though, probably still not quite as powerful as the active patterns):
data Blah = Dog { dogA :: Int } | Cat { catA :: Int }
f :: Blah -> Int f (Dog {dogA = a}) = a f (Cat {catA = a}) = a
f (Dog { dogA = 1}) ==> 1 f (Cat { catA = 1}) ==> 1 If we add more fields:
data Blah = Dog { dogA :: Int , dogB :: Int } | Cat { catA :: Int , catB :: Int }
f :: Blah -> Int f (Dog {dogA = a}) = a f (Cat {catA = a}) = a
f (Dog {dogA = 1, dogB = 2}) ==> 1 f (Cat {catA = 1, catB = 2}) ==> 1 Note that the definition of 'f' doesn't have to change. If you decide to remove that specific field, then you'll have to refactor f, but the act of adding *more* fields doesn't impact the existing definitions using record pattern matching. The addition of record disambiguation and wildcards[1] cleans this up a bit more.
{-# OPTIONS -XRecordWildCards #-} data Blah = Dog { a :: Int , b :: Int , c :: Int } | Cat { a :: Int , b :: Int }
dog = Dog {a = 1, b = 2, c = 12} cat = Cat {a = 1, b = 2}
f :: Blah -> Int f (Dog {..}) = a f (Cat {..}) = a
f dog ==> 1 f cat ==> 1 So, it still might not be able to pull everything off, but it sure covers most of the bases. The cards are especially useful. I <3 Haskell. /jve [1]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html
On Fri, 16 Jan 2009, John Van Enk wrote:
2009/1/16 Peter Verswyvelen
[...]
After a while you decide that you need to change the Bla data type, maybe give Dog more fields, maybe completely redesign it, maybe not exposing it, but you want to keep existing code backwards compatible. With F# you can write Active Patterns for the old Dog and Cat constructors, so all existing code remains compatible. At least that is the way I understand it, but I have not actually worked yet with Active Patterns, will do so soon :)
You get something similar with the record syntax (though, probably still not quite as powerful as the active patterns):
... or use data-accessor package.
As far as I understand, record syntax and data accessor only give access to the data, they don't provide alternate views / interpretations of the data, something that Active Patterns or view patterns in Haskell do? On Fri, Jan 16, 2009 at 4:27 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Fri, 16 Jan 2009, John Van Enk wrote:
2009/1/16 Peter Verswyvelen
[...]
After a while you decide that you need to change the Bla data type, maybe give Dog more fields, maybe completely redesign it, maybe not exposing it, but you want to keep existing code backwards compatible. With F# you can write Active Patterns for the old Dog and Cat constructors, so all existing code remains compatible. At least that is the way I understand it, but I have not actually worked yet with Active Patterns, will do so soon :)
You get something similar with the record syntax (though, probably still
not quite as powerful as the active patterns):
... or use data-accessor package.
Peter,
I think that's correct. I would really love to be able to make alternate
constructors and views. I know we can make "specialized" constructors, but I
don't think there's a good way to pattern match on these. It would be pretty
sweet if we could.
/jve
On Fri, Jan 16, 2009 at 11:14 AM, Peter Verswyvelen
As far as I understand, record syntax and data accessor only give access to the data, they don't provide alternate views / interpretations of the data, something that Active Patterns or view patterns in Haskell do?
On Fri, Jan 16, 2009 at 4:27 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Fri, 16 Jan 2009, John Van Enk wrote:
2009/1/16 Peter Verswyvelen
[...]
After a while you decide that you need to change the Bla data type, maybe give Dog more fields, maybe completely redesign it, maybe not exposing it, but you want to keep existing code backwards compatible. With F# you can write Active Patterns for the old Dog and Cat constructors, so all existing code remains compatible. At least that is the way I understand it, but I have not actually worked yet with Active Patterns, will do so soon :)
You get something similar with the record syntax (though, probably
still not quite as powerful as the active patterns):
... or use data-accessor package.
participants (5)
-
andy morris -
Henning Thielemann -
John Van Enk -
Luke Palmer -
Peter Verswyvelen