[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Here are some questions that we need to answer before adopting a
matching facility, along with my answers. I hope they generate
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
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
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.