Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
Carl Mäsak wrote: * It is my feeling that such encapsulation-breakage shouldn't be allowed. Do you agree, p6l? Time may proof me wrong, but I think it's not such a big issue. Note that encapsulation can be broken in many ways already, wither with MONKEY_TYPING or by using introspection techniques (which aren't fully specced yet, but they *will* exist. In case of doubt you can just parse .perl output). * 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)? There's a third possiblity - $!foo being bound to the $!foo attribute of the lexically enclosing class at compile-time. So that re-attaching methods make them still refer to the old attribute. Not sure if it's a good idea, just food for thought. Cheeers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S26 broken link
Hi, Offer Kaye wrote: 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? I't not that easy, because we currently don't have tool to turn p6doc into HTML. I can remove the link for now, if it's a concern to you. My apologies if this is the wrong place to ask this question. For infrastructural discussions, the perl6-compiler might be better suited, but we're not picky in here (I hope :-) Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Perl 6 User Documentation
Hi, Offer Kaye wrote: Following the release of Rakudo Star I've been playing around with learning Perl 6 and noticed a distinct lack of user-facing documentation. After some IRC chats with pmichaud++ I thought it would be a good idea if I got the ball rolling, assuming of course it doesn't reach a sharp incline, roll back and squash me. I appreciate your effort, and will help wherever I can. Attached are a 3 very initial (skeletal in nature) Perl 6 .pod documents, based loosely on the Perl 5 documentation. It is my understanding that currently there is no P6-Pod reader e.g. perl6doc so these are actually written in P5-POD, but the intent is to eventually of course translate them to P6-Pod. Agreed. My purpose is to get very initial feedback, see if this is the right direction to go at all, get some thoughts on basic terminology, stuff like that. For example: 1. Use P5 POD or insist on P6 Pod? p5pod is good for now. 2. Is it Perl 6 or just Perl? Currently it's perl6 but will it be just perl eventually? I'd use 'Perl 6' in the title, and then refer to it as 'Perl' in the body of the document. 3. Can I just rename S26.pod to perl6pod.pod and be done with it? :) S26.pod is intended as a reference (but quite readable, if I remember correctly). It's certainly a good start, maybe at some later point we might want to have something more tutorial-style. For what it's worth, there's an initial effort to get some documentation going in http://svn.pugscode.org/pugs/docs/u4x/ (look in the README for the vision, and documentation/ for some existing POD files). The rendered documents are at http://doc.perl6.org/. Certainly needs a better index file and some pre-text, but it's a start. You're welcome to add your stuff there (ping me or other Perl 6 hackers about a commit bit on #perl6), or start your own repo somwhere (though I'd prefer it not to have too much fragmentation, so if you do, just hand out commit bits liberally, and copy the u4x stuff over to the new repo. masak, is that OK for you?). Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Smart match isn't on Bool
On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington jonat...@jnthn.net wrote: No, given-when is smart-matching. The RHS of a smart-match decides what happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going to do +True and thus match. OK, but what about 0 ~~ True? That's what started this thread, extricated from the complicating trappings of given/when. Right now, (anything ~~ True) is true, and IMHO that's a misfeature; it's at least surprising. I'd expect (anything ~~ True) to be synonymous with ?(anything): true only if the LHS boolifies to true. By the same token, (anything ~~ False) would be synonymous with !?(anything). I don't think the capability to use an arbitrary block/sub/method/boolean as a when condition should trump the intuitiveness of smartmatching. Instead of overloading the smartmatch, I think we need a different way of specifying a condition that isn't meant to be compared to the topic, and so doesn't invoke smartmatching at all: it's just evaluated in Boolean context as-is. I like the suggestion of whenever for that; it has the no matter what sense that goes with ignoring the topic. -Mark -- Mark J. Reed markjr...@gmail.com
Re: Smart match isn't on Bool
On Mon, Aug 2, 2010 at 2:02 PM, Mark J. Reed markjr...@gmail.com wrote:
On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington jonat...@jnthn.net
wrote:
No, given-when is smart-matching. The RHS of a smart-match decides what
happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going to
do +True and thus match.
OK, but what about 0 ~~ True? That's what started this thread,
extricated from the complicating trappings of given/when. Right now,
(anything ~~ True) is true, and IMHO that's a misfeature; it's at
least surprising. I'd expect (anything ~~ True) to be synonymous with
?(anything): true only if the LHS boolifies to true. By the same
token, (anything ~~ False) would be synonymous with !?(anything).
Again, sorry for starting a long thread (I seem to do that, and I
swear I'm not trying... just pointing out the surprises I run into as
I try to code).
I want to stress that what you've said above is kind of moot: the spec
says that ~~True gets a parser warning, so we can consider that
deprecated. The only usage we're supporting, here, is a Bool value
stored in a variable or otherwise generated.
I would argue that that's even worse. For example:
my Bool $trash-status = take-out-the-trash();
... some time later ...
my Bool $dishes-status = wash-the-dishes();
if !$dishes-status $dishes-status ~~ $trash-status {
say No chores this week!;
}
Of course, that's a bug, but imagine the poor maintenance programmer
that tries to figure out what's going on. I feel for him/her. The only
advantage he/she will have is that this is likely to be so common an
error that they'll quickly learn to look for it first when
smart-matching is involved :-/
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
Re: Smart match isn't on Bool
HaloO,
On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington jonat...@jnthn.net
wrote:
No, given-when is smart-matching. The RHS of a smart-match decides what
happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going
to do +True and thus match.
OK, but what about 0 ~~ True? That's what started this thread,
extricated from the complicating trappings of given/when. Right now,
(anything ~~ True) is true, and IMHO that's a misfeature; it's at
least surprising. I'd expect (anything ~~ True) to be synonymous with
?(anything): true only if the LHS boolifies to true. By the same
token, (anything ~~ False) would be synonymous with !?(anything).
Note also that ($anything ~~ foo()) just throws away $anything. I would
opt for a regularization of the smart match table. First of all the
generic scalar rule should coerce the LHS to the type of the RHS and
then use === on them. This is how the Any ~~ Set case is specced. The
cases Stringy and Numeric fall out naturally from this definition. The
Bool case should become a special case just like Stringy and Numeric. The
auto-invocation of Callable is a good thing but the fact that the return
value is not subject to the generic scalar case is a misfeature. That is
we loose:
given 42
{
when foo() {...}
when bar() {...}
when baz() {...}
}
which could mean to execute that block whose controlling sub complies
with the given and not the one that returns True first. Note that this
style is particularly usefull with given True. But then we sort of have
the coercing the wrong way around because the idea is to check the
return value in boolean context not coercing the True to whatever the
type of the return value is. BTW, how is the case with a unary sub written?
Could someone please give a rational for the interspersing technique
given $anything
{
when $one {...}
when two() {...}
when $three {...}
}
where two() returning a true value prevents the case $three. And if it
is considered usefull I support the whenever proposal because different
things should look different. BTW, would
given $anything
{
when $one {...}
if two() {...}
else { when $three {...} }
}
still smart match $anything with $three? Or is the topic the return
value of two() at that point?
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: S26 broken link
Moritz Lenz wrote: Offer Kaye wrote: The link to the S26 Synopsis 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? I't not that easy, because we currently don't have tool to turn p6doc into HTML. I can remove the link for now, if it's a concern to you. And a major reason why we don't have a p6doc-to-HTML converter is because there are still some outstanding issues with the p6doc spec: it's not ready for prime time, as it were. IIRC, the biggest unresolved issues involved the code-sensitive documentation features: getting a pod6 parser to read perl code and extract appropriate values on the one hand, vs. safety concerns about its ability to _run_ perl code on the other. -- Jonathan Dataweaver Lang
Re: Natural Language and Perl 6
Jason (): No specific tool is best suited for natural language processing. There was apparently a time in which everyone thought that a formal grammar could clearly define any natural language, but I don't think anyone succeeded at creating a complete formal grammar for any language other than something like Esperanto. Even Esperanto is about on the same level of complexity as your regular Indo-European language. Sure, the word-formation is more regular, but the freedom in creating sentences with non-obvious antecedents and all manner of ambiguity, is just as large as in any national language. Now, had you said Lojban, I'd have believed you. :) // Carl
Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another
Carl (), Moritz ():
* 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)?
There's a third possiblity - $!foo being bound to the $!foo attribute of
the lexically enclosing class at compile-time. So that re-attaching
methods make them still refer to the old attribute. Not sure if it's a
good idea, just food for thought.
That's indeed what Stefan proposed as well, and what I currently
believe to be the right way of looking at this. The fact that you
don't mention an error condition in connection to the accessing of the
old attribute makes me realize yet another thing:
class Parent { has $!a; method foo { say $!a } }
class Child is Parent { has $!a }
my $child = Child.new( :a(42), Parent{ :a(5) } );
my $parent-foo = Parent.^can('foo');
$child.$parent-foo(); # works, prints 5\n
Or, in words, just because one detaches/re-attaches a method doesn't
automatically mean that private attribute accesses result in an error.
Specifically, they don't in child classes.
// Carl
Re: Natural Language and Perl 6
This is getting more and more off topic, but if you want some lojban pasers, start at http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers -y On Mon, Aug 2, 2010 at 3:58 PM, Carl Mäsak cma...@gmail.com wrote: Jason (): No specific tool is best suited for natural language processing. There was apparently a time in which everyone thought that a formal grammar could clearly define any natural language, but I don't think anyone succeeded at creating a complete formal grammar for any language other than something like Esperanto. Even Esperanto is about on the same level of complexity as your regular Indo-European language. Sure, the word-formation is more regular, but the freedom in creating sentences with non-obvious antecedents and all manner of ambiguity, is just as large as in any national language. Now, had you said Lojban, I'd have believed you. :) // Carl
Re: Natural Language and Perl 6
On Sun, Aug 1, 2010 at 6:46 AM, Timothy S. Nelson wayl...@wayland.id.auwrote: Hi. I'm wondering if any thought has been given to natural language processing with Perl 6 grammars. Yes. ;) -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
