Some other use of `{}`

Language enhancement
1

These are some ideas I collected for future use of {} in fortran from the forum itself after the change in templates feature.

  • Python inspired f-string: As it was shown in an another thread by @certik. I thought maybe we should keep the flavor of Fortran intact so, I propose a small change to the example
character(:), allocatable :: s, text
integer :: i
real :: a
i=1
a=1.123456789
text="this"
s = f"{i} is an integer, {a} is a rounded real and '{text}' is text"
print '(i, f1.2, a)', s
  • No implied save and default value: Using C++ for inspiration, may be something like this could be done to indicate that their is no implied save and the value presented is a default value.
integer :: b = {0} ! something like this is already presented by someone in the forum I think.
  • For dict/map type: This one is also inspired by python and @FortranFan
class(*), allocatable(dict) :: x ! key and values can be anything
! or
type(*), allocatable(dict) :: x  ! can only be intrinsic type

x = { 1:'one', 2:'two'}

Just presenting them for discussion. I hope others find them interesting.

8 Likes
2

Good points! I agree with you this is precisely the discussion we have to have.

Yes, LFortran already has dictionaries internally, to expose them in the front-end, we have to choose syntax, and {} seems the most natural for that, like Python. Although Julia uses {} for templates and Dict(true => "yes", 1 => "no", 1.0 => "maybe") for dictionaries.

P.S. I changed it from Meta to Language enhancement, I think Meta is for workflow discussions or discussions about the forum.

1 Like
3

For the template use case, whatever Fortran end up with as long as it composes well with the rest of the language, I am happy with it. For dictionaries personally I will go with Python it just feel natural. As for the syntax for dictionaries does the above mock syntax make sense or it’s not do able at all?

1 Like
4

Personally, I’d be in favour of bringing some of the Python string formatting features to Fortran. C++ has also adopted them, if you look at the standard format specification used by the std::format (C++20) and std::println (C++23) functions.

In the past I’ve wondered how hard would it be to write an external tool which translated from Python/C/C++ format strings into a Fortran format specifier. The same tool could be used in a preprocessor, with a simple regex-based parser that detected f"..." strings, and replaced them with internal I/O. This would also help to etch out the design of this feature further.

4 Likes
5

I created two relevant issues:

2 Likes
6

Interesting.

Any reason to file them under j3-fortran/generics instead of the following location?

2 Likes
7

@FortranFan great catch, I just moved it to fortran_proposals. Thanks!

2 Likes
8

A post was merged into an existing topic: Generics in Fortran 202Y: Petition to WG5?

9

I have proposed in the past using curly brackets to signal the compiler to create/allow a “ragged” array of pointers and deferred length strings so they don’t have to be imbedded in a derived type

ie

integer, pointer :: parray{10}
character(:) , allocatable :: strings{10}

etc

4 Likes
11

If I am remembering correctly (please correct me), the DT version of ragged arrays use 2 ()'s so why not make it the default way of doing it. I think C# also does it that way no?

integer, pointer :: parry(10)(:)  ! something like this 
character(:), allocatable :: strings(10)(:)
12

Just before my holidays I worked on a module that uses format strings with “{1}” and the like to provide an alternative formatting facility. It is standard Fortran (or at least I hope so :slight_smile: ) and, while limited in its current implementation, it does the job. It may not be as capable as the suggested language enhancement, but have a look - comments welcome:

2 Likes