🚀 go-pugleaf

In article <1990Jun5.175706.415@newcastle.ac.uk> Chris.Holt@newcastle.ac.uk (Chris Holt) writes:

   In article <RJC.90Jun4134659@brodie.uk.ac.ed.cstr> rjc@uk.ac.ed.cstr (Richard Caley) writes:

   >It would be nice this was possible. declare a dtat type ad declare a
   >`picture' of it which is what the outside world sees.

   The picture is surely just those functions that can take the data type
   as an argument, and those that can return the data type as a result.

These do form an image, but not necesarily the best ( ie most readable
). Consider lists, usually these will be built and accesed as linked
pairs with cons

	1 :: ( 2 :: (3 :: [] ))

( using POP operators, translate into your own favorite religion :-) )

Prolog, and I think some of the functional languages with pattern
matching, will only let you match this way 

	f([]) = 0
	f(H :: T ) 1+ f(T)

On the other hand, people not concerned with implimentation might be
better served in many cases by regarding lists as just that, ordered
sequences and matching based on that

	(1)	f( X, [ ... [ X Y ] ... ] ) = Y

I think the nearest we could come to this using functions would be

	(2)	f( X, A <> ( X :: Y :: [] ) <> B ) = Y

( where '<>' is list append )

I prefer (1). 

I think Jeff is right though, pattern matching in programing languages
is far to concrete. Just imagine implementing some kind of table ADT
and being able to say that programs using the ADT should be able to
match aginst it using (1) ( despite its being a hash table of has
tables or something equally ghastly internally ).

On the other hand, since I've never seen this dream langauage, I can't
say whether it would be a useful feature or just one of those things
that you read about in the documantation, try once and give up on.