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
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
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?
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
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,
>
>
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
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
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
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 < >
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
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
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
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
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
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
16 matches
Mail list logo
