HaloO,
On Tuesday, 17. March 2009 10:25:27 David Green wrote:
> > That is, it would return a Junction of Str, not a Str. So the
> > question is how to get something that returns an expression to the
> > effect of:
> > 'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
>
> say $choice.perl
>
>
On 3/15/09 11:19 AM, 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 nex
On 2009-Mar-17, at 2:16 am, Jon Lang wrote:
$choice.perl will return the same thing that the following would:
any($choice.eigenstates.«perl)
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any('
Darren Duncan wrote:
>
> Jon Lang wrote:
>>
>> Darren Duncan wrote:
>>> I would assume that invoking .perl on a Junction would result in Perl
>>> code
>>> consisting of the appropriate any/all/etc expression. -- Darren Duncan
>>
>> Tough to parse, though; and feels like a kludge. I expect better o
Jon Lang wrote:
Darren Duncan wrote:
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does
Larry Wall wrote:
> I think I've mentioned before that .perl autothreads. It's the final
> (low-level) stringification of a junction that slaps the appropriate
> quantifier around that, I suspect.
Please bear with me; I'm starting to get a little lost: are you
telling me that $j.perl does what I'
On Mon, Mar 16, 2009 at 09:24:58PM -0700, Jon Lang wrote:
: Darren Duncan wrote:
: > Jon Lang wrote:
: >> Larry Wall wrote:
: >>> This is basically a non-problem. Junctions have one public method,
: >>> .eigenstates, which is vanishingly unlikely to be used by accident by
: >>> any mere mortal any
Darren Duncan wrote:
> Jon Lang wrote:
>> Larry Wall wrote:
>>> This is basically a non-problem. Junctions have one public method,
>>> .eigenstates, which is vanishingly unlikely to be used by accident by
>>> any mere mortal any time in the next 100 years, give or take a year.
>>> If someone does
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechan
Larry Wall wrote:
> This is basically a non-problem. Junctions have one public method,
> .eigenstates, which is vanishingly unlikely to be used by accident by
> any mere mortal any time in the next 100 years, give or take a year.
> If someone does happen to be programming quantum mechanics in Perl
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
they're probably smart
Larry Wall wrote:
> Sigh. The current design of Junctions is quite extensible *because*
> it is based on a real type. You can easily write operators that
> work only on Junctions, just as you can easily write operators that
> are transparent to Junctions or autothread on Junctions by declaring
>
Sigh. The current design of Junctions is quite extensible *because*
it is based on a real type. You can easily write operators that
work only on Junctions, just as you can easily write operators that
are transparent to Junctions or autothread on Junctions by declaring
their arguments to take Obje
On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote:
> The problem that Richard just identified is that Junctions don't fully
> manage to hide themselves when it comes to their method calls.
[...]
> I'm thinking that maybe Junction shouldn't be a type. Instead, it
> should be a "meta-type"
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;
> }
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 Junctio
Jonathan Worthington wrote:
Richard Hainsworth wrote:
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.
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;
lo
,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(
19 matches
Mail list logo