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

[Aleksandar Bakic]

I played a bit with the real code, so there are some news.

> An empty output would trigger a syntax error in a similar way the {nilkind}
would (unless it,
> actually, can be parsed).

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

Surprise! We are talking about string-regexp, where both "{nilkind}" and
"#<...>" are parsable. It's in regexp-automaton that the latter may not be
accepted.

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

Actually, this may or may not be true (hopefully it is). Similarly for the
empty printout.

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

Note that the external representation of a regexp is not a string. You would
have to print it to a string.

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

BTW, with the currenct code, in SBCL debugger's backtrace you get:

  1: (AUTOMATON::CHECK #<error printing object>)
  2: (AUTOMATON::PARSE-COMPLEMENT-EXP #<error printing object>)
  3: (AUTOMATON::PARSE-REPEAT-EXP #<error printing object>)
  4: (AUTOMATON::PARSE-CONCATENATION-EXP #<error printing object>)
  5: (AUTOMATON::PARSE-INTERSECTION-EXP #<error printing object>)
  6: (AUTOMATON::PARSE-UNION-EXP #<error printing object>)

which seems fine to me.

Alex


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs