"Digit Grouping" is messed up

[IHarwell]

(01-01-2022 06:03 PM)Wes Loewer Wrote:  So it sounds like you are saying that the Java's output can be localized, but I was asking about the code itself. In other words, can

Code:

    double d = 1.2345;

be localized to accept

Code:

    double d = 1,2345;

like the Prime can?

Not typically. It creates problems with the language grammar. For instance, consider two functions:

Code:


f(x) { return x^2; }
f(x,y) { return x*y; }

Now, you have a problem if the user calls:

Code:

f(123,456)

Suddenly, your "formatting choice" changes the meaning of that function call unless the language has subtle rules to prevent the issue. Such rules can be done, but it's pretty low on the list of priorities for things I'd like the devs to put their time into.

It doesn't help that "subtle rules" and "scripting language" do not generally go well together from a design standpoint.

I can't help but notice that both function overloading and comma-separators are allowed in PPL. The method they use to address this collision of features is rather heavy-handed, short-sighted, and can really cause issues for sharing programs.

You have to change the second separator to something other than the first, but they allow symbols that are quite confusing for the second separator, such as ".", "&", "\" or even "*".

That last one is a real problem. What should f(123*456) return? Should that ever change based on a "formatting" choice? The number of ways to break programs or introduce subtle bugs using this is really quite staggering.

There are good reasons that programming languages tend to be as strict about their grammar as they are.