# Implementation of a parametrized objective function without using module variables or internal subroutines

**URL:** <https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919>\
**Category:** Uncategorized\
**Created:** [July 13, 2025, 3:28am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919 "2025-07-13T03:28:14Z")\
**Posts on this page:** 1\
**Showing post:** 53

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [July 17, 2025, 8:33pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/53 "2025-07-17T20:33:23Z")

</div>

> [@zaikunzhang](#):
>
> Thank you @ivanpribec for directing me to this option.

The credit goes to @fedebenelli who suggested it early in this thread.

> [@zaikunzhang](#):
>
> Are they consistent with what you quoted above?

I have the impression we might be assigning slightly different meanings to the same words. I don’t see a fundamental difference between the integration example in Note 12.18 and my root-finding example involving the fraction factor. We have discussed similar issues related to passing callback functions and safe multithreading before, just to remind you of two:

- [Modern Fortran interface for NLopt - #15 by ivanpribec](https://fortran-lang.discourse.group/t/modern-fortran-interface-for-nlopt/2685/15)
- [Modern Fortran interface to ODEPACK - #24 by ivanpribec](https://fortran-lang.discourse.group/t/modern-fortran-interface-to-odepack/4352/24)

* * *

A recurring limitation in this discussion has been that the subroutine `solver` cannot be modified to accept a context argument (e.g. a derived type or similar). But given your expectation that compiler implementors should tackle the executable stack issue, and that the Fortran standard should ideally evolve to support better mechanisms — wouldn’t it also be fair to ask whether the third-party `solver` could be adapted too? It’s worth remembering that the word [_software_](https://en.wiktionary.org/wiki/software) (as opposed to hardware) implies flexibility:

> **software**
> 
> 1. (computing) Encoded computer instructions, usually **modifiable** (unless stored in some form of unalterable memory such as ROM). [emphasis added]

@certik has also remarked above that,

> … most 3rd party libraries allow you to pass user data. If they don’t, that’s a deficiency of the 3rd party library I think.

In another setting, a compiler expert once told me:

> _“When the need for a feature can be addressed in portable open-source libraries that are available today (or in a few years), experience shows that that’s a much better solution than trying to change the language. […] If you have a library implementation today, and it’s portable and universally available, you already have the best solution.”_

I wanted to conclude my post with an (ironic) quote from Alan Perlis’s [_Epigrams on Programming_](https://www.cs.yale.edu/homes/perlis-alan/quotes.html). There are several which resonate with this thread, for instance

> _“Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.”_

Sometimes, asking the language or compiler to bend is the harder road — especially when a small change to the signature of `solver` could go a long way.

---

_[View the full topic](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919)._