> (a/advance (a/compile [(int \f)]) nil \f ::fail)
ClassCastException java.lang.Character cannot be cast to java.lang.Number automat.stream/to-stream/reify--91907 (stream.cljc:73)
to-stream's prior attempt to cover the narrow case of char input when expecting a number caused other issues (#34), but the char/int mismatch is just the most obvious/convenient/common case. Any FSM that requires a numeric input to advance, but encounters one that can't be coerced to a number will fail with a ClassCast instead of rejecting.
A straightforward way to address this would be to signal rejection in the reified nextNumericInput impl if the return isn't actually a number. That would cover the immediate problem.
One interesting/useful case that this wouldn't cover is where one has an FSM expecting a numeric input, it encounters something non-numeric, but you'd like to account for this via the :signal mechanism. Right now, that's not possible at all, but in such a case, it could "back off" to use nextInput, get the non-numeric result, apply the :signal fn, and then attempt to continue. This might belong in a separate enhancement issue, but I think it would nicely shave off a rough corner and make :signal much more general-purpose. At the moment, I'm "preprocessing" inputs to my FSM because some never get to :signal in the first place.
to-stream's prior attempt to cover the narrow case of char input when expecting a number caused other issues (#34), but the char/int mismatch is just the most obvious/convenient/common case. Any FSM that requires a numeric input to advance, but encounters one that can't be coerced to a number will fail with a ClassCast instead of rejecting.A straightforward way to address this would be to signal rejection in the reified
nextNumericInputimpl if the return isn't actually a number. That would cover the immediate problem.One interesting/useful case that this wouldn't cover is where one has an FSM expecting a numeric input, it encounters something non-numeric, but you'd like to account for this via the
:signalmechanism. Right now, that's not possible at all, but in such a case, it could "back off" to usenextInput, get the non-numeric result, apply the:signalfn, and then attempt to continue. This might belong in a separate enhancement issue, but I think it would nicely shave off a rough corner and make:signalmuch more general-purpose. At the moment, I'm "preprocessing" inputs to my FSM because some never get to:signalin the first place.