Hi, there is no option for turning the load time evaluation of global variable definitions into compile time evaluations. The semantics of the ANSI standard don't allow any other behaviour than what ECL currently implements. You can use the #. syntax to define the variable at read time which should fix your problem. In my opinion this is a bug which should be fixed in your dependency. Assuming that the file is loaded only during compilation will break not only ECL but also other workflows. An example would be distributing a program as a set of fasl files which are loaded during startup which is a useful technique to reduce disk usage for distributing many small programs. Best regards, Marius Gerbershagen Am 7. Dezember 2025 17:46:21 MEZ schrieb Vasilii Smirnov <vasilii.smirnov@mailbox.org>:
Hello, sorry for the noob question, but I'm just starting out with ECL, and I can't quite find a solution for the following problem: some packages in the CL ecosystem seem to assume, that the toplevel is only evaluated during development / compilation, so by the time the final executable will have been launched all toplevel defparameters and defvars already have their precomputed values.
One such example is this bit of code: https://github.com/sabracrolleton/uax-15/blob/v0.1.3/src/precomputed-tables.... which gets pulled in by postmodern, for example. It reads some text files from the module's source directory and stores the result in a global variable. For image-based implementations this is not a problem, but in ECL the evaluation of this code is deferred until runtime, and ultimately fails, if executed on a different computer, where the source code of the module is not available.
Which prompts the question: is it possible to instruct ECL to precompute top-level variables before translating them to C code? If not, what's the general strategy of dealing with such modules, short of patching each dependency that has this problem?