[climacs-devel] Case missing from class regexp's print-object method

[Derek Peschel]

On Sat, Aug 27, 2005 at 11:02:15PM +0100, Christophe Rhodes wrote:
> I don't know what's the rationale behind the print-object method here,
> but wouldn't one solution be to print those regexps which aren't meant
> to be subsequently readable with PRINT-UNREADABLE-OBJECT?

The way SBCL does tracing, the printouts are a mixture of LISP syntax
and the syntax generated by regexp's print-object method.  Here's the
beginning of a trace log.  "{nilkind}" is produced by my patch.

------------------------------------------------------------------------------
  0: (STRING-REGEXP "a")
    1: (PARSE-UNION-EXP {nilkind})
      2: (PARSE-INTERSECTION-EXP {nilkind})
        3: (PARSE-CONCATENATION-EXP {nilkind})
          4: (PARSE-REPEAT-EXP {nilkind})
            5: (PARSE-COMPLEMENT-EXP {nilkind})
              6: (CHECK {nilkind} 2)
              6: CHECK returned T
------------------------------------------------------------------------------

You can see that LISP syntax is mixed with regexp parser syntax.
I assume PRINT-UNREADABLE-OBJECT uses LISP's #<...> syntax.  That may be a
_legal_ regexp input because # may refer to the empty language and <...>
may refer to a named automaton.  ("May" because you can change some parser
options and thus the input syntax.)  So you wouldn't want to have #<...>
appear where legal parser input now appears.

And to make things worse, if the syntax is designed to be illegal on reading,
it should be illegal whenever the object appears sa a part of some larger
expression, e.g., inside a character class or after an operator.  The syntax
should also be illegal regardless of how you have configured the parser.
My current notation is legal inside a character class.

Perhaps the real solution is to print all regexp objects in LISP read syntax.
But even that has to be done carefully, because regexp objects can include
other regexp objects.  I would hope to see the fewest possible nested #<...>
constructs.

And if you allow the LISP reader to read and complain about illegal regexp
objects, you should allow it to read and accept legal regexp objects.
I don't know enough about good LISP style to design that.  A reader macro?
Some kind of CLOS input syntax?  Printing objcts as calls to LISP functions
that can recreate them?

-- Derek