(Daniel Ruoso also proposed to call the adverb :test
instead of :ok, making it easier to read but a bit
longer; my happiness doesn't depend on the exact name,
but of course we can discuss it once we have settled
on this scheme, if we do so).

My two-cents worth:

The adverb on a boolean changes the nature of the statement, so that if the statement is true we get the diagnostic message in :OK<diagnostic message> but if the statement is false we get a failure message from the compiler / software

Given that the diagnostic appears when the test succeeds, I - like Fagyal - would prefer :OK<> to :TEST<> because this is the way I use OK, that is I expect a positive answer.

However, the nature of a test is that a program consisting of test commands continues to run even if there is a failure. This is not a problem if the boolean statements are 'standalones' meaning that the consequent flow of the program is not dependent on the test, eg.,
$x.value == 2 :OK<Value correctly assigned>;
$x.color eq 'red' :OK<Color assigned>;

But if this is part of perl6, then it will be possible (I think) to write
if $x.value == 2 :OK<value was 2> {dosomething()} else {dosomeotherthing()};

What sort of behaviour would be expected? I see several alternatives:
a) Suppose it is decided that :OK could be a part of ordinary software, then a fork in the program would occur depending on the boolean value. Hence :OK in general generates a trace commentary that is explicitly defined for the TRUE case, but is implicitly defined by the compiler for the FALSE case. b) However, if it is considered best for :OK only to operate in Test contexts. That would mean a boolean test with :OK should be illegal unless it is a standalone statement, eg., the test should not be in a control construct. In this case, I would think :TEST should be the variant chosen. The reason being that it focusses attention on the test behaviour. c) Suppose, as Damian suggested (I think), that tests should be included in normal software, but that they are ring-fenced into a separate block with a TEST {}. That way, TEST blocks would not normally run in production software. In this case, the extra semantic hint of ok expecting a positive response would be useful. Hence :OK would be the preferable variation.


Reply via email to