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

[Aleksandar Bakic]

Hi,

> Would you change anything about my patch?

I looked at the Java code again: it does not print anything when kind is nil,
so perhaps we could do that, too. I am willing to change something triggered by
your patch (so that errors are not signalled when tracing the parsing process),
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).

> As I said to Christophe, I'm still looking for a syntax that produces the
> same results whenever it's read back.  And my original post has some other
> questions which no one's addressed yet.

I'll try to address them (let me know if I missed something):

> 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.

> 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.

> 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.

> 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.

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).

> 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.

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

> 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?

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

To wrap up: the empty printout, like in the original code, or something that
causes a syntax error. The print-unreadable-object is probably the standard way
to do this.

I hope this suffices. I'd like to hear pros and cons for the above two options.
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).

Regards,
Alex


		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html