"OK. But there are 2 types of commands (that may not crash): 1) those that are ill-formed and 2) those that are well-formed but not expected/predicted by the developers. Ill-formed commands that still don't crash may have partial effects, right? For example, in a lazy language, if the ill-formed part occurs later in the expression, then the well-formed first part is still executed. In the context of a deployable that is configured (constrained to a sub-region of it's possible behavior), we need some way of ensuring the crispness of the boundary: these commands are allowed, these other one's are not.
Could these be loopholes in strong but non-strict languages?" The usual problem that occurs in non-strict languages are thunk leaks. I plan to plan to plan to plan ... to do something.. Delayed failure can occur too, but for me it is much less common then, say, ad-hoc type handling in a dynamically-typed language. I think it just comes down to the degree to which the developer articulates the constraints on the context as types, and then whether the language has the property of really enforcing those types. Also there's the problem of what happens when the developer just can't get across what they want in the types. Either because they can't be bothered or because the type system isn't versatile enough. I think these security issues come down to limitations in human attention. Tools and languages can help with that, but obsessiveness is needed too. Marcus ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
