Re: Evaluation of toplevel forms at compile time?

Marius Gerbershagen <[email protected]> Mon, 08 Dec 2025 17:40:08 +0100
Newsgroups gmane.lisp.ecl.general
Message-ID <[email protected]>
------FDDY462Y2V4PSQJJZPRF4ATPJ0660K
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

there is no option for turning the load time evaluation of global variable=
 definitions into compile time evaluations=2E The semantics of the ANSI sta=
ndard don't allow any other behaviour than what ECL currently implements=2E

You can use the #=2E syntax to define the variable at read time which shou=
ld fix your problem=2E In my opinion this is a bug which should be fixed in=
 your dependency=2E Assuming that the file is loaded only during compilatio=
n will break not only ECL but also other workflows=2E An example would be d=
istributing a program as a set of fasl files which are loaded during startu=
p which is a useful technique to reduce disk usage for distributing many sm=
all programs=2E

Best regards,

Marius Gerbershagen

Am 7=2E Dezember 2025 17:46:21 MEZ schrieb Vasilii Smirnov <vasilii=2Esmir=
nov@mailbox=2Eorg>:
>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=2E
>
>One such example is this bit of code:
>https://github=2Ecom/sabracrolleton/uax-15/blob/v0=2E1=2E3/src/precompute=
d-tables=2Elisp#L12
>which gets pulled in by postmodern, for example=2E It reads some text
>files from the module's source directory and stores the result in a
>global variable=2E 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=2E
>
>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?

------FDDY462Y2V4PSQJJZPRF4ATPJ0660K
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir=3D"auto">Hi,<br><br>there is no option fo=
r turning the load time evaluation of global variable definitions into comp=
ile time evaluations=2E The semantics of the ANSI standard don't allow any =
other behaviour than what ECL currently implements=2E<br><br>You can use th=
e #=2E syntax to define the variable at read time which should fix your pro=
blem=2E In my opinion this is a bug which should be fixed in your dependenc=
y=2E Assuming that the file is loaded only during compilation will break no=
t only ECL but also other workflows=2E An example would be distributing a p=
rogram as a set of fasl files which are loaded during startup which is a us=
eful technique to reduce disk usage for distributing many small programs=2E=
<br><br>Best regards,<br><br>Marius Gerbershagen</div><br><br><div class=3D=
"gmail_quote"><div dir=3D"auto">Am 7=2E Dezember 2025 17:46:21 MEZ schrieb =
Vasilii Smirnov &lt;vasilii=2Esmirnov@mailbox=2Eorg&gt;:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail"><div dir=3D"auto">Hello, sorry for the noob question=
, but I'm just starting out with ECL,<br>and I can't quite find a solution =
for the following problem: some<br>packages in the CL ecosystem seem to ass=
ume, that the toplevel is only<br>evaluated during development / compilatio=
n, so by the time the final<br>executable will have been launched all tople=
vel defparameters and<br>defvars already have their precomputed values=2E<b=
r><br>One such example is this bit of code:<br><a href=3D"https://github=2E=
com/sabracrolleton/uax-15/blob/v0=2E1=2E3/src/precomputed-tables=2Elisp#L12=
">https://github=2Ecom/sabracrolleton/uax-15/blob/v0=2E1=2E3/src/precompute=
d-tables=2Elisp#L12</a><br>which gets pulled in by postmodern, for example=
=2E It reads some text<br>files from the module's source directory and stor=
es the result in a<br>global variable=2E For image-based implementations th=
is is not a problem,<br>but in ECL the evaluation of this code is deferred =
until runtime, and<br>ultimately fails, if executed on a different computer=
, where the source<br>code of the module is not available=2E<br><br>Which p=
rompts the question: is it possible to instruct ECL to precompute<br>top-le=
vel variables before translating them to C code? If not, what's<br>the gene=
ral strategy of dealing with such modules, short of patching<br>each depend=
ency that has this problem?<br></div></pre></blockquote></div></body></html=
>
------FDDY462Y2V4PSQJJZPRF4ATPJ0660K--