Miko O'Sullivan aksed: > .... what would "true" (the string) be converted to?
In a numeric context: 0 (as in Perl 5). > Here's my point more > explicitly: in a boolean context, there's no need to get any specific string > (0, 1, "yup") as long as it correctly expresses true or false. It's when > you convert a boolean into a string or number that it becomes convenient to > define how they are represented by default. Yes, of course there are already > ways to change a variable from [some representation of false] to 0, but by > giving a slick way to default the string, a lot of ?? :: type stuff can be > done away with. Well, given that Perl 6 has an actual BOOL subtype, maybe C<true> and C<false> could return objects with: * a Boolean conversion to 1/"" * a string conversion to "true"/"false" * a numeric conversion to 1/0 > That sounds like a great way to do it. A follow up question, then: would it > be easy enough to accomplish that in a use-type format? I.e., something > like I said earlier: > > use StrictBoolean TRUE=>1, FALSE=>0; > > or even just let it default: > > use StrictBoolean; Yes. In Perl 6 C<use> statements will, by default be lexical in effect. The module itself *might* look like this: module StrictBoolean; my @truth = ({TRUE=>1, FALSE=>0}); sub import ($class, *%beauty) { push @truth, \%beauty } sub unimport { pop @truth } sub true is exported { return @truth[-1]{TRUE} } sub false is exported { return @truth[-1]{FALSE} } > The issue of what is more intuitive is of course highly subjective, but I > would argue that for several reasons the more concise version is more > unituitive to the population at large: Quite possibly. This is why I was so subjunctive about that option. And why I'm happy to leave such decisions to Larry. His track-record on DWIMity is exceptional. :-) > - There's already a huge population of programmers out there who already use > this notation. I frankly admit that I think of PHP as a great idea that > wasn't done quite right. I agree. Including that notation! ;-) Damian