[svn:perl6-synopsis] r9176 - doc/trunk/design/syn
Author: autrijus
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.podThu 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.
Re: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn
On Thursday 11 May 2006 5:52 am, [EMAIL PROTECTED] wrote: * 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
Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
On Thu, May 11, 2006 at 07:44:54AM -0400, Elyse M. Grasso wrote:
: 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
Re: Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
On Thu, May 11, 2006 at 10:24:24AM -0700, Larry Wall wrote:
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
Re: Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
Larry Wall writes:
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 Cbaz which they
explicitly want to mark as being 0-ary then writing it as C(baz) or
Cbaz() 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
