Re: Hyper concat ^_ ?
> 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
Re: TIMTOWT concat / hypo-operators
> 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 idea was that this could be done with an adverb just like '^' does > for element-wise array operations. Such an approach has been used > successfully in other languages, but I haven't seen any indication that > Larry and Damian are considering this for P6. FWIW, I haven't seen any indication that we are either. ;-) Damian
Re: Quick EX3 question
> 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'll probably have to work *much* harder to
explicitly stringify a reference.
Damian
Re: NaN semantics
> 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 C be false, causing the loop to continue > until a valid numeric string is entered. Err. Are you *sure*? That's an C, not a C, you realize? > The example can be rewritten > >print "Inflation rate: " and $inflation = +<> > while $inflation != $inflation; Err. No it can't. > That is ugly, non-intuitive and ugly; and non-intuitive too. But > inconsistency with a long accepted standard is also ungood. Perhaps we > need to write it thus: > >print "Inflation rate: " and $inflation = +<> > while $inflation.isnan; > > or some such? Or: print "Inflation rate: " and $inflation = +<> while $inflation == NaN; which is: print "Inflation rate: " and $inflation = +<> while !($inflation != NaN); which is: print "Inflation rate: " and $inflation = +<> until ($inflation != NaN); which is exactly what I wrote. ;-) Damian
RE: EX3: Adverbs and print()
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
#> adverbs?
#
# Yep. Although the "in-band"/"out-of-band" distinction is only one of
# convention.
#
# In reality, Perl 6 will merely distinguish between those
# arguments that
# come before a colon (and are bound to parameters before the
# colon in the
# parameter list), and those arguments that come after a colon (and are
# bound to parameters after the colon in the parameter list).
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? Is unary . gonna refer to the "one and only"
argument before the colon?
class FooBar;
method new($class : *@args) {
my $obj;
$obj=.bless;#transmogrified into $obj=$class.bless
}
method serialize($me : IO::Handle $fh) {
#$me is the only eccentricy I have left from my early work in (ugh) VB
print $fh: .quux; #same as $me.quux
print $fh: .gerflonkurator; #same as $me.gerflonkurator
}
Cool.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
RE: NaN semantics
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 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, then his example is correct. P.S. Congratulations to you and Larry for waking up perl6-language. I had seen almost no traffic on it in weeks, and was starting to get a bit worried that thoughts on the languages were coughing, sputtering and dying. :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: TIMTOWT concat / hypo-operators
[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-operators.
> >
> 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.
I'd like hypo-operators
a) for the sake of symmetry (imperfect symmetry that is)
b) because they minimize the separation of verb and object
cf. $acc += $_ for (@values);
vs. $acc +=^ @values;
(Well, that's not a hell of an argument, is it? :)
You could of course do more clever and confusing things
with multi-dim. arrays.
Anyway, I realize the need is less than urgent. :)
Maybe Perl 6 is going to be the language to resolve such
"I want it"/"I don't care"-arguments in a friendly way. It should be
feasible to write a module so you can do
{
use Operators::Hypo;
@score +=^ (4,1) *^ @points;
}
lexically, I mean.
What's needed is a parser hook for the operators (which is needed
anyway) and a way to write an extension module which provides
dynamically installable Perl ops which are (almost) as fast as the
builtins (which seems to be in planning).
-Edwin
Re: TIMTOWT concat / hypo-operators
[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) multiply @points element-wise by the matrix 4 1 1 ... 4 1 1 ... 4 1 1 ... ... ... 2) add the sum of all elements of the resulting matrix to score. -Edwin
Re: EX3: Adverbs and print()
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 reality, Perl 6 will merely distinguish between those arguments that > come before a colon (and are bound to parameters before the colon in the > parameter list), and those arguments that come after a colon (and are > bound to parameters after the colon in the parameter list). Yeah, that works and all, but it kind of kills the nice "adverb" angle. At that point, why not just have an arbitrary number of colons? ;) (I'm kidding! Step away from the keyboard! ;) -John
Re: NaN semantics
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 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, which is why the loop continues until a valid number is entered. > >The example can be rewritten > > > > print "Inflation rate: " and $inflation = +<> > > while $inflation != $inflation; > Err. No it can't. I meant, if we used IEEE semantics rather than those you showed, the example could be correctly written as ... And did I mention it's ugly this way? Brent Dax said: > 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, then his > example is correct. Thank you Brent. Brevity and clarity; what concepts! I must try them sometime. -- Tim Conrow
Re: Are .key and .value right for Pairs?
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 frame of reference of a .pm file, or a `module', it more reflects on an instance of a module. but i feel my opinions comes solely from an OOP point of view, and Perl and its current Core is multi-paradigmic, so $this isn't always as important as what is $first. -mark
Re: NaN semantics
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. > > > 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, which is why the > loop continues until a valid number is entered. Hi, This is my first post here, so don't laugh if I say something stupid. :) I haven't got any contact with NaN before, but when Tim pointed that NaN!=NaN is true in IEEE I thought that it does make sense. I see pros and cons and it's not so ugly and non-intuitive as it can look. When comparing $a and $b as numbers there is no need for $a==$b!=NaN, if NaN!=NaN then $a==$b is ok for any values of $a and $b, it would be true only if $a and $b are numbers and they are equal. If NaN==NaN is true, then the longer $a==$b!=NaN is needed. So when comparing two scalars as numbers NaN!=NaN being true makes it easier. But then "until $inflation != NaN" would be useless as NaN!=anything is always true (NaN!=NaN, and NaN!=anynumber). With NaN!=NaN some other way like $x.isNaN or $x.isnum would be needed. Or maybe NaN evaluates to 'NaN' in string context and +$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in fact very intuitive for me, as NaN is something without any numerical meaning, so numerically compared to anything doesn't make sense (as == means numerical equality, not just equality). Maybe it should be undef instead of false? 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). BTW, I really like the direction of Perl 6 development, all of you are doing really great job here. I was very surprised when I saw the negative feedback on Slashdot, and I thought that if my enthusiasm is so abnormal, than maybe it's a sign that I should join your team. :) Really, I'd love to help with Perl 6 development if I can be useful somehow. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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
Re: NaN semantics
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 enthusiasm. But hey, that's very optimistic, when most people won't learn Perl 6, then I'll be relatively smarter! :) - RaFaL Pocztarski, [EMAIL PROTECTED]
RE: EX3: Adverbs and print()
> 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
RE: NaN semantics
> 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, then his > example is correct. Sorry. I was focused on the Perl 6 semantics and missed that implication. 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) "ugly, non-intuitive and ugly; and non-intuitive too". ;-) > P.S. Congratulations to you and Larry for waking up perl6-language. I > had seen almost no traffic on it in weeks, and was starting to get a bit > worried that thoughts on the languages were coughing, sputtering and > dying. :^) Just one of many eyes in Hurricane Perl, I assure you! ;-) Damian
Re: NaN semantics
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 consistency with other languages >> may be. If NaN != NaN, then his example is correct. > > Sorry. I was focused on the Perl 6 semantics and missed that > implication. > > 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) > "ugly, non-intuitive and ugly; and non-intuitive too". But NaN could already be argued to be ugly, non intuitive and ugly. When you compare two indeterminate quantities (if quantity is even the right word) then expecting them to be equal is somewhat surprising. Maybe NaN is a misnomer, since NaN already has a defined meaning in this context, the IEEE sense. Changing its semantics in a perl context is surely a recipe for confusion (assuming you're not already confused by the IEEE behaviour). Trouble is, I'm not entirely sure what a good name for this would be. -- Piers
Re: NaN semantics
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, which is why the > loop continues until a valid number is entered. Uh huh. As I pointed out, I had missed your assumption of IEEE semantics. Damian
Re: NaN semantics
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 languages and reject the non-identity of NaN. > BTW, I really like the direction of Perl 6 development, all of you are > doing really great job here. I was very surprised when I saw the > negative feedback on Slashdot, and I thought that if my enthusiasm is so > abnormal, than maybe it's a sign that I should join your team. :) > Really, I'd love to help with Perl 6 development if I can be useful > somehow. You're already doing it. Rather than more cooks, we need more food critics: as many people as possible working through the ramifications and inconsistencies of the design. Damian
Re: NaN semantics
> > 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) > > "ugly, non-intuitive and ugly; and non-intuitive too". > > But NaN could already be argued to be ugly, non intuitive and ugly. > When you compare two indeterminate quantities (if quantity is even the > right word) then expecting them to be equal is somewhat surprising. I see your (and others') point here, but I view NaN as a *marker* indicating a non-numeric result. Markers should always compare equal to themselves. (Frankly, *everything* should compare equal to itself -- which is where IEEE 754 goes horribly wrong.) > Maybe NaN is a misnomer, since NaN already has a defined meaning in > this context, the IEEE sense. Changing its semantics in a perl context > is surely a recipe for confusion (assuming you're not already confused > by the IEEE behaviour). I suspect the number of people who know and understand the current IEEE semantics is relatively small, compared to the number of people who would be freshly confused if we honoured it in Perl 6. I would dread to have to explain why: $value == NaN; produces the opposite value to: $value.isNaN; (and only in the important case). > Trouble is, I'm not entirely sure what a good name for this would be. C is a good name. We just have to wrest it back from the corrupting clutches of the bit-twiddlers! Though, I confess, I wouldn't be averse to seeing a C value in Perl. ;-) Damian
Re: Hyper-operators and Underscore
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 not the underscore. Because there is conceptual dissonance between the purpose and the look. Why should the thing which glues strings together require spaces around it? Ted -- Ted Ashton ([EMAIL PROTECTED]) | From the Tom Swifty collection: Southern Adventist University| "I've declared the variable X so that its Deep thought to be found at | value is saved from one procedure http://www.southern.edu/~ashted | invocation to the next", said Tom | ecstatically.
Re: From the "Be Afraid. Be Very Afraid" department.
> : @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 looks
> to me as if it'll require substantial lookahead, which could become
> a problem.
I suspect it will actually require *less* lookahead than Perl 5
would. As soon as it encounters the $^_ it knows it's seeing a
higher-order function.
Damian
