Re: Ambiguity of parsing numbers with underscores/methods
Luke Palmer wrote: On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, 1_234; # surely 1234 1e23; # surely 1 * 10**23 1._5; # call of method _5 on 1? 1._foo; # call of method _foo on 1? 1.e5; # 1.0 * 10**5? 1.efoo; # call of method efoo on 1? 1.e_foo;# call of method e_foo on 1? 0xFF.dead; # call of method dead on 0xFF? I think we should go with the method call semantics in all of the ambiguous forms, mostly because no such method: Int::e5 is clearer than silently succeeding and the error coming up somewhere else. Luke 1.e5# all of these... 1._e5 # 1._0e5 # 1.e_0_5_# == 1 * 10^5? The longest-possible-token metarule, common among languages, would want all of these to be numbers. I see that perl5's lexer has this rule (3rd edition, p49); is not perl6's specced to have it as well? Likewise, if hex numbers allow fractions, 0xDE_AD.BE_EF # 57005.7458343505859375 ? 0xde_ad.be_ef # same should be taken as a number. (Naturally 'e' as exponent marker is here problematic.) If one wants to call a method on a number, surely one may follow the usual advise and write 1 ._5 1 ._foo 1 .efoo 1 .e_foo 0xFF .dead ? -- Roger Hale
Re: (OT) Re: Perl development server
Vadim Konovalov wrote: Icelandic: laukur (Incidentally, none of you will ever guess how to correctly pronounce that.) Russian: luk (pronounced similar to English look). For some reason, Icelandic translation of onion is much closer to Russian than any other variants... The English leek is another cognate (as a word, of the laukr; as a plant, of the onion)...
Re: mod/div
Just a nit, for the record, with no great perl relevance: TSa (Thomas Sandla) wrote: But what is the first quarter of year 0? 0.25? Sure (of course if there were a year 0 instead of becoming 1 BCE) And the last quarter of year -1? -0.25? Sure That works numerically, but March of a year is then not always the same difference to the start of the year, but you seem to have changed the question (first quarter to last quarter) but called both quarters March? rather: [] And the _first_ quarter of year -1? -0.75? Sure [] That works numerically, _and_ March of a [] year is then _ always the same difference to the start of the year, (although it's the end of March and April Fool's Day (-04-01) that's a quarter after New Year's Day.) [ although written differently as a decimal substring; two's complement numbers with positive fractions do this better, being 0b.01 in both cases.] paraphrasing It lets me do things without bounds checking and correct the ranges later, because, e.g., plugging in January -20, 0 AD yields the correct result for December 11, 2 BC. Such calculations break dramatically across 0 if you use the definition found in some C implementations, where (-3 mod 5) == -3. (Note that this recognizes that 0 CE == 1 BCE, and that January -20 brings you back into the previous December.)
Re: reduce metaoperator on an empty list
Damian Conway wrote:
Deborah Pickett wrote:
You are going to see empty lists more often than you think in
expressions like
$product = [*] @array;
and having to write that as
$product = [*] 1, @array;
just to protect against a common case doesn't exactly flaunt Perl's
DWIMmery to me. I *have* to write 1 there, or otherwise the reduce
meta-operator isn't calculating the product when there are items in
@array. This hardly makes sense from a Huffman perspective. Someone
please convince me otherwise.
The problem is that writing 1 there is still wrong in the no arguments
case. The product of zero numbers cannot possibly be one in any common
sense interpretation. (And, yes, I'm perfectly well aware of the
mathematical interpretations in which it does make sense...that's not
the point.)
Sure it is: it's the number you have before you've multiplied any
numbers into it. It's the center of the world, for multiplication. If
you started anywhere else you wouldn't end up at the correct product.
If you started at zero you'd never get off the dime.
What you want is:
$product = ([*] @values err 0);
Not what I'd ever want...
Or:
$factorial = ([*] 1..$n err 1);
So what you want is not an identity value as default (which isn't even
possible for many operators, as Luke pointed out), but a predictable
failure value as default, so you can intercept that failure and choose
your own outcome in the edge case.
Damian
This is why I would rather the o - [o] circumfixion left [o] an infix,
not prefix operator. I would rather be explicit about my identity:
$product = 1 [*] @array;
$factorial = 1 [*] 1..$n;
$text = [~] @lines;
$balance = $balance [-] @debits;
or
$balance [-]= @debits;
which last suggests how you don't always want to start at the identity,
and how [-] makes sense in this context.
Unfortunately it doesn't handle the case of join $sep, @strings:
[{$^a ~ $sep ~ $^b}] @strings
(yes, I know that's not going to pass lexical analysis) since, as was
pointed out, you get an extra $sep at the front.
yours,
Roger Hale
Re: Perl development server
Juerd wrote: If you want access, please let me know. I will send you a temporary password by e-mail, that I expect you to change the first time you get the chance. I would like an account, name 'spinclad'. The need for svn, ghc and such has finally pushed me to upgrade my home debian box to sarge, and I'm still looking for a package with ghc6.4, or the tuits to build one myself. (Doubtless someone will point me to an overlooked message announcing one months back...) I think having a joint testbed machine to look over, test things, compare with home, and help with would be a good use of my time at this point. Also, this new machine needs a hostname. Please help me think of a cute name! I prefer a short hostname with less than 9 letters. I like onion, too... maybe 'geode' later, when perl6 has been cast in stone. (Though then we wouldn't need a dev server...) Regards, Roger Hale [EMAIL PROTECTED]
Re: Hyper operator corner case?
Thomas Sandla wrote: John Williams wrote: Good point. Another one is: how does the meta_operator determine the identity value for user-defined operators? Does it have to? The definition of the identity value---BTW, I like the term neutral value better because identity also is a relation between two values---is that $x my_infix_op $neutral == $x. One set of cases that doesn't seem to have come up in discussion: (1, 3, 2) - (83, 84, 81, 80, 85) Should this give (-82, -81, -79, -80, -85) as it would by hallucinating 0 (neither a left-identity nor left-neutral element for subtraction strictly, but at least a natural left pivot element), or (-82, -81, -79, 80, 85) as by hallucinating $neutral - $x == $x? This latter $neutral in fact doesn't exist among ordinary numbers, and I would call it algebraically unnatural: for all (other) $n, $n - ($a + $b) == ($n - $a) - $b or, as you increase $a by $b, $n - $a decreases by $b (a sort of contravariance), but $neutral - ($a + $b) == $a + $b == ($neutral - $a) + $b ! This violates algebraic relations I would prefer to rely on, both in my own reasoning and that of the compiler and other program-handling programs. Best regards Roger
