On Thu, Jul 26, 2007 at 11:28:03AM -0400, Dan Licata wrote: > I think what you're describing is equivalent to making the "implicit > view function" syntax so terse that you don't write anything at all. So > the pattern 'p' is always (view -> p).
Thanks, I wouldn't have thought of such a simple explanation myself :) > This seems like a pretty invasive change: > > I don't think the version with the functional dependency works (unless > you adopt some form of scoped type class instances, as you suggest > below), because then if you want to use a datatype as a view, you can no > longer pattern match on the datatype itself at all! Even with some form > of scoping, you can't decompose the view datatype as itself and as a > view in the same scope. Right, you can't pattern match on a type that is used as a view. But from what I've seen in library code, that usually doesn't happen - nobody matches ViewL except with viewl in the scrutinee, etc. You could create a proxy type (at some cost in ugliness) in the cases where you want to use the same structure for a concrete type and a view. > The non-functional type class will make everything very polymorphic > (e.g., where we used to infer a type based on the datatype constructors > that occurred, we will now say that it's anything that can be viewed as > that datatype). That's exactly the typing problem that I ... no wait I didn't actually mention it. :) > So, this syntax affects a lot of code, existing or otherwise, that > doesn't use view patterns, which is something we're trying to avoid. Eh? I *think* the typing rules are the same for the no-view case. If the auto-deriving hack isn't implemented, you only need a deriving(View), otherwise there should be no change at all... Stefan > > It's possible to go even simpler, and implement views via a simple > > desugaring without altering the typechecking kernel at all. > > > > (for simplicity of exposition, assume pattern matches have already been > > compiled to flat cases using Johnsson's algorithm; in particular the > > patterns mentioned consist of exactly one constructor, not zero) > > > > case scrut of > > pat -> a > > _ -> b > > > > ==> > > > > realcase (Prelude.view scrut) of > > pat -> a > > _ -> b > > > > Where in the Prelude (or the current type environment, if > > -fno-implicit-prelude) we have: > > > > class View a c | c -> a where > > view :: a -> c > > > > and we provide a deriving-form for View which generates View Foo Foo > > where view = id. > > > > Or, a rule which does that automatically if no explicit instance of View > > _ Foo is in the current module. > > > > Or, remove the fundep and add an instance View a a where view = id to > > the Prelude. > > > > Option 3 makes definitions more polymorphic. Options 1 and 2 keep the > > same level of polymorphism as before; 1 is simpler but breaks old code. > > > > Note that none of these options supports the value input feature; we > > need new syntax to support non-binding identifiers in patterns! > > > > Stefan
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
