some verification facility

[bottle2]

Standardized text formats such as HTTP, JSON and XML specifies generic rules for several elements, however when writing state machines, sometimes I want to parse some specific elements specially, such as certain HTTP fields or certain XML elements. Ragel's priorities allow me to achieve this effect, however I'm still subject to programming errors. In order to protect users from mistakes, Ragel should provide a facility to ensure that specific machines adhere to the definition of more generic machines. A friend tells me this is a decidable task. It would also serve as documentation.

Proposed solution: introduce a keyword such as is to assert that a specific machine doesn't offend the definition of a more generic machine, aborting the compilation if the programmer fails to do so.

The suggest syntax is a single statement:

specific_machine is generic_machine;

Challenge: Interaction with the when keyword. (I gave it zero thought so far)

[bottle2]

wait, I'm not really sure this is really useful... hmmmmm

[bottle2]

yeah I woke up and realize what is wrong.

suppose a HTTP 1.1 field line:

%% OWS = [ \t]*; # Optional whitespace.
%% field_line = field_name ':' OWS field_value OWS;

from https://www.rfc-editor.org/rfc/rfc9112#section-5.1-2

A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon.

Now, suppose I want to parse a very specific field, such as Accept-Encoding, and I write, using my suggested syntax:

%% accept_encoding = "accept-encoding:"i OWS ':' (codings weight? (OWS ',' OWS codings weight?)*)?
%% accept_encoding is field_Line;

It would abort because I match OWS before the colon, which is forbidden. After fixing this problem, my HTTP will silently fail sporadically, because I forgot to match OWS after the colon. My proposed construct cannot catch this.

Hence, I don't think my facility is totally useful, speaking in practical terms envisioning ultimate maintenance. It would convey a false sense of certainty that might disrupt debugging sessions and hurt maintenance. The one thing that could totally verify the state machine would be actual testing, such as unit testing, integration testing, fuzzer testing etc., none of which I bothered to setup so far. And then, maybe after setting them up, maybe they prove to be enough, rendering the proposed facility vestigial.

[bottle2]

okay now I'm kinda totally against this idea. I think some state machine generator thing will tackle the problem much better, but for now I only have a gut feeling. I will do some experiments with m4 to extend the language and push my implementations further and share what I find.