[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

About &parsers



I agree with your sentiments about lambda lists becoming too complex.
I have no objection to
  (defun f (x y z) (let (a b c) ..)) 
    instead of (defun f (x y z &aux a b c) ...)
nor to
  (defun f (stuff) (dlet ((a b c) stuff) ...))
    instead of (defun f ((a b c)) ...)
As everyone is probably aware, I think &keywords lose. I think that
(defun f (x (optional a b c) (rest d)) ...)
and related variants lose on similar grounds in spite of their
seeming lispiness. Anything short of 
(defun f (x (optional a) (optional b) (optional c) (rest d)) ...)
will not be a notable improvement for programs that have to do
code walking.

HOWEVER, I'll not suggest anything along those lines. I know there is
a camp of people with a valid gripe that such is overly verbose. I just 
wanted to make it clear this is not an attempt at taking a radical 
personal stand -- it is an attempt at compromise.

The proposal: I think all systems need to provide at the bare minimum, a
parser of the nature ALAN alluded to. Perhaps something like...

  (PARSE-&KEYWORDED-BVL '(X &QUOTE &OPTIONAL (A 3) &EVAL (B) &REST Z))

     => ((X (REQUIRED)   )
         (A (OPTIONAL 3) QUOTE)
         (B (OPTIONAL)   )
	 (Z (REST)       ))

or ANY suitably chosen canonical form. This example is only illustrative
of an idea, not of an implementation.  Such a program would want to be
maintained by the system programmers since when the surface syntax changed,
it would need to be updated. If a DEF-&KEYWORD were provided, it would have
to interface to the parser.

Perhaps even a WALK-&KEYWORDED-BVL which walked over useful kinds of nodes
(eg, the init specs) of a node, calling a function at each such node with 
info about what variables were bound so far, etc. Accumulating the return
values in interesting ways, and finally returning information about those
return values and a simple list of the variables which became bound... I
can be much more explicit about such a function, but it's not terribly
important right here, so I'll assume this gets the general idea across.

My point is, though, that the naive user should not have to be able to
understand how to write a parser just to be able to write code that 
manipulates lambdas. I think a system-provided parser and or code-walker 
facility of some sort is essential to avoid needless duplication of
effort and possibility of bug introduction due to incomplete understanding
of the funny &syntax.

Less essential, but a useful notion to consider, would be to retain
DEFUN as are, but to make them macroexpand into something
more explicit which the user does not see. This is probably not
practical in the current lispm situation since LAMBDA itself can
have these keywords, not just DEFUN. Nevertheless, I point it out
because traditionally, the nice thing about Lisp was that funny
surface forms had elegant and trivially decipherable underlying
representations. Eg, 'A looks like something you'd feed to a parser,
but underneath the (QUOTE A) is consistent with other stuff. Even,
`(A ,B ,C) which is icky to many people has a well-formed underlying
representation of (LIST 'A B C). That regularity is what made it so
easy to get people to accept the ` syntactic sugar -- because the
sugar was invisible to many programs that wanted to be treating a
simpler model of the world. If (SI:|`| ...) really resisted macro-
expansion attempts and code-walkers had to be constantly on guard
for such, I suspect resistance would have been higher. Ditto even for
things like LOOP which for all its bad points at least expands into
something tractable by pre-existing code-walkers. Hence, the
idea of having &keywords exist primarily at the visual level and
then macroexpand out to a more robust underlying representation is
-- to me -- at least conceptually the right mechanism. Perhaps
it is too late to think about that approach tho'... I don't know.

Is there any discussion on the idea of formalizing a parser for
general use? ... or even several flavors of parsers (pardon my
loose use of ice cream terminology) for such lists? What sorts
of properties would be desirable, etc?
-kmp