On 1/4/06, Luke Palmer wrote:
The other thing that is deeply disturbing to me, but apparently not to many other people, is that I could have a working, well-typed program with explicit annotations.
I don't think it disturbs me... but that might just be because I don't really understand it.
I could remove those annotations and the program would stop working!
If it changes how the program works, then by definition doesn't that mean it wasn't really an "annotation" to begin with? As far as specifying "Junction" in signatures to control auto-threading, that always felt funny to me anyway, because it's not consistent with the normal meaning of specifying a parameter type. I would've expected "is threaded" or "is junctive" or "is junctothreaded" or something.
I'm not sure if this is (part of) what you're getting at or not. In a strongly-typed language, can you always remove the typing from a working program without changing it? Or maybe just particular strongly-typed languages... in Perl, typing can be used to provide bonus information (say, as optimisation hints); but it can also be used for multiple-dispatch, so I certainly wouldn't expect a program to continue working properly if I changed *that* information. (Assuming "well-typed" refers to the former, but not the latter -- hope I've got that straight.)
In that vein, I think of junctions as a sort of implicit polymorphism: I define "sub foo(Int $a)" and also get "sub foo(Junction of Ints $j)" for free. Which is why "<" acting wacky doesn't bother me -- numbers may be well-ordered, but junctions aren't, and there are two different <'s at work. Arguably, different functions should have different names to avoid confusion, but I think that calling the junctive less-than something other than "<" would be even more confusing. (Certainly it would be too unDWIMilly pedantic to be Perl.)
Of course, I was also never bothered by using "+" to mean numeric addition and string concatenation. Come to think of it, perhaps that's because languages which do that are picky about distinguishing strings from numbers -- in Basic, 123 + "123" will get you a type-mismatch error, but to Perl, 123 and "123" are the same thing, so you need a numeric == and a stringic 'eq'.
But Perl does know the difference between a number and a junction. That means the programmer has to follow along at home, but ok, sometimes you just gotta be aware of what your code is doing. I think I understand your Functor proposal, and it does have a certain appeal for me... but along with the advantage of making it clearer when junctions are being used, it carries the disadvantage of *requiring* you to know when junctions are being used. I can't just say "if $x<3 ..." and expect it to Do the Right Thing regardless of whether $x happens to be an ordinary number or a junction -- I have to split up the two cases and handle them separately. That's surely going to reduce the happy-go-lucky usefulness of junctions.
Besides, don't we have a "no junctions" pragma that you can stick into any scope where you need exact mathematical purity?
-David
