On Apr 27, 2005, at 6:39 AM, Aaron Sherman wrote:
On Tue, 2005-04-26 at 10:48, Luke Palmer wrote:
Aaron Sherman writes:
The reasons I don't "use English" in P5:
* Variable access is slower
Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
they're the same: on each run a di
On Wed, 2005-04-27 at 14:38, Luke Palmer wrote:
> There's still a lot of premature optimization going on [...]
> I'm surely guilty of one of them. I feel like the autothreading
> semantics of junctions will be way to expensive without the compiler
> knowing whether there a junction in a particula
Hi,
does the following work as expected?
for %hash.pairs -> $pair { # Note: No "is rw"!
$pair.value = ...; # Modifies %hash
}
Or is it necessary to declare $pair as is rw? (The snippet does not
modify $pair, but $pair.value.)
--Ingo
--
Linux, the choice of a GNU | The next stat
Ingo Blechschmidt skribis 2005-04-28 14:30 (+0200):
> does the following work as expected?
> for %hash.pairs -> $pair { # Note: No "is rw"!
> $pair.value = ...; # Modifies %hash
> }
Yes, because a pair is an object (reference), and it's not the .value
that you're passing ro.
I still
Ingo Blechschmidt web.de> writes:
> > then it has a better chance of working, presuming someone has the
> > gumption to write .pick on hashes, which doesn't look entirely trivial
> > to do right.
>
> I'm sure I overlooked something, but the following
> seems to be correct and is not *that*
Juerd skribis 2005-04-28 14:47 (+0200):
> Yes, because a pair is an object (reference), and it's not the .value
> that you're passing ro.
An example of what would go wrong:
for %hash.pairs>>.value -> $value {
$value = ...;
}
But this will work:
for %hash.pairs>>.value {
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
role A { method foo() { 42 } }
role B { method foo() { 23 } }
class Test does A|B {}
my Test $test .= new;
my $ret = $test.foo; # 42|23?
role A {}
role B { method foo()
Ingo Blechschmidt wrote:
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
I like them! In the type lattice A|B is the lub (lowest upper bound)
of A and B. And A&B is the glb (greatest lower bound) of A and B.
Both are cases of multiple in
On Thu, 2005-04-28 at 09:51, Thomas Sandlaß wrote:
> Ingo Blechschmidt wrote:
> > Hi,
> >
> > so we had junctions of Code references some days ago, what's with
> > junctions of Class and Role objects? :)
>
> I like them! In the type lattice A|B is the lub (lowest upper bound)
> of A and B. And A&
Jonathan Lang wrote:
When you take the square root of a number, you actually get one of two
possible answers (for instance, sqrt(1) actually gives either a 1 or a
-1).
sqrt() is a function that maps its input domain into its output range.
As such multiple return values are at least not part of the
> Jonathan Lang wrote:
>> > When you take the square root of a number, you actually get one of two
>> > possible answers (for instance, sqrt(1) actually gives either a 1 or a
>> > -1).
Not quite. It¹s true that there are two possible square roots of any given
number, but sqrt(1) is defined as th
Hi,
> Essentially lazy lists are suspended closures. But I dought that
> arithmetic between them is defined such that pi + pi would leazily
> calculate 6.28...
...which makes me wonder if it'd be good|cool|whatever to not only have
lazy lists, but also lazy *values*...: :))
my $pi = calc_pi_laz
Ingo Blechschmidt wrote:
> And:
> my @ones = gather { take 1 while 1 };
> my $ones = join "", @ones; # does not burn out!
> say length $ones; # Inf
s/length/chars/ of course.
--Ingo
--
Linux, the choice of a GNU | God said: tar xvjf universe.tar.gz - and
generation on a dual AMD
Aaron Sherman wrote:
Now, I'm not saying that that's the way it MUST be, just that that seems
to be the way that junctions would work in that situation.
I know, and I'm very confused about all these pseudo procedural uses
of junctions. And others seem to share my state of affairs.
If we decide
tha
Ingo Blechschmidt writes:
> Hi,
>
> > Essentially lazy lists are suspended closures. But I dought that
> > arithmetic between them is defined such that pi + pi would leazily
> > calculate 6.28...
>
> ...which makes me wonder if it'd be good|cool|whatever to not only have
> lazy lists, but also la
Aaron Sherman writes:
> On Wed, 2005-04-27 at 14:38, Luke Palmer wrote:
>
> > There's still a lot of premature optimization going on [...]
> > I'm surely guilty of one of them. I feel like the autothreading
> > semantics of junctions will be way to expensive without the compiler
> > knowing wheth
I wrote:
permute( @x_chars ) »{ $^a eq $^b ?? $^a :: ''}« permute( @y_chars )
Permutation is the wrong thing here, sorry. It's just:
( @x_chars »xx« @y_chars.elems ) # or was that .size?
»{ $^a eq $^b ?? $^a :: ''}«
( @y_chars xx @x_chars.elems ) # note: no hypering
e.g. and give »{...}«
On 4/28/05, Thomas Sandlaß <[EMAIL PROTECTED]> wrote:
> I wrote:
> > permute( @x_chars ) »{ $^a eq $^b ?? $^a :: ''}« permute( @y_chars )
>
> Permutation is the wrong thing here, sorry. It's just:
I want to preface again that I have only recently started giving the
language aspect of p6 serious f
Juerd wrote:
Ingo Blechschmidt skribis 2005-04-28 14:30 (+0200):
does the following work as expected?
for %hash.pairs -> $pair { # Note: No "is rw"!
$pair.value = ...; # Modifies %hash
}
Yes, because a pair is an object (reference), and it's not the .value
that you're passing ro.
I come
Joshua Gatcomb wrote:
... FAQs such as union, difference, intersection of lists are
FAQs for a reason.
... it would be nice to have a real simple easy answer for p6.
And indeed it could be:
use Sets;
my @a is Set = (1,2,3);
my @b is Set = (2,3,4);
say @a + @b; # (1,2,3,4)
say @a / @b; # (2,3)
e
On Thu, 2005-04-28 at 10:00, Luke Palmer wrote:
> Aaron Sherman writes:
> > Well, more to the point, autothreading of junctions will hit the wall of
> > Parrot duping the interpreter. That's probably not something you want to
> > suffer just to resolve a junction, is it?
>
> What? Why will it do
Thomas Sandlaß skribis 2005-04-28 18:09 (+0200):
> >I still want <->, by the way.
> Me too. And I guess <- naturally completes the set.
Although it would complete the set, in the months since I first started
wanting <->, I have not been able to come up with a good reason to want
write-only bindin
On Thu, Apr 28, 2005 at 12:46:53PM -0400, Aaron Sherman wrote:
> On Thu, 2005-04-28 at 10:00, Luke Palmer wrote:
> > Aaron Sherman writes:
>
> > > Well, more to the point, autothreading of junctions will hit the wall of
> > > Parrot duping the interpreter. That's probably not something you want to
Aaron Sherman wrote:
> As a side note, I'd like to suggest that "English" is just rubbing
> people's noses in the fact that they're not allowed to program in their
> native tongue. "Names" might be less in-your-face.
Why are we even having to say use English or Names or whatever? Why
not just ma
Aaron Sherman wrote:
On Thu, 2005-04-28 at 10:00, Luke Palmer wrote:
Aaron Sherman writes:
Well, more to the point, autothreading of junctions will hit the wall of
Parrot duping the interpreter. That's probably not something you want to
suffer just to resolve a junction, is it?
Wh
On Thu, 2005-04-28 at 13:55, Rod Adams wrote:
> I would be dismayed if autothreading used threads to accomplish it's
> goals. Simple iteration in a single interpreter should be more than
> sufficient.
Sorry, I misunderstood. Thanks for the clarification.
--
Aaron Sherman <[EMAIL PROTECTED]>
S
On Thu, 2005-04-28 at 13:52, gcomnz wrote:
> Aaron Sherman wrote:
>
> > As a side note, I'd like to suggest that "English" is just rubbing
> > people's noses in the fact that they're not allowed to program in their
> > native tongue. "Names" might be less in-your-face.
>
> Why are we even having
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> I would be dismayed if autothreading used threads to accomplish it's
RA> goals. Simple iteration in a single interpreter should be more than
RA> sufficient.
how autothreading is implemented is distinct from the language
feature. a simp
Hi,
Luke Palmer wrote:
>> ...which makes me wonder if it'd be good|cool|whatever to not only
>> have lazy lists, but also lazy *values*...: :))
>
> Then every expression that referenced lazy values would be lazy in
> terms
> of them. And once you want to print X digits of the lazy answer, you
>
Ingo Blechschmidt writes:
> Hi,
>
> Luke Palmer wrote:
> >> ...which makes me wonder if it'd be good|cool|whatever to not only
> >> have lazy lists, but also lazy *values*...: :))
> >
> > Then every expression that referenced lazy values would be lazy in
> > terms
> > of them. And once you want
Rod Adams wrote:
I would be dismayed if autothreading used threads to accomplish it's
goals. Simple iteration in a single interpreter should be more than
sufficient.
For sure. No point in doing 10_000 cycles to set up a scratch area
for a single boolean test that might take 10 cycles.
A software
31 matches
Mail list logo
