Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83181
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
Message-ID: <54E5E438.7050903@gmx.de>
Date: Thu, 19 Feb 2015 14:25:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 Rick Widmer <vchkpw@developersdesk.com>,
 internals@lists.php.net
References: <54E5456E.4020103@gmx.de> <54E54E1E.1010906@lerdorf.com> <54E58F06.1040707@developersdesk.com> <54E594CA.5010200@lerdorf.com>
In-Reply-To: <54E594CA.5010200@lerdorf.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Digit separators for numeric literals
From: cmbecker69@gmx.de (Christoph Becker)

Rasmus Lerdorf wrote:

> On 02/18/2015 11:21 PM, Rick Widmer wrote:
>
>> how about:
>>
>> my_func( '1,000.04' );   //if you want to use separators there.
> 
> The problem with that is that the world is split. The other half, or
> actually more than half, would write that as '1.000,04'. There is no way
> we would want to take sides on that one. And we have support for
> locale-based number formatting and parsing via numfmt_format() and
> numfmt_parse(). If we were going to add a separator for literals, the
> only real low-ascii choice is _ which is also used by Ada, D, Java, Perl
> and Ruby.

I agree that _ is most reasonable, mainly because it is used by other
languages also.

> I was 90% kidding about using a Unicode character, but if you think
> about it a bit, most people are using IDEs or at least smart scriptable
> editors, it wouldn't be that much of a stretch to picture your editor
> pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9).
> It would be easy to make the parser ignore that character in numeric
> literals. Much easier than working out the various issues with _ anyway.

Which issues do you see?  IMHO it doesn't make much sense to use a digit
separator in a trailing or leading position, because that wouldn't
improve readability.  So PHP could make the same restrictions as Java
with regard to integer and float literals[1] (basically that the
underscore is allowed only between actual digits), in which case I don't
see any syntactic ambiguity.

Ignoring the _ in the scanner (IMHO there is no need to obtain it in the
token) doesn't seem to be harder than ignoring any other character.

[1] <http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10>

-- 
Christoph M. Becker