[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
match questions
From: "Guillermo J. Rozas" <jinx@geneva.ai.mit.edu>
I'm sorry, but I fail to see the point of a MATCH extension to the
language. Every time I've wanted pattern matching, I've built my own,
because the constraints and requirements were different, so a fixed
utility would do me no good.
My experience, which reflects what I've done with Scheme (I've never
written an emacs), is simply different. I've seldom felt the need for
optional arguments, and never a pressing need for more than the '.'
rest feature we already have. Thus my don't care attitude toward the
optional argument proposals, except for a general desire that all that
mechanism not be added to the language when I don't expect to use it.
But I respect the desires of the many who do use optional arguments,
at least as long as the facility is optional.
What I don't understand is why more people don't find use for MATCH
(or maybe they do, and we just haven't heard from them). I find a
constant need for destructuring (I hate car/cdr chains), and frequent
need for matching. Many a COND expression would look better if it
were a MATCH expression. I, and others here, have found the simple
sort of match facility I've outlined to be quite adequate for almost
all our needs. And people seldom build their own matches, but instead
use car/cdr chains and COND at every turn. The functional programming
community (broadly speaking, including languages like ML) certainly
goes for matching in a big way (and not optional arguments). Why is
the Lisp community traditionally so different?
We might as well try to agree on a UNIFY
facility. It would probably be more useful.
Not at all. Unification requires logic variables, which are a
significant semantic addition to any language (whereas MATCH is
semantically trivial). Also, it isn't clear how much unification is
worth without backtracking (multiple values, Prolog style), and that
is pretty clearly a step into another language.
Chris