in reply to Making use of a config file written in Perl

it would be good to configure the application quite fast
You may be trying to optimize something on the basis of some perceived speed gain that is just not there or which makes no difference. Unless you have some really special requirement, anything that you do is going to be just fine speed wise.

I don't really understand enough from your description of what you are trying to configure, but you may find that some standard modules will suit your purpose quite well. I would not put code into a file that a user is going to edit!

For something that a user might muck with, I find the series of Config* modules to be quite nice. They implement a HoH or HoHoH structure which can be accessed easily. Although sometimes I put my own module as a thin "wrapper" around that so that I wind up with something that just looks like a rocket fast DB. So instead of having a predefined variable in my code, I call my @filehistory = getdb('filehistory') or whatever when I need it.

I do have modules that init themselves by reading complicated hereis documents or other structures. That is fine too. For example one table I have has changed once in the last 20 years(existed before current Perl code) - and required coding changes to deal with the ramifications. Its just fine to put something like that in a program module that only somebody on the programming team should be messing with!

I have other modules that read in thousands of lines of data information and present a simple I/F to the rest of the code - but this isn't in the range of what I could call "configuration" - this is operational data.

Sorry to be long winded. But, either make a module that is part of "your" code and you "own" or make some sort of file (Config style or YAML, etc) that contains no code at all. Avoid putting your code into some user modifiable file.