match questions

[Chris Haynes <cth@iucs.cs.indiana.edu>]

Here are some questions that we need to answer before adopting a
matching facility, along with my answers.  I hope they generate
debate. 

1. Do we want a match facility?

	YES, very much so.

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

	No, but something like OPTIONALS might be in the Yellow Pages.
	In fact, we could get demote the '.' rest feature to optional
	status, or even eliminate it.  (Yeh!)

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)?

	I currently favor read format, but not by much, and if we
	can get a satisfactory answer to the next question, I'd
	probably favor construction format.

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

	I don't know.  Whatever it is, I feel it should simultaniously
	define constructor, predicate and destructuring functions.
	The obvious approaches I've thought of seem a bit clunky, and
	I question whether we want to add that much mechanism to
	Scheme.  Without this, the matching facility is pretty simple
	and does not clutter up the rest of the language.  (In fact, it
	can eliminate the optional arguments clutter.)  Still, it would
	be very nice and may well be worth the mechanism.  I just
	don't want to see resistance to this mechanism nix
	agreement on a simpler match facility.

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

	Yes, but I don't feel strongly about this.  The
	(? <predicate> <pattern>) syntax I proposed isn't wonderful,
	but it does the job.  Note that ? (and quote) may still be
	used as literals, e.g. ('? 'quote foo).  It is only their use
	as pattern variables that is prohibited.

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

	Local binding.  A MATCH-LAMBDA form might be optional (I could
	certainly imagine wanting it), but it's probably better to
	have only one abstraction form, and keep it as simple as
	possible.  If anyone wants MATCH-LAMBDA badly enough, it is
	easy to define given MATCH and any syntactic extension
	mechanism.

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

	Optional, since it is not very hard to implement with required
	facilities, we want to keep the required base language
	simple, and we want to avoid changes to the base if possible so
	existing implementations are not invalidated.  "Yellow Pages"
	status would be better than nothing, but quite dissapointing.
	I think it's a feature that should be widely available and
	much used.

It seems hard to come up with definitive answers to some of these
questions.  However, I don't see any indication that the issues
here are deep, so we should be able to agree on something satisfactory
without a whole lot of research.  So let's try to do it in time for
the July (?) meeting.

Chris