Dot forms of adjectives
But I recently read this on irc:
2009-03-12
23:16pugs_svnr25809 | lwall++ | This decrease in consistency on
the syntactic level is offset by an
23:16pugs_svnr25809 | lwall++ | increase in consistency on the
semantic level, as suggested by rouso++.
23:16pugs_svnr25809 | lwall++ | (We'd already gotten rid of the
dot forms of adverbs some time ago,
23:16pugs_svnr25809 | lwall++ | for similar reasons. We just
didn't quite carry the idea through.)
and then read this:
S03 Changes to Perl5 Operators
...
if $filename ~~ :e { say exists }
is the same as
if $filename.e { say exists }
The 1st form actually translates to the latter form, so the object's
class decides how to dispatch methods.
Is there an inconsistency here?
Re: Dot forms of adjectives
Original post not very clear. So here goes again:
First statement (below) says: dot forms of adverbs eliminated.
Second appears to say: adverb form is translated to dot form.
Richard Hainsworth wrote:
But I recently read this on irc:
2009-03-12
23:16pugs_svnr25809 | lwall++ | This decrease in consistency
on the syntactic level is offset by an
23:16pugs_svnr25809 | lwall++ | increase in consistency on the
semantic level, as suggested by rouso++.
23:16pugs_svnr25809 | lwall++ | (We'd already gotten rid of
the dot forms of adverbs some time ago,
23:16pugs_svnr25809 | lwall++ | for similar reasons. We just
didn't quite carry the idea through.)
and then read this:
S03 Changes to Perl5 Operators
...
if $filename ~~ :e { say exists }
is the same as
if $filename.e { say exists }
The 1st form actually translates to the latter form, so the object's
class decides how to dispatch methods.
Is there an inconsistency here?
Re: Dot forms of adjectives
On Sun, Mar 15, 2009 at 11:11:16AM +0300, Richard Hainsworth wrote:
But I recently read this on irc:
2009-03-12
23:16pugs_svnr25809 | lwall++ | This decrease in consistency on
the syntactic level is offset by an
23:16pugs_svnr25809 | lwall++ | increase in consistency on the
semantic level, as suggested by rouso++.
23:16pugs_svnr25809 | lwall++ | (We'd already gotten rid of the
dot forms of adverbs some time ago,
23:16pugs_svnr25809 | lwall++ | for similar reasons. We just
didn't quite carry the idea through.)
and then read this:
S03 Changes to Perl5 Operators
...
if $filename ~~ :e { say exists }
is the same as
if $filename.e { say exists }
The 1st form actually translates to the latter form, so the object's
class decides how to dispatch methods.
Is there an inconsistency here?
Different dot form. I was talking about :foo.(), :bar.[] and such,
which were removed from the spec some time ago, and are now actually
gone from STD.pm and t/spec, thanks to your++ bringing it up. :)
Larry
a junction or not
The following (the n: is to mark the lines) are legal:
1: my @x = 1,2,3,4; ([+] @x).say; # output 10
2: my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20)
3: my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10
However, the next line isnt
4: my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction or
not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
loop {
@x = @s.pick(3);
([+] @x).eigenstates.min.say;
};
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
I suggested to Masak on irc that an integer is a singleton, hence a
degenerate Junction. He said not.
So, how to determine whether a junction is being used or not?
Richard
Re: a junction or not
Richard Hainsworth wrote:
The following (the n: is to mark the lines) are legal:
1: my @x = 1,2,3,4; ([+] @x).say; # output 10
2: my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20)
3: my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10
However, the next line isnt
4: my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction
or not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
loop {
@x = @s.pick(3);
([+] @x).eigenstates.min.say;
};
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
I suggested to Masak on irc that an integer is a singleton, hence a
degenerate Junction. He said not.
So, how to determine whether a junction is being used or not?
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
Jonathan
Re: a junction or not
Jonathan Worthington wrote:
Richard Hainsworth wrote:
snip
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
Jonathan
Except it doesnt work :(
$ perl6
my %h=a b c Z 1|11,2,3;%h.perl.say
{a = any(1, 11), b = 2, c = 3}
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;$s.perl.say
any(6, 16)
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;say $s~~Junction ??
$s.eigenstates.min !! $s
Null PMC access in get_integer()
Re: a junction or not
This isn't the first (or second, or third, or fourth...) time that I've seen complications arise with regard to junctions. Every time, the confusion arises when some variation of the question is it a junction? is raised. Ultimately, this is because Perl is trying it's darnedest to treat Junctions as their members; this is something that it doesn't try anywhere else, leading to a counterintuitive approach. The other big example of this phenomenon that I've seen has to do with passing parameters into a routine: Should the code auto-parallelize, executing the code separately for each value in the junction, or should it execute only once, passing the parallelization buck on to whatever routines it happens to call? That is, should parallelization be eager or lazy? (I'm pretty sure that this was resolved, although I'm not recalling how.) The problem that Richard just identified is that Junctions don't fully manage to hide themselves when it comes to their method calls. Let's say that I'm writing a role that deals with quantum mechanics (say, Quantum), and for whatever reason I decide that I need an eigenstate method. Now we've got a problem: if I ever find myself dealing with a Junction that has at least one Quantum among its eigenstates, what happens when I call the .eigenstates method? I'm betting that I'll get Junction.eigenstates, rather than a Junction of Quantum.eigenstates. In fact, I see no easy way to get the latter. I'm thinking that maybe Junction shouldn't be a type. Instead, it should be a meta-type, in (very rough) analogy to the concept of the meta-operator. In particular, Junction bears a certain resemblance to the hyper-operator. Thus far, it's the only meta-type; and, like meta-operators, additional meta-types should be added sparingly. As I see it, the difference between a type and a meta-type is that all of the meta-type's methods are accessed via HOW. You wouldn't say $x.eigenstates to access a Junction's eigenstates; you'd say $x.^eigenstates for that. (Further speculation: maybe there's a meta-type that defines the default HOW methods.) That still doesn't solve the problem that Richard first raised, though. To do that, I'm thinking that his original suggestion should also be implemented: in the same way that an item can be treated as a one-item list for the purposes of list context (and vice versa), a non-Junction should be able to be treated as a Junction with a single eigenstate (i.e., a Singleton) for the purposes of junctive semantics. That is, $x.^eigenstates === ($x) if $x is not a junction. Not only does this reduce the need to test for junctions, but it also makes that test fairly straightforward: count the eigenstates. If you only have one, it isn't a junction. (Further speculation: perhaps undefined values have _no_ eigenstates...) -- Jonathan Lang
Re: a junction or not
On Sun, Mar 15, 2009 at 07:26:00PM +0100, Jonathan Worthington wrote:
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
I see no particular reason not to add an .eigenstates method to Object
that returns a list of the object itself . It doesn't interfere with
the .eigenstates method defined in Junction, unless you want to
determine whether something is a Junction by seeing if it can respond
to .eigenstates, which seems wrongish.
Larry
r25849 - docs/Perl6/Spec
Author: lwall Date: 2009-03-16 02:24:38 +0100 (Mon, 16 Mar 2009) New Revision: 25849 Modified: docs/Perl6/Spec/S02-bits.pod Log: make blocks transparent to Junctions (in the absence of explicit parameter types) Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-03-16 01:23:33 UTC (rev 25848) +++ docs/Perl6/Spec/S02-bits.pod2009-03-16 01:24:38 UTC (rev 25849) @@ -12,9 +12,9 @@ Maintainer: Larry Wall la...@wall.org Date: 10 Aug 2004 - Last Modified: 7 Mar 2009 + Last Modified: 15 Mar 2009 Number: 2 - Version: 158 + Version: 159 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1028,8 +1028,8 @@ Class Perl 6 standard class namespace RolePerl 6 standard generic interface/implementation Grammar Perl 6 pattern matching namespace -Any Perl 6 object (default parameter type, excludes Junction) -Object Perl 6 object (either Any or Junction) +Any Perl 6 object (default routine parameter type, excludes Junction) +Object Perl 6 object (default block parameter type, either Any or Junction) A CKeyHash differs from a normal CHash in how it handles default values. If the value of a CKeyHash element is set to the default
