On Wed, Jun 13, 2007 at 05:08:34PM -0400, Charles Bailey wrote: : I'm concerned that the relevant precedent isn't just Perl5. The ?: spelling : of the ternary is pretty deeply embedded in programming languages -- I'm : hard pressed to think of a widely used language in the past 10-15 years that : spells it differently (though that may say more about my experience than the : universe of "widely used" languages).
It's really just the C-based languages. Lots of popular languages don't even give you a conditional operator, and seem to get by okay without it. : Put more practically, I don't think : the issue is just moving people forward from Perl5; we need to think about : whether it'll help or hinder users moving back and forth among several : languages, or bringing familiarity with other languages to the process of : learning Perl6. That had to be one of the main design considerations for Perl 1, but now we've got the "design capital" to fix some things. The Perl 6 mandate is not universal compatibility (which Perl 5 still represents in a way), but the chance to fix everything that needs fixing. And this one of the things I think C got wrong. Perl 6 is looking more for semantic and pragmatic compatibility than syntactic compatibility. We won't have to teach anyone the *idea* of a conditional operator, just send them off to look for the green bikeshed. : Granting that Perl6 is a new language, I think there's still a role for : deferring to existing usage. Certainly, all other things being equal (give or take), we'll go for something familiar. And I'll say we even put a thumb on the scales in favor of what Perl 5 programmers expect, now and again. But sometimes it's still right to break something, and reduce the level of compatibility concern down to just making sure they get a good error message if they fall into old habits. In that case it means making something different enough that the old one can be recognized and dealt with. At some point you put the new wine into new wine skins and throw the old ones out. : If it's technically impossible, or would : prevent Perl6 from delivering some other important benefit (e.g. would : require a lot of special-casing elsewhere), then it's worth making a : change. But I'm not sure pure orthogonality, visual impact, or similar : considerations, adequate though they are for deciding how to implement a new : operation, are sufficient cause to trade common usage for a novel one. It's not really that common, compared to, say, assignment, which you'll note we've pretty much left untouched, except for relaxing the requirement for parens on the right side of list assignment. : <paranoia>There's also the less important social problem that Perl6 has : already spent a lot of goodwill in its long gestation. I think it can be : earned back by doing things well, because they've been thought through : carefully, but the language will be viewed with some initial skepticism. I would like to think that "doing things well" is exactly the approach we're taking. We're not optimizing for the past, but for the future. This might rehuffmanization of everything might influence more generations of computer language than we can possibly imagine. : That may be eased by sprinkling familiar ideas amongst the novel. Which we do quite liberally... :) : Sure, : it's still got +*-/, but would ?: hurt? At a minimum, is there a strong : enough reason for changing it that it will be difficult for skeptics to : describe it as merely another ideological change?</paranoia> Certainly. The main problem is not so much that ? is ambiguous, but that the : is. It's somewhat ambiguous with labels (though arguably those don't generally occur in the same context). The killer is that it's formally ambiguous with the colon that is used to indicate the list of an unparenthesized method call (in either direct or indirect form). That colon occurs where an infix is expected. It's also ambiguous with adverbs, which can occur in that position when modifying a preceding operator, as in 1..100:by(3). The fact that ?: tends to be used as one term in an expression means that things tend to be written compactly without spacing, which amplifies that ambiguity. On the plus side, the fact that it's the : and not the ? that is most problematic means that (unless the user adds their own infix:<?>) it's pretty easy to recognize the old usage and give a good error message at compile time. And I think that's all that's really necessary here. It's the differences that silently produce an unexpected result that we'll really need to worry about in terms of user satisfaction and FAQ minimization. That's also why there's no infix:<.>, so at least we can catch attempts to concatenate strings if they use spaces around it. For the rest, the fact that "foo"."bar" is unlikely to a find a .bar method on strings will have to suffice. Of course, if the "method" is nonalphanumeric, we're even less likely to find the method. And in the alphanumeric case, we can probably also alert on the fact that writing ."bar" is in fact a useless use of quotes. These are the everyday worries of a language designer. Well, me anyway... Larry
