Re: match questions

[willc%tekchips.tek.com@RELAY.CS.NET]

Chris's questions give me a welcome chance to express my personal
views on this matter.

1. Do we want a match facility?

	No.

2. Given a match facility, do we need optional arguments?

	Yes.  Optional arguments are in the standard library already,
	and that example encourages people to write new procedures
	with optional arguments.  The problem is that optional arguments
	must now be implemented either by rest arguments, which leads
	to poor error-checking because few people take the trouble to
	check for excess arguments, or by implementation-specific and
	therefore non-portable hacks.

	Using rest arguments to implement optional arguments is also
	inefficient.  The worst of it is that the inefficiency biases
	people toward omitting optional arguments, when people should
	be encouraged to write them explicitly:  WRITE-CHAR with two
	arguments conses, but WRITE-CHAR with one argument doesn't.  If
	you don't think that a single cons per character matters, then
	the implementation you've been using isn't fast enough.

	I would not be opposed to demoting the "." rest flag to optional
	or nonexistent status if it were replaced with #!optional and
	#!rest, or equivalent.

3. Should patterns be in read format (with quote), e.g. ('x 1 y), or
   in construction expression format, e.g. (list 'x 1 y)?

	Read format would be `(X 1 ,Y).  The above "read format"
	corresponds to no existing syntax.  It would be a new sublanguage,
	like Common Lisp's FORMAT though less silly.

	"Construction expression format" is sensible only if you have a
	meaningful notion of static type.  Without static types,
	patterns based on construction expression format offer all the
	embarrassments of Common Lisp's SETF.  For example, what would the
	pattern (LIST 'X 1 Y) mean inside (LET ((LIST VECTOR)) ...)?
	Even if you have static types, construction expression format
	generalizes only to free constructors, as even Philip Wadler
	observed in the SIGPLAN Notices article that seems to have given
	impetus to this particular crusade.

4. Can we define a good way of declaring additional constructors, to
   get more of an ML like matching mechanism?

	Sure, but first you have to turn Scheme into a statically typed
	language.  Even then it would only work for free constructors
	like CONS, and would not work for constructors like ADJOIN.

        An ML-like matcher is far too much machinery when you consider
	that it does't generalize beyond a small set of rudimentary data
	types.

5. Do we want to be able to embed arbitrary predicates in patterns,
   and if so, with what syntax?

	No.  To paraphrase Marie Antoinette, let them use COND.

6. Should the match facility be an abstraction (lambda) or local
   binding (let) form, or should it provide both?

	Neither.  It would be ok as a library procedure.

7. Should MATCH be required, optional, or "Yellow Pages".

	Yellow pages, if at all.  Unlike optional arguments, it can
	be implemented in terms of what we already have at no cost in
	efficiency or reliability.  It is not a thing I need, and if
	I ever find myself wanting it I'd be happy to include it from
	a source library.  By the way, I have written perhaps half a
	dozen specialized matchers for my own programs, some of them
	fairly powerful, but I don't believe the proposed facility would
	have saved me from writing any of them.  My matchers have generally
	been written to simplify the construction of mini-compilers for
	application-specific languages.

Thank you for requesting my opinions.

Peace, Will