Re: JSONNumber - optional decimal

2010-06-09 Thread Oliver Hunt
On Jun 8, 2010, at 8:46 PM, Garrett Smith wrote: Today I looked for a good json regexp tester and finding nothing, decided to write one. The strategy that occurred to me was to first define a regex for the literal components (ES5 lumps literal value into the JSONValue alongside JSONObject

Re: JSONNumber - optional decimal

2010-06-09 Thread Garrett Smith
On 6/8/10, Oliver Hunt oli...@apple.com wrote: On Jun 8, 2010, at 8:46 PM, Garrett Smith wrote: [...] IF anyone has a correct JSON parser, I would appreciate it. Also, are there any good test suites for JSON? I spent quite a bit of time ensuring JSC's JSON parser exactly matched the spec

mailing list to dicuss incorporating es-libraries into UA?

2010-06-09 Thread Jonathan Chetwynd
mailing list to dicuss incorporating es-libraries into UA? is there a mailing list to discuss how, when and which scripts are incorporated into UA? why for instance text input via forms is in html, but not available** to svg? and looking slightly further ahead, there is a whole variety

EcmaScript i18n API proposal

2010-06-09 Thread Nebojša Ćirić
We would like to propose adding i18n API to the EcmaScript standard (either as standard library or part of the language). Our current proposal is at EcmaScript i18n APIhttp://docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Rohl=en (open to edits). We will migrate the document to the

Re: Re: JSONNumber - optional decimal

2010-06-09 Thread Douglas Crockford
On 11:59 AM, Oliver Hunt wrote: That said I think allowing '1.' (etc) makes sense as it's fairly standard across multiple programming languages, and I am unaware of any specific reason for disallowing it. In the long term I don't see changing the grammar to allow a trailing period as being

Re: Re: JSONNumber - optional decimal

2010-06-09 Thread Mark S. Miller
On Wed, Jun 9, 2010 at 7:43 AM, Douglas Crockford doug...@crockford.comwrote: On 11:59 AM, Oliver Hunt wrote: That said I think allowing '1.' (etc) makes sense as it's fairly standard across multiple programming languages, and I am unaware of any specific reason for disallowing it. In the

Re: EcmaScript i18n API proposal

2010-06-09 Thread Mark S. Miller
Hi Nebojša, I notice in your informal specification notation *//* *The base language code (typically a ISO-639 language code).* *// @type {string} * Locale.language which I assume means that instances of Locale have a language property. However, this notation would more naturally

Re: EcmaScript i18n API proposal

2010-06-09 Thread Erik Corry
On the face of it this proposal introduces a huge new area of incompatibilities between engines in terms of both which locales are supported and the details of the locales. The example (German phonebook locale) is suitably obscure as to illustrate the hopelessness of expecting JS engines to