Re: match questions

[Andy Freeman <ANDY@Sushi.Stanford.EDU>]

Before I forget.  I don't think structures are a counter-proposal to
matchers.  They're for problems that matchers aren't the right tool
for and are completely inappropriate for the things that matchers do
best.

Actually, I was serious about the hokey accessor syntax award.  I
don't like it, there are lots of better syntaxes, but it does
illustrate my point.  The following defstruct only defines a predicate
function and accessor syntax.

(defstruct (branch left right)
  (left (or leaf branch))
  (right (or leaf branch)))

The predicate is branch? and the accessor syntax "verb" is branch.
(branch tree left) is syntax for accessing the left of tree's value
(which is a branch), but left isn't evaluated.  (This order obviously
has problems.)  Left is recognized as a field name in that position by
the branch accessor syntax.  Other structs can have a left and left
can be used for other purposes without confusion.

Yes, each instance of a struct in my proposal does add three names to
the namespace, but that's independent of the number of fields.  (I
didn't mention creators.)  On the other hand, one could define a
create syntax, (create branch left x right y), so that no creator name
is added to the namespace.  This create would be global syntax that
recognizes struct names and fields.  Similar games can be played with
accessor syntax and predicates so that no names are added to the
namespace by a definition.  (I think they'd be silly, but ....)

I don't understand the less-local objection.  Either you know what you
want out of the struct or you don't.  Matchers rely on positional
notation, structures rely on names.

The real bug with my proposal is that any user of a structure can see
everything in it; matchers have this problem too.  "private" fields
and the like are the solution, but I don't have a syntax.

-andy
-------