I had imagined the way things like
$R = 0 but true
would work is that the scalar would grow another couple of slots
in it, which would be the conversion operators. Everything defaults
to how it has worked in the past, but could be overridden. So the
boolean value starts as "default converter" until it gets accessed,
then the language figures out what the boolean value is and caches it
until an assignment happens and clears the boolean (and other
autoconverted)
value.
That allows booleans to get set to values other than perl 5 truth of
the scalar contents.
It also meshes well with alternate v-tables, although profusion of
what can be done by multiplying the number of vtables and what is better
done with a per-access check is a good case for some modeling and some
algebra
and some benchmarking on various platforms: Maybe we could have a slider
in the performance tuning widget.
But if the additional slots in the scalar are cleared at assignment, that
is
a very different sort of assignment to an item than a "property" such as
"will only hold integers" or "will only hold dogs or dog subtypes" which
does not
vary and can be used by the compiler.
I propose:
use "but" to override the default intrascalarvalue conversions, such as
$line = readline but true;
or even better,
$line = readline;
$line = $line but boolean(is_section_end_markerp($line));
Although this second use begs the question, "Why bother with combining
types if you're going to override them?"
Maybe overriding is not such a good idea anyway? Are there really
that many situations where having Truth autogenerated from
number/text-string
isn't confusing and bug-prone already?
reserve "is" for compiler optimization hints:
my $line is text;
I have not read the earlier discussion in the thread I am adding this
posting to,
or the essays referred to by them. The above is/but distinction is
something
that I believe needs to be made, by any names, because without it there
will be
confusions
