On Thu, Feb 01, 2007 at 09:12:02AM -0800, David Roundy wrote:
> On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
> > Next, i don't think that ability to use any functions in view buy
> > something important. pattern guards can be used for arbitrary
> > functions, or such function can be used in view definition. view,
> > imho, is not a function - it's a two-way conversion between abstract
> > and real data representation which has one or more alternative
> > variants - just like Algebraic Data Types. so, when defining a view, i
> > want to have ability to define exactly all variants alternative to
> > each other. for another representation, another view should be
> > created. so
>
> But you *are* using functions in views, that's what they are. And the
> two-way conversion, while pretty, is likely to be a fiction. It'll be too
> easy (and useful) for someone to define
>
> view RegexpMatch String of String where
> string | matchesRegexp regexp string = RegexpMatch regexp
> RegexpMatch regexp = undefined
Never mind. I see that this won't work, and it's not so easy to usefully
get around your restrictions. But I must admit that this power was one of
the nicest things in Simon's proposal. You'd still be in danger of me
subverting your proposal with something like
view Odd of Int where
i | isOdd i = Odd
Odd = undefined
but I'll admit that this isn't particularly powerful. It's allowing
arguments to the match (e.g. the regexp I was trying to sneak through) that
gives Simon's views their power. It's also what forces the syntactic
complexity of the -> in the matches, since you need a way to distinguish
the arguments from the patterns in something like
f (foomatch "x" "y" "z")
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
