Ticket #275 (new defect)

Opened 1 year ago

Last modified 1 month ago

(Resolved) Builtins: Number.parse

Reported by: lth Assigned to: lth
Type: defect Priority: minor
Milestone: Component: Spec
Version: Harmony Keywords:
Cc: brendan, pascallouis

Description (last modified by lth) (diff)

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.

Attachments

Change History

  Changed 1 year ago by brendan

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

/be

  Changed 1 year ago by pascallouis

  • cc changed from brendan to brendan, 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.

  Changed 1 year ago by 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

follow-up: ↓ 9   Changed 1 year ago by 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();
}

  Changed 1 year ago by 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

  Changed 1 year ago by pascallouis

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

  Changed 1 year ago by 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

  Changed 1 year ago by 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).

in reply to: ↑ 4   Changed 1 year ago by 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.

  Changed 1 year ago by 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.

  Changed 1 year ago by lth

See #233 for the discussion on AnyNumber, FloatNumber.

  Changed 1 year ago by 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

  Changed 1 year ago by lth

  • description changed from 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, 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. to 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.

Yes, good point about + and -.

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

  Changed 1 year ago by lth

  • owner set to lth
  • priority changed from major to trivial
  • component changed from Proposals to Spec
  • summary changed from Builtins: Number.parse to (Resolved) Builtins: Number.parse

Approved at the 15 Jan 2008 phone meeting.

  Changed 7 months ago by airforce1

  Changed 1 month ago by David-Sarah Hopwood

  • priority changed from trivial to minor
  • version changed from 4 to Harmony

Proposal still relevant to ES-Harmony.

Note: See TracTickets for help on using tickets.