On 8/13/2015 3:51 AM, Sönke Ludwig wrote:
> These were, AFAICS, the only major open issues (a decision for an opt() variant
> would be nice, but fortunately that's not a fundamental decision in any way).

1. What about the issue of having the API be a composable range interface?

http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html

I.e. the input range should be the FIRST argument, not the last.

2. Why are integers acceptable as lexer input? The spec specifies Unicode.

3. Why are there 4 functions that do the same thing?

http://s-ludwig.github.io/std_data_json/stdx/data/json/generator.html

After all, there already is a http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.html

On Friday, 14 August 2015 at 00:18:39 UTC, Adam D. Ruppe wrote:
> On Thursday, 13 August 2015 at 03:44:14 UTC, Walter Bright wrote:
>> Hah, I'd like to replace dmd.conf with a .json file.
>
> There's an awful lot of people out there replacing json with more ini-like files....

Referring to TOML?

https://github.com/toml-lang/toml

On 8/13/2015 5:18 PM, Adam D. Ruppe wrote:
> On Thursday, 13 August 2015 at 03:44:14 UTC, Walter Bright wrote:
>> Hah, I'd like to replace dmd.conf with a .json file.
>
> There's an awful lot of people out there replacing json with more ini-like
> files....

We've currently invented our own, rather stupid and limited, format. There's no point to it over .json.

On Friday, 14 August 2015 at 00:16:47 UTC, Walter Bright wrote:
> On 8/13/2015 5:22 AM, CraigDillabaugh wrote:
>> No configuration file should be in a format that doesn't support comments.
>
> [ "comment" : "and you thought it couldn't have comments!" ]

You are cheating :o)

There do seem to be some ways to comment JSON files, but they all feel, and look like hacks.

I think something like YAML or SDLang even would be better.

Anyway, at least you aren't proposing XML, so I won't complain too loudly.

On 8/12/2015 12:44 AM, Sönke Ludwig wrote:
> That's where Decimal would come in. There is some code for that commented out,
> but I really didn't want to add it without a standard Phobos implementation. But
> I wouldn't say that this is really an argument against BigInt, maybe more one
> for implementing a Decimal type.

Make the type for storing a Number be a template parameter.

Am 14.08.2015 um 02:26 schrieb Walter Bright:
> On 8/13/2015 3:51 AM, Sönke Ludwig wrote:
>> These were, AFAICS, the only major open issues (a decision for an
>> opt() variant
>> would be nice, but fortunately that's not a fundamental decision in
>> any way).
>
> 1. What about the issue of having the API be a composable range interface?
>
> http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html
>
> I.e. the input range should be the FIRST argument, not the last.

Hm, it *is* the first function argument, just the last template argument.

>
> 2. Why are integers acceptable as lexer input? The spec specifies Unicode.

In this case, the lexer will perform on-the-fly UTF validation of the input. It can do so more efficiently than first validating the input using a wrapper range, because it has to check the value of most incoming code units anyway.

>
> 3. Why are there 4 functions that do the same thing?
>
> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator.html
>
> After all, there already is a
> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.html
>

There are two classes of functions that are not covered by GeneratorOptions: writing to a stream or returning a string. But you are right that pretty printing should be controlled by GeneratorOptions. I'll fix that. The suggestion to use pretty printing by default also sounds good.

On 14-Aug-2015 03:48, Walter Bright wrote:
> On 8/13/2015 5:18 PM, Adam D. Ruppe wrote:
>> On Thursday, 13 August 2015 at 03:44:14 UTC, Walter Bright wrote:
>>> Hah, I'd like to replace dmd.conf with a .json file.
>>
>> There's an awful lot of people out there replacing json with more
>> ini-like
>> files....
>
> We've currently invented our own, rather stupid and limited, format.
> There's no point to it over .json.

YAML is (plus/minus braces) the same but supports comments and is increasingly popular for hierarchical configuration files.

-- 
Dmitry Olshansky

Am 14.08.2015 um 07:11 schrieb Walter Bright:
> On 8/12/2015 12:44 AM, Sönke Ludwig wrote:
>> That's where Decimal would come in. There is some code for that
>> commented out,
>> but I really didn't want to add it without a standard Phobos
>> implementation. But
>> I wouldn't say that this is really an argument against BigInt, maybe
>> more one
>> for implementing a Decimal type.
>
> Make the type for storing a Number be a template parameter.
>

Then we'd lose the ability to distinguish between integers and floating point in the same lexer instantiation, which is vital for certain input files to avoid losing precision for 64-bit integers. The only solution would be to use Decimal, but that doesn't exist yet and would be slow.

But the use of BigInt is already controlled by a template parameter, only the std.bigint import is currently there unconditionally.

Hm, another idea would be to store a void* (to a BigInt) instead of a BigInt and only import std.bigint locally in the accessor functions.

On Friday, 14 August 2015 at 07:14:34 UTC, Sönke Ludwig wrote:
> Am 14.08.2015 um 07:11 schrieb Walter Bright:
>> Make the type for storing a Number be a template parameter.
>>
>
> Then we'd lose the ability to distinguish between integers and floating point in the same lexer instantiation, which is vital for certain input files to avoid losing precision for 64-bit integers. The only solution would be to use Decimal, but that doesn't exist yet and would be slow.

Why can't you specify many types? You should be able to query the range/precision of each type?

On 8/14/2015 12:14 AM, Sönke Ludwig wrote:
> Am 14.08.2015 um 07:11 schrieb Walter Bright:
>> Make the type for storing a Number be a template parameter.
> Then we'd lose the ability to distinguish between integers and floating point in
> the same lexer instantiation, which is vital for certain input files to avoid
> losing precision for 64-bit integers. The only solution would be to use Decimal,
> but that doesn't exist yet and would be slow.

Two other solutions:

1. 'real' has enough precision to hold 64 bit integers.

2. You can use a union of 'long' and a template type T. Use the 'long' if it fits, and T if it doesn't.