Re: Meditations on a Loop
Larry Wall larry-at-wall.org |Perl 6| wrote:
And since the when modifier counts as a conditional, you can rewrite
grep Dog, @mammals
as
$_ when Dog for @mammals;
So perhaps will see a lot of subtypes used this way:
subset Odd if Int where { $_ % 2 };
@evens = ($_ * 2 when Odd for 0..*);
@primes = do $_ if prime($_) for 1..100;
becomes
@primes = $_ when prime($_) for 1..100;
?
Not sure that is any better.
Re: Meditations on a Loop
On Thu, May 21, 2009 at 11:25 PM, John M. Dlugosz
2nb81l...@sneakemail.com wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
And since the when modifier counts as a conditional, you can rewrite
grep Dog, @mammals
as
$_ when Dog for @mammals;
So perhaps will see a lot of subtypes used this way:
subset Odd if Int where { $_ % 2 };
�...@evens = ($_ * 2 when Odd for 0..*);
@primes = do $_ if prime($_) for 1..100;
becomes
@primes = $_ when prime($_) for 1..100;
?
Not sure that is any better.
subset Prime of Int where { prime($_) }
@primes = do $_ when Prime for 1..100;
But yes, something does get lost when you have to explicitly pass $_
into a function; its topical nature gets degraded. Back when .prime
was shorthand for prime $_, this wasn't a big deal; now, with the
fact that you'd somehow have to add a prime method to Int before you
could reliably say .prime, it's a bit more of a problem.
--
Jonathan Dataweaver Lang
Re: Meditations on a Loop
Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu: @primes = do $_ if prime($_) for 1..100; becomes @primes = $_ when prime($_) for 1..100; you gained one stroke, it's certainly better... I think it's time to play golf with Perl 6 already ;) jokes aside, $_ when prime($_) looks more natural than do $_ if prime($_) daniel
Re: Meditations on a Loop
Daniel Ruoso wrote:
Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu:
@primes = do $_ if prime($_) for 1..100;
becomes
@primes = $_ when prime($_) for 1..100;
you gained one stroke, it's certainly better... I think it's time to
play golf with Perl 6 already ;)
jokes aside, $_ when prime($_) looks more natural than do $_ if
prime($_)
Yes and:
@primes = 1..100.grep: { prime($^n) };
Is actually vaguely, like, readable AND two characters shorter than the
best you've managed so far.
Jonathan
Re: Meditations on a Loop
On Fri, 22 May 2009, Jonathan Worthington wrote:
Daniel Ruoso wrote:
Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu:
@primes = do $_ if prime($_) for 1..100;
becomes
@primes = $_ when prime($_) for 1..100;
you gained one stroke, it's certainly better... I think it's time to
play golf with Perl 6 already ;)
jokes aside, $_ when prime($_) looks more natural than do $_ if
prime($_)
Yes and:
@primes = 1..100.grep: { prime($^n) };
Is actually vaguely, like, readable AND two characters shorter than the best
you've managed so far.
Oh, if we're looking for readability, I'd look for:
1..100.grep: { prime($^n) } == @primes;
It's longer, though :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Meditations on a Loop
On Fri, May 22, 2009 at 5:34 AM, Timothy S. Nelson
wayl...@wayland.id.au wrote:
On Fri, 22 May 2009, Jonathan Worthington wrote:
Daniel Ruoso wrote:
Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu:
�...@primes = do $_ if prime($_) for 1..100;
becomes
�...@primes = $_ when prime($_) for 1..100;
you gained one stroke, it's certainly better... I think it's time to
play golf with Perl 6 already ;)
jokes aside, $_ when prime($_) looks more natural than do $_ if
prime($_)
Yes and:
@primes = 1..100.grep: { prime($^n) };
Is actually vaguely, like, readable AND two characters shorter than the
best you've managed so far.
Oh, if we're looking for readability, I'd look for:
1..100.grep: { prime($^n) } == @primes;
It's longer, though :).
These are only readable if you know geek-speak (i.e., what does
'grep' mean?). The alternatives being proposed are using words like
do, if, when, and for. I think that it's rather impressive
that they're coming within a handful of characters of a grep-based
version.
--
Jonathan Dataweaver Lang
Re: Meditations on a Loop
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote: The page currently says: The reason this [.prime] works is because the method-call syntax will call an ordinary non-member sub also. I think this is no longer the case (and hasn't been for some time). Pm Wow, that's news to me. I found the paragraph that has been inserted in S12 to that effect, larry 8/21/2008 2:58:24 PM remove failover from methods to subs but it was crudly inserted, so just before it the text still reads, The dot form and the indirect object form DEFAULT to method calls. All other prefix calls DEFAULT to subroutine calls. (emphasis mine), and in S06, set_name $obj: Sam; # try $obj.set_name(Sam) first, then # fall-back to set_name($obj, Sam) $obj.set_name(Sam); # same as the above So, I'll make some edits this weekend. --John
Re: Meditations on a Loop
Em Qui, 2009-05-21 às 20:21 -0500, John M. Dlugosz escreveu: but it was crudly inserted, so just before it the text still reads, The dot form and the indirect object form DEFAULT to method calls. All other prefix calls DEFAULT to subroutine calls. (emphasis mine), That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... daniel
r26912 - docs/Perl6/Spec
Author: jnthn
Date: 2009-05-22 23:59:49 +0200 (Fri, 22 May 2009)
New Revision: 26912
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[spec] We now always require the candidate to be passed to bless, otherwise
there's potential for confusion with the first auto-vivifying type object.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-05-22 14:47:04 UTC (rev 26911)
+++ docs/Perl6/Spec/S12-objects.pod 2009-05-22 21:59:49 UTC (rev 26912)
@@ -12,8 +12,8 @@
Maintainer: Larry Wall la...@wall.org
Date: 27 Oct 2004
- Last Modified: 4 May 2009
- Version: 82
+ Last Modified: 22 May 2009
+ Version: 83
=head1 Overview
@@ -682,15 +682,18 @@
$object = $class.bless({k1 = $v1, k2 = $v2, ...});
-If the candidate is omitted, a candidate object is implicitly created in
-the current class by calling CCREATE:
+However, the normal way to create a candidate to bless is by calling
+CCREATE:
-$object = $class.bless(k1 = $v1, k2 = $v2, ...)
-$object = $class.bless(:k1($v1), :k2($v2), ...) # same
+$object = $class.bless($class.CREATE(), k1 = $v1, k2 = $v2, ...)
+$object = $class.bless($class.CREATE(), :k1($v1), :k2($v2), ...) # same
-(The default CCREATE makes an opaque object.)
+Alternatively, you can pass CWhatever and have Cbless call CREATE
+for you.
-In addition to the candidate position argument, Cbless also
+$object = $class.bless(*, k1 = $v1, k2 = $v2, ...)
+
+In addition to the candidate positional argument, Cbless also
allows one or more positional arguments representing autovivifying
type objects. Such an object looks like a type name followed by a
hash subscript (see Autovivifying objects below). These are used
r26914 - docs/Perl6/Spec
Author: jnthn
Date: 2009-05-23 00:34:34 +0200 (Sat, 23 May 2009)
New Revision: 26914
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[spec] Oops, forgot to save before commit.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-05-22 22:16:01 UTC (rev 26913)
+++ docs/Perl6/Spec/S12-objects.pod 2009-05-22 22:34:34 UTC (rev 26914)
@@ -683,7 +683,7 @@
$object = $class.bless({k1 = $v1, k2 = $v2, ...});
However, the normal way to create a candidate to bless is by calling
-CCREATE:
+CCREATE (which by default creates an opaque object):
$object = $class.bless($class.CREATE(), k1 = $v1, k2 = $v2, ...)
$object = $class.bless($class.CREATE(), :k1($v1), :k2($v2), ...) # same
Array variables as formal parameters ???
Please take a look at
http://www.dlugosz.com/Perl6/web/passing_examples.html.
I started working through how the detailed behavior of the Capture and
passing rules need to work, and I ran into something that startled me.
There's no examples in S06 of formal parameters, other than the special
*...@slurp form, that is declared with a sigil other than a $. For example,
sub f1 ($x, @y, @z) { ... }
Before I get any farther with this line of thought, I want to know if
I'm missing something important.
Thanks,
--John
Re: Meditations on a Loop
Daniel Ruoso wrote: Em Qui, 2009-05-21 às 20:21 -0500, John M. Dlugosz escreveu: but it was crudly inserted, so just before it the text still reads, The dot form and the indirect object form DEFAULT to method calls. All other prefix calls DEFAULT to subroutine calls. (emphasis mine), That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... daniel You mean by installing a different dispatcher for the object? By hooking the grammar at a lower level? Or will it be as simple as defining a multi sub for that? --John
Re: Meditations on a Loop
Em Sex, 2009-05-22 às 18:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso wrote: That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... You mean by installing a different dispatcher for the object? By hooking the grammar at a lower level? Or will it be as simple as defining a multi sub for that? Last time I heard about it, it was a simple multi sub... daniel
Re: Meditations on a Loop
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Sex, 2009-05-22 às 18:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso wrote: That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... You mean by installing a different dispatcher for the object? By hooking the grammar at a lower level? Or will it be as simple as defining a multi sub for that? Last time I heard about it, it was a simple multi sub... daniel That sounds like a circular reference problem. If the dot is a simple multi sub and is expected to dispatch based on type (different types may have different dispatchers), what type are you keying off of to pick the standard dispatcher? And how do you determine that without method calls? And what type is the right-hand-side?
Re: Meditations on a Loop
On Fri, May 22, 2009 at 7:52 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: That sounds like a circular reference problem. If the dot is a simple multi sub and is expected to dispatch based on type (different types may have different dispatchers), what type are you keying off of to pick the standard dispatcher? And how do you determine that without method calls? I haven't been following Perl 6 design terribly closely, but I'll take a shot at these two questions from what I know about OO design. The standard dispatcher is associated with Perl 6's equivalent of Perl 5's UNIVERSAL (or CLOS's t, Java's java.lang.Object or whatever, etc.). The superest superclass. A class would be able to say no no, use this dispatcher instead, which would take effect for all of its descendents (unless they too override dispatching). There would be several behind-the-scenes method calls involved in calling $object.foo. The first would be $object.HOW to get the metaclass of $object. The metaclass would then perform many method calls on itself and its associated behind-the-scenes objects in order to dispatch the original method call of foo on $object. The metaclass's own method calls would not be affected, since the metaclass is (presumably) using the standard dispatch logic. Of course, metaclasses would be able to define their own dispatch logic. That would mean changing the metaclass's metaclass. Due to the layered and recursive nature of metaobject protocols, it should all just work. That's why MOPs are so nice. Again, I must stress that I don't actually know how Perl 6 chose to do this, but this is how it works in the MOP-empowered languages I've looked at closely. :) I'd be more than happy to be corrected by someone who knows how it does work. Shawn
Re: Meditations on a Loop
Sartak sartak-at-gmail.com |Perl 6| wrote: On Fri, May 22, 2009 at 7:52 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: That sounds like a circular reference problem. If the dot is a simple multi sub and is expected to dispatch based on type (different types may have different dispatchers), what type are you keying off of to pick the standard dispatcher? And how do you determine that without method calls? I haven't been following Perl 6 design terribly closely, but I'll take a shot at these two questions from what I know about OO design. The standard dispatcher is associated with Perl 6's equivalent of Perl 5's UNIVERSAL (or CLOS's t, Java's java.lang.Object or whatever, etc.). The superest superclass. A class would be able to say no no, use this dispatcher instead, which would take effect for all of its descendents (unless they too override dispatching). The dispatcher isn't associated with an ultimate base class. I think the bases are in fact independant from the dispatcher chosen for a concrete class. Your wierdo class will still inherit from Object or whatever it's called. The metaobject is pointed to by the HOW. There would be several behind-the-scenes method calls involved in calling $object.foo. The first would be $object.HOW to get the metaclass of $object. The metaclass would then perform many method calls on itself and its associated behind-the-scenes objects in order to dispatch the original method call of foo on $object. The metaclass's own method calls would not be affected, since the metaclass is (presumably) using the standard dispatch logic. Of course, metaclasses would be able to define their own dispatch logic. That would mean changing the metaclass's metaclass. Due to the layered and recursive nature of metaobject protocols, it should all just work. That's why MOPs are so nice. I see. Except for accessing the method accessor HOW. But I think you are agreeing with my point. I've thought about the details, but the Moose folks have it all figured out, they tell me. IAC, Installing the dispatcher is done by setting up the object that lives at $object.HOW. That process gets kicked off when the parser determines a method call is needed, and differing dispatchers don't bother that process at all. It has nothing to do with changing what the dot performs when it is found by the parser. Again, I must stress that I don't actually know how Perl 6 chose to do this, but this is how it works in the MOP-empowered languages I've looked at closely. :) I'd be more than happy to be corrected by someone who knows how it does work. Shawn
