(Resolved) Builtins: Number.parse

[lth]

We probably want a number parser that understands the numeric suffixes i, u, d, and m.

See #274 for background on why parseInt and parseFloat should retain their ES3 semantics.

For ES4, I propose that we add Number.parse, which parses a sequence of blanks, an optional sign, a valid number literal including suffix, and optionally more blanks, and returns the number. It should have the same semantics (wrt ranges and other interpretations) as the language proper, so if 123456789012345i is (in)valid as an ES4 literal then it is (in)valid here too.

I propose that Number.parse should not allow random junk to follow what it parses, though that is a secondary point.

[brendan]

Agree on adding Number.parse, and agree too on future-proofing by not allowing random junk after.

/be

[pascallouis]

Having a parsing function seems fair, but I don't believe it should be on Number which has only a small relation with int, double, etc. Why not add

int.parseInt
double.parseDouble
etc.

and a global function

parseNumber(s : string) : (int, uint, double, decimal);

a la parseInt/parseFloat except that it has the same semantics as the language parsing.

[brendan]

Number.parse is by analogy to Date.parse, and a better extension than a global parseNumber function given the greater likelihood of the latter colliding with some pre-existing function.

int.parse and double.parse were suggested (these method names need not restate the types, I think), but the point here is that you often don't know ahead of time what type to expect. Since we have parseInt and parseFloat (blame me, it was 1995, I was cloning names from Java, and I was in a hurry), we see little to gain in making int.parse and double.parse aliases. But please try to sell this idea harder. Making parallel T.parse methods for built-in types T is pretty.

BTW, (int, uint, double, decimal) is spelled AnyNumber ;-).

/be

[pascallouis]

parseNumber is crap, ok. But Date.parse produces a Date whereas Number.parse never produces a Number... It doesn't look nice (to me, at least) to have this parsing functionality there.

T.parse has a nice an precise return type, I might want to write

var i : int = int.parse(foo);

and not

var tmp : RealNumber = parsingFunctionHere(foo);
if (tmp is int) {
  let i : int = tmp;
} else {
  throw new TypeError();
}

[brendan]

Agreed, int.parse is pretty and has its uses, compared to parseInt even. Ditto double.parse.

Number.parse can return an AnyNumber?, so I don't see the problem with it being a static method of the Number wrapper-class. Nothing here is perfectly aesthetic, but in for a penny... ;-).

/be

[pascallouis]

Number.parse returns values with type RealNumber? not AnyNumber?, right? Why would it return a wrapper?

[brendan]

Sorry, I didn't get what you meant by RealNumber -- thought you were talking about a future addition of constructive reals or something like that. You must mean

type RealNumber = (int, uint, double, decimal)

if I follow (and that's what I meant in two comments ago, not AnyNumber). Besides the potential confusion with mathematical real numbers, this seems a useful type. I swear Lars already defined it somewhere, but I can't find it in the RI or the overview.

/be

[pascallouis]

The page http://wiki.ecmascript.org/doku.php?id=proposals:numbers&s=realnumber#open_issues defines RealNumber, which is indeed a confusing name for (int, uint, double, decimal).

[lth]

Replying to pascallouis:

parseNumber is crap, ok. But Date.parse produces a Date whereas Number.parse never produces a Number...

Date.parse produces a primitive number (a double) in ES3, not a Date.

[lth]

There is no RealNumber, we decided not to do this in order not to be too constraining on future developments. (I believe you were on the call but busy handling a child :-) There is a FloatNumber, though.

IMO the return typing of the function is irrelevant because all the numeric types are interconvertible, so if Number.parse returns (int,uint,double,decimal) then any numerically typed context can receive the value even in strict mode. Furthermore, since Number.parse handles suffixes and does not accept random junk, it will only parse actual numbers. The only job it will not handle is to parse values of precisely one given format; eg, int.parse would reject "1.0" but Number.parse will not.

Though I see the motivation for int.parse et al, and though the complexity increase with four functions (with different boundary cases) is slight, it has been our position that we are not really in the library-building business.

Pascal, should double.parse("1") return 1.0 or should it reject it because that's an int literal? What should decimal.parse("1") do?

My point is merely that Number.parse probably serves almost all purposes and everyone else is encouraged to go with a regular expression preprocessing step to get more precise behavior.

[lth]

See #233 for the discussion on AnyNumber, FloatNumber.

[brendan]

Are + and - unary operators (!) parsed by this proposal? Should they be?

IIRC waldemar raised the question of whether the new parse method(s) handle single tokens in the lexical grammar (surrounded by optional blanks), or common input parsing cases (numerical data in an HTML spreadsheet-table, e.g.). The blank chomping already in this proposal says the latter, but then what about +/-?

/be

[lth]

Yes, good point about + and -.

I have updated the proposal to allow an initial sign, following the initial blanks.

[lth]

Approved at the 15 Jan 2008 phone meeting.

[airforce1]

thanks get a nice air force ones

[David-Sarah Hopwood]

Proposal still relevant to ES-Harmony.