On 8/13/2015 11:54 PM, Dmitry Olshansky wrote:
> 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.

Yes, but we (will) have a .json parser in Phobos.

On 8/13/2015 11:52 PM, Sönke Ludwig wrote:
> 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.

Ok, my mistake. I didn't look at the others.

I don't know what 'isStringInputRange' is. Whatever it is, it should be a 'range of char'.


>> 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.

There is no reason to validate UTF-8 input. The only place where non-ASCII code units can even legally appear is inside strings, and there they can just be copied verbatim while looking for the end of the string.


>> 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.

Why do both? Always return an input range. If the user wants a string, he can pipe the input range to a string generator, such as .array

> 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.

Thanks

On Friday, 14 August 2015 at 08:03:34 UTC, Walter Bright wrote:
> 1. 'real' has enough precision to hold 64 bit integers.

Except for the lowest negative value…

(it has only 63 bits + floating point sign bit)

On 8/14/2015 2:20 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
> On Friday, 14 August 2015 at 08:03:34 UTC, Walter Bright wrote:
>> 1. 'real' has enough precision to hold 64 bit integers.
>
> Except for the lowest negative value…
>
> (it has only 63 bits + floating point sign bit)
>

You can always use T for that.

On 8/12/15 5:43 AM, Sönke Ludwig wrote:
>> Anyway, I've just started to work on a generic variant of an enum based
>> algebraic type that exploits as much static type information as
>> possible. If that works out (compiler bugs?), it would be a great thing
>> to have in Phobos, so maybe it's worth to delay the JSON module for that
>> if necessary.
>>
>
> First proof of concept:
> https://gist.github.com/s-ludwig/7a8a60150f510239f071#file-taggedalgebraic-d-L148
>
>
> It probably still has issues with const/immutable and ref in some
> places, but the basics seem to work as expected.

struct TaggedAlgebraic(U) if (is(U == union)) { ... }

Interesting. I think it would be best to rename it to TaggedUnion (instantly recognizable; also TaggedAlgebraic is an oxymoron as there's no untagged algebraic type). A good place for it is straight in std.variant.

What are the relative advantages of using an integral over a pointer to function? In other words, what's a side by side comparison of TaggedAlgebraic!U and Algebraic!(types inside U)?


Thanks,

Andrei

On Friday, 14 August 2015 at 09:20:14 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 14 August 2015 at 08:03:34 UTC, Walter Bright wrote:
>> 1. 'real' has enough precision to hold 64 bit integers.
>
> Except for the lowest negative value…
>
> (it has only 63 bits + floating point sign bit)

actually the x87 format has 64 mantissa bits, although the bit 63 is always '1' for normalized numbers.

On Friday, 14 August 2015 at 11:44:35 UTC, Matthias Bentrup wrote:
> On Friday, 14 August 2015 at 09:20:14 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 14 August 2015 at 08:03:34 UTC, Walter Bright wrote:
>>> 1. 'real' has enough precision to hold 64 bit integers.
>>
>> Except for the lowest negative value…
>>
>> (it has only 63 bits + floating point sign bit)
>
> actually the x87 format has 64 mantissa bits, although the bit 63 is always '1' for normalized numbers.

Yes, Walter was right.

The most negative number can be represented since it is a -(2^63) , so you only need the exponent to represent it (you only need 1 bit from the mantissa).

On 2015-08-14 10:04, Walter Bright wrote:

> Yes, but we (will) have a .json parser in Phobos.

Time to add a YAML parser ;)

-- 
/Jacob Carlborg

On 08/14/2015 01:40 PM, Andrei Alexandrescu wrote:
> On 8/12/15 5:43 AM, Sönke Ludwig wrote:
>>> Anyway, I've just started to work on a generic variant of an enum based
>>> algebraic type that exploits as much static type information as
>>> possible. If that works out (compiler bugs?), it would be a great thing
>>> to have in Phobos, so maybe it's worth to delay the JSON module for that
>>> if necessary.
>>>
>>
>> First proof of concept:
>> https://gist.github.com/s-ludwig/7a8a60150f510239f071#file-taggedalgebraic-d-L148
>>
>>
>>
>> It probably still has issues with const/immutable and ref in some
>> places, but the basics seem to work as expected.
>
> struct TaggedAlgebraic(U) if (is(U == union)) { ... }
>
> Interesting. I think it would be best to rename it to TaggedUnion
> (instantly recognizable; also TaggedAlgebraic is an oxymoron

No, it isn't. I believe the word you might want is "pleonasm". :o)

> as there's no untagged algebraic type).

The tag is an implementation detail. Algebraic types are actually more naturally expressed as polymorphic higher-order functions.

On 8/13/15 8:16 PM, 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!" ]

There can't be two comments with the same key though. -- Andrei