January 22, 2013

On 21.01.2013 08:27, Walter Bright wrote:
> The current version is pretty verbose. For:
>
>      int ***x;
>
> it will emit as the type:
>
> "type" : {
>          "kind" : "pointer",
>          "pretty" : "int***",
>          "targetType" : {
>                  "kind" : "pointer",
>                  "pretty" : "int**",
>                  "targetType" : {
>                          "kind" : "pointer",
>                          "pretty" : "int*",
>                          "targetType" : {
>                                  "kind" : "int",
>                                  "pretty" : "int"
>                          }
>                  }
>          }
> }
>
> I find this to be excessive, and it helps to produce truly gigantic
> .json files. I think it's better to just put out the deco for the type:
>
> "type" : "PPPi"
>
> But, you might say, that is not user friendly! Nope, it isn't. But the
> .json output is for a machine to read, not humans, and the deco types
> are very space efficient, and are trivial to convert to whatever data
> structure the reader needs. Much easier than the verbose thing.
>
> What do you think?

I agree the verbose output is overkill.

Considering that the demangling in druntime still has a number of open issues (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=3034, http://d.puremagic.com/issues/show_bug.cgi?id=6045) and that there are ambiguities in the name mangling (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5957, http://d.puremagic.com/issues/show_bug.cgi?id=4268), my first reaction was that it might be better to provide a function to parse the pretty type. It is not too difficult and would be a nice start for the lexer/parser topic, but might be burdened with new bugs.

Considering function types, the deco does not contain any function argument identifiers anymore, but these are very useful for tooltips in an IDE like Visual D.

As a compromise, the type chould just contain the mangled and the pretty name:

> "type" : {
>          "mangled" : "PPPi",
>          "pretty" : "int***",
> }


January 22, 2013
Am 22.01.2013 09:02, schrieb Rainer Schuetze:
> 
> Considering function types, the deco does not contain any function argument identifiers anymore, but these are very useful for tooltips in an IDE like Visual D.
> 

I thought so, too. But considering that types are always subject to this problem:

---
alias StateCallback = void function(int state);
static assert(StateCallback.stringof == "void function(int state)");

alias IndexCallback = void function(int index);
static assert(IndexCallback.stringof == "void function(int state)"); // still "state"
---

... it may be better to not even make it possible to fall into this trap by excluding them. Except if I'm wrong and the JSON output happens at an earlier stage where the parameter name information is still tagged to the declaration, of course.
January 22, 2013
On Tuesday, 22 January 2013 at 08:02:26 UTC, Rainer Schuetze wrote:
>>
> > "type" : {
> >          "mangled" : "PPPi",
> >          "pretty" : "int***",
> > }

I would favour plain "type" : "int***".

Consider it will be parsed from many different languages, C#, Java... etc and the generic tools may be able to handle json from multiple languages, and in this context have no reason to use differently mangled types for different languages.

"int***" is both compact and easy enough to parse anyway.

Even for pure D-based tools, for unit-test reasons it could be useful to have the pretty name to compare against, thus Rainer's proposal is a reasonable compromise.
January 22, 2013
On 1/22/13 2:48 AM, Walter Bright wrote:
> On 1/21/2013 10:56 PM, ric wrote:
>> Would it be reasonable to put an option whether to produce the (too)
>> verbose
>> json output or the minimal one?
>
> I'd rather we make a decision.

Verbose should probably be it.

Andrei
January 22, 2013
Am 22.01.2013 18:05, schrieb Tove:
> (...)
> 
> "int***" is both compact and easy enough to parse anyway.
> 
Consider "int[4u] delegate(scope float*[void function(scope int)] p1, Rebindable!(const(C))*[]* b)"

There are actually quite some things to parse in human readable type strings, I even remember some expressions. And parsing this is at least as language specific as the mangled name. But I agree that having both should be a good compromise.
January 22, 2013
On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote:
> On 1/22/13 2:48 AM, Walter Bright wrote:
>> On 1/21/2013 10:56 PM, ric wrote:
>>> Would it be reasonable to put an option whether to produce the (too)
>>> verbose
>>> json output or the minimal one?
>>
>> I'd rather we make a decision.
>
> Verbose should probably be it.

Rationale?

January 23, 2013
On 1/22/13 3:36 PM, Walter Bright wrote:
> On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote:
>> On 1/22/13 2:48 AM, Walter Bright wrote:
>>> On 1/21/2013 10:56 PM, ric wrote:
>>>> Would it be reasonable to put an option whether to produce the (too)
>>>> verbose
>>>> json output or the minimal one?
>>>
>>> I'd rather we make a decision.
>>
>> Verbose should probably be it.
>
> Rationale?

You can always filter out the verboseness with a simple program, but you can't add missing information.

If the efficiency of generating json ever comes up, _then_ it's worth looking into an option that produces less verbose output directly. For now be verbose and let downstream tools filter it out.


Andrei

January 23, 2013
On 1/22/2013 9:42 PM, Andrei Alexandrescu wrote:
> On 1/22/13 3:36 PM, Walter Bright wrote:
>> On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote:
>>> On 1/22/13 2:48 AM, Walter Bright wrote:
>>>> On 1/21/2013 10:56 PM, ric wrote:
>>>>> Would it be reasonable to put an option whether to produce the (too)
>>>>> verbose
>>>>> json output or the minimal one?
>>>>
>>>> I'd rather we make a decision.
>>>
>>> Verbose should probably be it.
>>
>> Rationale?
>
> You can always filter out the verboseness with a simple program, but you can't
> add missing information.
>
> If the efficiency of generating json ever comes up, _then_ it's worth looking
> into an option that produces less verbose output directly. For now be verbose
> and let downstream tools filter it out.

Using the deco string is not missing information - and it's easier to parse it and manipulate it.

January 23, 2013
On 2013-01-23 06:45, Walter Bright wrote:

> Using the deco string is not missing information - and it's easier to
> parse it and manipulate it.

I vote for the suggestion by Rainer:

"type" : {
    "mangled" : "PPPi",
    "pretty" : "int***",
}

-- 
/Jacob Carlborg
January 23, 2013
On 2013-01-22 20:53, Sönke Ludwig wrote:

> Consider "int[4u] delegate(scope float*[void function(scope int)] p1, Rebindable!(const(C))*[]* b)"
>
> There are actually quite some things to parse in human readable type strings, I even remember some
> expressions. And parsing this is at least as language specific as the mangled name. But I agree that
> having both should be a good compromise.

This wouldn't be fun to parse. It basically requires a front end.

-- 
/Jacob Carlborg