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

Use '.' to separate scope from variable name instead of '_'. #280

Open
dorchard opened this issue Nov 17, 2023 · 1 comment
Open

Use '.' to separate scope from variable name instead of '_'. #280

dorchard opened this issue Nov 17, 2023 · 1 comment
Assignees

Comments

@dorchard
Copy link
Member

At the moment, the renaming (Language.Fortran.Analysis.Renaming) generates names that use the scope and name and a freshid, but using _ to separate all of these. However since _ is a valid part of an identifier I think this is a little confusing when looking at outputs. Consider:

function area_of_circle(r) result(area)
  real, parameter :: pi = 3.14e0
  real, intent(in) :: r
  real :: area
  area = ((r * r) * pi)
end function area_of_circle

then we get things like


_area_of_circle_1                - Function
area_of_circle_area_2           Real 4 Variable
area_of_circle_pi_4             Real 4 Parameter
area_of_circle_r_3              Real 4 Variable

What about if instead we used .?, i.e.,

% fortran-src program.f90 --typecheck

.area_of_circle_1                - Function
area_of_circle.area_2           Real 4 Variable
area_of_circle.pi_4             Real 4 Parameter
area_of_circle.r_3              Real 4 Variable

Does that have any problems with generated names wanting to be used like actually variables anywhere (i.e., in generated code)? It doesn't appear so.

@RaoulHC
Copy link
Collaborator

RaoulHC commented Nov 21, 2023

I think more than being being confusing it could potentially lead to clashes couldn't it? @raehik eventually figured out that in #190 that some weird behaviour I was getting was due to the renaming not being quite unique.

I think for internal names using . would be fine, but for generated code this might cause problems with the syntax for field accessors. Using . is non standard but widely used (on account of virtually every other language using .).

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

6 participants