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

[Derek Peschel]

On Sun, Aug 28, 2005 at 11:21:41AM -0700, Aleksandar Bakic wrote:

> but I am not sure what that something is yet. An empty output would trigger a
> syntax error in a similar way the {nilkind} would (unless it, actually, can be
> parsed).

The trace log doesn't put any quotation marks around the results of print-
object, so an empty output would probably only show up as extra space.
That's not convenient.

> > It may be a good idea to create a similar case in the REGEXP-AUTOMATON method
> > but I don't know what the action of the case should be.
> 
> I am not sure either, perhaps an empty output, too. Like with the above issue,
> I haven't thought about possible uses of this functionality. I just wrote the
> same (to the extent I understood it) functionality that was present in the Java
> code.

Is "output" the right word?  REGEXP-AUTOMATON takes a regexp object (a tree
created from STRING-REGEXP) and returns an automaton to parse the regexp.
I don't know what automaton would correspond to the uninitialized regexp
object.

> > It may also be a good idea to have an output syntax that can't be mistaken
> > for any legal input.  The real Perl engine, and many clones, first try to
> > read a quantifier when they see a left brace.  If the read fails they reread
> > the "quantifier" as a string of literal characters.  If Automaton ever copied
> > that dubious feature, then my current syntax would become legal input.
> > So is it best to just choose a new "magic" character or string now?
> 
> If the purpose of the magic character/string is to cause a syntax error, why is
> empty string not good enough? You would get an "unexpected end of string"
> error.

For simple cases, yes, you would get an error.  But say you have a regexp
object that's a sequence of three others: character "a", uninitialized object,
character "b".  Then you would print "a", the empty string, and "b".
This gives "ab" which is indistinguishable from character "a" followed by
character "b".  Your uninitialized object has disappeared from the printout
and you also wouldn't see an error if you read in the printout.

> > Or perhaps objects should be intiialized so they print out as "()" or "#"
> > (without the quotes).
> 
> I am not sure that is correct, because an incomplete regexp object should
> accept neither an empty string nor the empty language.

Good point.  The problem is that these uninitialized objects don't fit into
the language, you never want to accept them, and you always want to see them
(to accurately debug code).  To me that strengthens the case for using
a visible character or string.

> I assume the #<...> syntax would include the address of a regexp object, so it
> would hardly be parsable (you'd get something like "undefined subautomaton"
> error).

That dpeends on what can go into the name of an automaton.  To me, an error
that says "you have tried to read in an uninitialized boject" is better
than an error that says "you have an illegal automaton name" or "you have
a brace followed by a letter" and just happens to mean "you have tried to
read in an uninitialized object".  My current "{nilkind}" notation doesn't
produce an accurate error.

> If the #<...> is illegal as argued above, it is illegal in nested regexps, too.

True.  The point about being illegal by accident also holds for nested
regexps.

> You could just use string-regexp. If you define a reader macro to call
> string-regexp, you would prepend a macro dispatch character unambiguously.

That would work -- then the trace logs would show #R"" or whatever (with
the quote marks).  But you still have the problem of a legal expression
including an uninitialized object inside.  If the #R macro reads strings,
by convention it doesn't look for #<...> syntax inside them, right?

> Thank you for your original email, you have clearly found an issue (that
> perhaps was not there in the original code, but I introduced it for some reason
> or none).

You're welcome.  Eventually I want to understand the syntax, fix the
grammar, create a Climacs syntax file for the grammar, and get Climacs
to use the syntax file to color the echo area while you're entering a
search expression.  But that's another subject.

-- Derek