Packages in CMUCL
Oleksandr Kozachuk
I have problems with packages in CMUCL.
I have this files:
testpack1.lisp : ----------------------------------------
(provide 'testpack1)
(defpackage testpack1 (:use common-lisp) (:export testfunc1))
(in-package testpack1)
(defun testfunc1 (x) (* x x))
---------------------------------------------------------
testpack2.lisp : ----------------------------------------
(require 'testpack1)
(defpackage testpack2 (:use testpack1) (:use common-lisp))
(in-package testpack2)
(defun testfunc2 (x) (* x 2))
(print (testfunc1 4))
(print (testfunc2 4))
---------------------------------------------------------
so, this comman work correct:
$ lisp -load testpack2.lisp
but this does not work:
$ lisp -eval '(compile-file "testpack2.lisp")'
Type-error in COMMON-LISP::PACKAGE-OR-LOSE: "TESTPACK1" is not of type PACKAGE
So, why it work with "-load", and fails on compile?
Thanks,
Alex.
P.S.: This work without problems on CLISP.
Nils Goesche
I am not sure what the behavior should be, but it works if you do
(eval-when (:compile-toplevel :load-toplevel :execute)
(require 'testpack1))
in testpack2.lisp.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
Barry Margolin
The REQUIRE call isn't being executed when you compile the file. Change it
to:
(eval-when (:compile-toplevel :load-toplevel :execute)
(require 'testpack1))
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Pierre R. Mai
> > So, why it work with "-load", and fails on compile?
>
> I am not sure what the behavior should be, but it works if you do
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (require 'testpack1))
>
> in testpack2.lisp.
Based on my reading of the standard, require is the same as
e.g. proclaim, in that the file-compiler isn't required to treat it
specially. So if one wants to have require affect the compile-time
environment, too, then I think one needs to wrap it inside an
eval-when form.
I guess the current situation is the direct result of require/provide
being deprecated (and at times during the standards process even
removed), and hence no further effort was spent on specifying
compile-time effects, in the way that was done with declaim...
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Oleksandr Kozachuk
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (require 'testpack1))
>
> in testpack2.lisp.
Can you please explain me, why it work?
i don't understand this :-(((
Alex.
Pierre R. Mai
> In article <87sn6ch...@darkstar.cartan>, Nils Goesche wrote:
> > (eval-when (:compile-toplevel :load-toplevel :execute)
> > (require 'testpack1))
> >
> > in testpack2.lisp.
>
> Can you please explain me, why it work?
When you compile testpack2.lisp, testpack1.lisp hasn't been loaded
yet, so the package TESTPACK1 doesn't exist yet, which is what causes
your error.
So what you want is the file compiler to load testpack1.lisp, before
it processes the rest of the file.
In order to get the compiler to treat the require form specially, and
execute it at compile-time, too (normally it is only executed at load
time), you'll have to wrap it inside an eval-when form, which
specifies :compile-toplevel as one of its situations.
Nils Goesche
It's just as Barry Margolin said:
``The REQUIRE call isn't being executed when you compile the file.''
When you do COMPILE-FILE on testpack2.lisp, you could imagine the
forms being compiled one-by-one, but usually /not/ being evaluated.
In order to compile the defpackage form in testpack2.lisp, and what
follows it, possibly even to merely read it in, it must know, however,
about the package defined in testpack1.lisp, because it is :used. So,
it is crucial that the first form, (require 'testpack1), is actually
evaluated when compiling testpack2.lisp. It is a bit unclear if it
should do this automatically, as CLISP apparently does. By wrapping
it into an EVAL-WHEN, as above, you ensure that it /will/ be evaluated
and the package defined in testpack1.lisp will be known to the compiler
(or the reader?) when it needs it for the rest of the file.
I am not sure if I have understood this fully myself, but I hope it
helps, anyway.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Kent M Pitman
> In article <slrnaaoaev...@Tron.ddeus.lan>, Oleksandr Kozachuk wrote:
> > In article <87sn6ch...@darkstar.cartan>, Nils Goesche wrote:
> >> (eval-when (:compile-toplevel :load-toplevel :execute)
> >> (require 'testpack1))
> >>
> >> in testpack2.lisp.
> >
> > Can you please explain me, why it work?
> >
> > i don't understand this :-(((
>
> It's just as Barry Margolin said:
>
> ``The REQUIRE call isn't being executed when you compile the file.''
...
> I am not sure if I have understood this fully myself, but I hope it
> helps, anyway.
Your explanation was find. The right way to understand this is to see that
the compiler isn't reading the "English" of the file. REQUIRE does just
what it's defined to do: call a function. The compiler just compiles it
the same as if you wrote (FOO ...). Normal functions are not considered for
execution until runtime.
It wouldn't hurt to think of REQUIRE as
WHEN-YOU-GET-AROUND-TO-EXECUTING-THIS-FORM-YOU-SHOULD-REQUIRE
because my sense is that the confusion is that you're thinking its dignified
name means it is a compiler declaration and that it is _FALSELY_ being
seen as
HEY-COMPILER-DONT-COMPILE-OR-LOAD-THIS-FILE-WITHOUT-REQUIRING
Am I right in believing this is the confusion? Otherwise, I just don't
understand why people have such difficulty with this... and I would like
to understand what the true nature of the underlying mental block is here.
If instead of REQUIRE it had been a user function called LOAD-IT-UP,
would there have been some confusion where the user thought it should load
at both compile and load time?
Lars Magne Ingebrigtsen
> Am I right in believing this is the confusion? Otherwise, I just don't
> understand why people have such difficulty with this... and I would like
> to understand what the true nature of the underlying mental block is here.
I think the confusion might come from the Emacs Lisp semantics, where
`require' does mean
HEY-COMPILER-DONT-COMPILE-OR-LOAD-THIS-FILE-WITHOUT-REQUIRING...
--
(domestic pets only, the antidote for overdose, milk.)
la...@gnus.org * Lars Magne Ingebrigtsen
Lorance Stinson
> It wouldn't hurt to think of REQUIRE as
> WHEN-YOU-GET-AROUND-TO-EXECUTING-THIS-FORM-YOU-SHOULD-REQUIRE
> because my sense is that the confusion is that you're thinking its dignified
> name means it is a compiler declaration and that it is _FALSELY_ being
> seen as
> HEY-COMPILER-DONT-COMPILE-OR-LOAD-THIS-FILE-WITHOUT-REQUIRING
> Am I right in believing this is the confusion? Otherwise, I just don't
> understand why people have such difficulty with this... and I would like
> to understand what the true nature of the underlying mental block is here.
My programming background is Pascal, Perl and HTML. In all of the above the
directives to include/require/load a file are performed at compile time.
And
from my limited knowledge of C this is also the case for #include. Since
these languages all inherite many of the same ideas and methods most people
assume this would be the case for other languages. I personally thought of
Perl's 'use PACKAGE_NAME' which loads packages and modules when I first saw
a reference to require. When a person learns something new they tend to
rely on past experiences to guide them. Since Lisp does not behave they way
people expect and are used to confusion results. This is seems to be
furthur
compounded by the amount of flexability the standard gives to everyone,
flexability that most languages do not have.
Just my $0.02. I'm almost positive I'm wrong.
(Please pardon the spelling and grammar, I'm running a day shy of sleep.)
--
Lorance Stinson <lor...@worldpbx.com> http://www.worldpbx.com/
Codito, Ergo Sum (I Code, therefore I am)
Nils Goesche
> Am I right in believing this is the confusion? Otherwise, I just don't
> understand why people have such difficulty with this... and I would like
> to understand what the true nature of the underlying mental block is here.
Well, in my case, any confusion is easily explained by the fact that
I have been too lazy so far to read all of chapter 3 ;-)
Frederic Brunel
> And from my limited knowledge of C this is also the case for #include.
No, #include is a preprocessor directive, the C compiler doesn't known
anything about file inclusions. Generally, C programs needs a
preprocessing phase before the compilation.
--
Frederic Brunel
Software Engineer
In-Fusio, The Mobile Fun Connection
Duane Rettig
There is _no_ magic going on here. So far, everyone has been
concentrating on normal forms such as REQUIRE, but what we really
should be understanding is how DEFPACKAGE, IN-PACKAGE, etc, work,
which are the forms which go _against_ the proper intuition that
nothing should normally happen at compile-time.
So how do DEFPACKAGE and IN-PACKAGE work?
Try a pprint/macroexpand and see for yourself, e.g.:
(pprint (macroexpand '(in-package "FOO")))
There is _no_ magic here.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Thomas F. Burdick
> Kent M Pitman <pit...@world.std.com> writes:
>
> > Am I right in believing this is the confusion? Otherwise, I just don't
> > understand why people have such difficulty with this... and I would like
> > to understand what the true nature of the underlying mental block is here.
>
> I think the confusion might come from the Emacs Lisp semantics, where
> `require' does mean
> HEY-COMPILER-DONT-COMPILE-OR-LOAD-THIS-FILE-WITHOUT-REQUIRING...
I remember how confused I was when I figured this out. I personally
prefer the Emacs notion that require declares dependencies, it's not
just a sugary way of calling load. That's why I use my own require
(and provide) macro that wraps its body in
(eval-when (:compile-toplevel :load-toplevel :execute) ...)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Lorance Stinson
>
> Lorance Stinson <lor...@worldpbx.com> writes:
>
> > And from my limited knowledge of C this is also the case for #include.
>
> No, #include is a preprocessor directive, the C compiler doesn't known
> anything about file inclusions. Generally, C programs needs a
> preprocessing phase before the compilation.
Like I said, I have limited knowledge.
I, of course, remembered this while having a smoke after posting.
Doh!!
Christopher C. Stacy
Christophe Rhodes
> DEFSYSTEM.
That's not as obvious as you might like to make it seem. Care to
elaborate?
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Barry Margolin
Thomas F. Burdick <t...@famine.OCF.Berkeley.EDU> wrote:
>Lars Magne Ingebrigtsen <la...@gnus.org> writes:
>
>> Kent M Pitman <pit...@world.std.com> writes:
>>
>> > Am I right in believing this is the confusion? Otherwise, I just don't
>> > understand why people have such difficulty with this... and I would like
>> > to understand what the true nature of the underlying mental block is here.
>>
>> I think the confusion might come from the Emacs Lisp semantics, where
>> `require' does mean
>> HEY-COMPILER-DONT-COMPILE-OR-LOAD-THIS-FILE-WITHOUT-REQUIRING...
>
>I remember how confused I was when I figured this out. I personally
>prefer the Emacs notion that require declares dependencies, it's not
>just a sugary way of calling load. That's why I use my own require
>(and provide) macro that wraps its body in
>(eval-when (:compile-toplevel :load-toplevel :execute) ...)
It would be nice, but it would be a big special case, a real wart on the
language. At one point in X3J13 we decided that the compiler should never
do anything with top-level function calls. Everything that the compiler
should execute automatically must be either a special form or a macro
(which the compiler must expand, and the expansion will have to contain an
appropriate special form). In CLTL1, PROCLAIM was special in this way, and
we realized it was wrong, so we created the DECLAIM macro (which would
normally expand into an EVAL-WHEN wrapped around the equivalent PROCLAIM,
but it could also involve implementation-specific code). We also changed
IN-PACKAGE from a function to a macro for the same reason.
Perhaps we could have done something similar with REQUIRE. But since we
were deprecating PROVIDE/REQUIRE, it didn't really make sense to change the
specification. They're only still in the language for CLTL1 compatibility,
and if we changed how REQUIRE works it wouldn't be compatible. The point
of deprecating them was to encourage use of and work on better tools for
managing groups of source files (e.g. DEFSYSTEM).
Thomas F. Burdick
> DEFSYSTEM.
You say that as if there were one coherent idea of what defsystem is,
and it was easy to get, use, and move across systems. My experience
with defsystem has been more like you need a new copy of defsystem
itself for every system defined. Plus, the whole idea of a central
repository of whole system definitions, I find repulsive. For most
things, I find require/provide sufficient. For more complicated
systems, I use my own system-building system that I started before I
knew what defsystem was; I keep using it because I've yet to have a
pleasant defsystem experience.
Nils Goesche
> cst...@theworld.com (Christopher C. Stacy) writes:
>
>> DEFSYSTEM.
>
> You say that as if there were one coherent idea of what defsystem is,
> and it was easy to get, use, and move across systems. My experience
> with defsystem has been more like you need a new copy of defsystem
> itself for every system defined. Plus, the whole idea of a central
> repository of whole system definitions, I find repulsive. For most
> things, I find require/provide sufficient.
Hm. Isn't the idea of lots of REQUIRE's and PROVIDE's hidden all over
the place much more repulsive? From the HyperSpec:
# If the pathname-list is nil, an implementation-dependent mechanism
# will be invoked in an attempt to load the module named module-name;
so it doesn't look very portable, either.
> For more complicated
> systems, I use my own system-building system that I started before I
> knew what defsystem was; I keep using it because I've yet to have a
> pleasant defsystem experience.
I stumbled over MK:DEFSYSTEM before I would have been able to write
anything like it in Lisp myself, so I was quite happy about it.
And then there is the very cool system browser in LispWorks...
Kent M Pitman
> ... In CLTL1, PROCLAIM was special in this way, and
> we realized it was wrong, so we created the DECLAIM macro (which would
> normally expand into an EVAL-WHEN wrapped around the equivalent PROCLAIM,
> but it could also involve implementation-specific code). We also changed
> IN-PACKAGE from a function to a macro for the same reason.
>
> Perhaps we could have done something similar with REQUIRE.
Yes, I think that's what this discussion is telling us.
> But since we were deprecating PROVIDE/REQUIRE, it didn't really make
> sense to change the specification.
Good catch on the historical reasoning. I think this is right.
Then again, a lot of people were angry about deprecating these.
> They're only still in the language for CLTL1 compatibility,
and because some people thought the deprecation would get canceled.
As I recall, the problem was not a dispute over this issue, but a dispute
over how the required module should be found. Some people said
"at least leave me two-argument REQUIRE, don't deprecate it entirely"
> and if we changed how REQUIRE works it wouldn't be compatible. The point
> of deprecating them was to encourage use of and work on better tools for
> managing groups of source files (e.g. DEFSYSTEM).
Well, yeah...
Too bad the same crew of people didn't care to vote in a DEFSYSTEM proposal
when it came before them (admittedly after the feature freeze, but still in
time that it _could_ have been adopted).
Kent M Pitman
> cst...@theworld.com (Christopher C. Stacy) writes:
>
> > DEFSYSTEM.
>
> You say that as if there were one coherent idea of what defsystem is,
> and it was easy to get, use, and move across systems. My experience
> with defsystem has been more like you need a new copy of defsystem
> itself for every system defined.
Well, the Lisp Machine was the de facto fountain of such ideas and had
one that could have been used.
Also, there was a specific DEFSYSTEM proposal made to X3J13 (and rejected,
due to lateness, they said...)
> Plus, the whole idea of a central
> repository of whole system definitions, I find repulsive.
Why? Does the Java scheme not work?
At HyperMeta, I'm using a scheme very like Java (with both dotted components
and directory search lists).
[The only thing that is majorly irritating to me is that "Find Files
or Folders..." on the PC isn't able to be given multiple folders so
that I can search all the directories in my search list at once. Does
anyone know a way to do this?]
> For most things, I find require/provide sufficient. For more
> complicated systems, I use my own system-building system that I
> started before I knew what defsystem was; I keep using it because
> I've yet to have a pleasant defsystem experience.
HyperMeta code does it all through its own haired up DEFPACKAGE actually.
Erik Naggum
| Hm. Isn't the idea of lots of REQUIRE's and PROVIDE's hidden all over
| the place much more repulsive? From the HyperSpec:
|
| # If the pathname-list is nil, an implementation-dependent mechanism
| # will be invoked in an attempt to load the module named module-name;
|
| so it doesn't look very portable, either.
But this is what makes it portable. How you organize files on a system
is not portable, so if you do what require needs on every system, what
the single (require :foobar) does is portably ensure that feature :foobar
is portably loaded in every system, regardless of how that actually works
on each system.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Erik Naggum
| When a person learns something new they tend to rely on past experiences
| to guide them.
Not if they are smart. If they are smart, they are both aware of their
past experiences and check that they actually hold before they rely on
them. If relying on the past produces unreliable results, it would be
stupid to continue to attempt to rely on them and just become frustrated.
| Since Lisp does not behave they way people expect and are used to
| confusion results.
Only if you do not stop relying on past experiences when they fail to
produce the expected results.
Nils Goesche
> * Nils Goesche <car...@cartan.de>
> | Hm. Isn't the idea of lots of REQUIRE's and PROVIDE's hidden all over
> | the place much more repulsive? From the HyperSpec:
> |
> | # If the pathname-list is nil, an implementation-dependent mechanism
> | # will be invoked in an attempt to load the module named module-name;
> |
> | so it doesn't look very portable, either.
>
> But this is what makes it portable. How you organize files
> on a system is not portable, so if you do what require needs
> on every system, what the single (require :foobar) does is
> portably ensure that feature :foobar is portably loaded in
> every system, regardless of how that actually works on each
> system.
Ok (I hope I'm not killing lots of kittens right now), it is
certainly fine for loading libraries that are installed somehow,
but we were talking about using REQUIRE instead of DEFSYSTEM and
I can't find any guarantees, for instance, that this will look in
the current directory. The OP was doing COMPILE-FILE on, say,
file1.lisp that contained a (require 'file2) line. file2.lisp
contains (provide 'file2). So, we'd have to assume that the
system knows somehow that the module file2 will be in file2.lisp,
or in some file2.some-fasl-extension, which is to be found in the
same directory as file1.lisp (if we don't supply a third argument
to REQUIRE). Moreover, in order to be a proper replacement for
DEFSYSTEM, it would /also/ have to check if the fasl file is
newer than the lisp file, and compile the lisp file before
loading it if it isn't. Something like this was spooking through
my head when I posted the above.
Oleksandr Kozachuk
> Barry Margolin <bar...@genuity.net> writes:
>> and if we changed how REQUIRE works it wouldn't be compatible. The point
>> of deprecating them was to encourage use of and work on better tools for
>> managing groups of source files (e.g. DEFSYSTEM).
What is defsystem? Where can i reade about it?
Alex.
Nils Goesche
Friedrich Dominicus
That's a sort of Makefile for Lisp programs. CMUCL does come usually
with MK:DEFSYSTEM. You can read about it in the sources and/or in the
documentation for CMUCL
Regards
Friedrich
Raymond Toy
Friedrich> That's a sort of Makefile for Lisp programs. CMUCL does
Friedrich> come usually with MK:DEFSYSTEM. You can read about it
It has been but won't be in the next release. It hasn't been very
well maintained and is out-of-date. The one in clocc.sourceforge.net
is actually maintained.
Ray
Paolo Amoroso
wrote:
> Also, there was a specific DEFSYSTEM proposal made to X3J13 (and rejected,
> due to lateness, they said...)
Was that proposal based on an existing DEFSYSTEM? If so, which one(s)?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * Nils Goesche <car...@cartan.de>
> | Hm. Isn't the idea of lots of REQUIRE's and PROVIDE's hidden all over
> | the place much more repulsive? From the HyperSpec:
> |
> | # If the pathname-list is nil, an implementation-dependent mechanism
> | # will be invoked in an attempt to load the module named module-name;
> |
> | so it doesn't look very portable, either.
>
> But this is what makes it portable. How you organize files on a system
> is not portable, so if you do what require needs on every system, what
> the single (require :foobar) does is portably ensure that feature :foobar
> is portably loaded in every system, regardless of how that actually works
> on each system.
The problem I find with REQUIRE/PROVIDE is that there is no portable user
controllable way to inquire about the conventions en vogue in the
underlying CL implementation.
This is coupled with the very low level interface REQUIRE/PROVIDE have
when it comes to specify the pathname list.
IMHO it is this lack of "high level" introspection combined with this
too low-level interface that may be causing problems to various users.
In Emacs Lisp things work more easily because you can inspect the
`*load-path*'.
This is my .02E
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Dr. Edmund Weitz
> This is my .02E
Euro?
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>
Marco Antoniotti
Raymond Toy <t...@rtp.ericsson.se> writes:
To clarify. There has been some discussion in the CMUCL mailing list
about whether to include a defsystem in the distribution. A decision
has been made to point users toward the site(s) where these utilities
are actually maintained.
In the case of MK:DEFSYSTEM (3.x and 4.x) the place is the CLOCC.
Marco Antoniotti
e...@agharta.de (Dr. Edmund Weitz) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > This is my .02E
>
> Euro?
>
Of course. Let's start using the currency, shall we. Sooner of later
the Brits will capitulate! :)
Eduardo Muñoz
> [The only thing that is majorly irritating to me is that "Find Files
> or Folders..." on the PC isn't able to be given multiple folders so
> that I can search all the directories in my search list at once. Does
> anyone know a way to do this?]
Type something like this in the "Look in" listbox:
C:\Programs;C:\Temp
--
Eduardo Muñoz
Thomas F. Burdick
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > This is my .02E
>
> Euro?
Huh, according to Yahoo, Marco's opinion is worth 12% less than my
$.02 :)
Lorance Stinson
>
> * Lorance Stinson
> | When a person learns something new they tend to rely on past experiences
> | to guide them.
>
> Not if they are smart. If they are smart, they are both aware of their
> past experiences and check that they actually hold before they rely on
> them. If relying on the past produces unreliable results, it would be
> stupid to continue to attempt to rely on them and just become frustrated.
>
> | Since Lisp does not behave they way people expect and are used to
> | confusion results.
>
> Only if you do not stop relying on past experiences when they fail to
> produce the expected results.
I put my past experiences to use. But I only do this when it is
appropriate.
I don't use my Unix experience when working on Novell for example. I have
encountered many people that try to put the most remote past experiences to
use on something that is completely unrelated. Like a person I have worked
with attempting to put past DOS experiences to use on UNIX, and continually
ignoring that they are different and give different results.
Erik Naggum
| I must agree fully. When I work on a new system, language or what have
| you I put my past experiences to use. But I only do this when it is
| appropriate.
Great! :)
| I don't use my Unix experience when working on Novell for example. I
| have encountered many people that try to put the most remote past
| experiences to use on something that is completely unrelated. Like a
| person I have worked with attempting to put past DOS experiences to use
| on UNIX, and continually ignoring that they are different and give
| different results.
Gotta relate one of the more bizarre stories I experienced. At the U of
Oslo, CS dept, some of us had access to good old 9-track tape stations
and made our own private backups on 3600' tapes. In the process of doing
just that one day, a childhood friend of mine came by and saw me through
the machine room window and wanted to know what I was doing; this was
nowhere near what he was used to, having been to a technical college
before the university. So I explained tapes and he seemed to get it, but
then he asked how the FAT was updated on the tape, as he saw some serious
problems with that.
Thomas F. Burdick
Right. Using cl:require and cl:provide for system construction does
assume that the implementation lets the user customize the method it
uses to find modules. Eg:
==== some-module.lisp ===
(defpackage :some-module ...)
;;; set up loading for CMUCL
(defvar *modules-search-list* '("home:src/some-module/"))
(rotatef (search-list "modules:") *modules-search-list*)
(require 'part1)
(require 'part2)
;;; ...
;;; put things back for the CMUCL user
(rotatef (seearch-list "modules:") *modules-search-list*)
==== end some-module.lisp ====
And remember, DEFSYSTEM isn't a facility provided by the language.
Unfortunately, it doesn't provide any more sophisticated of a system
construction facility.
> Moreover, in order to be a proper replacement for DEFSYSTEM, it
> would /also/ have to check if the fasl file is newer than the lisp
> file, and compile the lisp file before loading it if it isn't.
Right. It's too bad that DEFSYSTEM isn't standardized, and the
standard for require/provide doesn't include this functionality. I
actually wrote an elisp-like require/provide system that should be
perfectly portable, and allows you to compile a system, following the
path of REQUIREs, compiling as needed. You mess with *REQUIRE-PATHS*
to change where require looks. The only function that needs to be
ported is COMPILE-FILE-P, but it "works" just fine if you leave the
default of always returning T. And of course, I only need to use my
non-standard facility for compiling -- if I just want to load the
system, in whatever mixture of source/object code it's in, I can use
the language-provided require.
I'm not saying that this is the best system for building systems, but
it's good enough for simple systems. A standardized defsystem
(probably) would have been nice, though.
Lorance Stinson
> Gotta relate one of the more bizarre stories I experienced. At the U of
> Oslo, CS dept, some of us had access to good old 9-track tape stations
> and made our own private backups on 3600' tapes. In the process of doing
> just that one day, a childhood friend of mine came by and saw me through
> the machine room window and wanted to know what I was doing; this was
> nowhere near what he was used to, having been to a technical college
> before the university. So I explained tapes and he seemed to get it, but
> then he asked how the FAT was updated on the tape, as he saw some serious
> problems with that.
times I have tried to explain EXT2, NTFS and UFS to people that only had a
little experience with DOS. It is not easy at times. It get really hard
when
I get to the part about said file systems not needing defragmenting like
FAT
does. May I send this to a friend of mine that will appreciate it more than
I did?
Kent M Pitman
> ...
> I'm not saying that this is the best system for building systems, but
> it's good enough for simple systems. A standardized defsystem
> (probably) would have been nice, though.
People interested in the conceptual issues behind DEFSYSTEM might like
to read
Thomas F. Burdick
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > cst...@theworld.com (Christopher C. Stacy) writes:
> >
> > > DEFSYSTEM.
> >
> > You say that as if there were one coherent idea of what defsystem is,
> > and it was easy to get, use, and move across systems. My experience
> > with defsystem has been more like you need a new copy of defsystem
> > itself for every system defined.
>
> Well, the Lisp Machine was the de facto fountain of such ideas and had
> one that could have been used.
>
> Also, there was a specific DEFSYSTEM proposal made to X3J13 (and rejected,
> due to lateness, they said...)
Hmm. I think I'm glad there's not a half-assed DEFSYSTEM in the
standard. Although a non-depricated, and expanded REQUIRE/PROVIDE
system or a fully-planned out DEFSYSTEM would be even better.
> > Plus, the whole idea of a central
> > repository of whole system definitions, I find repulsive.
>
> Why? Does the Java scheme not work?
Oh, it works. I just don't like it. Of course, I also don't like
that require uses string=, so maybe I'm just bitchy on the subject ...
> At HyperMeta, I'm using a scheme very like Java (with both dotted components
> and directory search lists).
[...]
> > For most things, I find require/provide sufficient. For more
> > complicated systems, I use my own system-building system that I
> > started before I knew what defsystem was; I keep using it because
> > I've yet to have a pleasant defsystem experience.
>
> HyperMeta code does it all through its own haired up DEFPACKAGE actually.
Huh. So your packages require other packages, which get loaded on
demand? I assume the same thing happens when you compile a file?
Doesn't sound that different from my setup, actually. More of a
stylistic difference along the lines of:
(defpackage "FOO" (:use "BAR"))
vs
(defpackage :foo)
(use-package :bar)
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > Also, there was a specific DEFSYSTEM proposal made to X3J13 (and rejected,
> > due to lateness, they said...)
>
> Hmm. I think I'm glad there's not a half-assed DEFSYSTEM in the
> standard. Although a non-depricated, and expanded REQUIRE/PROVIDE
> system or a fully-planned out DEFSYSTEM would be even better.
Well, I'm not sure I'm capable of saying, since it was my proposal,
whether it was "half-assed" or not. However, just for the sake of
conversation, I've put a copy of version 4 of failed proposal DEFSYSTEM
online at
http://world.std.com/~pitman/CL/defsystem.html
> > HyperMeta code does it all through its own haired up DEFPACKAGE actually.
>
> Huh. So your packages require other packages, which get loaded on
> demand?
Yes.
> I assume the same thing happens when you compile a file?
Not exactly. Sometimes you may have to arrange for it manually.
But that doesn't come up much.
Normally if you compile a file you are puttting it in a package, using
IN-PACKAGE. And normally you have created the package that you are
using with IN-PACKAGE using an earlier DEFPACKAGE. So that call to
DEFPACKAGE will have done the demand loading.
> Doesn't sound that different from my setup, actually. More of a
> stylistic difference along the lines of:
>
> (defpackage "FOO" (:use "BAR"))
>
> vs
>
> (defpackage :foo)
> (use-package :bar)
Sort of, I suppose.
Certainly one can do
(com.hypermeta.module:load-module "COM.HYPERMETA.WHATEVER")
if one wants to force a module to load.
But the load-module won't do the package integration. USE-PACKAGE
still does what it does in CL. I just added a thing that says
"if the package has a dot in its name, it's participating in the
scheme of autoloading packages, so try to assure its module is loaded
before proceeding. It's been working fine for me. I had some trouble
with getting it to force recompilation of package dependents when the
dependencies changed dynamically due to debugging, and that used to
be a nuissance, but I think I finally have that mostly working.
Carl Shapiro
> Well, I'm not sure I'm capable of saying, since it was my proposal,
> whether it was "half-assed" or not. However, just for the sake of
> conversation, I've put a copy of version 4 of failed proposal DEFSYSTEM
> online at
> http://world.std.com/~pitman/CL/defsystem.html
Do you mean, http://world.std.com/~pitman/CL/Issues/defsystem.html
???
Kent M Pitman
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
I may add that in the design (well, I am exagerating here) of
MK:DEFSYSTEM 4.x , I took to heart the suggestions you make in that
paper. Dan Barlow did the same for asdf.
The syntax layer is separated from the underlying implementation up to
a certain point, and the implementation of separate operation through
different methods (EXECUTE-ACTION and friends) is done as consistently
as possible. The deviations come when accommodating MK:DEFSYSTEM 3.x
back compatibility was necessary and when hierarchical construction of
components got in the way.
All in all the system is not perfect (yet), but it is rather usable
already.
Marco Antoniotti
t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kent M Pitman <pit...@world.std.com> writes:
>
> > t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > cst...@theworld.com (Christopher C. Stacy) writes:
> > >
> > > > DEFSYSTEM.
> > >
> > > You say that as if there were one coherent idea of what defsystem is,
> > > and it was easy to get, use, and move across systems. My experience
> > > with defsystem has been more like you need a new copy of defsystem
> > > itself for every system defined.
> >
> > Well, the Lisp Machine was the de facto fountain of such ideas and had
> > one that could have been used.
> >
> > Also, there was a specific DEFSYSTEM proposal made to X3J13 (and rejected,
> > due to lateness, they said...)
>
> Hmm. I think I'm glad there's not a half-assed DEFSYSTEM in the
> standard. Although a non-depricated, and expanded REQUIRE/PROVIDE
> system or a fully-planned out DEFSYSTEM would be even better.
Of course. But it is not there. Too bad. :}
> > > Plus, the whole idea of a central
> > > repository of whole system definitions, I find repulsive.
> >
> > Why? Does the Java scheme not work?
>
> Oh, it works. I just don't like it. Of course, I also don't like
> that require uses string=, so maybe I'm just bitchy on the subject
> ...
You may want to check CL-CONFIGURATION in the CLOCC.
> > At HyperMeta, I'm using a scheme very like Java (with both dotted
> > components and directory search lists).
>
> [...]
>
> > > For most things, I find require/provide sufficient. For more
> > > complicated systems, I use my own system-building system that I
> > > started before I knew what defsystem was; I keep using it because
> > > I've yet to have a pleasant defsystem experience.
> >
> > HyperMeta code does it all through its own haired up DEFPACKAGE actually.
>
> Huh. So your packages require other packages, which get loaded on
> demand? I assume the same thing happens when you compile a file?
> Doesn't sound that different from my setup, actually. More of a
> stylistic difference along the lines of:
>
> (defpackage "FOO" (:use "BAR"))
>
> vs
>
> (defpackage :foo)
> (use-package :bar)
My 0.01E (even less than the 0.02 of yersterday) opinion is that it is
not a good idea to overload commonly used things. That is why I came
up with CL-CONFIGURATION.
In my view, you need a separate place to have all the dependency
informations of your "system". This could be the package, but it is
not (and it is not even in Java). It could be the ``system''
(i.e. what you define with a DEFSYSTEM) but that meant (at the time I
wrote CL-CONFIGURATION) messing up with an already complicated piece
of software.
All in all, "separation of concerns" won and I wrote CL-CONFIGURATION.
If you are interested, you can check it out in the CLOCC (the CVS
version is obviously more up to date and with more bugs fixed).
Kent M Pitman
> t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > > t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
...
Heh. Sounds like an application for Pitman's Two-Bit Rule (when you have
two bits of information to represent, use at least two bits to do it....
or some such. i can't remember if i have a standard wording. i just know
jonl white gave it a good name.)
> That is why I came up with CL-CONFIGURATION.
> In my view, you need a separate place to have all the dependency
> informations of your "system".
Actually, I also have another piece of low-level dependency handling.
I arrange file X.Y.Z as an X folder containing a Y containing a Z,
and my defpackage speaks to interpackage dependencies, but not intrapackage
dependencies. To load a package, I load the file _loader.lisp in the
directory in question. This allows a great deal of flexibility in
organizing subsystems.
One thing I don't presently have is complex recompile dependencies between
modules. I mostly now just assume that if someone's module gets recompiled,
then the dependents must, too. Within a module, I might do something more
refined, or I might not. My theory was that anyone's DEFSYSTEM could go here.
This forms a very low-tech way of interrelating packages described by
conflicting DEFSYSTEMs without forcing everyone to have a single defsystem
paradigm, since effectively each of these _loader.lisp files is a node in
a recursive descent and has its own responsibility for descending; it can
change paradigms within itself to load any of its own dependents in a
different way...
It's kind of vague file-based variant of what's in my large systems paper.
I'd be willing to collaborate with people working on other defsystems to
make sure we had the right procedural protocol for this, btw.
Marco Antoniotti
I am almost convenced that the "stuff.conf" files I have in my never
setups (substitute <stuff> with "application", "package", "system")
serve a similar purpose. I also tend to organize my systems in a Java
like way.
A problem I see with this setup is that is requires a discipline that
is not enforced by the language. Java does enforces that up to a
certain extent, but CL does not. This is a "social" problem of sort,
but it is there.
> One thing I don't presently have is complex recompile dependencies between
> modules. I mostly now just assume that if someone's module gets recompiled,
> then the dependents must, too. Within a module, I might do something more
> refined, or I might not. My theory was that anyone's DEFSYSTEM
> could go here.
> This forms a very low-tech way of interrelating packages described by
> conflicting DEFSYSTEMs without forcing everyone to have a single defsystem
> paradigm, since effectively each of these _loader.lisp files is a node in
> a recursive descent and has its own responsibility for descending; it can
> change paradigms within itself to load any of its own dependents in a
> different way...
This is a very good point and I specifically addressed (alas, not
completely implemented) in CL-CONFIGURATION, which accepts different
DEFSYSTEMs.
> It's kind of vague file-based variant of what's in my large systems paper.
> I'd be willing to collaborate with people working on other defsystems to
> make sure we had the right procedural protocol for this, btw.
Well :) The CVS module for MK:DEFSYSTEM 4.x in the CLOCC is
`defsystem-4.x' :)
The main problem now is to rewrite the documentation.