I would like to compile file with specific optimization settings.
More precisely, I would like to write a function
'compile-file-with-optimization'. My first attempt is
However, I would like that after compiling the file optimization
setting should remain unchanged. I was thinking about restoring
original settings via second 'proclaim', but it seems that there
is no way to query the compiler about optimization settings.
Is there a simple solution to this problem (besides having my
own bookeeping which remembers all changes to settings done
via proclaim). I was thinkig about forking separate process
for compilations, but on non-Unix systems I would have to
start entirely new Lisp process and that would be too expensive.
-- Waldek Hebisch
hebi...@math.uni.wroc.pl
sorry, I found no solution to your problem in general.
If you are able to modify the files that you want to compile
you can of course place appropriate DECLAIM statements at
the beginning of the file. On the other hand, if the files
already contain such statements you are can do much about
it anyway.
I guess doing your own bookkeeping is not so bad at all.
Just being curious: what is your application scenario for compile-file-
with-optimization?
> sorry, I found no solution to your problem in general.
> If you are able to modify the files that you want to compile
> you can of course place appropriate DECLAIM statements at
> the beginning of the file. On the other hand, if the files
> already contain such statements you are can do much about
> it anyway.
> I guess doing your own bookkeeping is not so bad at all.
> Just being curious: what is your application scenario for compile-file-
> with-optimization?
OK, full details. I am main developer of computer algebra
system FriCAS (which is a fork of Axiom). Largest part of
FriCAS is written in Spad, which is strongly typed language
translated to Lisp. Slightly smaller part is written
in Boot which is a syntactic sugar over Lisp or in Lisp
directly. In principle Lisp code generated from Spad
should be free of type errors and some other factors
make other types of runtime errors less likely.
FriCAS may be used to perform rather heavy computations,
so optimization for speed is desirable. Real code
always have bugs so by FriCAS is normally compiled
using default Lisp compiler setting, which in most
cases gives reasonable speed and enough safety to
debug when problems show up. However, users requested
way to control speed/safety compiler settings.
In particular they wanted to be able to compile
Spad files at lower safety settings than rest of
sources. Given that users may know nothing about
Lisp whole business of declaring/proclaiming things,
calling compile etc, must be done by FriCAS.
The first implementation of the feature stored
desired setting in variable and then used 'proclaim'
inside a 'locally' form to apply the settings. But
of course it did not work as intended, 'locally'
had no effect and setting were changed globally,
at least potentially affecting more files then wanted.
I considered wrapping whole content of generated file
into a 'locally' with proper declarations, but that
is unattractive because currently once generated
Lisp files can be reused, but putting declarations
inside files would made reuse harder.
Couldn't you set the optimisation settings in a variable which is then evaluated by the reader using something like (declaim #.*optimisation-settings)?
Elias Mårtenson <loke...@gmail.com> writes:
> Couldn't you set the optimisation settings in a variable which is then evaluated by the reader using something like (declaim #.*optimisation-settings)?
(proclaim *optimization-settings*) does it.
DECLAIM is just an eval-when wrapper over PROCLAIM.
As it seems that you are in control of the translation from Spad to
Lisp, I guess you just could generate any optimization settings users
are expecting.
I don't know if it is standardized behavior but I just made a small
experiment in SBCL and it appears that DECLAIMed optimization settings
in files that are given to COMPILE-FILE do not affect the global
optimization settings but are only used for the file being compiled.
"S.Mandl" <StefanMa...@web.de> wrote:
> I don't know if it is standardized behavior but I just made a small
> experiment in SBCL and it appears that DECLAIMed optimization settings
> in files that are given to COMPILE-FILE do not affect the global
> optimization settings but are only used for the file being compiled.
I would be happy to be shown to be wrong, but I think this is not portable
behaviour (though it is allowed I think). In fact if I read the description
of DECLAIM right, the previous sentence is correct.
On Saturday, February 11, 2012 8:04:58 PM UTC+1, Tim Bradshaw wrote:
> "S.Mandl" <StefanMa...@web.de> wrote:
> > I don't know if it is standardized behavior but I just made a small
> > experiment in SBCL and it appears that DECLAIMed optimization settings
> > in files that are given to COMPILE-FILE do not affect the global
> > optimization settings but are only used for the file being compiled.
> I would be happy to be shown to be wrong, but I think this is not portable
> behaviour (though it is allowed I think). In fact if I read the description
> of DECLAIM right, the previous sentence is correct.
I believe this is what ANSI mandates - I may be wrong, but I recall reading something like this. Proclamations do not affect compilations across files. Which kind of beats the purpose.
On 2012-02-13 06:41:39 +0000, Marco Antoniotti said:
> Proclamations do not affect compilations across files.
I think chapter & verse is:
"If a use of this macro appears as a top level form in a file being processed by the file compiler, the proclamations are also made at compile-time. As with other defining macros, it is unspecified whether or not the compile-time side-effects of a declaim persist after the file has been compiled."
On 13 Feb., 12:56, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2012-02-13 06:41:39 +0000, Marco Antoniotti said:
> > Proclamations do not affect compilations across files.
> I think chapter & verse is:
> "If a use of this macro appears as a top level form in a file being
> processed by the file compiler, the proclamations are also made at
> compile-time. As with other defining macros, it is unspecified whether
> or not the compile-time side-effects of a declaim persist after the
> file has been compiled."
> from DECLAIM.
I agree of course and what I previously described was just a simple
experiment that I thought to be of interest in the context of this
thread.
As Waldek is generating the Lisp code that later is fed into compile-
file, I think he simply could generate the appropriate DECLAIM
statements according to what users specify. So I think there is no
real problem in his particular scenario; or I didn't understand the
description.
As for the problem in general, I think there are good arguments for
all kinds of behaviors and therefore I think it is a reasonable choice
that the effects are unspecified.
On Feb 13, 3:56 am, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2012-02-13 06:41:39 +0000, Marco Antoniotti said:
> > Proclamations do not affect compilations across files.
> I think chapter & verse is:
> "If a use of this macro appears as a top level form in a file being
> processed by the file compiler, the proclamations are also made at
> compile-time. As with other defining macros, it is unspecified whether
> or not the compile-time side-effects of a declaim persist after the
> file has been compiled."
> from DECLAIM.
Yes, but even more general is 3.2.3.1.1, "Processing of Defining
Macros":
"It is not specified whether definitions made available in the
compilation environment are available in the evaluation environment,
nor is it specified whether they are available in subsequent
compilation units or subsequent invocations of the compiler. As with
eval-when, these compile-time side effects happen only when the
defining macros appear at top level."
So this provides guidance for all of the listed defining macros (and
if interpreted that way, any defining-macros created by the user),
_and_ it provides limitations, i.e. the long-term effect can only
happen when the form is at top-level.
Allegro CL uses the Environments Access module, and integrates it into
its compiler fully. Whether it is a feature of that module by
necessity or of Allegro CL for convenience and programmability, we
distinguish those top-level forms by whether they are placed within an
eval-when which includes both :compile-toplevel (or compile) and :load-
toplevel (or load). If both of these times are included within the
eval-when specification, the definition is promised to be carried
beyond the current compilation-unit (usually a compile-file, in most
cases). Otherwise, if compile and load times of either style are not
both present, the scope of the definition dies with the compilation-
unit. This guarantee provides some flexibility and control for
programmers who wish to guarantee what definitions last when, at least
when using Allegro CL.
