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 S12.

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

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 C<bazwhich 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