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