> : @costs = (sort { $a.key <=> $b.key }
> : { amortize($^_) => $^_ }^.(@cost ^* $inflation)
> :)^.value;
>
> I wonder how the parser is going to tell that the start of the second
> line is supposed to be an anon sub, rather than an anon hash. It
Thus it was written in the epistle of Erik Lechak,
>
> I guess my biggest complaint was that underscore would be the only single
> character operator that would be in danger of being lumped into the variable
> name. I forgot about x . I use it all the time. If x has that
> constraint why n
> > Let me make it clear: AFAIK Perl NaN's will not be IEEE 754
> > compliant. That was certainly my intention in suggesting them to
> > Larry. I share the view of a number of other language designers that
> > the non-self-identity of IEEE NaN is (to slightly misquote Tim)
> > "ug
RaFaL asked:
> So OK, tell me if I get it right, and how (and why) it will look in Perl
> 6. From Exegesis I see that NaN==NaN, but that's not stated in
> Apocalypse (or I just missed it).
No, it's not stated there. But I hope that Perl 6 will follow the lead of
other high level langu
Tim wrote:
> > Err. Are you *sure*? That's an C, not a C, you realize?
>
> Yes. I had to use all my fingers and toes to keep everything straight,
> but I think I did. :-) In the semantics you show (different from IEEE
> semantics) "NaN==NaN" is true, so "NaN!=NaN" is false, whic
Damian Conway <[EMAIL PROTECTED]> writes:
>
>> His point was that the NaN IEEE came up with is defined to have
>> NaN != NaN, and that it might be confusing if Perl's behavior
>> wasn't consistent with that. Not that I think NaN != NaN is a
>> particularly good idea, but consist
> His point was that the NaN IEEE came up with is defined to have NaN !=
> NaN, and that it might be confusing if Perl's behavior wasn't consistent
> with that. Not that I think NaN != NaN is a particularly good idea, but
> consistency with other languages may be. If NaN != NaN, th
> So, does that mean that, to keep C and
> Cnew($baz, $frob)> doing the same thing, the object will always
> come in before the colon?
Yes.
> Is unary . gonna refer to the "one and only"
> argument before the colon?
Yes.
> Cool.
Yes.
;-)
Damian
John Siracusa wrote:
> On 10/7/01 4:19 PM, RaFaL Pocztarski wrote:
> > I was very surprised when I saw the negative feedback on Slashdot
>
> Heh, did you just discover Slashdot recently? ;)
Well, maybe I was so excited about everything I read about Perl 6 that I
thought everyone will share my en
On 10/7/01 4:19 PM, RaFaL Pocztarski wrote:
> I was very surprised when I saw the negative feedback on Slashdot
Heh, did you just discover Slashdot recently? ;)
-John
Tim Conrow wrote:
> Damian Conway said:
>> > > print "Inflation rate: " and $inflation = +<>
>> > > until $inflation != NaN;
>> >
>> > This requires that C be false, causing the loop to
>> > continue until a valid numeric string is entered.
>
Damian Conway wrote:
>Very nice. And yes, too many brackets of various kinds.
>Also $this doesn't really describe what it stores.
>Maybe $first would be better?
>
as i see it, $first describes what is true of the implementation of passing
the object reference, but looking at the $this in the f
Damian Conway said:
> > > print "Inflation rate: " and $inflation = +<>
> > > until $inflation != NaN;
> >
> > This requires that C be false, causing the loop to
continue
> > until a valid numeric string is entered.
> Err. Are you *sure*? That's a
On 10/7/01 4:17 AM, Damian Conway wrote:
>> Does that mean that in the built-in print, the file handle is the only
>> "in-band" argument, and all the actual items to be printed are merely
>> adverbs?
>
> Yep. Although the "in-band"/"out-of-band" distinction is only one of
> convention.
>
> In rea
[EMAIL PROTECTED] (Edwin Steiner) writes:
> @score +=^ (4,1) *^ @points;
Sorry, I completely f...ed up the example.
What I was thinking of would be more like:
$score +=^ (4,1) ^* @points;
So one hypo- and one hyper-operator.
Assuming @points is 2-dimensional this would:
1) mu
[EMAIL PROTECTED] (Jeremy Howard) writes:
> Brent Dax wrote:
> > Edwin Steiner:
> > # Could there also be *hypo*-operators, i.e. operators which try to
> > # *lower* (reduce) the dimensionality of their operands to the lowest
> > # common dim. So
[snip]
> > I don't really see the use of hypo-opera
Damian Conway:
#> The example can be rewritten
#>
#>print "Inflation rate: " and $inflation = +<>
#> while $inflation != $inflation;
#
# Err. No it can't.
His point was that the NaN IEEE came up with is defined to have NaN !=
NaN, and that it m
Damian Conway:
#> So, in the
operator, the filter is the adverb:
#>
#> $sum =
@costs : {$^_ < 1000};
#>
#> Does that mean that in the built-in print, the file
# handle is the only
#> "in-band" argument, and all the actual items to be
# printed are merely
#> adve
> Semantic confusion alert!
Aroogha! Aroogha! All crew to clarification stations!
> EX3 (great document!)
Thank-you.
> sez:
>
> > print "Inflation rate: " and $inflation = +<>
> > until $inflation != NaN;
>
> This requires that
> Are these the same thing?
>
> print _@{$data.{costs}};
> print _ $data{costs};
Larry has indicated that they almost certainly will be.
Arrays and array refs will be interchangeable in a scalar context
(such as the unary _ applies to its argument).
In fact, in Perl 6 you
> Well, it's pretty handy to be able to generalise what join() does
> for concat to any abitrary function. It's covered by:
> http://dev.perl.org/rfc/76.html which proposes a new reduce()
> builtin.
C is almost definitely in (in some form). That's why I used it
in E3.
> Edwin's
> Actually... Damian, does this, along with the new reference/context
> stuff, mean that HOFs could also have hash and array parameters? I
> guess there's no reason why not...
None at all. Though I haven't specifically discussed that with Larry,
I think it's very likely.
Damian
22 matches
Mail list logo
