At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote:
Summary: An ordered hash that does not support deletes could cause a
user visible bug. At a minimum it should support the special case
of delete that is supported by the Perl each() operator.
Details: This Week in Perl 6, May 25, 2005-May 31, 2005
# New Ticket Created by Curtis Rawls
# Please include the string: [perl #36223]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36223 >
This patch adds a new function, natural_preheader(), to cfg.c. This
function finds and
Gaal Yahas wrote:
On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
There will certainly be an event manager for all sorts of events floating
around in Perl 6. The main trick will be to hide this from the people
who aren't interested. The other trick will be to actually spec it,
sin
: If it can be done in less than 10 lines lines of code, to get the most
: minimal hooks into the core, I'd like to see it done.
10 lines? I laugh in your general direction.
No really. In perl itself, I just to see...
throw Event("CORE::prefork") if $Event::Manager::VERSION;
...or something
On Tuesday 07 June 2005 22:35, Sam Vilain wrote:
> Let's look at the type of one of the many `reduce' variants in
> Haskell;
>
>foldr1 :: (a -> a -> a) -> [a] -> a
>
> This is the Perl6ish;
>
>sub reduce( ::Code{( ::(someType), ::(someType) ) returns
> ::(someType)} $func, Array of ::(someT
On Thu, 2 Jun 2005, Stuart Cook wrote:
On 6/1/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
Speaking
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/8/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
>> > In other words, it outputs:
>> >
>> >Foo
>> >Foo
>> ># dies
>
> Yep. My mistake.
>
>> If that works, then I think it means we can write:
>>
>> sub call-with-current-continuation(Code
Larry Wall <[EMAIL PROTECTED]> writes:
> On Wed, Jun 08, 2005 at 10:51:34PM +, Luke Palmer wrote:
> : Yeah, that's pretty. But that will bite people who don't understand
> : continuations; it will bite people who don't understand "return"; it
> : will even bite people who understand continuat
On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
> On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote:
> : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
> : To take a notorious example, you mentioned fork() -- if this event manager
> : becomes part of P
Edward Cherlin wrote:
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions < > <= >= = != should return only Booleans,
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that < >
Nigel Sandever wrote:
On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote:
: On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
: To take a notorious example, you mentioned fork() -- if this event manage
HaloO Larry,
you wrote:
: Might I add that it should read
:
: $var = (&op.does(identval) ??
: &op.identval($value) :: undef) op $value;
:
: The rational is, that &op is subject to MMD, so the .identval method
: should be dispatched as well. Actually &op.identity($value) r
On Sun, Jun 05, 2005 at 05:11:55PM +0200, BÁRTHÁZI András wrote:
> Thanks, it helped me!
>
> More questions. ;) It seems to me, that the following constructs not
> yet(?) implemented in Pugs. Is it true?
I'll note briefly here that questions regarding implementation (in Perl 6
or Pugs) generally
On Thu, Jun 09, 2005 at 06:41:55PM +0200, "TSa (Thomas Sandlaß)" wrote:
> Edward Cherlin wrote:
> >That means that we have to straighten out the functions that can
> >return either a Boolean or an item of the argument type.
> >Comparison functions < > <= >= = != should return only Booleans,
>
>
So, the return in pointy sub thread got me thinking about useful uses of return
in pointy subs that involve being able to return multiple times. And this is
what I came up with, it's an implementation of 'choose':
my &give_up = sub { fail "Ran out of choices" }
sub choose ([EMAIL PROTECTE
TSa (Thomas Sandlaß) wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the &op multi method object
pick the correct one *without* looking at $value's type?
Edward Cherlin wrote:
You haven't convinced me, but rather than flog a dead horse,
I'll just suggest that we both reserve the right to say "I
told you so" when there are several years' worth of Perl 6
code out there, and we see how common our respective examples
are.
No need to wait. There is
From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Wed, 8 Jun 2005 16:22:35 -0400
At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote:
>. . . Dan Sugalski says: "I'd just pitch an exception if code
>deletes an entry ..."
>
>Perhaps this is OK, because this code is intended for internal u
TSa (Thomas Sandlaß) wrote:
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that < > <= >= when chained return an accumulated
boolean and the least or greatest value where the condition was
true. E.g.
0 < 2 < 3 returns 0 but true
1 < 2 < 1 returns 1 but false
19 matches
Mail list logo
