Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fortran 90: add common extensions #4086

Open
suehshtri opened this issue May 7, 2024 · 4 comments
Open

Fortran 90: add common extensions #4086

suehshtri opened this issue May 7, 2024 · 4 comments

Comments

@suehshtri
Copy link

The following do not appear to be in the Fortran 2003 standard (though it is hard to tell given that the standard document is not freely available).

  • integer literal using hexadecimal when prefixed with #: #20200c
  • use dollar in a name: mylib$myfunc

While neither are in the standard, the use is common in the wild, the latter for certain vendor extensions.
-fdollar-ok is a gfortran dialect option.

The grammar would be more useful if it had some toggles to allow for these out-of-standard-but-common language features.

@kaby76
Copy link
Contributor

kaby76 commented May 8, 2024

While neither are in the standard, the use is common in the wild, the latter for certain vendor extensions. -fdollar-ok is a gfortran dialect option.

Extensions can be added, but it should be wrapped in a flag, which would be used in semantic predicates in the grammar.

@suehshtri
Copy link
Author

suehshtri commented May 15, 2024

The first, most immediately useful I would propose would be "dollarOk".

then adjust Fortran90Lexger.g4:

NAME: (LETTER | DOLLAR {dollarOk} ) ( ALPHANUMERIC_CHARACTER)*;

EXIT: 'EXIT' | 'exit';

BLANK: 'BLANK' | 'blank';

ALPHANUMERIC_CHARACTER: LETTER | NUM | SCORE | DOLLAR {dollarOk};

I'll try it here and see if I can get it patchworthy.

@suehshtri
Copy link
Author

Question: should I prefer an agnostic get/set for DollarOk as opposed to a property?

Longer:
Looking at how target-agnostic grammars have been written along with their base class, it looks like I should prefer a boolean get/set pair of methods as opposed to a property. If it were just C# a property would work, but we need to support the other target languages.

@kaby76
Copy link
Contributor

kaby76 commented May 19, 2024

Question: should I prefer an agnostic get/set for DollarOk as opposed to a property?

Longer: Looking at how target-agnostic grammars have been written along with their base class, it looks like I should prefer a boolean get/set pair of methods as opposed to a property. If it were just C# a property would work, but we need to support the other target languages.

I can't think of an equivalent syntax for a C# property across targets. It's probably best to stick with a method (function) call, even though one could use the "transformGrammar.py" hack to convert the "property" into a function or method call depending on the target.

But, there is no "universal action coding programming language", where you write the action once and it works in all targets. The best alternative is to add templating on top of .g4's. At some point, Antlr (or a fork of Antlr) will incorporate a templating engine. An example is the "templated actions" PR. antlr/antlr4#4345 antlr/antlr5#51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants