Re: Reviewers for Perl 6 Essentials, 2nd. ed.
Allison Randal wrote: It's that time of year again, and we're looking for reviewers for the 2nd edition of Perl 6 Essentials. The review will start mid-March and last about a week. Drop me a message if you're interested. I would just love to help. I've read the 1st edition, I've read the apocalypses, exegeses, synopses, PPDs and I've been reading all of the perl6-* mailing lists for couple of months. I have written few posts in perl6-language two or three years ago, but later I was unfortunately unable to contribute any more. Now if I only could be helpful, I would really love to, or at the very least read the 2nd edition of Perl 6 Essentials as soon as I possibly can... Of course I might not remember everything, but there is still some time to reread all of the apocalypses and other documentation. Will the new edition cover the Apocalypse 12? We may have to narrow down the list of volunteers a bit. 15 sets of comments is about the maximum we can process and still meet our deadline. If there are too many volunteers, then maybe we could be divided into some teams, each of them preparing one set of comments? Thanks. -- Rafal Pocztarski, [EMAIL PROTECTED]
Re: Indenting
Bart Lateur wrote: I can remember that an even smarter version of this was discussed in an RFC -- I don't remember which -- so it's not unlikely that it will be part of Perl6. RFC162 - Heredoc contents: http://dev.perl.org/rfc/162.html Apocalypse 2: http://dev.perl.org/perl6/apocalypse/2#rfc 162: heredoc contents (I don't like spaces in anchor names...) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
David Nicol wrote: RaFaL Pocztarski wrote: First this thread tells me that 123foo will be 123 in numeric context. Now I find myself wondering what 123indigo evaluates to! Also 123. I think that complex numbers, if happening automatically, would only match ($realpart, $imaginarypart) = /^\b(\d*\.?\d+)\+(\d*\.?\d+)i\b/ and 123indigo does not match that. I'm not sure how strings like 123indigo should be handled, but I think that imaginary numbers should also be recognized as complex written 10i and not only 0+10i. I don't think that imaginary numbers should have their own class, like real ones have. I would love literals like 10k+4iMi to be valid numbers, but I don't know what others think about it. But it probably should be just an addition of two numbers, real and imaginary, not just a complex literal as a whole. BTW, it reminds me my another bad idea I got some time ago: Currently in Perl 5 string '2**16' in numeral context evaluates to 2 (with warning). To DWIM it should be 65536. I know that it would be harder to implement and I won't argue if you tell me that it's to hard to be worth all the work, but I'd like to know what do you think about it, maybe it would evolve to a better idea, but anyway, here's what I thought: strings in numerical context could be evaluated using all numerical operators like +, -, *, /, **, etc. to calculate the result. To enter 4294967295 i could use '2**32-1' (I mean strings of course, like user input etc.) with no need to use eval on the string, as eval on user input could be unsafe. Now I have idea that maybe some 'neval' (numerical eval) function should be useful, and it could be used only when string in numerical context would normally produce a warning (so normal +'123' won't me any slower). Such neval could be useful anyway, for using as safe eval for other things. It could be just eval after removing everything which is not a numerical operator or number literal, whatever it will mean. :) I'm just thinking loudly. What do you think about it? - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
David Nicol wrote: RaFaL Pocztarski wrote: 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? I'm coming to this thread after nearly a week of everyone weighing in their opinions, and fully expect to see what I'm about to type in stated by someone else, days ago, a little further down the long list of posts. Actually you have just quoted me when I said that.. :) What if not-a-number stringifies to NaN, but numerically always compares to false, so the conditional in the example could CLEARLY be written while $inflation ne NaN; It should be: while +$inflation ne NaN; because $inflation itself can be (and probably is) some other string than 'NaN', so +$inflation evaluates to NaN, and when ne operator provides a string context it then evaluates to 'NaN'. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
Dan Sugalski wrote: At 01:27 PM 10/11/2001 +0200, RaFaL Pocztarski wrote: David Nicol wrote: RaFaL Pocztarski wrote: First this thread tells me that 123foo will be 123 in numeric context. Now I find myself wondering what 123indigo evaluates to! Also 123. I think that complex numbers, if happening automatically, would only match ($realpart, $imaginarypart) = /^\b(\d*\.?\d+)\+(\d*\.?\d+)i\b/ and 123indigo does not match that. I'm not sure how strings like 123indigo should be handled, but I think that imaginary numbers should also be recognized as complex written 10i and not only 0+10i. Sure. 5 + 10i will probably evaluate to 5 + 10i and just get constant-folded at compile time. ;) That's good to know. :) I don't think that imaginary numbers should have their own class, like real ones have. If we support imaginary numbers, it'll be via a beefed up number type. Basically the numeric bits will be expanded to have a real and an imaginary type. (Support for generating imaginary numbers will probably be lexically scoped. As Hugo's pointed out, suddenly generating imaginaries where we used to throw errors will probably trip up the unwary) As for more complex string literals evaluating to numbers, I think that's something best left to either a user-written sub, or user-written fancy parser hacks. Up to Larry whether it goes in the base language, but I think I'd prefer not. If it will be easily possible to run some sub in the place where (with -w) 'Argument x isn't numeric in addition (+) at -e line 1.' would be produced, than I can try to write such sub, or a whole module. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
(sorry, I posted it before I finished...) Dan Sugalski wrote: Sure. 5 + 10i will probably evaluate to 5 + 10i and just get constant-folded at compile time. ;) That's good to know. :) I don't think that imaginary numbers should have their own class, like real ones have. If we support imaginary numbers, it'll be via a beefed up number type. Basically the numeric bits will be expanded to have a real and an imaginary type. (Support for generating imaginary numbers will probably be lexically scoped. I see. So there are two main basic types, real and imaginary, and complex is made of both, and not the imaginary being implemented as complex with zero as real part, as I thought before. I'm a little bit confused, so I'm not sure if I get it right.. :) As Hugo's pointed out, suddenly generating imaginaries where we used to throw errors will probably trip up the unwary) Right, but there should be a way to easily process imaginary and complex numbers in strings, however not by default. As for more complex string literals evaluating to numbers, I think that's something best left to either a user-written sub, or user-written fancy parser hacks. Up to Larry whether it goes in the base language, but I think I'd prefer not. If it will be easily possible to run some sub in the place where (with -w) 'Argument x isn't numeric in addition...' would be produced, than I can try to write such sub, or a whole module. I'm not saying that it should be in the core language, or turned on by default, I'd just like it to be easy to turn on and to use. Now I don't know how exactly to do that, but I would like to, at least, help with the implementation. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
raptor wrote: | It's bothered me that I can write 100_000 in my perl code, but if I have | a string 100_000 it'll evaluate to 100 when numerified. It would be | really weird if 10indigo became 10i, 1e3foobar became 1000, and | 10_000 became 10 in Perl 6 IMHO. ]- Agree if u want this in strings then use : $( 10i ) ndigo $( 1e3 ) foobar In your own code of course, it's easy now in Perl 5 $x=1e3.' foobar'; but the main problem is with external input, which could be 1_000 but I don't think $(1_000) (and I hope that the $(...) in input won't be evaluated anyway). - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
Aaron Sherman wrote: For example, zero-filled numbers are not converted to octal because many text files contain zero-filled numbers. The idea that 0cat is 0, but 0xat is 10 will confuse a lot of folk. It all should be at least possible to do, but not mandatory. If strings in numeric context are treated the same way as the parser would, then I think there need to be warnings for trailing garbage. There's already a warning for that. No, I think if you want 10_000 to be 1, you can always eval it, but I don't think anyone reading in text should expect that. I don't think that evaling input should be the best solution. In all of those proposition, the underscore seems to be the simplest and the less ambiguous one. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
Glenn Linderman wrote: On the other hand, there is a case to be made that any form of number that might get printed by perl's unformatted i.e. print 0+$var should be reconvertible back to a string via implicit numeric conversions of strings. I think the only thing that would affect would be imaginary numbers, if supported, and if enabled in the lexical scope of the conversion. Yes, good point. +$x should be still the same as $x, otherwise any implicit stringification could cause a lot of troubles. It would certainly seem reasonable to have a warning for numeric conversion of strings containing trailing garbage. At least under some level of strict-ness. There is already such warning. But I think it should also be way to get NaN in such cases. Or, perhaps a collection of string methods could be useful... $string.as_num # do the Perl usual implicit string conversion $string.is_num # same as as_num, but undef if trailing garbage $string.as_code_num # convert all numeric literals legal in code $string.is_code_num # same as as_ext_num, but undef if garbage That's definitely a good idea to have such methods but there also have to be way to define what to do with +$string. I think having some levels of that would be the best idea, with the lowest level even 5E3 is converted to 5 and with the highest pi*(2k+3iM)/12_650**1e-1 is converted to whatever it is, but the default is somewhere in the middle, close to that what we have now. That seems to be the only reasonable way. And besides, there could be some level of strictness where 123foo is NaN (whatever it will mean), not 123, where not the whole string is valid as number. (now there's a warning, but there should be warning by default and NaN if wanted)). - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN+NaNi
Jonathan Scott Duff wrote: It's bothered me that I can write 100_000 in my perl code, but if I have a string 100_000 it'll evaluate to 100 when numerified. It would be really weird if 10indigo became 10i, 1e3foobar became 1000, and 10_000 became 10 in Perl 6 IMHO. That should be the easiest. Just ignoring underscores in strings. Even if not by default, I think it should be made possible. I think that it also should be possible (however not by default) to output numbers that way in string context, with the chosen delimeter. So it would be possible to just say that I want my numbers in string context to always look like 10_000_000 or 10,000,000 or 10'000'000 or whatever. Now it's to hard with clever regexes, it's very common and should be easier. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Damian Conway wrote: But I assume that == means numerically equal (and here I could be wrong). If what I assume is true however, then anything which doesn't have any numerical meaning, numerically compared to anything (even to itself) should not return the misleading result that the two compared values are numerically equal. Then again, if you tell me that == operator doesn't mean numerically equal, I will agree that NaN==NaN should be true even considering that 'cat'=='dog' will also be true. But 'cat'=='dog' *is* true. Numerically, they *are* equal. They are equally not numbers. One should certainly get a warning (and one will if warnings are enabled), but this expression shouldn't return false. OK, now I see your point even better. The difference in our points is that I suggested that numerical comparison of NaNs shouldn't make sense. But yes, two NaNs are equally not numbers. Now the question is if being a NaN should be the special case of numerical meaning or the lack of any numerical meaning. I don't think that the one idea is more correct than another, maybe that's the matter of taste, however they are mutually exclusive, so one of them has to be chosen. I joined this thread, because I thought that assuming that NaN!=NaN idea is just ugly and thus not worth deeper discussion, was oversimplifying and the problem deserves a little more of controversy. However I wasn't suspecting that NaN semantics will grow to one of the most important threads here. Sigh. I *do* see your point of view (Laziness), but I still have immense difficulty with the notion that: $x == NaN doesn't return true if $x contains NaN. Well, Laziness is very important to me, but here it won't be hurt much, as in fact $x==$y!=NaN wouldn't be used very often. Only when numerically comparing two unknown values, and I can't remember when I did it last time. Maybe when sorting but with sorting it doesn't matter if every NaN is equal or not. Hmmm, maybe NaN==NaN would make starship operator simpler..? Anyway, even with NaN==NaN 'text'!=0, unlike Perl 5, where 'text'==0, which could've been the main problem with == operator. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Dan Sugalski wrote: At 08:37 AM 10/9/2001 -0700, Brent Dax wrote: For consistency, I'd prefer to use is: 3+(2 is i). Well, the convention is suffixing an imaginary number with an i. I don't think we'd be too well served to go a different route. So the imaginary numbers would be standard literals? Like $x=2+10i; Great idea, as well as sqrt(-1) returning 1i istead of raising the exception. BTW, I was thinking once that numeral literals like 4k or 10G (meaning 4*2**10, 10*2**30) would be very nice. What do you think? - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Trond Michelsen wrote: BTW, I was thinking once that numeral literals like 4k or 10G (meaning 4*2**10, 10*2**30) would be very nice. What do you think? I think the meaning of the suffices are sufficiently vague as to make me uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case for both, and that's never a good sign. There's always the possibility of supporting SI's binary prefixes ;) I thought about it but it wouldn't work with imaginary numbers. :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Dan Sugalski wrote: I'll leave that for Larry to decide. I'm just thinking of all the 60G hard drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm resistors that are really 1000 ohms. (Well, give or take a bit for ambient temperature...) I prefer powers of 1024 because it help a lot more than powers of 1000. But if you think that the ambiguity is the only problem then use kbin; / use kdec; or use k1000; / use k1024; pragmas could solve it. I would prefer to use k1024 by default (with warning. and maybe with use strict the default would not be allowed, i.e. user have to choose one to use it. but I would like the default 1024 to work with one-liners) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Glenn Linderman wrote: An excellant idea. I was unaware of that standard, but was trying to head that direction in my last posting. Someone thought it wouldn't work with imaginary numbers, but there actually is no ambiguity if the imaginary i must immediately follow the number, and the metric suffix follow that, if both exist. You're right, I was assuming that the imaginary i must be in the very end of literal, and was even thinking about using j instead. :) OK, that seems to be the nicest solution. So we have: 5Gmeans 5 * 10**9, 5 giga 5Gi means 5 * 2**30, 5 gibi 5iG means 5 * 10**9 * i, 5i giga 5iGi means 5 * 2**30 * i, 5i gibi (I really like those binary prefixes names!) Very nice, unambiguous, compatible with SI standard, no need for any pragmas, I'm really impressed! - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Buddha Buck wrote: As someone else pointed out, the e notation is good for powers of 10. How about a corresponding b notation for binary exponents? 4_294_967_296 == 4b30? I really like that idea, it makes the floating point (scientific?) notation symmetric and consistent with X/Xi SI prefixes. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Jonathan Scott Duff wrote: On Wed, Oct 10, 2001 at 10:21:38AM -0700, David Whipp wrote: First this thread tells me that 123foo will be 123 in numeric context. Now I find myself wondering what 123indigo evaluates to! It would evaluate to 123. If use complex is in effect, it would evaluate to 123i. At least that's the position I'm taking at the moment ;-) 123i unless of course we use nano prefix (postfix?), then it would be 0.00123i of course. ;) - RaFaL Pocztarski, [EMAIL PROTECTED]
