[climacs-devel] cl-automton's automaton objects may print incorrect state numbers

[Derek Peschel]

On Thu, Sep 01, 2005 at 12:38:53PM -0700, Aleksandar Bakic wrote:
> If I remember correctly, this state number "feature" is intentional. Please
> take a look at variables *print-renumerate-states* (setting it to true will fix

But why does *print-renumerate-states* only suppress some state numbers?
In the example with "a.c" the numbers appear.

> the first problem) and *do-not-escape* (setting it to nil will solve the other
> problem). The (indirect) reason for introducing the first variable is

Thanks for the tip about *do-not-escape*.  I have indeed seen SBCL start
the debugger when printing characters.  Slime can't get control and becomes
confused.  BTW is there a way to tell SBCL about the terminal? (Latin-1,
UTF-8 up to a certain limit, Slime connected to Emacs with a given encoding
running inside a terminal window with certain settings)

It makes more sense to me to have positive variable names, e.g.,
*escape-unicode-chars* which then would have nil as a default setting
and which you would set to t while using Slime.

> automaton-equal, which disregards state numbers.

Does *print-renumerate-states* affect automaton-equal too?  To really
test for equality (maybe "isomorphism" is a better word) you need to pair
each state in one automaton with a state in the other.  So you won't be
looking at the individual state numbers, but you will be numbering the pairs,
in effect.

If the printout (with all state numbers the same) reflects how automaton-
equal works, then the printout implies automaton-equal isn't keeping
a pair number, and I don't see how it can work reliably.  If it is keeping
a pair number, then automaton-equal's dump of its arguments should show
the pair numbers, and other printouts of individual automata should show
the original state numbers.  At least that's how I'd do it.  If I've missed
some part of your reasoning, though, let me know.

-- Derek