(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.
Richard
