Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
better wording in case States: is not given #39
Consider this (IMHO incorrect) input:
The specifications currently say:
but that does not really specifies what is expected if the optional
The last part of the last sentence, i.e.
says that we do not want to count a state that has the highest number if it is neither initial nor target of any transition? These states are useless, but legal and they should not be simply ignored IMHO.
I also suggest to relax from the condition saying that every state between 0 and n-1 should be explicitly listed. I would replace it by assumption that states that are not listed have no outgoing transitions and empty label (test for automaton completeness has to be adapted for that).
I missed those. Good point.
I'm ambivalent about this. What you suggest is actually how I'm handling unlisted states in Spot.
One case I can imagine where it would be useful to not declare a state, is if you have an operation that remove states from an automaton, and yet you do not want to change the numbers of your states. Then you would declare an automaton with more states than you actually use, and then (without the relaxed condition that you suggested) you would have to list all the removed states with no successor. As it turns out, this is exactly how
Also if we don't require the states to be listed explicitly, I'm afraid tools authors will be more likely to declare more states than needed. For instance if I'm building a product
The scenario leading me to suggestion of "missed states" is like this: one manually edits an automaton in such a way that the it has less states: do we want to push them to rename all the states or do we allow skipping state numbers?
My feeling is that skipping states make the format more robust. But I'm not going to fight for that, it is not that important.
I'm sympathetic to both points of view, on the one hand making the life of the consumer easier, on the other hand giving the producer more flexibility, especially when doing manual editing. Having such structural sanity checks however is very useful to identify broken or suspect output by tools.
One option would be to use the n = highest state index that occurs anywhere approach, with the states that are not explicitely listed having no successors etc, and provide a property, e.g. "compact", that signifies that the stricter interpretation (all states have to be defined) should apply. It would then be relatively easy to provide transformations in autfilt and jhoafparser to compactify a given automaton, renaming the states to satisfy the property. Tools that expect to generate compact output on the other hand would benefit from the warnings/errors that are raised when they specify the property while having broken output. We could then add language to the format spec to "encourage tools to produce compact output".
I fear that adding one more "mode" (dense / sparse) to the format is just making it more complex to implement and specify. This point is not very complex in itself, but the accumulation of all these little mode tweaks (state-based versus transitions-based acceptance, explicit labels vs. implicit labels, implicit number of states versus explicit number of states, etc.) builds the complexity.
How about just applying Postel's law: we have a strict format that tools should strive to follow in their output, but this should not prevent us from writing parsers that are more lax in what they input. How lax we are is not something that the format should specify (otherwise that is not "lax" anymore, plus we do not want to encourage producer tools to be lax too). This is already the case in Spot as I have done a lot of work on error recovery (which is especially important when handling a stream of automata, as you don't want to just bail out at the first error): you can input automata with some syntax errors,
So in my view of the "human edition scenario" is already supported:
If the human editor adds new states to the automaton and forget to update the "States:" line, it will be diagnosed and fixed too; this already works too. I think the human editor can live with a couple of warnings, and should be happy to see them fixed automatically; while the author of a producer tool should just fix his tool so the warnings disappear.
referenced this issue
Apr 17, 2015
FYI, here is the actual status with Spot regarding the "human-editor scenario".
Assume the following automaton is the result of the (quick and dirty) human edition:
You can either pass it to
Or if the missing states are the result of some removal, you probably want to remove all dead states (i.e., those that cannot be part of an infinite run):