[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: match questions
Chris's questions give me a welcome chance to express my personal
views on this matter.
1. Do we want a match facility?
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
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
Thank you for requesting my opinions.