q-lang-users

[q-lang-users] Views and Virtual Constructors

[Rob H. <hub...@gm...>]

Hello Albert,

[This is not urgent -- it's just a question out of curiosity.]

Suppose I wish to have two separate virtual constructor sets for my
own type. As an artificial example, here's a type MyList that behaves
just like a 'Q' list:

	public type MyList
			= virtual mylist_cons Head Tail, mylist_nil
			| virtual mylist_join Left Right, mylist_singleton Elt
			| private const mylist List;

	mylist_nil = mylist [];
	mylist_cons Head (mylist Tail) = mylist [Head | Tail];

	mylist_join (mylist Left) (mylist Right) = mylist (Left ++ Right);
	mylist_singleton Elt = mylist [Elt];

	view (mylist []) = 'mylist_nil;

	view (mylist [Head | Tail]) = '(mylist_cons Head Tail)
		where Tail = mylist Tail;

	view (mylist [Elt]) = '(mylist_singleton Elt);

	view (mylist Elts:List) = '(mylist_join Left Right)
		where Left = (mylist (take N Elts)), Right = (mylist (drop N Elts))
		where N = (#Elts) div 2;

Suppose I have a list

	==> def L = mylist [1,2,3,4]

I'd like to perform pattern matching like this:

	==> def (mylist_cons H T) = L; H; T
	1
	mylist_cons 2 (mylist_cons 3 (mylist_cons 4 mylist_nil))

or like this:

	==> def (mylist_join X Y) = L; X; Y
	mylist_cons 1 (mylist_cons 2 mylist_nil)
	mylist_cons 3 (mylist_cons 4 mylist_nil)

The trouble is: the latter of these does not work because the second
view definition 'hides' the third and fourth, in that the match will
always succeed if it reaches the second.

Do you know of a way around this please?

That is, is there a way for 'overlapping' views to be defined for use
by the new pattern matching feature on virtual constructors?

(I imagine not.)

Thanks,
Rob.

Re: [q-lang-users] Views and Virtual Constructors

[Albert G. <Dr....@t-...>]

Rob Hubbard wrote:
> That is, is there a way for 'overlapping' views to be defined for use
> by the new pattern matching feature on virtual constructors?

No, not with the notion of views that Q currently implements. This is
the same kind of "alternative views" feature also discussed in the "New
stuff in cvs: multichar ops, views" thread.

To implement this feature, a more powerful notion of views would be
needed, which has something like the "value input feature", see
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns for a discussion
of various approaches. The notion of views proposed there for Haskell
allows this, effectively, by specifying the particular 'view' routine to
invoke when matching the pattern. Then you could write something like:

  foo (mylist_view1 -> mylist_cons H T) = ...;
  bar (mylist_view2 -> mylist_join X Y) = ...;

But I don't really see the point in this, as you can already have as
many ordinary access operations on an ADT which deliver as many
different concrete representations of the data as you want, and match
against these inside a 'where' clause:

  foo L:MyList = ... where mylist_cons H T = mylist_view1 L;
  bar L:MyList = ... where mylist_join X Y = mylist_view2 L;

This isn't much clumsier and doesn't require any special kind of view
implementation.

For me, views, in the spirit of Wadler's original proposal, are just a
convenience to make an ADT look like a concrete algebraic type with its
own "canonical" representation in terms of a given set of constructors.
In Q this virtual representation is then also used for pretty-printing,
so that you have "what you see is what you (can) get" in terms of
pattern-matching. This is convenient, simple and straightforward to use.
I don't see right now what the more elaborate view notions buy you that
you cannot achieve just as easily with some appropriate access
operations and a 'where' clause. Someone please set me straight if I'm
missing something important there. ;-)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Views and Virtual Constructors

[John C. <co...@cc...>]

Albert Graef scripsit:

> I don't see right now what the more elaborate view notions buy you that
> you cannot achieve just as easily with some appropriate access
> operations and a 'where' clause. Someone please set me straight if I'm
> missing something important there. ;-)

What comes to mind at once is to allow a complex number to be constructed
in rectangular form and then matched in polar form, or vice versa.
At present, the rectangular form is privileged, and adding your own
view rules only makes the polar form privileged.  There is no way to
make them equals.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

Re: [q-lang-users] Views and Virtual Constructors

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> What comes to mind at once is to allow a complex number to be constructed
> in rectangular form and then matched in polar form, or vice versa.
> At present, the rectangular form is privileged, and adding your own
> view rules only makes the polar form privileged.  There is no way to
> make them equals.

This is true, but concrete algebraic types also have only a single,
canonical representation, and this is what views are supposed to mimic.
I concede that there is a case for generalizing this and allow multiple
views, like floating point numbers can be printed in 'fix' or 'std'
formats. I must think a bit more about this...

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag