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 least
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote:
(Umm... what's a better name than coloned form? That term sounds
really... um... bad.)
How about:
- explicit radix
- dotted notation
- DSD (Dot Separated Digits)
--Dks
On Mon, Nov 25, 2002 at 10:06:13AM -0800, Michael Lazzaro wrote:
: With clarifications, and additional syntactic edge cases.
:
: The last remaining known numeric literals issue is whether we want to
: allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
: disallow it as being Way
On Friday, November 22, 2002, at 03:31 AM, Anton Berezin wrote:
This:
- radix 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Correct. It's an error, because radix 36 mandates coloned
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 in
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Correct. It's an error, because radix 36 mandates coloned form, and
the colon-form digit 253254255 cannot exist in base 256. AND since
With clarifications, and additional syntactic edge cases.
The last remaining known numeric literals issue is whether we want to
allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
disallow it as being Way Too Creepy. This version assumes that '.' is
allowed, but exponential
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.
Michael Lazzaro wrote:
snip
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
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 the novice.
On Mon, 2002-11-25 at 13:06, Michael Lazzaro wrote:
0x0 # ok, == 0
0x0.0 # ok
0x.0# ok
Given that .1 is wrong (from above), I would disallow it here simply for
consistency sakes.
0d1.1E5 # WRONG, exp not allowed in shorthand radix
0B0110
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 have
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
This:
- radix 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
%Anton.
--
| Anton Berezin| FreeBSD: The
On Thursday, November 21, 2002, at 04:41 PM, Andrew Wilson wrote:
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
_01.23 # wrong
01.23_ # wrong
Is _ not space eater, or was that not decided? If it is then aren't
these two just literals with space eaters.
On Friday, November 22, 2002, at 03:31 AM, Anton Berezin wrote:
This:
- radix 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Ick, good point. In theory, the second of those was
With the very latest corrections. The last remaining known numeric
literals issue is whether we want to allow '.' in explicit radix, e.g.
10#1.234, or whether we want to disallow it as being Way Too Creepy.
Am I missing anything else, or is this part done?
--- Numeric Literals ---
decimal
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
_01.23 # wrong
01.23_ # wrong
Is _ not space eater, or was that not decided? If it is then aren't
these two just literals with space eaters.
andrew
--
Capricorn: (Dec. 22 - Jan. 19)
You will soon be unwillingly
Dave Storrs writes:
On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
Michael Lazzaro writes:
depending on WYW . or the casting may be let to happen in two stages
: string - num - specific num type ,e.g. uint16
How about if we got adverbial on the problem:
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.
With the latest corrections:
--- 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
On Wednesday, November 20, 2002, at 11:01 AM, Dave Storrs wrote:
Actually, this would be a good reason to have a function called
literal -- if it went both ways. So, I could do this:
print literal(200+55):hex; # == print 0xff;
print literal(0xff)); # == print 255;
[EMAIL
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
On Sat, 2002-11-16 at 07:37, Michael Lazzaro wrote:
Due to ambiguities, the proposal to allow floating point in bases other
than 10 is therefore squished. If anyone still wants it, we can ask
the design team to provide a final ruling.
Why are we so hung up on spelling floating-point
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old oct/hex
: functions to do a similar both-way thing, such that:
What's a two-way function supposed to return if you pass it something
that has both a string and a numeric
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 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
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
and _I'm_ trying to promote the reuse of the old oct/hex
functions to do a similar both-way thing, such that:
[...]
but people just aren't biting, so far. Don't see why
not, I think it's keen.
There's the problem Larry
From: Martin D Kealey [EMAIL PROTECTED]
Date: 18 Nov 2002 11:50:14 +1300
On Sat, 2002-11-16 at 07:37, Michael Lazzaro wrote:
Due to ambiguities, the proposal to allow floating point in bases other
than 10 is therefore squished. If anyone still wants it, we can ask
the design team to
Date: Wed, 20 Nov 2002 10:54:18 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
exponential notation:
-1.23e4 # num
-1.23E4 # num (identical)
1.23_e_4# wrong
Lord Larry has ruled that _ can only appear between digits. I, for
one, do not see the reasoning behind this
On Wednesday, November 20, 2002, at 12:11 PM, Larry Wall wrote:
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old oct/hex
: functions to do a similar both-way thing, such that:
What's a two-way function supposed to return
On Wednesday, November 20, 2002, at 12:54 PM, Luke Palmer wrote:
My opinion: don't allow floating point arbitrary radix. It's uncommon
enough that it could be done with a module. It would be trivial with
a grammar munge.
I tend to agree. The amount of time you're going to want to use
From: Luke Palmer [mailto:[EMAIL PROTECTED]]
From: Martin D Kealey [EMAIL PROTECTED]
10:1.2.3:4.5:6== 12345
2:1:1:1110== 0x6000
60:22.0.-27::-2 == 21.9925
I've always wanted to meet The Devil. :)
Honestly, I can't tell by looking at that what those are
Larry Wall [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old oct/hex
: functions to do a similar both-way thing, such that:
What's a two-way
On Thu, 2002-11-21 at 09:54, Luke Palmer wrote:
I've always wanted to meet The Devil. :)
You're welcome :-)
Honestly, I can't tell by looking at that what those are supposed to
mean. And I'm not putting any numbers that ugly into my Perl soup.
Perl 6 is trying to Idecrease obfuscation.
I
On Wed, Nov 20, 2002 at 12:11:21PM -0800, Larry Wall wrote:
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old oct/hex
: functions to do a similar both-way thing, such that:
What's a two-way function supposed to return if
On Wed, Nov 20, 2002 at 01:23:04PM -0800, Dave Whipp wrote:
Larry Wall [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old oct/hex
:
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
On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
Michael Lazzaro writes:
Let's summarize some of the string-to-num issues:
my int $i = literal 0xff; # 255
(3) -- We want to be able to parse a string as a number using a very
_specific_ rule; for
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, 0C0123, and
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
Hmm, interesting. Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.) For example:
4294967296:1.2.3.4 #
Graham Barr wrote:
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
Or how about run-time evaluated versions?
# Set a timer to run for either a day or an hour, depending
$timer = 60*60*($use_days ? 24 : 1):10
Then it is no longer a literal is it.
True. But this might:
On Mon, Nov 18, 2002 at 10:47:17AM -0600, Garrett Goebel wrote:
I've tried asking if lists are literals or not... but I've been Warnock'd.
I have comments to make on several things posted recently. I'm waiting
for my boss to ask our legal department if I can contribute. There may
be others
On Mon, Nov 18, 2002 at 03:14:52PM +, Graham Barr wrote:
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
24*60*60:10 # one day in seconds, easy representation
And the advantage of that over 24*60*60*10 would be ?
Well, for one thing, my version means 1 day and
On Monday, November 18, 2002, at 07:14 AM, Graham Barr wrote:
Are we not just getting too carried away with all this base
of literals.
I also think -documentation is the wrong place to discuss this.
Yep. I'll try and come up with a summary today or tomorrow that marks
all the *known*
--- 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
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
summary list
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
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 where
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,
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 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
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
Dave Storrs wrote:
[...] Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.) For example:
4294967296:1.2.3.4 # working with a really big base, hard to grok
On 15 Nov 2002 at 12:02, Dave Whipp wrote:
A couple more corner cases:
$a = 1:0; #error? or zero
Shouldn't base-1 be:
1:0 == 10:0
1:1 == 10:1
1:11 == 10:2
1:111 == 10:3
1:1010111 == 10:5
etc..
Also 0:0 == 10:0
--
Markus Laire 'malaire' [EMAIL PROTECTED]
On Sun, Nov 17, 2002 at 03:01:08PM +0200, Markus Laire wrote:
On 15 Nov 2002 at 12:02, Dave Whipp wrote:
A couple more corner cases:
$a = 1:0; #error? or zero
Shouldn't base-1 be:
1:0 == 10:0
1:1 == 10:1
1:11 == 10:2
1:111 == 10:3
1:1010111 == 10:5
etc..
Nope. Remember, for
Date: Sun, 17 Nov 2002 18:51:05 -0800
From: Dave Storrs [EMAIL PROTECTED]
Therefore, in base 1, you can only use the digit 0. (Actually, I
think base 1 is a corner case--you only get one digit, but that digit
is 1, so you can represent any number N by making N tally marks.)
Well, if you
On Sun, Nov 17, 2002 at 08:13:58PM -0700, Luke Palmer wrote:
Date: Sun, 17 Nov 2002 18:51:05 -0800
From: Dave Storrs [EMAIL PROTECTED]
Therefore, in base 1, you can only use the digit 0. (Actually, I
think base 1 is a corner case--you only get one digit, but that digit
is 1, so you
On Thu, Nov 14, 2002 at 01:33:31PM -0600, Jonathan Scott Duff wrote:
On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
1.23_e_4# ok?
Hrm. This one is annoying, but I think it should be okay.
Are you sure? If so, can you explain why for me, because I don't
think it
On Fri, Nov 15, 2002 at 12:02:02PM -0800, Dave Whipp wrote:
$b = 4294967296:1.2.3.4 # base 2**32
Hmm, interesting. Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.)
Richard Nuttall wrote:
How about
my $a = 256:192.169.34.76;
my $b = $a.base(10);
my $c = '34:13.23.0.1.23.45'.base(16);
This coupling makes me nervous. A number is a number: its value is not
effected by its representation.
I can see that, in some scripts, it might be useful to define a
Dave Whipp writes:
Richard Nuttall wrote:
How about
my $a = 256:192.169.34.76;
my $b = $a.base(10);
my $c = '34:13.23.0.1.23.45'.base(16);
This coupling makes me nervous. A number is a number: its value is not
effected by its representation.
I can see that, in
On Thursday, November 14, 2002, at 01:27 PM, Dave Whipp wrote:
And now I know why we can't use C. as a floating point in base 16:
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
Due to ambiguities, the proposal to allow floating point in bases other
than 10 is therefore squished. If anyone still
Michael Lazzaro [EMAIL PROTECTED] wrote
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
Due to ambiguities, the proposal to allow floating point in bases other
than 10 is therefore squished. If anyone still wants it, we can ask
the design team to provide a final ruling.
So what about
10:1.5
is
On Friday, November 15, 2002, at 10:51 AM, Dave Whipp wrote:
Michael Lazzaro [EMAIL PROTECTED] wrote
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
Due to ambiguities, the proposal to allow floating point in bases
other
than 10 is therefore squished. If anyone still wants it, we can ask
the
A couple more corner cases:
$a = 1:0; #error? or zero
$b = 4294967296:1.2.3.4 # base 2**32
printf %32x, $b;
0001000200030004
Dave.
Let's summarize some of the string-to-num issues:
(1) -- A number is just a number, regardless of how it's put in.
Therefore:
my int $i = 0xff;
my int $i = 255;
result in the identical number, 255, being placed in $i. Once it's in
there, there's no way to tell what format it
Michael Lazzaro writes:
Let's summarize some of the string-to-num issues:
my int $i = literal 0xff; # 255
(3) -- We want to be able to parse a string as a number using a very
_specific_ rule; for example, if a user is expected to enter a value in
a specific format, like
0x00ff # hex value ff
'0x00ff'# integer value 0, with trailing 'x00ff'
I think ways to solve this should be open to discussion. Hopefully
Luke can give us some proposals, since he's writing that part.
The behavior described there should stay. If you want literal-like
Michael Lazzaro [EMAIL PROTECTED] wrote
exponential:
-1.23e4 # num
-1.23E4 # num (identical)
And now I know why we can't use C. as a floating point in base 16:
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
There would be an ambiguity as to the meaning of 'e', so it should probably
On Thursday, November 14, 2002, at 10:28 AM, Michael Lazzaro wrote:
W/ regards to numeric literals, here are a number of
examples/proposals that we should verify the behavior of. Anything I
missed?
Oh, this is ignoring the issue of floats in bases other than 10. I'm
not dissing the idea,
bin/oct/hex literals:
0b0110 # bin
0c0123 # oct
0x00ff # hex
0x00fF # hex, == 0x00ff
0x00FF # hex, == 0x00ff
0xf_f # ok
0x_ff # ok
I thought that bin/oct/hex literals where deprecated in favour of
explicit radix
On Thursday, November 14, 2002, at 10:37 AM, Angel Faus wrote:
I thought that bin/oct/hex literals where deprecated in favour of
explicit radix notation. But maybe I am wrong. I am?
AFAIK, I don't think it has been decided. Some people like the old
format, some people like the radix format,
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Thu, 14 Nov 2002 10:28:38 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
Of course, a key issue is that, in perl5, the treatment of numeric
literals is not at all the same as the treatment of stringified
numerics. For example:
On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
01_._23 # wrong?
this one has to be wrong by Larry's decree that _ is only valid
between digits (hexits?)
1.23_e_4# ok?
Hrm. This one is annoying, but I think it should be okay.
20:1.G.K# base 20
On Thu, Nov 14, 2002 at 12:22:03PM -0700, Luke Palmer wrote:
The behavior described there should stay. If you want literal-like
interpretations of strings, use the Coct function. The name of that
function should probably be changed to something more appropriate.
Clit, Cliteral, Cnum
74 matches
Mail list logo
