Re: Generalizing ?? !!
On Fri, 22 Jun 2007 15:40:37 +0100, Aaron Crane wrote: Peter Scott writes: can someone tell me why you can't just use ... || in place of ?? ... !!, now that and || propagate context to both sides? You get the wrong result when the antecedent is true and the consequent is false: my $a = 1 ?? 0 !! 42; # Now $a is 0 my $b = 1 0 || 42; # Now $b is [42] Duh, there it is. Still curious as to whether their results could preserve lvalueness. -- Peter Scott
Re: Generalizing ?? !!
Peter Scott writes: can someone tell me why you can't just use ... || in place of ?? ... !!, now that and || propagate context to both sides? You get the wrong result when the antecedent is true and the consequent is false: my $a = 1 ?? 0 !! 42; # Now $a is 0 my $b = 1 0 || 42; # Now $b is 17 -- Aaron Crane
Re: Generalizing ?? !!
On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote: my $b = 1 0 || 42; # Now $b is 17 s/17/42/ or vice-versa, I think. -- Paraphernalia/Never hides your broken bones,/ And I don't know why you'd want to try:/ It's plain to see you're on your own.-- Paul Simon http://surreal.istic.org/ Show, don't tell. signature.asc Description: Digital signature
Re: Generalizing ?? !!
Daniel Hulme writes: On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote: my $b = 1 0 || 42; # Now $b is 17 s/17/42/ or vice-versa, I think. Uh, yes. Serves me right for trying to change metasyntactic numbers midstream. -- Aaron Crane
Re: assign-if-uninitialized [Was: Generalizing ?? !!]
On 6/19/07, Larry Wall [EMAIL PROTECTED] wrote: On Tue, Jun 19, 2007 at 11:50:35AM -0400, Charles Bailey wrote: : Yep. For that matter, if I had to pick one change in this area that'd : have maximum impact, I'd say a good assign-if-uninitialized idiom : would be way ahead of an if-then-else idiom. Depending on how you mean uninitialized, that would be either: $x //= 42; # init if undefined or state $x = 42; # init first time through Both of which are getting borrowed back into Perl 5, as it happens. This is a Good Thing, on both counts. (I was thinking primarily of the former.) My intent was to say that I'm glad this was addressed in the design of P6, since it is, in my experience, a much more common version of the conditional assignment problem than the ternary operator. Yet another example of P6 doing things well. Rereading my original comment, I see this is less than clear. My apologies for the confusion. -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ edu
Re: Generalizing ?? !!
[ Sorry to fall off the net for several days . . .] On 6/13/07, Larry Wall [EMAIL PROTECTED] wrote: 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. Granted, but that's 8 of the top 10 languages on the current TIOBE list. Lies, damned lies, and statistics . . . 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 You may well be right here -- you're certainly more qualified than I in language building -- but this line of reasoning leaves me with something of an uneasy feeling. I'm not sure Perl6 has all that much of what I'll call practical design capital, by which I mean ability to change practice by making new ideas common usage. I'm distinguishing that from what I'll call formal design capital -- the ability to change practice by having good ideas to which people will listen -- of which I think Perl6 has a good amount. I think this distinction can be important for several reasons, not the least of which is that they may antagonize one another. I'd argue that Perl's FDC arises from its current widespread acceptance, showing that many people think it currently implements good solutions to some of the problems they need to solve, and from the respect given to [EMAIL PROTECTED], because they've implemented those solutions, discussed them intelligently, and are in general good people. This sort of capital works best for big ideas, whether by putting them out for discussion (read: persuasion), or by implementing them in a new language. OTOH, I'd argue that PDC is more of a transient phenomenon, and arises from the comfort users have with the language, whether it's that it feels natural overall, or that they recall being able to accomplish some necessary task(s) easily or elegantly. In some respects, it's the net-equivalent of what have you done for me lately? I think Perl 6 has less of a reserve here, partly because of its long gestation, partly because of its informal reputation as a small step up from APL in readability (cue the JAPH culture), and partly because of its reputation for being disorganized and unsecure. (As an aside, let me take pains to emphasize -- this being email -- that I am not arguing that these claims are true, not that, to the extent they're true they're Perl's fault. Nonetheless, they exist, in the minds of potential users, and of the managers/vendors/spinners that specify what language choices are allowed.) I also think that one wins or loses in this arena as often due to the little things -- whether something is easy and intuitive -- as to the big things -- whether something is possible and clean. Why do I belabor the obvious so? Because I think the discussion about the ternary operator, like several others recently on these lists, might be conflating the two, and might be missing an opportunity thereby. In some cases, Perl6 will want to be the language on a hilltop, beckoning others to follow into the land of elegance and orthogonality. But there's also something to be said for ingratiating and subverting. That, in turn, implies that there will be cases where it's better to make a suboptimal choice in a small matter -- not sacrificing major principles, and not jumping through hoops inside the box to save the user two keystrokes, but inculturating in order to better be able to make the really important points. Whether ?: is a better choice in this respect than ??!! is perhaps a matter of taste, and I'm not going to argue that either is the Platonic spelling of the ternary operator. As best I can articulate it, I think I'm arguing for a more explicit balance of better with comfortable in making these choices. I don't mean by any of this to devalue the extensive community input into the early stages of Perl6 design. If anything, I may be undervaluing it, since it occurred during a time when RL required that I essentally drop out of the Perl community, and I missed much of the detail. I also don't mean to ignore the ongoing input via these lists, and I'm sure several other channels. It's also true that at some point, to get a working result, The Cabal has to make design decisions whether or not The Masses have come to consensus. That can be hard for both sides,
assign-if-uninitialized [Was: Generalizing ?? !!]
On Tue, Jun 19, 2007 at 11:50:35AM -0400, Charles Bailey wrote: : Yep. For that matter, if I had to pick one change in this area that'd : have maximum impact, I'd say a good assign-if-uninitialized idiom : would be way ahead of an if-then-else idiom. Depending on how you mean uninitialized, that would be either: $x //= 42; # init if undefined or state $x = 42; # init first time through Both of which are getting borrowed back into Perl 5, as it happens. Larry
Re: Generalizing ?? !!
On 6/11/07, Luke Palmer [EMAIL PROTECTED] wrote: On 6/11/07, Jonathan Lang [EMAIL PROTECTED] wrote: Still, Damian has a good point - which renders the bulk of this discussion moot. The one thing left to consider (IMHO) is whether or not it's worthwhile (or even possible) to go back to '$c ? $t : $f' or to '$c ? $t ! $f'. As I said, the primary concern originally expressed about the Perl 5 syntax involved matters of ambiguity which seem to have been resolved since then. A case could be made that if the Perl 5 syntax for this doesn't clash with the rest of Perl 6, it should be used: anything else would be change for change's sake. First, don't consider it a change. We're making a new language, not modding Perl 5. 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). 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. Granting that Perl6 is a new language, I think there's still a role for deferring to existing usage. 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. paranoiaThere'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. That may be eased by sprinkling familiar ideas amongst the novel. 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 -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ edu
Re: Generalizing ?? !!
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). 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. In short, is C:: ?? going to be Perl 6's C - ? Again, this presupposes that C: ? is a feasible option (i.e., doesn't conflict with anything important) now that we have whitespace disambiguation. If it isn't, then this whole line of reasoning is moot. So: Is it feasible? -- Jonathan Dataweaver Lang
Re: Generalizing ?? !!
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. : paranoiaThere'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
Re: Generalizing ?? !!
On Mon, Jun 11, 2007 at 01:43:40AM -, NeonGraal wrote: Surely if you defined !! to return undef but true and both operators to be left associative then it all works. 1==0 ?? True !! False - (undef) !! False which seems right to me. 1==1 !! False ?? True - (undef but true) ?? True also good. TTFN, Struan Nope. $a = $b ?? $c !! $c; If $b is true, you want a to have the value of $c, NOT $c but true. Later code may want to use the value of $a in a boolean context. When the but true is added to make the short circuiting work, it can have longer lasting effects that are not desired. (I know Larry already agreed with the principle of not mucking around with simple stuff, but I just wanted to provide a bit more detail of how said mucking might be a problem. We don't need no stinking epicycles upon epicycles. :-) --
Re: Generalizing ?? !!
On 11/06/07, Audrey Tang [EMAIL PROTECTED] wrote: 在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate to Moose, instead of undef as we wanted? Perhaps I haven't understood hypothetical variables, but would it make sense to make ?? hypothetically bind its LHS? That way, !! would be analogous to the other short-ciruiting or operators: || # truth // # definedness !! # boundness This haskell seems to be equivalent (using ? ! as the token !! is already in use). True ? a = Just a False ? _ = Nothing Just a ! _ = a Nothing ! b = b *Main True ? Bill ! Ben Bill *Main False ? Bill ! Ben Ben Ciao, osfameron
Re: Generalizing ?? !!
On Jun 11, 9:10 am, [EMAIL PROTECTED] (Jonathan Lang) wrote: Rereading A03, I ran across the original reasoning behind why Perl 5's '?:' trinary operator became '?? ::' first, and then '?? !!'. Three reasons were given: * the '?' and ':' tokens are far too broadly useful to be gobbled up by the trinary operator. * the doubled symbols bring to mind the short-circuiting operators (e.g., '' and '||'), suggesting a similar short-circuiting behavior here. * the '!!' brings to mind evaluate this when the condition fails. IMHO, the first point was always more about the ':' than it was about the '?'; if you were to replace ':' with '!', I suspect that this concern would largely go away. That is, I don't see any infix:? or infix:! operators in the current draft. A case could be made that a trinary '... ? ... ! ...' operator could work within the current state of things without conflict. Also, the whitespace disambiguation rules that were later implemented go a long way to resolving the original problem of ':' trying to do too much. That said, the latter two points are still valid. '... ? ... : ...' might be perfectly workable; but so is '... ?? ... !! ...'. However, there still may be room for improvement. Consider the following possibility: Instead of being a single, inflexible trinary operator, break this into a pair of binary operators: infix:?? and infix:!!. Each can be used on its own, returning the right side if the condition evaluates as expected (i.e., true for ?? and false for !!), and otherwise returns 'undef'. A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. So all of the following would be valid syntax: $test ?? $a !! $b # true: $a; false: $b $test !! $a ?? $b # true: $b; false: $a $test ?? $a # true: $a; false: undef $test !! $b # true: undef; false: $a I suggest this mainly because it's potentially more extensible than the current model. I could see someone devising a fuzzy logic module which could allow for such things as: $test ?? $a !! $b maybe $c likely $d unlikely $e -- Jonathan Dataweaver Lang Surely if you defined !! to return undef but true and both operators to be left associative then it all works. 1==0 ?? True !! False - (undef) !! False which seems right to me. 1==1 !! False ?? True - (undef but true) ?? True also good. TTFN, Struan
Re: Generalizing ?? !!
?? and !! could always return some kind of result object that boolizes to true or false. Zev Audrey Tang wrote: 在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate to Moose, instead of undef as we wanted? Cheers, Audrey
Re: Generalizing ?? !!
Zev Benjamin skribis 2007-06-11 0:57 (-0400): ?? and !! could always return some kind of result object that boolizes to true or false. Can we *please* keep simple things simple? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Generalizing ?? !!
On Mon, Jun 11, 2007 at 12:16:35PM +0200, Juerd Waalboer wrote: : Zev Benjamin skribis 2007-06-11 0:57 (-0400): : ?? and !! could always return some kind of result object that boolizes : to true or false. : : Can we *please* keep simple things simple? Indeed, basic control flow is not a good place to play mind games for either the programmer or the compiler. There are very few true primitives in Perl 6, and this is right up there close to lambdas, I suspect. Larry
Re: Generalizing ?? !!
Audrey Tang wrote: Jonathan Lang wrote: A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate to Moose, instead of undef as we wanted? Nope; because of the short-circuiting behavior: True ?? undef !! Moose - True ?? undef // True !! Moose The condition evaluates to True, causing the ?? to evaluate its RHS and then short-circuit the rest of the expression. The fact that the RHS evaluates to undef is irrelevant. In a sense, ?? and !! would invert the usual short-circuiting behavior: with normal short-circuiting operators ( and ||), the RHS is evaluated if and only if the operator does not short-circuit; with ?? and !!, the RHS would be evaluated if and only if the operator _does_ short-circuit. NeonGraal wrote: Surely if you defined !! to return undef but true and both operators to be left associative then it all works. 1==0 ?? True !! False - (undef) !! False which seems right to me. 1==1 !! False ?? True - (undef but true) ?? True also good. ...except that '1==1 !! False' would return 'undef but true' on a failure. I'm sure that a rationale could be provided for doing this; but it's a potentially surprising result which could get you in trouble. Best to keep to a simple 'undef' result on a failure. Hakim: I'm not familiar with Haskell, so I can't follow your code as well as I need to to provide an informed response. Juerd Waalboer wrote: Zev Benjamin wrote: ?? and !! could always return some kind of result object that boolizes to true or false. Can we *please* keep simple things simple? Agreed. I'm in favor of this proposal to the extent that it breaks a simple trinary operator down into equally simple binary operators (with the trinary form continuing to exist as an emergent property of the interaction of the binaries); if those binary operators become more complex than the trinary form, or if you lose the ability to recover the trinary form from them, there's no point in pursuing this proposal. -- Jonathan Dataweaver Lang
Re: Generalizing ?? !!
Ok, let me take a step back and see what's being suggested.
it certainly seems like a case can be made for a binary operator, say
??, that returns its rhs if the lhs is true, undef otherwise,
analogous to the shell's ${var+val} construct.
At first glance it appears that the desired ternary behavior could be
achieved by chaining such an operator with //:
A ?? B // C
But that fails if B happens to be undef. And it seems to me that
anything you do to the chaining rules to fix that case is going to be
pretty confusing in general.
So I prefer keeping a single construct, but perhaps the else-part
could be optional?
On 6/11/07, Jonathan Lang [EMAIL PROTECTED] wrote:
Audrey Tang wrote:
Jonathan Lang wrote:
A variation of chaining associativity gets
used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3'
instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison
chaining.
But wouldn't that make:
True ?? undef !! Moose;
evaluate to Moose, instead of undef as we wanted?
Nope; because of the short-circuiting behavior:
True ?? undef !! Moose
-
True ?? undef // True !! Moose
The condition evaluates to True, causing the ?? to evaluate its RHS
and then short-circuit the rest of the expression. The fact that the
RHS evaluates to undef is irrelevant.
In a sense, ?? and !! would invert the usual short-circuiting
behavior: with normal short-circuiting operators ( and ||), the RHS
is evaluated if and only if the operator does not short-circuit; with
?? and !!, the RHS would be evaluated if and only if the operator
_does_ short-circuit.
NeonGraal wrote:
Surely if you defined !! to return undef but true and both operators
to be left associative then it all works.
1==0 ?? True !! False - (undef) !! False which seems right to
me.
1==1 !! False ?? True - (undef but true) ?? True also good.
...except that '1==1 !! False' would return 'undef but true' on a
failure. I'm sure that a rationale could be provided for doing this;
but it's a potentially surprising result which could get you in
trouble. Best to keep to a simple 'undef' result on a failure.
Hakim: I'm not familiar with Haskell, so I can't follow your code as
well as I need to to provide an informed response.
Juerd Waalboer wrote:
Zev Benjamin wrote:
?? and !! could always return some kind of result object that boolizes
to true or false.
Can we *please* keep simple things simple?
Agreed. I'm in favor of this proposal to the extent that it breaks a
simple trinary operator down into equally simple binary operators
(with the trinary form continuing to exist as an emergent property of
the interaction of the binaries); if those binary operators become
more complex than the trinary form, or if you lose the ability to
recover the trinary form from them, there's no point in pursuing this
proposal.
--
Jonathan Dataweaver Lang
--
Mark J. Reed [EMAIL PROTECTED]
Re: Generalizing ?? !!
Mark J. Reed concluded: So I prefer keeping a single construct, but perhaps the else-part could be optional? I hope not. The mandatory else-part is one of the most valuable features of the ternary operator. It helps ensure that variables initialized with a cascaded ternary actually do get initialized: $action = $name eq 'Kirk' ?? 'fight' !! $name eq 'Spock' ?? 'think' !! $shirt eq 'red' ?? 'die' !! 'stand'; The required-ness of the else-part makes cascaded ternaries a safer, more robust choice than if-elsif-else chains in many cases. Damian
Re: Generalizing ?? !!
Besides ?? !! with out an else part is just . -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Damian Conway [EMAIL PROTECTED] Mark J. Reed concluded: So I prefer keeping a single construct, but perhaps the else-part could be optional? I hope not. The mandatory else-part is one of the most valuable features of the ternary operator. It helps ensure that variables initialized with a cascaded ternary actually do get initialized: $action = $name eq 'Kirk' ?? 'fight' !! $name eq 'Spock' ?? 'think' !! $shirt eq 'red' ?? 'die' !! 'stand'; The required-ness of the else-part makes cascaded ternaries a safer, more robust choice than if-elsif-else chains in many cases. Damian
Re: Generalizing ?? !!
[EMAIL PROTECTED] wrote: Besides ?? !! with out an else part is just . No, it isn't. While behaves properly when the condition turns out to be true, the result of the condition turning out to be false is whatever the condition turned out to be. Still, Damian has a good point - which renders the bulk of this discussion moot. The one thing left to consider (IMHO) is whether or not it's worthwhile (or even possible) to go back to '$c ? $t : $f' or to '$c ? $t ! $f'. As I said, the primary concern originally expressed about the Perl 5 syntax involved matters of ambiguity which seem to have been resolved since then. A case could be made that if the Perl 5 syntax for this doesn't clash with the rest of Perl 6, it should be used: anything else would be change for change's sake. -- Jonathan Dataweaver Lang
Re: Generalizing ?? !!
On 6/11/07, Jonathan Lang [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Besides ?? !! with out an else part is just . No, it isn't. While behaves properly when the condition turns out to be true, the result of the condition turning out to be false is whatever the condition turned out to be. Still, Damian has a good point - which renders the bulk of this discussion moot. The one thing left to consider (IMHO) is whether or not it's worthwhile (or even possible) to go back to '$c ? $t : $f' or to '$c ? $t ! $f'. As I said, the primary concern originally expressed about the Perl 5 syntax involved matters of ambiguity which seem to have been resolved since then. A case could be made that if the Perl 5 syntax for this doesn't clash with the rest of Perl 6, it should be used: anything else would be change for change's sake. First, don't consider it a change. We're making a new language, not modding Perl 5. But I think there's a very good, if obvious, reason to change ? : to ?? !!. ? : is simply too small for the behavior of this construct. The ternary conditional is control flow, I'd say moreso than and ||. It should stand out; it's one of the more important things in a sentence. It also has a nice pseudosymmetry with and ||, what with its doubled characters. But we seem to be missing the junctional ternary conditional ? ! :-p Luke
Generalizing ?? !!
Rereading A03, I ran across the original reasoning behind why Perl 5's '?:' trinary operator became '?? ::' first, and then '?? !!'. Three reasons were given: * the '?' and ':' tokens are far too broadly useful to be gobbled up by the trinary operator. * the doubled symbols bring to mind the short-circuiting operators (e.g., '' and '||'), suggesting a similar short-circuiting behavior here. * the '!!' brings to mind evaluate this when the condition fails. IMHO, the first point was always more about the ':' than it was about the '?'; if you were to replace ':' with '!', I suspect that this concern would largely go away. That is, I don't see any infix:? or infix:! operators in the current draft. A case could be made that a trinary '... ? ... ! ...' operator could work within the current state of things without conflict. Also, the whitespace disambiguation rules that were later implemented go a long way to resolving the original problem of ':' trying to do too much. That said, the latter two points are still valid. '... ? ... : ...' might be perfectly workable; but so is '... ?? ... !! ...'. However, there still may be room for improvement. Consider the following possibility: Instead of being a single, inflexible trinary operator, break this into a pair of binary operators: infix:?? and infix:!!. Each can be used on its own, returning the right side if the condition evaluates as expected (i.e., true for ?? and false for !!), and otherwise returns 'undef'. A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. So all of the following would be valid syntax: $test ?? $a !! $b # true: $a; false: $b $test !! $a ?? $b # true: $b; false: $a $test ?? $a # true: $a; false: undef $test !! $b # true: undef; false: $a I suggest this mainly because it's potentially more extensible than the current model. I could see someone devising a fuzzy logic module which could allow for such things as: $test ?? $a !! $b maybe $c likely $d unlikely $e -- Jonathan Dataweaver Lang
Re: Generalizing ?? !!
在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate to Moose, instead of undef as we wanted? Cheers, Audrey
Re: Generalizing value property setting to become postits
Me: [$foo is bar] can change the value of $foo. Damian: Yes. For example: my $foo is persistent; Could you explain this further please? The programmer has specified a property named 'persistent'. The programmer has marked the $foo variable as being persistent. The specification of that variable property has caused the initial value of $foo to be retreived from disk. Hence the specification of a property has changed a variable. What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. Otherwise, I see a possibly interesting twist in which bar can do things beyond property setting, in particular, change $foo's value. I am hopeful that properties *will* be generalizable in some of the ways you're suggesting. I just wanted to clear up some misconceptions about their semantics. For an idea of what might be possible with properties, see the various Attribute::* modules, starting with Attribute::Handlers. Damian
Re: Generalizing value property setting to become postits
What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. What's the practical utility of this? 1. Simplification for perl 6 implementation. I would expect it to be easier, when implementing the case of a user-defined property setting sub, to implement this as a straight reuse of existing perl functionality, namely use of plain old subs and $_ aliasing, than to invent some alternate mechanism purely because it is deemed evil to even have the option of changing the bar'd value. 2. Simplification for explanation. A value property setting sub is just a sub that happens to set a value property. Oh, and by the way, the most convenient and expressive notation for calling value property setting subs is the one we taught you for applying a sub to a value, namely one gets to: return $foo : bar; from @foo := bar;# already gonna have to be learnt for perl 6 3. Availability of another, brief, convenient and expressive way of calling subs with one argument on the left: OUTPUT : open foo; OUTPUT : print bar; OUTPUT : close; I realize that a more general mechanism for postfix (or more accurately, infix) subs is hoped for, and, depending on how that looks, it might well make the above example pointless. Or, the more general mechanism for postfix/infix might subsume the above, so that property setting is just a way to use a sub with one of its args on its left, and that is just one of various postfix/infix options available. Once one takes that step, : can become a generalized apply to value(s) character, and the next natural step is: @foo := bar;# iterate over @foo, applying bar to values. Actually, Larry has already indicated in an earlier message to the list that ':' will work a lot like that! Yes, that was part of my reason for posting this. I thought it was interesting how the syntax fell in to place nicely for what Larry had already said he wanted, if ':' property setters are allowed to generalize to being subs (or blocks or -- I have more ideas on this, but they can wait or die with this thread) that can see and change the values from their left hand side. A key point here is that value properties apply to values, not variables, and element-wise operations also apply to values, not variables. Given that they share this applicability aspect, and (coincidentally?) shared ':' in proposed syntaces to date, I thought there might be value in looking at just how they might fit together.
Re: Generalizing value property setting to become postits
Me: [$foo is bar] can change the value of $foo. Damian: Yes. For example: my $foo is persistent; Could you explain this further please? Me: $foo : bar baz is roughly equivalent to baz(bar($foo)) Damian: Err. No. That would be: bar(1); baz(1); or possibly: $_=\$foo; bar(1); baz(1); . . There will, I hope, be a mechanism for pre- and postfixing subroutines, but not properties I think. I'm certainly not suggesting that : be _THE_ way to enable postfixing of subs. (I would assume you need a character pair to surround multiple args in the general case anyway, quite apart from the fact that : doesn't immediately strike me as a natural looking character for this sort of purpose.) But the $foo : bar syntax IS (at the very least rather close to) _A_ postfix sub syntax, whether or not this is currently viewed as a desirable way to look at it. Damian: You lost me here. Your ideas for properties are different from mine I didn't mean to suggest any changes whatsoever regarding properties. To the extent I understand them, I like them just the way you have proposed. (Indeed, I thoroughly applaud your influence on Perl 6. Personally I am rooting for one of my favortite bits from clos, multimethods, which was covered by one of your RFCs, but has not yet been raised on the list, though object inheritance is all about method dispatch as well, so that has made interesting reading.) What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. If constraints of what bars can do are deemed appropriate to ensure adequate performance for the property setting case, which is after all, in the first place, the motivation for the syntax, and in the second, the foreseeable primary use, well, so be it. Otherwise, I see a possibly interesting twist in which bar can do things beyond property setting, in particular, change $foo's value. Once one takes that step, : can become a generalized apply to value(s) character, and the next natural step is: @foo := bar;# iterate over @foo, applying bar to values. One character, one concept (apply to value(s)), used for two purposes that I think might not ever get in the way of each other. (Though I'm not sure about that -- that's what this thread was intended to help determine.) Finally, and really a distinct point, I would like to see a distinct term for value properties that doesn't use the word properties. I liked the metaphor of post-it notes, and, if bars were to end up being allowed to be an idiosyncratic but handy form of postfix sub, then postit or similar would, imo, be a natural name for value properties. Indeed, I think this may be true even if bars remain constrained to setting postits, er, properties.
Re: Generalizing value property setting to become postits
What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. What's the practical utility of this? This discussion has been pretty abstract so far... It's easy to see how properties can be used, since we've already used attributes in p5 for all kinds of stuff. Can you give an example or two of problems (with code) that the generalised postfix sub syntax would make easier to solve? Otherwise, I see a possibly interesting twist in which bar can do things beyond property setting, in particular, change $foo's value. Once one takes that step, : can become a generalized apply to value(s) character, and the next natural step is: @foo := bar;# iterate over @foo, applying bar to values. Actually, Larry has already indicated in an earlier message to the list that ':' will work a lot like that! The examples he has shown to date basically allow ':' to be a modifier to allow element-wise array operations, much like: http://dev.perl.org/rfc/82.html A good way to understand the possibilities with this kind of syntax is to examine other languages that allow their 'verbs' (operators / subroutines) to be modified by 'adverbs'. J and APL are probably the definitive source here. Although they don't need a ':' adverb, since they by _default_ apply all operations across an array argument, you can imagine how Perl could benefit from an insert adverb: http://www.jsoftware.com/primer/insert_adverb.htm or a table adverb: http://www.jsoftware.com/primer/table_adverb.htm
Re: Generalizing value properties to become postits
Simplifying somewhat (ok, a heck of a lot), an rvalued: $foo is bar or $foo : bar is syntactic sugar for: bar($foo) with some extra magic for handling a properties hash associated with $foo's value, in particular resetting the hash when $foo's value changes. Right? No. I do not think $foo will be passed to the bar handler like that. Basically, perl will (do the equivalent of) define a sub bar if it doesn't exist, then call bar, and bar can attach some data to the value in $foo, or update some data attached to the value in $foo, and will always return $foo. Right? Yes. If I got the above badly wrong, the rest of this post probably won't make sense. I also presume it would make sense to alias $_ to $foo in (the method associated with) bar. (Is that intended?) There will need to be some way to access the referent that the property handler is invoked upon. Passing a reference to it in $_ might be one such way. One could generalize so that bar can do as above, but doesn't _have_ to do as above, ie it doesn't have to attach data to $foo's value or update that data; Yes. For example, it might just write out a log message (indicating that $foo has been declared) or it might set some other variable indicating that $foo has been bar'red. it can return a value other than $foo; I would not expect that this would be allowed. and it can change the value of $foo. Yes. For example: my $foo is persistent; Basically, an rvalued: $foo : bar becomes a syntactically and cognitively cheap way, and a cognitively very different way, of calling bar on $foo, a cheapness and difference that amplifies if one applies several of these: $foo : bar baz qux instead of qux(baz(bar($foo))) Err. No. That would be: bar(1); baz(1); qux(1); or possibly: $_=\$foo; bar(1); baz(1); qux(1); I realize this isn't particularly appealing, but bare with me ;-) a little longer. So, in: $foo : bar bar in this context is not a property, but instead a more general post or similar (alluding to the notion that it is a bit like a postfix sub as well as (possibly) having the sticky note aspect.) No. There will, I hope, be a mechanism for pre- and postfixing subroutines, but not properties I think. So, to recap: $foo : bar; means bar is posted to $foo. $foo's value may change or stay the same. The return value may be $foo's, either before or after posting, or some other value. $foo's value may now have an attached bar postit. You lost me here. Your ideas for properties are different from mine (which may well, in turn, be different from Larry's). Damian
Re: Generalizing value properties to become postits
On 7/3/01 8:14 PM, Damian Conway wrote: You lost me here. Your ideas for properties are different from mine (which may well, in turn, be different from Larry's). Anyone else get the feeling that properties are to Perl 6 what oo was to Perl 5? :) It's like we'll finally be getting the oo bit right in Perl 6 (I hope!) after years of experimentation in Perl 5, but now we're adding this new, wonderful, terrible feature that will take *another* whole version of Perl to sort what works, what doesn't, etc. So much for Perl 6 being the last version... ;) -John
Generalizing value properties to become postits
Simplifying somewhat (ok, a heck of a lot), an rvalued:
$foo is bar
or
$foo : bar
is syntactic sugar for:
bar($foo)
with some extra magic for handling a properties hash
associated with $foo's value, in particular resetting the
hash when $foo's value changes.
Right?
Basically, perl will (do the equivalent of) define a sub bar
if it doesn't exist, then call bar, and bar can attach some
data to the value in $foo, or update some data attached
to the value in $foo, and will always return $foo.
Right?
If I got the above badly wrong, the rest of this post
probably won't make sense.
I also presume it would make sense to alias $_ to $foo
in (the method associated with) bar. (Is that intended?)
-
One could generalize so that bar can do as above, but
doesn't _have_ to do as above, ie it doesn't have to
attach data to $foo's value or update that data; it can
return a value other than $foo; and it can change the
value of $foo. Basically, an rvalued:
$foo : bar
becomes a syntactically and cognitively cheap way, and
a cognitively very different way, of calling bar on $foo, a
cheapness and difference that amplifies if one applies
several of these:
$foo : bar baz qux
instead of
qux(baz(bar($foo)))
I realize this isn't particularly appealing, but bare with me
a little longer.
So, in:
$foo : bar
bar in this context is not a property, but instead a more
general post or similar (alluding to the notion that it is
a bit like a postfix sub as well as (possibly) having the
sticky note aspect.)
So, to recap:
$foo : bar;
means bar is posted to $foo. $foo's value may change
or stay the same. The return value may be $foo's, either
before or after posting, or some other value. $foo's value
may now have an attached bar postit.
Presumably bar can be a block, method, or expression:
$foo : { code };
$foo : method;
More interestingly:
@foo : bar;
posts bar (expression, sub, block) to each element of
@foo. An alternate to 'for (@foo) bar' for single dim
arrays, and a syntactically cheap way to iterate over
entire multi-dim arrays (I'm assuming here that 'for'
won't, by default at least, iterate over all dimensions.)
@foo : bar;
@foo := bar;
@foo = @foo : bar;
are possibly just alternate ways of saying the same thing.
$foo := bar;
$foo = $foo : bar;
are also probably alternate ways of saying the same
thing, but are not necessarily the same as:
$foo : bar;
as the latter could return a value other than $foo.
