On 2015-08-19 19:29, Andrei Alexandrescu wrote:

> Forgot about those. The invariant is that byToken should return a
> sequence of tokens that, when parsed, produces the originating object.

That should be possible without the comma tokens in this case?

-- 
/Jacob Carlborg

On 8/19/15 1:59 PM, Jacob Carlborg wrote:
> On 2015-08-19 19:29, Andrei Alexandrescu wrote:
>
>> Forgot about those. The invariant is that byToken should return a
>> sequence of tokens that, when parsed, produces the originating object.
>
> That should be possible without the comma tokens in this case?

That is correct, but would do little else than confusing folks. FWIW the distinction is similar to AST vs. CST (C = Concrete). -- Andrei

On 07/30/2015 02:40 PM, Jacob Carlborg wrote:
> On 2015-07-30 06:41, Walter Bright wrote:
>
>> I agree with your goal of readability. And if someone wants to write
>> code that emphasizes it's JSON, they can write it as
>> std.data.json.parseStream. (It's not about saving typing, it's about
>> avoiding extra redundant redundancy, I'm a big fan of Strunk & White :-)
>> ) This is not a huge deal for me, but I'm not in favor of establishing a
>> new convention that repeats the module name. It eschews one of the
>> advantages of having module name spaces in the first place, and evokes
>> the old C style naming conventions.
>
> I kind of agree with that, but at the same time, if one always need to
> use the fully qualified name (or an alias) because there's a conflict
> then that's quite annoying.
>

It also fucks up UFCS, and I'm a huge fan of UFCS.

I do agree that D's module system is awesome here and worth taking advantage of to avoid C++-style naming conventions, but I still think balance is needed. Sometimes, just because we can use a shorter potentially-conflicting name doesn't mean we necessarily should.

On 08/14/2015 04:33 PM, Walter Bright wrote:
>
> That is, the ECMA 404 spec. There seems to be more than one JSON spec.
>
> www.ecma-international.org/.../files/.../ECMA-404.pdf

Amusingly, that "ECMA-404" link results in an actual HTTP 404.

On 08/15/2015 01:03 AM, Walter Bright wrote:
> On 8/14/2015 9:58 PM, suliman wrote:
>> On Friday, 14 August 2015 at 20:44:59 UTC, Walter Bright wrote:
>>> Config files will work fine with json format.
>> Walter, and what I should to do for commenting stringin config for
>> test purpose?
>> How it's can be done with json?
>
> { "comment" : "this is a comment" }
>

I'll take an "invented our own, rather stupid and limited, format" over comments that ugly any day.

Seriously, with DUB, I've been using json for configuration file a lot lately, and dmd.conf is a way nicer config format. There's very good reason DUB's added an alternate format.

On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote:
> On 8/18/15 2:31 AM, Jacob Carlborg wrote:
>>
>> I don't think this is excessive. We should strive to have small modules.
>> We already have/had problems with std.algorithm and std.datetime, let's
>> not repeat those mistakes. A module with 2000 lines is more than enough.
>
> How about a module with 20? -- Andrei
>

Module boundaries should be determined by organizational grouping, not by size.

On Friday, 21 August 2015 at 15:58:22 UTC, Nick Sabalausky wrote:
> It also fucks up UFCS, and I'm a huge fan of UFCS.

Are you saying that "import json : parseJSON = parse; foo.parseJSON.bar;" does not work?

 – David

On Friday, 21 August 2015 at 16:25:40 UTC, Nick Sabalausky wrote:
> Module boundaries should be determined by organizational grouping, not by size.

By organizational grouping as well as encapsulation concerns. Modules are the smallest units of encapsulation in D, visibility-wise.

 — David

On 8/21/15 12:25 PM, Nick Sabalausky wrote:
> On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote:
>> On 8/18/15 2:31 AM, Jacob Carlborg wrote:
>>>
>>> I don't think this is excessive. We should strive to have small modules.
>>> We already have/had problems with std.algorithm and std.datetime, let's
>>> not repeat those mistakes. A module with 2000 lines is more than enough.
>>
>> How about a module with 20? -- Andrei
>>
>
> Module boundaries should be determined by organizational grouping, not
> by size.

Rather by usefulness. As I mentioned, nobody would ever need only JSON's exceptions and location. -- Andrei

On 8/19/15 4:55 AM, Sönke Ludwig wrote:
> Am 19.08.2015 um 03:58 schrieb Andrei Alexandrescu:
>> On 8/18/15 1:24 PM, Jacob Carlborg wrote:
>>> On 2015-08-18 17:18, Andrei Alexandrescu wrote:
>>>
>>>> Me neither if internal. I do see a problem if it's public. -- Andrei
>>>
>>> If it's public and those 20 lines are useful on its own, I don't see a
>>> problem with that either.
>>
>> In this case at least they aren't. There is no need to import the JSON
>> exception and the JSON location without importing anything else JSON. --
>> Andrei
>>
>
> The only other module where it would fit would be lexer.d, but that
> means that importing JSONValue also has to import the parser and lexer
> modules, which is usually only needed in a few places.

I'm sure there are a number of better options to package things nicely. -- Andrei