Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • lfortran lfortran
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 432
    • Issues 432
    • List
    • Boards
    • Service Desk
    • Milestones
    • Requirements
  • Merge requests 72
    • Merge requests 72
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • lfortranlfortran
  • lfortranlfortran
  • Issues
  • #84
Closed
Open
Issue created May 04, 2019 by Ondřej Čertík@certikOwner

Idea: Support dot (`.`) as an alternative to the `%` operator

This is an idea to consider:

The . is a lot more readable, consider os.path.join() vs. os%path%join(). The reason it's more readable is because the . has more vertical space, and thus the words are visually more divided, while the % character is filling up all the space, and thus visually it is much harder to immediately see where one word ends and another begins.

Besides . being more readable, it is also way more common, e.g. in Python, C++, Julia and many other languages.

And Intel Fortran actually seems to support it in some cases.

It makes the parsing ambiguous, since a.not.b can be an operator .not., or derived type access. In addition, Fortran allows to have user defined operators, so any word of the type .something. can be an operator. However, there might be a way to parse things properly and to disambiguate this.

For example one way to do that would be that a.not.b would mean .not. as an operator. One should not use derived types with names like not. Regarding user defined operators, I would say user defined operators will take precedence, and so if one imports a user defined operator, say .path., then os.path.join() will mean .path. as an operator. One would need to use % in such a case then. This will be very rare, so shouldn't be a problem.

Edited May 04, 2019 by Ondřej Čertík
Assignee
Assign to
Time tracking