<div>I've often thought having constructor "views" would be handy.</div><div><br></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">data Foo = Foo A B C D E F G H I</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">view Bar = (Foo A _ C _ _ _ G _ I) => Bar A C G I</span></div><div><br></div><div>This does bring up problems with case alternatives though.</div>
<div><br></div><div>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.</div><div><br></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">data Foo = {</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> a :: A,</span></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> b :: B,</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> c :: C,</span></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> d :: D,</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> e :: E,</span></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> f :: F,</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;"> g :: G</span></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">}</span></div><div>
<span class="Apple-style-span" style="font-family: 'courier new', monospace;"><br></span></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">f (Foo {a = var_a, g = var_g}) = ...</span></div>
<br clear="all">/jve<br>
<br><br><div class="gmail_quote">2009/1/15 Peter Verswyvelen <span dir="ltr"><<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<div>
<br></div><div>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)</div><div><br></div><div>pattern Polar c = (mag c, phase c)</div>
<div>
pattern Rect c = (real c, imag c)</div><div><br></div><div>This seems handy:</div><div><br></div><div>polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2)</div><div><br></div><div>However, I think it is flawed, since the following</div>
<div><br></div><div><div>case c of </div><div> Polar _ _ -> "it's polar!"</div><div> Rect _ _ -> "it's rect!"</div><div><br></div><div>seems like valid code but does not make any sense.</div>
<div><br></div><div>So I think the GHC extension of view patterns is better than the active patterns in F#?</div><div><br></div><div>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?</div>
<div><br></div><div><br></div><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br>