Consider the following file:
(defparameter *foo*
'(1 #.(function (lambda (x) x)) 2))
(defun foo ()
(print (cadr *foo*))
(funcall (cadr *foo*) 77))
This works if I load this file. But doesn't when I compile the
file. For example, I see in CMUCL:
* (compile-file "1215.cl")
Python version 1.0, VM version Intel x86 on 15 DEC 01 06:22:51 pm.
Compiling: /home/vlz/acl/1215.cl 15 DEC 01 06:19:33 pm
File: /home/vlz/acl/1215.cl
In: DEFPARAMETER *FOO*
'(1 #<Interpreted Function (LAMBDA (X) X) {4802A6B1}> 2)
Error: Cannot dump objects of type EVAL:INTERPRETED-FUNCTION into fasl files.
Would you mind to suggest something ? I'd like to have functional object
(preferably compiled function) as a part of a list and in a way as I do
above (or similar but w/o additional EVAL at "runtime") for interpreted
function. Even if I managed to compile this file the function introduced
this way will remain interpreted.
--
Vladimir Zolotykh ······@eurocom.od.ua
Vladimir Zolotykh wrote:
>
> (defparameter *foo*
> '(1 #.(function (lambda (x) x)) 2))
> (defun foo ()
> (print (cadr *foo*))
> (funcall (cadr *foo*) 77))
May be
(defparameter *foo*
`(1 ,#'(lamda (x) x) 2))
This should give what I want. Sorry for useless question.
--
Vladimir Zolotykh ······@eurocom.od.ua
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Consider the following file:
>
> (defparameter *foo*
> '(1 #.(function (lambda (x) x)) 2))
> (defun foo ()
> (print (cadr *foo*))
> (funcall (cadr *foo*) 77))
>
> This works if I load this file. But doesn't when I compile the
> file. For example, I see in CMUCL:
>
> * (compile-file "1215.cl")
>
> Python version 1.0, VM version Intel x86 on 15 DEC 01 06:22:51 pm.
> Compiling: /home/vlz/acl/1215.cl 15 DEC 01 06:19:33 pm
>
>
> File: /home/vlz/acl/1215.cl
>
> In: DEFPARAMETER *FOO*
> '(1 #<Interpreted Function (LAMBDA (X) X) {4802A6B1}> 2)
> Error: Cannot dump objects of type EVAL:INTERPRETED-FUNCTION into fasl files.
>
> Would you mind to suggest something ? I'd like to have functional object
> (preferably compiled function) as a part of a list and in a way as I do
> above (or similar but w/o additional EVAL at "runtime") for interpreted
> function. Even if I managed to compile this file the function introduced
> this way will remain interpreted.
In CLHS, read these sections fully:
3.2.3 File Compilation
3.2.4 Literal Objects in Compiled Files
The latter is especially important.
For this particular problem, the situation is easy because you don't need
anything as powerful as what you're thinking in order to accomplish it:
(defparameter *foo*
`(1 ,#'(lambda (x) x) 2))
This is because load-time toplevel evaluation is pretty much the same "time"
as execution time for DEFPARAMETER.
In a program context, where execution time and load time were
farther apart and you wanted to assure the evaluation happeend
at load time, I'd use:
(defun foo ()
(bar (load-time-value `(1 ,#'(lambda (x) x) 2))))
which will behave like
(defun foo ()
(bar '...constant...))
but will not compute that constant until load time instead of computing it
at compile time and suffering the consequences of it potentially containing
an object that is not externalizable.
Section 3.2.4 will explain this issue.
Kent M Pitman wrote:
>
> In CLHS, read these sections fully:
>
> 3.2.3 File Compilation
> 3.2.4 Literal Objects in Compiled Files
Thank you Kent. I read it. Better to say 'tried to read',
because I just didn't catch much. I haven't enough experience
to understand it. I'm not giving up. Will try some later.
--
Vladimir Zolotykh ······@eurocom.od.ua
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Kent M Pitman wrote:
> >
> > In CLHS, read these sections fully:
> >
> > 3.2.3 File Compilation
> > 3.2.4 Literal Objects in Compiled Files
>
> Thank you Kent. I read it. Better to say 'tried to read',
> because I just didn't catch much. I haven't enough experience
> to understand it. I'm not giving up. Will try some later.
The main thing you want to understand is that the rule isn't about
having a kind of datum in a program. You can have any datum in a
program. But you can't "file compile" all data. It is not a
limitation of the language semantics per se but of the ability to
externalize (what Java now, since then, calls serialization, I
suppose). Any object is in principle serializable but not all objects
are. Those builtins that are not are not something you can
after-the-fact make be, and since functions are among them, they don't
make good data in file compilation. I hope that makes sense.
The issue with externalization relates to the issue of recognizing
"the same" datum across images. Normal models of sameness bottom out
at pointer-compares, but those pointer compares are valid only for a
session. So reconstructing the same object is problematic.
Hope this helps.
Beiginnig to understand.
DEFPARAMETER, DEFVAR, LOAD-TIME-VALUE don't evaluate their forms until
load time. This greatly simplifies work for the COMPILE-FILE function.
It should not code objects some way (difficult) being reconstructable to the
same at load time (when compiled file is loaded). (It must do that if
forms should be evaluated like that in DEFUN in your example). Probably
this representation of objects in compiled file called 'externalization'
and not all objects fall in this category. This above applicable to
so called 'literal objects' This objects should be reconstructed to the same
at load time.
--
Vladimir Zolotykh ······@eurocom.od.ua
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Beiginnig to understand.
>
> DEFPARAMETER, DEFVAR, LOAD-TIME-VALUE don't evaluate their forms until
> load time.
ALL TOPLEVEL FORMS are evaluated at load time. There is nothing special about
DEFPARAMETER or DEFVAR. If you just have (PRINT 'HELLO) at topleve it won't
execute until loadtime. Indeed, conceptually, even DEFUN won't evaluate until
load-time in the sense that (DEFUN FOO (X) ...) approximately turns into just
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA (X) ...)) and although this code gets
compiled, the executiion effect does not happen until load time.
Now, LOAD-TIME-VALUE is special because it's used in a place that might
otherwise get evaluated more than once, and it arranges for it only to haappn
> This greatly simplifies work for the COMPILE-FILE function.
Yes.
> It should not code objects some way (difficult) being reconstructable to the
> same at load time (when compiled file is loaded). (It must do that if
> forms should be evaluated like that in DEFUN in your example). Probably
> this representation of objects in compiled file called 'externalization'
> and not all objects fall in this category. This above applicable to
> so called 'literal objects' This objects should be reconstructed to the same
> at load time.
Yes, literal objects must be constructed at load time. In compiled code,
I think this will generally include objects to be created by LOAD-TIME-VALUE
even though they do not appear in the source as literals and instead want
to be computed.
* Vladimir Zolotykh
| DEFPARAMETER, DEFVAR, LOAD-TIME-VALUE don't evaluate their forms until
| load time. This greatly simplifies work for the COMPILE-FILE function.
| It should not code objects some way (difficult) being reconstructable to
| the same at load time (when compiled file is loaded). (It must do that
| if forms should be evaluated like that in DEFUN in your example).
| Probably this representation of objects in compiled file called
| 'externalization' and not all objects fall in this category.
Seems you got most of this exactly right, excet that you can define
methods on make-load-form for your own classes to make them loadable.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.