Re: [Haskell-cafe] F# active patterns versus GHC's view
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
Re: [Haskell-cafe] F# active patterns versus GHC's view
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
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
Hi Luke, On Fri, Jan 16, 2009 at 2:31 AM, Luke Palmer wrote: > 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 :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
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 < lemm...@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. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] F# active patterns versus GHC's view
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 wrote: > 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 < > lemm...@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. >> > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
