So if I had to talk about practice:
* Transform untrusted input into value objects on input.
* Don't accept non-value object input in your internal APIs
* Use transformations with implicit type class patterns to do interpolation
to an export format.
These are useful rules, and provide a simple answer to the complex
problem for programmers who are swamped in work and don't have time
to think about this stuff. I think that's something the langsec
project should strive for as useful output.
I fully agree. The difficulty here appears to be in describing the
_semantic_ output of the recognizer in such terms as appeals to
programmers. "Value object" sounds like a great way to appeal to a
particular part of the audience; we were also thinking in terms of types
and semantic actions.
Our own recurring design recommendation stressed the boundary between
the _recognizer_ and _processing code_, which explicitly assumes that the
recognizer has done its job (in terms of the above, produced a fully
cooked and validated value object). Hence a recommendation for code
review: look for that boundary, identify it, and see if the assumptions
are actually being checked by the recognizer. I recognize that these
are rather general recommendations, and should be made clear on specific
examples, continuing the "Shotgun parser" series of examples.
Thank you,
--Sergey
_______________________________________________
langsec-discuss mailing list
[email protected]
https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
