Simple Functions in Constant Expressions

[everythingfunctional]

The 202X standard will include a new attribute for procedures, simple. If a procedure is simple it depends on, and uses only its arguments, and calls only simple procedures. This means that, in theory, if a simple function's arguments are themselves constant expressions, it could be evaluated before program startup. I contend that this would be quite valuable for defining named constants of derived types whose components are private. For example given a string type defined like

module string_m
  implicit none
  private
  public :: string_t
  type :: string_t
    private
    character(len=:), allocatable :: str_
  end type

  interface string_t
    module procedure constructor
  end interface
contains
  simple function constructor(str) result(string)
    character(len=*), intent(in) :: str
    type(string_t) :: string

    string%str_ = str
  end function
end module

It should be possible to define something like the following

type(string_t), parameter :: lines(*) =  &
    [ string_t("Hello, World!") &
    , string_t("It's a great day!") &
    , string_t("Hooray Fortran!") &
    ]

[FortranFan]

@everythingfunctional ,

SIMPLE procedures, as developed in Fortran 202X, are not limited by constant expression considerations.

Please see this #214 which proposes CONSTEXPR procedures instead for user-defined functions in constant expressions. There is a reason for this: there are certain difficult complications with Fortran standard semantics when it comes to allowing executable statements and constructs in constant expressions.

Consider the string%str_ = str statement in your example code: I will spare commentary but you know there is a lot "underneath" this statement with allocation-upon-assignment that many a implementation handles only during run-time. For these, what you propose is effectively a no-no.

I have surmised improved compile-time computing is only amenable in Fortran with a rather limited set of instructions. Having the ability to define them as CONSTEXPR procedures that essentially only include constant expression statements themselves which then enable certain code reuse and yield all the attendant benefits will be a good one to achieve for enhanced compile-time computing in Fortran 202Y.

Hence it will be helpful if you and others who see value in this proposal would also give a thumbs up for #214.

Thank you,

[everythingfunctional]

@FortranFan , you honed right in on the complications and saw through my attempt not to specifically mention them. However, your assumption that constant expressions must be known at compile time is not quite true. In fact, the standard says nothing about compile time. It would be perfectly reasonable for constant expressions to be computed immediately prior to program execution (i.e. at program startup). In fact there are languages which do this. I believe initializing a constant value of a type with pointer members in C++ (i.e. it's components must be allocated on the heap), or even just a user defined constructor, is done exactly this way.

Part of my reason for asking for this feature is specifically because I want to be able to define constants of types with allocatable components. Let alone be able to have those types keep their components private. I'll admit there might be some complications involved with this that I'm not quite seeing, but as far as being able to implement such a feature, I think it's absolutely feasible within the current standard.

[FortranFan]

@everythingfunctional wrote Mar. 16, 2022 1:15 PM EDT:

your assumption that constant expressions must be known at compile time is not quite true. In fact, the standard says nothing about compile time. It would be perfectly reasonable for constant expressions to be computed immediately prior to program execution (i.e. at program startup). In fact there are languages which do this.

Note

• my comments re: compile-time were only directed at the practitioners particularly with what they understand now re: the use of Fortran with current processors that involve compilation. And how getting a fair amount of computing completed during that compilation phase can be beneficial in their programs. I understand clearly the language standard says nothing about compile-time.
• From the language standard point-of-view, the existing semantics appear to be such at almost anything which constitutes an executable-construct is effectively a no-no in constant expressions, particularly what the language defines as action-stmt notwithstanding the assignment-stmt here refers to a variable and not a named constant:
• Sure it may be viable with some processors to compute certain expressions and instructions prior to execution. But as noticed time and again that does not help one bit with proposals to the standard. The suggested changes and extensions have to fit with the entirety of the existing semantics and that is where the problems lie given how the "limitations" have been built into the language with constant expressions.

I really think an attempt to get the standard to allow SIMPLE functions in constant expressions will not gain traction with the committee.

[klausler]

Poor persevering programmers preparing processors for practitioners can, perhaps, put some run-time "constant" expressions into play (initializer expressions), but perusing your published PDF produces a plethora of prohibited possibilities. A plurality of points where "scalar-int-constant-expr" appears must positively produce proper constants, per se, post parsing. Ponder real(kind=simplefunc()) :: x patiently.

[everythingfunctional]

real(kind=simplefunc()) :: x

I see. This actually does pose a potential problem if the expression cannot be fully evaluated at compile time. But I still contend that CONSTEXPR would restrict one to what is effectively already doable via named constants (i.e. the parameter attribute).

Perhaps I'm trying to apply this idea too broadly by utilizing an already existing aspect of the language. Perhaps what I'm really after is a new designation, something like "initialization expression". These could include the use of simple functions, and many places that require constant expressions now, could be relaxed to allow for initialization expressions. The kind value for an intrinsic type would then be a place that still requires a constant expression.

[certik]

real(kind=simplefunc()) :: x

In LFortran we do two passes over the AST (Abstract Syntax Tree, the result of parsing), in the first pass we figure out types of all functions and variables (symbols), and we evaluate an expression like kind = simplefunc(), and currently such expressions can only use constants, arithmetic operations and intrinsic function calls, so it can be straightforwardly evaluated in the compiler itself, without executing any Fortran code (for example if you call sin(x), then we call our own implementation in C++). Then in the second pass we finish compiling the bodies of all functions and resolve all variables to (now existing) symbols in the symbol table.

This approach would obviously break if simplefunc() is a user defined function, as it would require to compile this function first and execute it, while figuring out the types of symbols.

However, I think that can be done, I think one can allow executing of any function at compile time: as long as the function(s) can be actually compiled (all the types are known), then we can execute them while still compiling other code. Perhaps we can restrict it to only allow calling user defined functions from other modules, so we can still use the above two pass approach for a given module, but if another module is already compiled, we can execute functions from it. For example the Jai language allows executing of any code (including the whole program!) at compile time.

There is also a security and a performance implication: right now no user code is being run at compile time, only code that is already implemented in the compiler, so as long as there are no bugs in the compiler, it is currently safe to compile the whole code. Once we allow executing any random code at compile time, all kinds of things can happen:

• The code could be malicious, so it could potentially be unsafe to compile Fortran code
• It could take a very long time (including never finishing!) to compile Fortran code, if the user function is slow

[gklimowicz]

I may be an idiot, but how does using SIMPLE functions in initialization expressions work in a world of separate compilation? Only the interface may be known at compile time, not the implementation.

[everythingfunctional]

how does using SIMPLE functions in initialization expressions work in a world of separate compilation?

The expression isn't computed at compile time, it's computed at run time, prior to beginning execution of the main program.

[everythingfunctional]

In fact, it's a bit odd to me that compilers felt it acceptable that

real, parameter :: y = sin(1.0)
print *, y

and

real :: x, y

x = 1.0
y = sin(x)
print *, y

might produce different outputs, since one math library would be used at compile time, but a different one used at run time.

[everythingfunctional]

I did think of a case that a proposal will need to prevent, a named constant defined in terms of a simple function that references it. I.e.

module foo
  implicit none

  integer, parameter :: UH_OH = bar()
contains
  simple function bar()
    integer :: bar

    bar = UH_OH
  end function
end module

[gklimowicz]

Yeah, that was the sort of thing I was thinking.

[certik]

might produce different outputs, since one math library would be used at compile time, but a different one used at run time.

With optimizations enabled, as a user I would expect both to produce a compile time value, in this case identical value computed using the compile time (slow but more accurate) math library.

[everythingfunctional]

As a user, I'd expect the following program to always output "T", no matter what. But what are the actual chances of that? You can easily link to a math library that is different from the one used by the compiler. The choice of optimizations and link time options should not affect whether this program outputs "T" or "F". x = sin(1.0) should always be computed at program startup time, not compile time. If that's true, why can't user defined simple functions also be used there?

program huh
  implicit none
  real, parameter :: x = sin(1.0)
  real :: y

  y = 1.0
  print *, x == sin(y)
end program

[certik]

Regarding your last example, one approach could be that the compiler only uses the "more accurate" math library when optimizations are enabled, thus this should still return T in most simple cases. In the standard "Debug" mode, the compiler can call the exact same math library for both compile time and runtime, thus also returning T.

On a broader issue, I never compare floating point numbers directly like this, but always with abs(x - sin(y)) < eps, in which case this will return T no matter what.

[everythingfunctional]

the compiler can call the exact same math library for both compile time and runtime

The compiler doesn't know the runtime math library. I.e.

$ gfortran -c huh.f90 -o huh.o
$ ld huh.o -lmkl -lgfortran -o huh # I don't know exactly what all the necessary libraries are, but you get the idea