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
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 particular
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
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 want
Ingo Blechschmidt iblech at 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.
thinking out loudI'm sure I overlooked something, but the following
seems to be correct
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
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 AB is the glb (greatest lower bound) of A and B.
Both are cases of multiple
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 AB is the glb
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 the
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 =
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
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 lazy
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 whether there
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. a b c and x y give a
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 focus.
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)
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 that?
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 binding.
A
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 make it
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?
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]
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 to say use
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 simple version
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
have to
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 to print X
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
31 matches
Mail list logo
