On Sun, Feb 13, 2005 at 04:10:08PM -0600, Jonathan Scott Duff wrote:
: On Sun, Feb 13, 2005 at 11:10:20AM -0600, Patrick R. Michaud wrote:
: > Autothreading, even if enabled by default, doesn't happen until a
: > junction is created and used somewhere. Thus the only time our hypothetical
: > new programmer would be forced to become aware of junctions (without
: > himself/herself having created a junction) is when he/she calls some
: > routine that chooses to generate and return a junction on its own.
:
: Like when he uses a module from CPAN that uses junctions (as an
: implementation detail of the module that just happens to be exposed).
: Or when the module that he has created and released to CPAN starts
: getting used with code that uses junctions and his users discover
: bizarre behavior.
:
: > That isn't likely to happen often.
:
: Perhaps.
We've already got an invariant on incoming parameters that lets the
user ignore junctions until they're ready to handle them. (That's
really what the autothreading "feature" is all about, after all. It's
not really there in it's own right; it's an encapsulation feature--or
in this case, an eXcapsulation feature.) Now, we might break that
invariant by making it too easy to declare junctive parameter types,
so I suspect we need to make sure that doesn't happen too easily. More
on that below.
But what y'all are talking about above is the other end--the return
type. And maybe we need to enforce a newbie-friendly invariant on that
end as well. I suppose we could default to not accepting junctional
return values by default, and have a pragma to turn it on. Or perhaps
the problem isn't returning junctions per se, but storing them into
a variable that the user is thinking of as a simple scalar value.
So we could allow a user to write junctions as arguments:
if $a == 1 | 2 | 3 {...}
while by default disallowing an assignment like:
$a = 1 | 2 | 3;
They could allow such assignments by use of a special pragma:
use Quantum::Superpositions;
(or some such... :-)
Come to think of it, we could have the same default on modules
that declare function parameters. Then to suppress autothreading
excapsulation you'd have to both declare the parameter as a junctional
type *and* use the pragma in the lexical scope. That might ameliorate
the problem of having types that sneakily become junctional when the
person declaring the function parameters wasn't expecting it.
The pragma would only be aimed at the assignment type checker. Since
junctional return values are allowed, you could still say things like:
@foo = (1|2|3).values;
The main thing is that this approach allows most of the newbie-friendly,
rvalue uses of junctions without letting people get into trouble by storing
junctions where they weren't expecting. Basically, we disallow storing
qubits into lvalues. So maybe the actual pragma name is
use qubits;
Note: the pragma is not "use junctions", since they're already allowed
to use junctions, as long as they don't try to observe them. :-)
I'd be tempted to make it just
use qm;
but people might confuse that with some kind of quote operator. Plus,
they're already using qm in the same sense that we all use QM every
day of our lives without thinking about it. On the other hand, if
we ever get real quantum computers we might want to reserve "qubits"
for a real data type. So maybe it should be
use jubits;
or some such...
On the other hand, we're multiplying entities here. Maybe we should
stick with:
use junctions;
with the understanding that it merely turns on full support for junctions
instead of the default partial support. Which implies you could go
the other way and turn off all junction support in the current lexical
scope with:
use junctions :none;
And now, of course, I'm trying to figure out what
use junctions :one;
use junctions :any;
use junctions :all;
would mean... :-)
Larry
