Condition Propagation renamed: Proviso

Everyone who works in abstracts knows the importance of names. I've had to try to explain the concept of Condition Propagation (see Actively managing missing information through Condition Propagation) several times now, and a major challenge has been the vague terminology involved. Specifically, the generic term condition, versus the formal concept I am trying to define.

In an effort to be clearer, I am giving the "conditions" in the scheme I formerly called "Condition Propagation" a new name: provisos. This term's primary use is in regards to stipulations in contracts and legal documents, and so I am confident that its use in the context of computer languages should be unambiguous.

I am still not sure if the concept of provisos as I have presented them is unique or not. I have observed several similarities to other previously raised concepts, but have yet to find a duplicate. I believe that provisos would eliminate many of the design and implementation challenges facing other languages and libraries.

I've begun to attempt to flesh out provisos more formally, and to work out open questions, such as what to do with unresolved provisos at the expressive/imperative boundary. For proviso resolution, I am toying with the following imaginary syntax: ? as a suffix resolution, followed by a conjunctive list of provisos (individually inverted if necessary); and ?* as an short hand for "? true" meaning any and all provisos.

value.IndexOf(',') ?* value.Length

This reads: the index of the substring ',' in "value" or the length of "value" if no such substring is contained. This is short-hand (in this case) for:

value.IndexOf(',') ? IndexOfFound value.Length

Here is possible syntax for proviso evaluation (just return the condition):

if value.IndexOf(',') ?? IndexOfFound then ...

??* would, as expected, be short-hand for evaluation of any and all provisos.

A final thought: Myself and others have asked the question, are provisos too complex? No matter how ideal or elegant an idea is, complexity is a tremendous obstacle. As an example, I've interviewed numerous developer prospects in my career and have observed that very few practitioners understand nulls in SQL. Most SQL users, of course, know to use "is null" rather than "= null" in where conditions, but asked why they do this, they almost never understand null propagation. SQL style nulls are sufficiently complex that almost nobody has come to understand let alone leverage them. In fact the battle cry among practitioners and theoreticians alike is "avoid nulls at all cost". Regardless, I believe that users could overcome the learning curve associated with provisos for at least the following reasons:

  • Similarity to familiar concepts such as exceptions, nulls, and preconditions.
  • Deep library integration. Unlike SQL nulls, users couldn't simply learn to work around them.
  • Deep compiler integration. Unlike other systems, the compiler would "help" enforce proper usage of provisos.
  • Fundamental simplicity. Ultimately provisos seem a simplifying concept, consolidating and eliminating otherwise competing design options.
  • Performance. It is not difficult to imagine scenarios where implementations of provisos could benefit from certain performance advantages.

Comments

Popular posts from this blog

Don't Repeat Yourself... Really!

Issues raised by polymorphism in relation land

Camtasia Studio Tips