http://exploring-lisp.blogspot.com/2008/01/auto-defining-functions.html
GEOFF WOZNIAK has above article about auto defining functions.
Here is some experimentation with autoloading:
; We can associate a pathname with a symbol, property :autoload
(defun define-autoload (symbol pathname)
(setf (get symbol :autoload) pathname))
; this does the loading of the pathname for a symbol
(defun autoload (symbol)
(let ((pathname (get symbol :autoload)))
(assert (and (pathnamep pathname) (probe-file pathname))
(pathname)
"Autoload for symbol ~a, file ~a does not exist." symbol pathname)
(format *standard-output* "Autoloading file ~a for symbol ~a." pathname symbol)
(load pathname)))
(defun try-autoloading (condition)
(autoload (cell-error-name condition))
(continue condition))
(defun call-with-autoloading (function)
(handler-bind ((undefined-function #'try-autoloading))
(funcall function)))
(defmacro autoloading (&body body)
`(call-with-autoloading
(lambda ()
,@body)))
;;; Test, foo1.lisp contains a definition for FOO2
(define-autoload 'foo2 (pathname "/Users/joswig/foo1.lisp"))
(defun test ()
(autoloading
(foo2 10)))
? (test)
Autoloading file /Users/joswig/foo1.lisp for symbol FOO2.
30
? (test)
30
Liquid CL has something like that:
http://www.lispworks.com/documentation/lcl50/aug/aug-26.html
Rainer Joswig <······@lisp.de> writes:
> http://exploring-lisp.blogspot.com/2008/01/auto-defining-functions.html
>
> GEOFF WOZNIAK has above article about auto defining functions.
It's interesting that Geoff is using Allegro CL to experiment with; we
already have such a mechanism - try (apropos "def-autoload") or for a
broader net, (apropos "autoload").
> Here is some experimentation with autoloading:
Our autloading mechanism is similar, but it uses a closure technique
to save quite a bit of space. Also, there is an autoloadp function
that allows a test for whether a function will be autoloaded or not,
without actually loading it.
I don't know why we haven't exported and documented our autoload
facility; we've talked about it since 1990, and each time there is
something that gets in the way. One thing that does get in the way of
exporting def-autoload-generic-function is that the autoload function
itself is not a generic function, and so not only is there an
identity crisis, but our excl::generic-function-p predicate doesn't
give the expected answer. And the other functionalities also have the
same identity crisis (#'foo may not be eq to #'foo at a later time)
but that shouldn't stop us from exporting def-autoload-function or
def-autoload-macro with caveats...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <··············@gemini.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > http://exploring-lisp.blogspot.com/2008/01/auto-defining-functions.html
> >
> > GEOFF WOZNIAK has above article about auto defining functions.
>
> It's interesting that Geoff is using Allegro CL to experiment with; we
> already have such a mechanism - try (apropos "def-autoload") or for a
> broader net, (apropos "autoload").
>
> > Here is some experimentation with autoloading:
>
> Our autloading mechanism is similar, but it uses a closure technique
> to save quite a bit of space. Also, there is an autoloadp function
> that allows a test for whether a function will be autoloaded or not,
> without actually loading it.
>
> I don't know why we haven't exported and documented our autoload
> facility; we've talked about it since 1990, and each time there is
> something that gets in the way. One thing that does get in the way of
> exporting def-autoload-generic-function is that the autoload function
> itself is not a generic function, and so not only is there an
> identity crisis, but our excl::generic-function-p predicate doesn't
> give the expected answer. And the other functionalities also have the
> same identity crisis (#'foo may not be eq to #'foo at a later time)
> but that shouldn't stop us from exporting def-autoload-function or
> def-autoload-macro with caveats...
I can remember seeing autoloading being used in earlier Lisps
on small machines. What kind of 'applications' did you have
in mind?
Rainer Joswig <······@lisp.de> writes:
> I can remember seeing autoloading being used in earlier Lisps
> on small machines. What kind of 'applications' did you have
> in mind?
Every machine is a small machine, if you have an application (i.e. a
program in this application of the word :-) large enough for it.
Autoloading single functions doesn't buy you much, it's true, but
autoloading whole systems, which might have arbitrary amounts of data
which is either loaded or built when such functions are sucked in -
well, a gigabyte here, a gigabyte there, and pretty soon you're
talking real memory...
Is that where you were going with that question?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <··············@gemini.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > I can remember seeing autoloading being used in earlier Lisps
> > on small machines. What kind of 'applications' did you have
> > in mind?
>
> Every machine is a small machine, if you have an application (i.e. a
> program in this application of the word :-) large enough for it.
> Autoloading single functions doesn't buy you much, it's true, but
> autoloading whole systems, which might have arbitrary amounts of data
> which is either loaded or built when such functions are sucked in -
> well, a gigabyte here, a gigabyte there, and pretty soon you're
> talking real memory...
>
> Is that where you were going with that question?
I'll try to read between the lines...