On Monday, November 25, 2002, 7:59:01 PM, you (mailto:[EMAIL PROTECTED])
wrote:
>> you'll have to write the code so that compiler knows how to handle
>> it. While not overly hard, I think its a little much for something
>> that should be provided in the core. I think the design team should
>> at
> Date: Mon, 25 Nov 2002 14:49:25 -0500
> From: "Joseph F. Ryan" <[EMAIL PROTECTED]>
>
> I think "easy enough with a grammar munge" gets tossed around way too
> often; don't forget, in addition to having to know how to hack the core
> grammer (which I assume won't be for the novice;
It's not for t
Michael Lazzaro wrote:
Hmm, that's not overpoweringly ugly. Looks nice, even. The fact that
it doesn't generalize is a little awkward.
I'm still thinking that, unless someone comes up with a really
compelling real-world reason to *have* floats in bases other than 10,
we shouldn't ask the
On Mon, Nov 25, 2002 at 09:25:32AM -0800, Michael Lazzaro wrote:
> (Ooooh, there's another idea we _SHOULDN'T_ pursue... adding postfix
> '%' to mean 'percent', but in any radix. So 0x80% of 0x10 would be
> 0x08 !)
And here you give the PERFECT example as to why this idea shouldn't be
pursued.
On Sunday, November 24, 2002, at 04:16 AM, Richard J Cox wrote:
We could adopt the C99 version and use "p" or "P" for hex decimal
values (this, reportedly, allows certain values not expressible in
decimal for floats to be specified).
Thus
0x.4Ap10
0xA.BCDp-15
(The exponent cannot be i
On Wednesday, November 20, 2002, 6:16:41 PM, you (mailto:[EMAIL PROTECTED])
wrote:
> On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote:
>> On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
>>> - floating point becomes allowed in explicit radix (and 0b,0c,0x)
>>
>> How can one h
On Wed, Nov 20, 2002 at 10:16:41AM -0800, Michael Lazzaro wrote:
: We probably couldn't get away with it, though I guess the only one that
: really changes is binary. Of course, as you pointed out, we don't
: _need_ to have 0b, 0x at all, they're just for backwards brain
: compatibility. I thi
On Wed, Nov 20, 2002 at 10:31:06AM -0800, Michael Lazzaro wrote:
:
: On Tuesday, November 19, 2002, at 10:26 PM, Dave Storrs wrote:
: >I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to
: >the forms with lower-case base markers, right?
:
: Huh, dunno. Let's ask for a ruling on
On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
> - floating point becomes allowed in explicit radix (and 0b,0c,0x)
How can one have floating point if "E" is a valid digit?
0x1.0e1 # 1.054931640625 or 16 ?
Has any consideration been given to using letters other than a~f in the
second pos
On Tuesday, November 19, 2002, at 10:26 PM, Dave Storrs wrote:
I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to
the forms with lower-case base markers, right?
Huh, dunno. Let's ask for a ruling on that.
-0xff # ok
-0x00ff # ok
Are these two identical?
On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote:
On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
- floating point becomes allowed in explicit radix (and 0b,0c,0x)
How can one have floating point if "E" is a valid digit?
0x1.0e1 # 1.054931640625 or 16 ?
Oops, sorry
On Mon, Nov 18, 2002 at 10:57:10AM -0800, Michael Lazzaro wrote:
>
> --- Numeric Literals ---
>
> bin/oct/hex notation:
>
> 0b0110 # bin
> 0c0123 # oct
> 0x00ff # hex
> 0x00fF # hex, == 0x00ff
> 0x00FF # hex, == 0x00ff
I would assume that 0B0110, 0C0
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
--- Numeric Literals ---
62:zZ # base 62 (?)
62:z.Z # base 62 (identical?)
62:z_Z # base 62 (identical?)
62:Zz # base 62 (not identical?)
Doh! That shouldn't be in there anymore... for bases
I've updated the literals tests to fully account for the radix notation;
and I've also updated the tests to use the new radix#(number):(number)
notation. Let me know if anyone finds any errors.
Find them at:
http://jryan.perlmonk.org/images/literals.tar.gz
Michael Lazzaro wrote:
--- Numeric L
On Monday, November 18, 2002, at 12:48 PM, Garrett Goebel wrote:
I went back through those posts, and I found where you suggested
0c0123... but I can't find a post from Larry confirming it.
It's not confirmed, just wild speculation. If we're reasonably sure we
don't have any gaping errors in
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
> On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote:
> > In perl5, octal is signified by the leading zero. There is no 0c0123
> > notation.
>
> Right, but on p6l we had been talking about eliminating the assumed
> octalness of 0123,
On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote:
In perl5, octel is signified by the leading zero. There is no 0c0123
notation.
Right, but on p6l we had been talking about eliminating the assumed
octalness of 0123, therefore requiring us to come up with an alternate
syntax, e
Michael Lazzaro wrote:
>
> decimal notation:
> 123 # int 123
> 0123 # int 123
[...]
> 0c0123 # oct
[...]
> - need to verify that 0b1, 0c1, 0x1 are still allowed
Found a problem:
perl -e "print 0123"
gives: 83
perl -e "print 0c0123"
gives:
Bareword found
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
Eek, that one was short-lived! No problem: if Larry decides on Ada
syntax, the following changes happen:
s/:/#/ (for explicit radix)
s/./:/ (for dotted -- er, coloned -- form)
- floating point becomes allowed in
--- Numeric Literals ---
decimal notation:
123 # int 123
0123 # int 123
123.0 # num 123.0
-123 # int -123
0_1.2_3 # ok
_01.23 # wrong
01.23_ # wrong
01_._23 # wrong
1__2# wrong
exponential notation:
-1.23e4
20 matches
Mail list logo
