[svn:perl6-synopsis] r9176 - doc/trunk/design/syn
autr...@cvs.perl.org
Date: Thu May 11 02:52:17 2006
New Revision: 9176
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: "but true" is now spelled as "but True"
Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod (original)
+++ doc/trunk/design/syn/S06.pod Thu May 11 02:52:17 2006
@@ -1575,7 +1575,7 @@
sub system {
...
return $error but false if $error;
- return 0 but true;
+ return 0 but True;
}
Properties are predeclared as roles and implemented as mixins--see S12.
Elyse M. Grasso
> * S06: "but true" is now spelled as "but True"
>
> ...
> return $error but false if $error;
> - return 0 but true;
> + return 0 but True;
> }
>
> Properties are predeclared as roles and implemented as mixins--see S12.
>
Is "but false" now spelled "but False"? If not, if there a reason for the
asymmetry?
--
Elyse M. Grasso
CTO
ReleaseTEAM Inc.
http://www.releaseteam.com
phone 720-887-0489
fax 720-977-8010
cell 303-356-2717
Larry Wall
: Is "but false" now spelled "but False"? If not, if there a reason for the
: asymmetry?
Yes, the false value is False now, just as the true value is not True.
The reason for changing them is to avoid confusion with the built-in
true() function, and the theoretical false() function, which is
actually spelled "not".
The Bool type is an enum with values <False True>. As with any enum,
we also treat those names as subset types. Indeed, any constant can
function as a subset type. Constant functions are naturally 0-ary,
and in C culture tend to be uppercase anyway. So arguably, we could
have a rule or policy that 0-ary functions are generally uppercase,
not just the constant ones. Instead of time, we'd have Time.
Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
form would never look for an argument. Defining a
sub baz ($x?) {...}
would also define
sub Baz () {...}
Have to think about that some more, though. Could also say that,
unlike a provisional "foo", a provisional "Foo" would be considered
0-ary rather than list op. As with any provisional, a Foo would
have to resolve to a sub Foo () or a sub foo ($x?) by the end of
the compilation.
Hmm.
Larry
Nicholas Clark
> function as a subset type. Constant functions are naturally 0-ary,
> and in C culture tend to be uppercase anyway. So arguably, we could
> have a rule or policy that 0-ary functions are generally uppercase,
> not just the constant ones. Instead of time, we'd have Time.
> Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
> form would never look for an argument. Defining a
I'm not convinced that this holds, as Rand isn't constant, whereas the C
uppercase convention applies to constants. Also, the C convention tends to
be all-caps, unless I've mis-understood which convention you're referring to.
> sub baz ($x?) {...}
>
> would also define
>
> sub Baz () {...}
>
> Have to think about that some more, though. Could also say that,
Presumably it's titlecase rather than uppercase.
This doesn't introduce any interesting ambiguities, does it?
IIRC the "fun" stuff involves lowercase and Greek letter sigma following
something, which therefore isn't relevant here.
Nicholas Clark
--
I'm looking for a job: http://www.ccl4.org/~nick/CV.html
Smylers
> Yes, the false value is False now, just as the true value is not True.
It's not? I thought somebody had just said that it was?
> The reason for changing them is to avoid confusion with the built-in
> true() function,
Makes sense.
> So arguably, we could have a rule or policy that 0-ary functions are
> generally uppercase, not just the constant ones. Instead of time,
> we'd have Time.
Does that actually gain us anything?
> Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
> form would never look for an argument.
Personally I think that'd be more confusing. It isn't particularly
intuitive, and it makes switching from one form to another more awkward
cos you don't just have to change the params after the function name but
also the case of the letter at the start.
And what about functions with names starting with an underscore?
> Defining a
>
> sub baz ($x?) {...}
>
> would also define
>
> sub Baz () {...}
>
> Could also say that, unlike a provisional "foo", a provisional "Foo"
> would be considered 0-ary rather than list op.
Who would benefit from this? To me it just seems like more complexity,
and encouraging hard-to-spot typos as we have things which differ only
in case. Surely if somebody has a function call C<baz> which they
explicitly want to mark as being 0-ary then writing it as C<(baz)> or
C<baz()> is already a sufficiently convenient way of doing this, and is
intuitive to the casual reader.
I think the effort in learning this special case outweighs any benefit
it brings.
Smylers