Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Jim Ingham]

Andrew & Fernando,

Okay, here are Rab's comments about the proposed change to the MI 
interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the 
Project Builder side of debugging for Apple's IDE.):

> 1) The delimiters for a list should be different from those for a tuple.
> The output of MI is, basically, a property list. Property lists have 
> been around for a long time and they have different delimiters for 
> tuples and lists.
>
> The current situation, in which the same delimiters are used for both 
> lists and tuples, results in stream of MI output which is difficult to 
> inspect "by eye". The parser is a bit more complex than it needs to be 
> because it has to handle the overloading of '{'. As a result, the data 
> structures used to represent a VALUE is not a clean as they could be 
> either.
>
> And, I mean this in the nicest way possible, this oversight sticks out 
> like a sore thumb... when I wrote the special-cases in the parser to 
> deal with this obvious error in the grammar, I wondered if MI was 
> really up to snuff.
>
> 2) '[' and ']' are the correct delimiters
> Adding these characters to the grammar does not complicate the parsing 
> of MI output. These are the obvious characters to be used as the 
> delimiters for a list.
>
> 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> I don't think this example is allowed by the proposed grammar. It 
> should be one of:
> 	bps=["1", "2", "4"]
> 	[{bp="1"}, {bp="2"}, {bp="4"}]
>
> -rab

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Fernando Nasser]

I rest my case :-)

Jim Ingham wrote:
> 
> Andrew & Fernando,
> 
> Okay, here are Rab's comments about the proposed change to the MI
> interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the
> Project Builder side of debugging for Apple's IDE.):
> 
> > 1) The delimiters for a list should be different from those for a tuple.
> > The output of MI is, basically, a property list. Property lists have
> > been around for a long time and they have different delimiters for
> > tuples and lists.
> >
> > The current situation, in which the same delimiters are used for both
> > lists and tuples, results in stream of MI output which is difficult to
> > inspect "by eye". The parser is a bit more complex than it needs to be
> > because it has to handle the overloading of '{'. As a result, the data
> > structures used to represent a VALUE is not a clean as they could be
> > either.
> >
> > And, I mean this in the nicest way possible, this oversight sticks out
> > like a sore thumb... when I wrote the special-cases in the parser to
> > deal with this obvious error in the grammar, I wondered if MI was
> > really up to snuff.
> >
> > 2) '[' and ']' are the correct delimiters
> > Adding these characters to the grammar does not complicate the parsing
> > of MI output. These are the obvious characters to be used as the
> > delimiters for a list.
> >
> > 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> > I don't think this example is allowed by the proposed grammar. It
> > should be one of:
> >       bps=["1", "2", "4"]
> >       [{bp="1"}, {bp="2"}, {bp="4"}]
> >
> > -rab
> 
> Jim
> --
> Jim Ingham                                   jingham@apple.com
> Developer Tools - gdb
> Apple Computer

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Jim Ingham]

Andrew,

We do use the MI for communication between Project Builder - Apple's IDE 
for Mac OS X - and gdb.  I sent this discussion off to the fellow who 
does actually USES the stuff we generate to see what he thinks.  I will 
try to get back on this as soon as may be.

Jim

> I'm very very open to feedback.  Given that MI currently involves a
> custom GDB, I suspect that no one is using it in a production
> environment (Apple?).
>

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

[5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Andrew Cagney]

Hello,

The MI documentation currently contains:

GDB/MI Draft Changes to Output Syntax
=====================================

   One problem identified in the existing GDB/MI output syntax was the
difficulty in differentiating between a tuple such as:

     {number="1",type="breakpoint",disp="keep",enabled="y"}

   where each value has a unique label, and a list such as:

     {"1","2","4"}
     {bp="1",bp="2",bp="4"}

   where values are un-labeled or the label is duplicated.

[....]

`RESULT ==>'
     STRING "=" VALUE

`VALUE ==>'
     C-STRING `|' TUPPLE `|' LIST

`TUPPLE ==>'
     "{}" `|' "{" RESULT { "," RESULT } "}"

`LIST ==>'
     "`[]'" `|' "`['" VALUE { "," VALUE } "`]'"

--

Which would change the above examples to:

     ["1","2","4"]
     [bp="1",bp="2",bp="4"]

This should look familar if you've used erlang or maranda(?).

I'd like to propose that this change be adopted before MI is enabled
(before 5.1 is released).  The code change is trivial.

My concern is with people that might currently be using MI.  While the
opening section reads:

     Note that GDB/MI is still under construction, so some of the
  features described below are incomplete and subject to change.

I'm very very open to feedback.  Given that MI currently involves a
custom GDB, I suspect that no one is using it in a production
environment (Apple?).

--

Should my proposal to ``correctly fix'' the problem fail, I'll fix the
problem by deleting that section of the MI spec :-)

I might also add a note warning implementors of the ambigious syntax :-)

enjoy,
	Andrew

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Fernando Nasser]

Andrew,

I strongly object to the use of "[]".  This will add another special
character and make things more difficult.

The output like {"1","2","4"} can easily be considered as a list value
by the parser.  The parser will need to have some description of the
expected result, even if in a lose way so it should still be able to
identify that this is a list value and not a list of values.

The {bp="1",bp="2",bp="4"} result should not be generated.  As we
currently have to share the output producing code with the CLI, we end
up generating things like this.  But I guess we should fix the source of
such anachronisms instead of changing the output format because of it.

It may be better to leave the output as is for 5.1 and see what the
parser implementers say.  If they complain, we can discuss the best
alternative and patch both the branch and the trunk.  As you said, it is
a simple change to the mi-out code.

Fernando



Andrew Cagney wrote:
> 
> Hello,
> 
> The MI documentation currently contains:
> 
> GDB/MI Draft Changes to Output Syntax
> =====================================
> 
>    One problem identified in the existing GDB/MI output syntax was the
> difficulty in differentiating between a tuple such as:
> 
>      {number="1",type="breakpoint",disp="keep",enabled="y"}
> 
>    where each value has a unique label, and a list such as:
> 
>      {"1","2","4"}
>      {bp="1",bp="2",bp="4"}
> 
>    where values are un-labeled or the label is duplicated.
> 
> [....]
> 
> `RESULT ==>'
>      STRING "=" VALUE
> 
> `VALUE ==>'
>      C-STRING `|' TUPPLE `|' LIST
> 
> `TUPPLE ==>'
>      "{}" `|' "{" RESULT { "," RESULT } "}"
> 
> `LIST ==>'
>      "`[]'" `|' "`['" VALUE { "," VALUE } "`]'"
> 
> --
> 
> Which would change the above examples to:
> 
>      ["1","2","4"]
>      [bp="1",bp="2",bp="4"]
> 
> This should look familar if you've used erlang or maranda(?).
> 
> I'd like to propose that this change be adopted before MI is enabled
> (before 5.1 is released).  The code change is trivial.
> 
> My concern is with people that might currently be using MI.  While the
> opening section reads:
> 
>      Note that GDB/MI is still under construction, so some of the
>   features described below are incomplete and subject to change.
> 
> I'm very very open to feedback.  Given that MI currently involves a
> custom GDB, I suspect that no one is using it in a production
> environment (Apple?).
> 
> --
> 
> Should my proposal to ``correctly fix'' the problem fail, I'll fix the
> problem by deleting that section of the MI spec :-)
> 
> I might also add a note warning implementors of the ambigious syntax :-)
> 
> enjoy,
>         Andrew

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Andrew Cagney]

Fernando Nasser wrote:
> 
> Andrew,
> 
> I strongly object to the use of "[]".  This will add another special
> character and make things more difficult.

This is interesting :-)

From memory, the proposal came about because a person implementing a
parser found that they needed contextual information (expect a list of
breakpoints) when translating the MI output into an internal structure. 
The intention of the syntax change (differentiate between lists and
tupples) was to make things easier - the basic structure could be
reconstructed without the need for that context.

An existing parser would just tread ``[ ]'' like ``{ }''.  I don't see a
need for any other special characters.

> The output like {"1","2","4"} can easily be considered as a list value
> by the parser.  The parser will need to have some description of the
> expected result, even if in a lose way so it should still be able to
> identify that this is a list value and not a list of values.

My memory of the reasoning behind the change was to remove the need for
the parser to have this knowledge.

> The {bp="1",bp="2",bp="4"} result should not be generated.  As we
> currently have to share the output producing code with the CLI, we end
> up generating things like this.  But I guess we should fix the source of
> such anachronisms instead of changing the output format because of it.

Do you think that the syntax should be tightened so that the above isn't
allowed?

> It may be better to leave the output as is for 5.1 and see what the
> parser implementers say.  If they complain, we can discuss the best
> alternative and patch both the branch and the trunk.  As you said, it is
> a simple change to the mi-out code.

I'd really like this resolved before MI is permenantly enabled.  Once it
is enabled, things like the syntax will become impossible to change.

In the end I guess the question is, is the world be made up of just
lists and atoms or lists, tupples and atoms.  The answer probably
depends on which list like language you were taught :-)

	enjoy,
		Andrew