Re: Smart match isn't on Bool
Aaron Sherman wrote:
In this code:
given False {
when True { say True }
when False { Say False }
default { say Dairy }
}
I don't think it's unreasonable to expect the output to be False.
In this code:
sub test() { True };
given 0 {
when test() { say OH NOEZ }
}
I don't think it's unreasonable to expect the output to be OH NOEZ.
However, it actually outputs True. Why? Well, because it's in the
spec that way. So... why is it in the spec that way?
Because you can't have a ponie, and eat it. Or so.
You can't please everyone, so we try to please at least some of the
people, and in the future you can expect a warning from a bare True or
False in a 'when', or on the RHS of a smart-match.
STD.pm already implements that warning, Rakudo doesn't. (But I'd
appreciate it if some brave soul could port the warning over to Rakudo,
shouldn't be too hard)
Cheers,
Moritz
r31883 -[S26] Attempts at clarifying language
Author: jani Date: 2010-07-31 11:49:53 +0200 (Sat, 31 Jul 2010) New Revision: 31883 Modified: docs/Perl6/Spec/S26-documentation.pod Log: [S26] Attempts at clarifying language Modified: docs/Perl6/Spec/S26-documentation.pod === --- docs/Perl6/Spec/S26-documentation.pod 2010-07-31 08:15:21 UTC (rev 31882) +++ docs/Perl6/Spec/S26-documentation.pod 2010-07-31 09:49:53 UTC (rev 31883) @@ -13,7 +13,7 @@ =table Maintainer: Damian Conway Date: 9 Apr 2005 -Last Modified: 30 Jul 2009 +Last Modified: 31 Jul 2010 =end VERSION =head1 @@ -39,28 +39,31 @@ of comments in Perl 6. Every directive starts either with an equals sign (C=) followed -immediately by an identifier Nas specified in Synopsis 2, or with a +immediately by an identifier Nas specified in Synopsis 2, or with C#= followed immediately by whitespace or an opening bracket. Directives that start with C= can be indented like the code they interleave, but their initial C= must still be the first non-whitespace character on their line. Directives that start with C#= can be placed -anywhere that a Perl 6 comment can appear (though they are meaningful -only in a subset of those places; see L#Declarator blocks). +anywhere that a Perl 6 comment can appear, though they are meaningful +only in a subset of those places; see L#Declarator blocks. -If a directive is indented from the left margin, the column at which the -first character of its opening delimiter appears is thereafter -considered the first column of the entire block's contents. That is, an -indented Pod block is considered to have a Ivirtual left margin, -determined by the indentation of its opening delimiter. As with Perl 6 -heredocs, the virtual margin treats leading tabs as aligning to tabstops -spaced every C($?TABSTOP // 8) characters. +An indented Pod block is considered to have a Ivirtual left margin, +determined by the indentation of its opening delimiter. +In other words, if a directive is indented from the left margin, the +column at which the first character of its opening delimiter appears is +thereafter considered the first column of the entire block's contents. + +As with Perl 6 heredocs, the virtual margin treats leading tabs as +aligning to tabstops spaced every C($?TABSTOP // 8) characters. + =head2 Pod blocks The content of a document is specified within one or more Dblocks|block. Every Pod block may be declared in any of four forms: + LIdelimited style|#Delimited blocks, LIparagraph style|#Paragraph blocks, LIabbreviated style|#Abbreviated blocks, or LIdeclarator style|#Declarator blocks. The first three forms are all equivalent; the @@ -70,8 +73,8 @@ within a Pod block is treated as ambient material. Typically this would be the source code of the program that the Pod is documenting. Pod parsers still parse this text into the internal representation of the -file (representing it as a CPod6::Block::Ambient block), but renderers -will Iusually ignore such blocks (but see L#Aliases). +file, representing it as a CPod6::Block::Ambient block. Renderers +will Iusually ignore such blocks, but see L#Aliases. In Perl 5's POD format, once a POD directive is encountered, the parser considers everything that follows to be POD, until an explicit C=cut
Re: Smart match isn't on Bool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 03:33 , Moritz Lenz wrote:
In this code:
sub test() { True };
given 0 {
when test() { say OH NOEZ }
}
I don't think it's unreasonable to expect the output to be OH NOEZ.
I think there's a confusion about what given/when is doing. Naïvely(?), I
expect it to be shorthand where the value for when is matched against the
one for given, thus your example would be (pseudocode) if 0 == True and
expecting OH NOEZ *would* be unreasonable.
Is given/when trying to do too many things at once?
- --
brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxUOJsACgkQIn7hlCsL25WPlwCeJKwKQWDl+qaNbJMyAOcZ5UXf
R2EAn1AQBqB5hZIFmqymcaqSSGJdx9GJ
=cmZ6
-END PGP SIGNATURE-
Re: Smart match isn't on Bool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 11:17 , Mark J. Reed wrote: What if you say 'when test($_)'? Or just 'when test'? How do you smart match on a function: call the func with the target as argument and use the return value, or call it without any argument and compare the return value to the target? Does arity matter? Or whether the function is declared to return a Boolean value/called in a Boolean context? As I understand the spec: given expr sets $_ to expr when test() calls test with no argument when test($_) calls test with the topic when testuses the function object test It seems like this leaves $_ in an odd place, no longer really a topic, just a sort of shorthand which is sometimes implied (see for example .foo as calling method foo() of $_) and sometimes not (given/when). when as currently specced seems like it's just a synonym for if. Overgeneralization seems to have left $_ and when in a rather muddy spot. I feel like if the point of given/when is an overly general case statement (as it currently seems to be), then using $_ is a Huffmanization waste (surely $^a is good enough?) and confuses what $_ is supposed to mean, and if the point is to be a general case statement then when expr block should smartmatch expr against $_ instead of evaluating it with $_ available as a shorthand/topic. Thus the confusion in the message that started this thread: most people expect the latter behavior, but are getting the former which feels like a Huffmanization failure in addition to confusing the question of implicit vs. explicit topicalization/$_. (Am I making any sense here? I know what I'm trying to say, but am unsure that I am describing it sensibly.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxURYEACgkQIn7hlCsL25X/4QCfT3xbqtyY9sJ8UvT0VycKqetf nYgAnR5dw7sDNsMj6hSnwHYT90TzFxia =u4Hj -END PGP SIGNATURE-
Re: Smart match isn't on Bool
On Sat, Jul 31, 2010 at 11:47:13AM -0400, Brandon S Allbery KF8NH wrote:
[...], and
if the point is to be a general case statement then when expr block
should smartmatch expr against $_ instead of evaluating it with $_
available as a shorthand/topic.
This is exactly what when expr block does -- it smartmatches
expr against $_. The problem is that there are at least two
interpretations of a true result of expr:
when True { ... }# execute when $_ is exactly True
when foo() { ... } # execute when foo() returns true
It's been decided that the latter is far more useful in general;
there are plenty of ways to express the former that are much
less ambiguous.
Pm
Re: Smart match isn't on Bool
On 2010-07-30, at 4:57 pm, Aaron Sherman wrote:
given False { when True { say True } when False { Say False } default {
say Dairy } }
I don't think it's unreasonable to expect the output to be False.
However, it actually outputs True. Why? Well, because it's in the spec
that way. So... why is it in the spec that way?
Well, if you want to do a boolean test, you'd probably use if instead; but
something that already gives you a Bool, like when time$limit, is likely to
be the result you want to test itself rather than comparing it against $_
(which is likely not to be a Bool).
So Perl is trying to be helpful by doing something useful instead of making the
useful thing much harder at the expense of something that isn't useful anyway.
The catch is that I think that comparing against a boolean IS useful. The fact
that this question keeps coming up, even on the p6l list, seems to demonstrate
that the helpful way isn't completely natural or obvious (at least, not to
everyone).
On 2010-07-31, at 1:33 am, Moritz Lenz wrote:
sub test() { True };
given 0 { when test() { say OH NOEZ } }
I don't think it's unreasonable to expect the output to be OH NOEZ.
It's not unreasonable, especially if that's what you expect. But it's even
more reasonable to expect this to work:
given $something {
when True { say That's the truth! }
when 42 { say Good answer! }
when viaduct { say You guessed the secret word! }
}
In both these examples, the intent is fairly clear from the context. It's
easier to forget that Bools behave differently from other types when you only
have some variable that could be any type:
if $guess ~~ $answer { say Correct! } # hope your question wasn't T/F!
Maybe we can't please everyone, but we can at least try not to displease
anyone. Perl is awfully clever at keeping your eaten ponies, and there is a
way we can have both the helpful syntax and the consistent one:
given $who-knows-what {
when True { say It's a true thing! }
when 42 { say It's numbery! }
whenever timeout() { say Who cares what you say, time's up! }
whenever $override { say Whatever, switching to automatic
override }
}
This way (or something similar) is just as clear when reading something in
context, but also makes it clear(er) when the context doesn't help (like 'when
who-knows()') or when you reasonably expect more consistent matching. [Or do I
mean whenever??]
-David
Re: Smart match isn't on Bool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 12:56 , David Green wrote: a boolean IS useful. The fact that this question keeps coming up, even on the p6l list, seems to demonstrate that the helpful way isn't completely natural or obvious (at least, not to everyone). Thank you; *that* is the real point I was trying to make. That, and that special-casing one particular type is *not* actually helpful; it means I must remember a special case, when one of the goals of Perl 6 was supposedly to eliminate all the special cases in Perl 5, helpful or no. (Maybe make it more concrete? There's another discussion going on about how a .. b should behave. Arguably it is an argument about helpfulness versus purity... and the decision is clearly in the direction of purity. Why, then, is *this* in the direction of helpfulness at the expense of purity? It's just another arbitrary decision I have to remember instead of a general rule.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxUX4UACgkQIn7hlCsL25X1DACeIQryF49L/90FRDuYUQraRlW/ 7UEAniG4lw5FhhnfNIDKqg+QZTolzFlc =DDaL -END PGP SIGNATURE-
Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
Here's a case where a bug report stumped me and made me feel I'm
missing something:
http://rt.perl.org/rt3/Ticket/Display.html?id=69260
I'll give a somewhat summarized version of the above page, which
gradually turns into a set of questions and not enough answers:
* It has been decided that attribute slots of the type $!foo are only
allowed *syntactically* within the class block that declares them.
(The exception to this, I guess, is the 'trusts' directive.) But this
means that something like this anonymous method
my $reveal-foo = method { say $!foo }
isn't allowed. I think that's good, because it would provide a very
easy way to break encapsulation of an object; just call
$object.$reveal-foo() on it.
* Today we discovered that it's possible to break encapsulation by
detaching a method from an object of one class, and calling that
method on an object of another class. Which means that breaking the
encapsulation of a foreign class is as easy as creating a custom class
with all of the same private attributes, and with a method to print
(or otherwise reveal) them.
* It is my feeling that such encapsulation-breakage shouldn't be
allowed. Do you agree, p6l?
* If it isn't allowed, which of the two steps is disallowed?
*Detaching* a method containing references to private accessor slots
(thereby extending the syntactic restriction of no private accessors
outside of the class block), or *attaching* an anonymous method to an
object belonging to a different class than the one from which it was
detached (thereby by necessity having to complicate anonymous methods
somewhat)?
I only see those three options:
a. Allow this form of encapsulation breakage.
b. Disallow detaching of certain methods.
c. Disallow attaching of certain anonymous methods.
I must confess I don't particularly like either option. I'm by no
means an OO expert. It would be interesting to hear your views on
this.
// Carl
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:23 , Carl Mäsak wrote: a. Allow this form of encapsulation breakage. b. Disallow detaching of certain methods. c. Disallow attaching of certain anonymous methods. I must confess I don't particularly like either option. I'm by no means an OO expert. It would be interesting to hear your views on this. The whole concept of detaching and attaching methods seems suspect to me; in particular, attaching a method from a class not declared to be related reeks of monkey patching. As such, I'd only allow it when monkey patching is enabled. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxUbRAACgkQIn7hlCsL25URzACfeQwHqlQWs4IL6RdSCkkI1inr BasAoM0LyLl19dylqoOcMjCfk3kvC9j3 =FyAF -END PGP SIGNATURE-
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
On Sat, Jul 31, 2010 at 08:23:29PM +0200, Carl Mäsak wrote:
* It has been decided that attribute slots of the type $!foo are only
allowed *syntactically* within the class block that declares them.
(The exception to this, I guess, is the 'trusts' directive.) But this
means that something like this anonymous method
my $reveal-foo = method { say $!foo }
isn't allowed. I think that's good, because it would provide a very
easy way to break encapsulation of an object; just call
$object.$reveal-foo() on it.
There is no $!foo. There is only $!Class::foo, and $!foo is a lexically
scoped alias to it. This is necessary to allow privacy from your children
to work:
class Class {
has $!foo; # the mere existance of $!foo is an implementation detail
}
class SubClass is Class {
has $!foo; # hey why doesn't this work?
}
So $reveal-foo can't be defined because $!foo isn't even in scope.
* Today we discovered that it's possible to break encapsulation by
detaching a method from an object of one class, and calling that
method on an object of another class. Which means that breaking the
encapsulation of a foreign class is as easy as creating a custom class
with all of the same private attributes, and with a method to print
(or otherwise reveal) them.
Calling such methods should fail, because the $!OtherClass:: attributes
don't exist even if the shortnames are the same.
* It is my feeling that such encapsulation-breakage shouldn't be
allowed. Do you agree, p6l?
It's not.
* If it isn't allowed, which of the two steps is disallowed?
*Detaching* a method containing references to private accessor slots
(thereby extending the syntactic restriction of no private accessors
outside of the class block), or *attaching* an anonymous method to an
object belonging to a different class than the one from which it was
detached (thereby by necessity having to complicate anonymous methods
somewhat)?
I only see those three options:
a. Allow this form of encapsulation breakage.
b. Disallow detaching of certain methods.
c. Disallow attaching of certain anonymous methods.
I must confess I don't particularly like either option. I'm by no
means an OO expert. It would be interesting to hear your views on
this.
Perl philosophy has always been it's not that I have a shotgun, you just
weren't invited, so stay out of my living room. I don't see any reason for
Perl 6 to break with this - encapsulation should be about helping the
programmer, not helping the sysadmin maintain system security.
-sorear
signature.asc
Description: Digital signature
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: On 7/31/10 14:23 , Carl Mäsak wrote: a. Allow this form of encapsulation breakage. b. Disallow detaching of certain methods. c. Disallow attaching of certain anonymous methods. I must confess I don't particularly like either option. I'm by no means an OO expert. It would be interesting to hear your views on this. The whole concept of detaching and attaching methods seems suspect to me; in particular, attaching a method from a class not declared to be related reeks of monkey patching. As such, I'd only allow it when monkey patching is enabled. Methods are just functions. $object.$method(@args) is simply sugar for $method($object, @args) so disallowing it is not quite that simple. -sorear signature.asc Description: Digital signature
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:38 , Stefan O'Rear wrote: On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: The whole concept of detaching and attaching methods seems suspect to me; in particular, attaching a method from a class not declared to be related reeks of monkey patching. As such, I'd only allow it when monkey patching is enabled. Methods are just functions. $object.$method(@args) is simply sugar for $method($object, @args) so disallowing it is not quite that simple. That would seem to make it worse (type conformability on the first positional parameter; does declaring a method not implicitly declare the type of its positional parameter to be the class that declared it, or a subclass thereof?) --- but I think you addressed that in your other response. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkxUbtAACgkQIn7hlCsL25WOkwCgvq2SevYoVtGWSio0q7lVDxWy Qt8AmM8FijA51vxGjylUwuCq1+zpF9k= =XroU -END PGP SIGNATURE-
Re: Smart match isn't on Bool
On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
It's not unreasonable, especially if that's what you expect.
But it's even more reasonable to expect this to work:
given $something {
when True { say That's the truth! }
when 42 { say Good answer! }
when viaduct { say You guessed the secret word! }
}
I'm not so sure about this. There's an argument to be made that
the Cwhen 42 and Cwhen viaduct cases should never be reachable,
since both C42 and Cviaduct are considered true values...
... unless you want Cwhen True to do a value-and-type check,
in which case it doesn't exactly follow the pattern for smartmatching
of the other builtin types (which only check value equivalence,
not type equivalence).
Pm
S26 broken link
Hi, The link to the S26 Synopsys on http://perlcabal.org/syn/ points to http://perlcabal.org/syn/S26.html which is a broken link - would it be possible to fix this? My apologies if this is the wrong place to ask this question. Best regards, -- Offer Kaye
Re: Smart match isn't on Bool
HaloO,
On Saturday, 31. July 2010 18:56:47 David Green wrote:
On 2010-07-31, at 1:33 am, Moritz Lenz wrote:
sub test() { True };
given 0 { when test() { say OH NOEZ } }
I don't think it's unreasonable to expect the output to be OH NOEZ.
How does this relate the given to the when? If I get you right the
given is completely ignored and the truth of test() gives OH NOEZ.
I think the given must determine the result.
It's not unreasonable, especially if that's what you expect. But it's even
more reasonable to expect this to work: given $something {
when True { say That's the truth! }
when 42 { say Good answer! }
when viaduct { say You guessed the secret word! }
}
Here I expect the $something to *select* one of the alternatives.
It can't be that a literal True ignores the given and just executes
the block.
In both these examples, the intent is fairly clear from the context. It's
easier to forget that Bools behave differently from other types when you
only have some variable that could be any type: if $guess ~~ $answer { say
Correct! } # hope your question wasn't T/F!
Maybe we can't please everyone, but we can at least try not to displease
anyone. Perl is awfully clever at keeping your eaten ponies, and there is
a way we can have both the helpful syntax and the consistent one:
given $who-knows-what {
when True { say It's a true thing! }
when 42 { say It's numbery! }
whenever timeout() { say Who cares what you say, time's up! }
whenever $override { say Whatever, switching to automatic
override }
}
Am I getting your intention to be that when honors the given and whenever just
checks truth? Couldn't we use if for this? That would avoid the new keyword.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Smart match isn't on Bool
On Sat, Jul 31, 2010 at 12:56 PM, David Green david.gr...@telus.net wrote:
On 2010-07-30, at 4:57 pm, Aaron Sherman wrote:
given False { when True { say True } when False { Say False }
default { say Dairy } }
I don't think it's unreasonable to expect the output to be False.
However, it actually outputs True. Why? Well, because it's in the spec
that way. So... why is it in the spec that way?
Well, if you want to do a boolean test, you'd probably use if instead;
I'm sorry, I didn't know I'd sent this message to the python-language list
;-)
Seriously though, I don't want there's more than one way to do it to be an
excuse for redundancy, but on the other hand, it's rather odd for a
rationale in Perl to be there's already a way to do that rather than the
intuitiveness of the feature, even when it's only situational.
It's also quite useful for testing truth as a fallback:
given $_ {
when $motor-oil { say mmm syrupy! }
when $methane { say dangerou! }
when $jet-fuel { say I can haz skaiz? }
when /crude/ { say refine it first }
when False { say Sorry, no petroleum products }
when True { say Unknown petroleum products }
default { say Unpossible! }
}
but something that already gives you a Bool, like when time$limit, is
likely to be the result you want to test itself rather than comparing it
against $_ (which is likely not to be a Bool).
My problem with that is that it's a really odd use of given/when, and given
the implicit smart-match, it doesn't make much sense. Now, to slightly
backtrack, I do agree that there should be at least one way to do something,
and if that were the only way to perform independent tests within a given,
I'd agree. Thankfully, it's not:
given $_ {
when /clock/ { say clock }
if time $limit { say tick }
default { say tock }
}
And the really nice thing about that usage is that you immediately see that
we're not testing time with respect to $_, but with respect to $limit. If
you use when, that's left rather confusingly ambiguous unless you know that
boolean values are a special case.
So Perl is trying to be helpful by doing something useful instead of making
the useful thing much harder at the expense of something that isn't useful
anyway.
Well, since it's easy to do both, as demonstrated above, I think we can
agree that we've satisfied the first rule.
But given isn't very interesting compared to smart matching in general, and
that's where:
$foo ~~ True
Really does seem to me as a very intuitive question, and that question isn't
is the RHS true?
The catch is that I think that comparing against a boolean IS useful. The
fact that this question keeps coming up, even on the p6l list, seems to
demonstrate that the helpful way isn't completely natural or obvious (at
least, not to everyone).
Agreed.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
Re: Smart match isn't on Bool
On Sat, Jul 31, 2010 at 04:29:00PM -0400, Aaron Sherman wrote:
My problem with that is that it's a really odd use of given/when, and given
the implicit smart-match, it doesn't make much sense. Now, to slightly
backtrack, I do agree that there should be at least one way to do something,
and if that were the only way to perform independent tests within a given,
I'd agree. Thankfully, it's not:
given $_ {
when /clock/ { say clock }
if time $limit { say tick }
default { say tock }
}
The problem with this formulation is that a successful 'when'
exits the block, while a successful 'if' does not. This is one
of the significant differences between 'if' and 'when'.
So in the above, the default say tock is executed regardless
of the result of the time $limit test.
Well, since it's easy to do both, as demonstrated above, I think we can
agree that we've satisfied the first rule.
It's not as easy to do both as your example seems to illustrate.
Perhaps you can provide a better example that does illustrate
testing for a condition that also results in exiting the Cgiven
block?
Pm
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
Carl (), sorear ():
* It has been decided that attribute slots of the type $!foo are only
allowed *syntactically* within the class block that declares them.
(The exception to this, I guess, is the 'trusts' directive.) But this
means that something like this anonymous method
my $reveal-foo = method { say $!foo }
isn't allowed. I think that's good, because it would provide a very
easy way to break encapsulation of an object; just call
$object.$reveal-foo() on it.
There is no $!foo. There is only $!Class::foo, and $!foo is a lexically
scoped alias to it. This is necessary to allow privacy from your children
to work:
class Class {
has $!foo; # the mere existance of $!foo is an implementation detail
}
class SubClass is Class {
has $!foo; # hey why doesn't this work?
}
So $reveal-foo can't be defined because $!foo isn't even in scope.
Thanks, that's an excellent way to explain this. It also provides the
answer to this whole thread:
class A {
has $!x;
}
class B {
has $!x;
method foo { say $!x } # really 'say $!B::x'
}
my $b-foo = B.^can(foo);
A.new( :x(42) ).$b-foo(); # doesn't work, can't access $!B::x from A
This solution is a fourth one that I didn't see, and the first one that I like:
d. Disallow illegally accessing a private attribute slot that isn't yours.
It also incidentally answers a random thought I had today after
posting my original email: Hey, jnthn talked about implementing
attribute accesses as array accesses rather than hash accesses -- how
the heck will that work if methods can be detached and re-attached to
objects of a different class? With $!foo really meaning
$!MyClass::foo it makes a lot more sense.
// Carl
Re: Smart match isn't on Bool
Brandon S Allbery KF8NH wrote:
I think there's a confusion about what given/when is doing. Naïvely(?), I
expect it to be shorthand where the value for when is matched against the
one for given, thus your example would be (pseudocode) if 0 == True and
expecting OH NOEZ *would* be unreasonable.
Is given/when trying to do too many things at once?
I would prefer if given/when was nothing more than an alternate syntax for
if/then that does comparisons. That is, these would be equivalent:
given $foo {
when $bar {...}
when $baz {...}
default {...}
}
if $foo eqv $bar {...}
else if $foo eqv $baz {...}
else {...}
On the other hand, Perl 6 has multiple equality comparison operators, eqv, eq,
==, ===, etc, and hence ~~ semantics instead of eqv may seem to make some sense,
though I think that would cause more problems.
So I think if given-when just used eqv semantics and then users explicitly
coerced their arguments instead, that might be best. For example, in the
general case, say they want numeric semantics and the arguments aren't
necessarily already numbers:
given +$foo {
when +$bar {...}
when +$baz {...}
default {...}
}
All this being said, I really do *not* like the idea of saying Bool is just a
subset of Int as it seems to be. Bool should be disjoint from every other
common type like Int/Str/etc instead.
Asking False eqv 0 should be false, though either False eqv ?0 or +False
eqv 0 being true is okay.
If people want ~~ semantics, let them ask for it explicitly, such as with:
given $foo {
when ~~ $bar {...}
when ~~ $baz {...}
default {...}
}
-- Darren Duncan
Re: Smart match isn't on Bool
Darren (): All this being said, I really do *not* like the idea of saying Bool is just a subset of Int as it seems to be. Bool should be disjoint from every other common type like Int/Str/etc instead. I don't know whence you got the impression that Bool is a subtype. Bool is an enumeration type, which makes True and False distinct objects both of which aren't (but instead wrap) their corresponding Int values. Asking False eqv 0 should be false, though either False eqv ?0 or +False eqv 0 being true is okay. All those are as you want them. // Carl
Re: Smart match isn't on Bool
On 2010-07-31, at 12:47 pm, Patrick R. Michaud wrote:
On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
given $something {
when True { say That's the truth! }
when 42 { say Good answer! }
when viaduct { say You guessed the secret word! }
}
I'm not so sure about this. There's an argument to be made that the Cwhen
42 and Cwhen viaduct cases should never be reachable, since both C42
and Cviaduct are considered true values...
Oops, no, I don't want it to do a value-and-type-check. I guess in this case
the when True could be moved last, but it's still not a great example.
Aaron's example with when True as a fallback at the end of a block is better.
[re Aaron's example with: if time $limit { say tick } ]
The problem with this formulation is that a successful 'when' exits the
block, while a successful 'if' does not. This is one of the significant
differences between 'if' and 'when'.
It's possible to break out with an explicit leave or succeed. Slightly
less elegant, but still straightforward and it doesn't require any exceptions.
And it makes the different tests look different.
Meanwhile, from one of your earlier replies:
The problem is that there are at least two interpretations of a true result
of expr:
when True { ... }# execute when $_ is exactly True
when foo() { ... } # execute when foo() returns true
Except that the latter 'when' isn't executed when foo() returns true; only when
it returns True! Well, maybe by true you meant Bool::True -- after all,
that's a comment, not code; or maybe you were even thinking True and the
lowercase T was a typo. At any rate, it confused me for several moments.
-David
Re: Smart match isn't on Bool
On 2010-07-31, at 11:38 am, Brandon S Allbery KF8NH wrote: Thank you; *that* is the real point I was trying to make. That, and that special-casing one particular type is *not* actually helpful; it means I must remember a special case, when one of the goals of Perl 6 was supposedly to eliminate all the special cases in Perl 5, helpful or no. I don't know if it was supposed to eliminate *all* special cases, but I'm happy that it eliminates lots of them. I think some exceptions can be justified if it's a way humans naturally think (though it may be exceptional to a machine), or if there is some construct that isn't useful at all (if it has no legitimate use, why not use that syntax to mean something else? — but in that case, the trade-off is remembering an exception [of something you'd never want to do anyway] versus remembering extra syntax to do the other thing). I'm even prepared to accept exceptions for something that isn't meaningless. (My no-exception rule has exceptions!) 0 but true in P5 is a good example. The exception is that it suppresses a warning, and that warning isn't totally useless; there *could* be a situation where you accidentally get that exact string when you wanted a pure number, but it's unlikely *and* the warning doesn't actually do anything — the code works the same way with or without the warning. $foo ~~ True is different. It may be less useful than the exception in that it's less frequent; but it still has a legitimate (non-exceptional) meaning. A bear of little memory like me will see when timeout() but instead of internalising P6 handles when $bool differently from when $anything-else, I will take away Perl DWIM. And then I'll expect it to DWIM in $true-false-queston ~~ $bool-answer. -David
Re: Smart match isn't on Bool
On 2010-07-31, at 5:55 pm, Darren Duncan wrote:
I would prefer if given/when was nothing more than an alternate syntax for
if/then that does comparisons.
And that breaks out of its enclosing scope.
On the other hand, Perl 6 has multiple equality comparison operators, eqv,
eq, ==, ===, etc, and hence ~~ semantics instead of eqv may seem to make some
sense, though I think that would cause more problems.
Yes, since if you've got a whole list of when's to compare against, it's not
unlikely that they're different types of things, so ~~ would be more useful
than === or eqv. Of course, given the bool-exception spec, one workaround is
when $_ eqv $x. But I was already thinking of a more elegant possibility.
Using when ~~ $bar is problematic because Perl couldn't know whether to
expect a term or an operator after when. But what if ~~ were merely the
default operator, and you could override it?
given $foo :using( [===] ) { ... }
given $foo :using(binary-func) { ... }
such that any 'when's inside the block use ===, or the provided
operator/function instead, of ~~. Actually, the option should be on 'when', so
that above line would mean something like:
given $foo { my when = when.assuming( :using( [===] )) ... }
...er, except 'when' isn't a function, so that doesn't actually work. Anyway,
the idea is that there could be some way to set the default operation to use
for 'when' in a given scope.
Here's another thought: 'when' is different from 'if' in two ways. One is that
it does an implicit comparison on the topic; the other is that it breaks out of
its enclosing block. Maybe the comparison could be indicated another way,
leaving 'when' and 'if' to differ in breaking out or not. Suppose a colon
indicated compare against $_ using ~~, or whatever the default operation is
(we're not using the colon for anything else, are we?!?):
when $a $b { ... }
if $foo.does($bar) { ... }
when: /foo/ { ... }
if: .defined { ... }
-David
Re: Smart match isn't on Bool
On 2010-07-31, at 2:00 pm, TSa (Thomas Sandlaß) wrote:
On Saturday, 31. July 2010 18:56:47 David Green wrote:
given $who-knows-what {
when True { say It's a true thing! }
# ^--oops, this still shouldn't come first!
when 42 { say It's numbery! }
whenever timeout() { say Who cares what you say, time's up! }
whenever $override { say Whatever, switching to automatic override }
}
Am I getting your intention to be that when honors the given and whenever
just checks truth? Couldn't we use if for this? That would avoid the new
keyword.
Right; except that whenever still breaks out, unlike if. I like having a
new keyword because it makes it perfectly clear that whenever $foo does not
mean the same thing as when $foo (though it suggests something related by
having when in the name).
However, as suggested in my previous message, we could also distinguish them
with something like when vs. when:. The colon there isn't quite a new
keyword, but it still is something to make the distinction visible. Plus it
allows us to extend the same useful behaviour to if vs if:.
-David
Re: Smart match isn't on Bool
David Green wrote:
snip
given $foo :using( [===] ) { ... }
given $foo :using(binary-func) { ... }
snip
I do like the general principle of what you're proposing, that one can customize
the semantics of how given-when picks options. But I have no further details to
suggest at this time. -- Darren Duncan
Unwanted warnings (was Re: Something wrong with str.reverse)
On 2010-06-18, at 10:48 am, Larry Wall wrote: If you make it the default to not warn, then the people who really need the warnings will almost never turn them on. If you make it default to warn, then people will have to turn off the warnings forever. Doesn't the site-policy policy help here? I could turn certain warnings off in my policy file instead of having to turn them off in every new program. Of course, such settings should arguably apply per-project or per-person-who-wrote-the-code; so maybe any file should adopt settings from a .policy.pm in its own dir, if there is one. Actually, no, it should probably use Some::Policy, but there should be a way for a policy module to identify itself as such so Perl knows whether it should override or be overridden by other policy modules. Also, certain warnings could be suppressed if the code is compiled, on the grounds that compiling the code is a way of saying, I'm finished with this, it all works and I don't expect to be changing it any more. Library modules will presumably be compiled, so that would prevent warnings from code you didn't even write. (Although if a module you installed from somewhere else is full of warnings, maybe you do want to know, hm) 0123; # warns 0123; # ok!# suppresses this warning here 0123; # OK!# suppresses this warning from now on Though I'm hesitant to use comment syntax for that. A statement prefix might be more appropriate. We've currently reserved quietly for simple run-time warning suppression, but that's kinda long, and not defined for compile-time warnings yet. Admittedly, it would be rather amusing to have to shout at Perl 6 to make it shut up: my $x = QUIETLY 0123; Call it sh? (for suppression handler, of course) Using comments doesn't feel quite right to me either, but on the other hand, almost anything else seems distracting for something that is supposed to avoid drawing attention. Maybe a statement suffix? -David
Re: Unwanted warnings (was Re: Something wrong with str.reverse)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 23:26 , David Green wrote: On 2010-06-18, at 10:48 am, Larry Wall wrote: 0123; # warns 0123; # ok! # suppresses this warning here 0123; # OK! # suppresses this warning from now on Though I'm hesitant to use comment syntax for that. A statement prefix might be more appropriate. We've currently reserved quietly for simple run-time warning suppression, but that's kinda long, and not defined for compile-time warnings yet. Admittedly, it would be rather amusing to have to shout at Perl 6 to make it shut up: my $x = QUIETLY 0123; Call it sh? (for suppression handler, of course) I am amusedly imagining borrowing PLEASE from Intercal. :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxU96sACgkQIn7hlCsL25XZ3QCdHjdXi9XgbyxGsOeqM6rzoK6p kzsAoKlbd+CgLIfNhTpzcqP99nTIkKsh =ZHRo -END PGP SIGNATURE-
Re: series operator issues
On 2010-07-23, at 4:25 am, Moritz Lenz wrote: I'm still not convinced. [that there should be a special index variable] Yes, it would be convient, but I've yet to see a non-contrived example where it's actually necessary, and which can't be implemented trivially with other Perl 6 tools. I see it like the situation with self. Sure, it's not necessary, it's easy to specify it explicitly, and so on, but nevertheless it feels somehow too heavy not to deserve some sugar. My own first instinct was to use map or a loop to produce those a series of squares or factorials or whatever... on the other hand, the series operator does naturally come to mind when you're thinking about a series! The series code is already rather complex (and thus slow), and having to add introspection to find out whether the production code object accepts a named parameter 'i' is not going to help in any way. I do agree that having a special named parameter isn't the way to do it, though. What if there were a special keyword instead? (Again, like the situation with 'self'.) If you used the word index (or counter or n?) in a loop or series or anywhere else suitable, it could be detected at compile-time. It shouldn't be any worse than making your own counter, and might even be better (since Perl needs its own counter for some loops, maybe it could make it available rather than having to define one of your own as well). -David
