Re: [RFC] FORTRAN95 Expression parser

Re: [RFC] FORTRAN95 Expression parser

[Michael Elizabeth Chastain]

Coincidentally, I was looking at a FORTRAN pr this morning.

I think the existing FORTRAN expression parser is lame and I would
not miss it.

I favor the side-by-side strategy.  Keep the files as f95-x files.
Let the gdb people play with it side by side.  If the new interface
dominates the old interface, we can remove the old f-x files.
If we think there will be a constituency for the old interface,
then we can release both.

The problem with merging is that it makes the code much less readable
and makes it harder to discard the old code.

My two cents,

Michael C

Re: [RFC] FORTRAN95 Expression parser

[Petr Sorfa]

Hi All,

Thanks for all the input and comments.

The side-by-side integration was my original intention, so that once
everybody realizes how great the new F95 parser is then a quick switch
can be done. Note that I'm thinking of automatically enabling it for
F90/F95 binaries (as long as they are appropriately marked by the DWARF
language attribute.) To do this I'll add a new language to gdb -
fortran95

Since the parser full functionality depends on many features touching
DWARF support, column major support, variable evaluation, location
expression, new scoping, etc.. which will require separate code reviews
and comments. I'll initially release the parser as a "crimped" version.
Basically it will do the parsing, but will raise an error if any of the
unsupported features are used. I'll be adding the other features
separately and enable the various functionality of the parser as it goes
on.

I'm hoping to roll out everything over the next couple of weeks. The
test suite update will be put in early as well.

Even with this roll-out plan I personally think that the initial
"crimped" version will be more robust than the existing FORTRAN parser.

Petr

> Coincidentally, I was looking at a FORTRAN pr this morning.
> 
> I think the existing FORTRAN expression parser is lame and I would
> not miss it.
> 
> I favor the side-by-side strategy.  Keep the files as f95-x files.
> Let the gdb people play with it side by side.  If the new interface
> dominates the old interface, we can remove the old f-x files.
> If we think there will be a constituency for the old interface,
> then we can release both.
> 
> The problem with merging is that it makes the code much less readable
> and makes it harder to discard the old code.
> 
> My two cents,
> 
> Michael C

Re: [RFC] FORTRAN95 Expression parser

[Michael Snyder]

Petr Sorfa wrote:
> 
> Hi All,
> 
> Thanks for all the input and comments.
> 
> The side-by-side integration was my original intention, so that once
> everybody realizes how great the new F95 parser is then a quick switch
> can be done. Note that I'm thinking of automatically enabling it for
> F90/F95 binaries (as long as they are appropriately marked by the DWARF
> language attribute.) To do this I'll add a new language to gdb -
> fortran95
> 
> Since the parser full functionality depends on many features touching
> DWARF support, column major support, variable evaluation, location
> expression, new scoping, etc.. which will require separate code reviews
> and comments. I'll initially release the parser as a "crimped" version.
> Basically it will do the parsing, but will raise an error if any of the
> unsupported features are used. I'll be adding the other features
> separately and enable the various functionality of the parser as it goes
> on.
> 
> I'm hoping to roll out everything over the next couple of weeks. The
> test suite update will be put in early as well.

Sounds like a good plan.
 
> Even with this roll-out plan I personally think that the initial
> "crimped" version will be more robust than the existing FORTRAN parser.
> 
> Petr
> 
> > Coincidentally, I was looking at a FORTRAN pr this morning.
> >
> > I think the existing FORTRAN expression parser is lame and I would
> > not miss it.
> >
> > I favor the side-by-side strategy.  Keep the files as f95-x files.
> > Let the gdb people play with it side by side.  If the new interface
> > dominates the old interface, we can remove the old f-x files.
> > If we think there will be a constituency for the old interface,
> > then we can release both.
> >
> > The problem with merging is that it makes the code much less readable
> > and makes it harder to discard the old code.
> >
> > My two cents,
> >
> > Michael C

[RFC] FORTRAN95 Expression parser

[Petr Sorfa]

Hi,

I've created a FORTRAN95 expression parser for GDB. It is based off the
current FORTRAN expression parser, but has changed significantly in
source and functionality. I've developed it as a new separate parser
with the file prefix of f95-x as opposed to the existing f-x files.

The question is whether I should submit the patch as the f95-x files
(which will leave the current FORTRAN parser untouched) or replace the
existing FORTRAN parser?

Note that the F95 parser fully supports F77/F90/F95, but differs a bit
from the existing fortran gdb parser (which relies a bit heavily on C
notation.)

Petr

Re: [RFC] FORTRAN95 Expression parser

[Michael Snyder]

Petr Sorfa wrote:
> 
> Hi,
> 
> I've created a FORTRAN95 expression parser for GDB. It is based off the
> current FORTRAN expression parser, but has changed significantly in
> source and functionality. I've developed it as a new separate parser
> with the file prefix of f95-x as opposed to the existing f-x files.
> 
> The question is whether I should submit the patch as the f95-x files
> (which will leave the current FORTRAN parser untouched) or replace the
> existing FORTRAN parser?
> 
> Note that the F95 parser fully supports F77/F90/F95, but differs a bit
> from the existing fortran gdb parser (which relies a bit heavily on C
> notation.)

How much does it differ?  Functionally?  In user-visible ways?
How about test suites?

Re: [RFC] FORTRAN95 Expression parser

[Petr Sorfa]

Hi Michael,

> > I've created a FORTRAN95 expression parser for GDB. It is based off the
> > current FORTRAN expression parser, but has changed significantly in
> > source and functionality. I've developed it as a new separate parser
> > with the file prefix of f95-x as opposed to the existing f-x files.
> >
> > The question is whether I should submit the patch as the f95-x files
> > (which will leave the current FORTRAN parser untouched) or replace the
> > existing FORTRAN parser?
> >
> > Note that the F95 parser fully supports F77/F90/F95, but differs a bit
> > from the existing fortran gdb parser (which relies a bit heavily on C
> > notation.)
> 
> How much does it differ?  Functionally?  In user-visible ways?
> How about test suites?
It differs considerably - it supports FORTRAN expressions, not C
expressions that handle FORTRAN stuff. It supports FORTRAN intrinsics
(KIND, SIZE, LEN, ALLOCATED, ASSOCIATED, etc..). Proper FORTRAN array
subscripts (including stride). Proper print out of FORTRAN types and
variables. Supports column major notation. Supports MODULES, CONTAINS,
TYPE records, and so on.

User visible ways are considerably different, like I said, it treats
expressions like FORTRAN would.

I've added around 500 new test cases.

Petr

Re: [RFC] FORTRAN95 Expression parser

[Michael Snyder]

Petr Sorfa wrote:
> 
> Hi Michael,
> 
> > > I've created a FORTRAN95 expression parser for GDB. It is based off the
> > > current FORTRAN expression parser, but has changed significantly in
> > > source and functionality. I've developed it as a new separate parser
> > > with the file prefix of f95-x as opposed to the existing f-x files.
> > >
> > > The question is whether I should submit the patch as the f95-x files
> > > (which will leave the current FORTRAN parser untouched) or replace the
> > > existing FORTRAN parser?
> > >
> > > Note that the F95 parser fully supports F77/F90/F95, but differs a bit
> > > from the existing fortran gdb parser (which relies a bit heavily on C
> > > notation.)
> >
> > How much does it differ?  Functionally?  In user-visible ways?
> > How about test suites?
> It differs considerably - it supports FORTRAN expressions, not C
> expressions that handle FORTRAN stuff. It supports FORTRAN intrinsics
> (KIND, SIZE, LEN, ALLOCATED, ASSOCIATED, etc..). Proper FORTRAN array
> subscripts (including stride). Proper print out of FORTRAN types and
> variables. Supports column major notation. Supports MODULES, CONTAINS,
> TYPE records, and so on.
> 
> User visible ways are considerably different, like I said, it treats
> expressions like FORTRAN would.

Hmmm, tough call.  Sounds like your front end is considerably better, 
but who knows how many users may have grown accustomed/dependent on
the old behavior?

Any way you could merge the two?  Otherwise, it sounds like we
might need to keep both, perhaps with a mode switch.

Re: [RFC] FORTRAN95 Expression parser

[Stan Shebs]

Petr Sorfa wrote:
> 
> Hi Michael,
> 
> > > I've created a FORTRAN95 expression parser for GDB. It is based off the
> > > current FORTRAN expression parser, but has changed significantly in
> > > source and functionality. I've developed it as a new separate parser
> > > with the file prefix of f95-x as opposed to the existing f-x files.
> > >
> > > The question is whether I should submit the patch as the f95-x files
> > > (which will leave the current FORTRAN parser untouched) or replace the
> > > existing FORTRAN parser?
> > >
> > > Note that the F95 parser fully supports F77/F90/F95, but differs a bit
> > > from the existing fortran gdb parser (which relies a bit heavily on C
> > > notation.)
> >
> > How much does it differ?  Functionally?  In user-visible ways?
> > How about test suites?
> It differs considerably - it supports FORTRAN expressions, not C
> expressions that handle FORTRAN stuff. It supports FORTRAN intrinsics
> (KIND, SIZE, LEN, ALLOCATED, ASSOCIATED, etc..). Proper FORTRAN array
> subscripts (including stride). Proper print out of FORTRAN types and
> variables. Supports column major notation. Supports MODULES, CONTAINS,
> TYPE records, and so on.

Hmmm, then users used to the old syntax, plus any scripts that
use the old syntax, will all have to change.  I'd say they
should live side-by-side for a while, at least for one release.
Choice of syntax should be a user preference, so people needing
compat can set in .gdbinit and not have to deal with immediately.
Should be OK to default to the new parser though.

There's no real downside to having both present, right?

Stan