Allegro compilation warnings
Mario Frasca
I was playing around with the idea of having my programs checked for
compilation anytime I start them, and I managed to achieve this by
using the defsystem utility (I'm not sure I understand how much that is
a standard utility, it is included in the CLtL2 online docs, but it is
not described in the allegro ones)
then this construct at the beginning of some of the programs:
(eval-when (:execute :compile-toplevel)
(require <whatever the code requires>)
<...>
)
and something like this at the end of a 'loader' program:
(eval-when (:execute)
(print "checking add-ons system, or compiling them")
(defsystem add-ons-system
(:default-package "ideal"
:default-pathname "ideal:add-ons;"
)
(:module only-one ("cc-utils"
"qual"
"explanation"
"Cooper88a"
"timer"
"add-display-fns"
"matrix"
"gauss"
"extensions"
"top-sort")))
(compile-system 'add-ons-system))
then the question:
this is working, and it allowed me to find a lot of compilation
warnings, which I hate.
the most irritating ones are of this format
Warning: Free reference to undeclared variable *PRECISION* assumed special.
This symbol may have been intended: IDEAL::*PRECISION*.
most of them don't include the second line.
any suggestion on what to do to give the compiler as much information
as it needs so that it won't complain any more?
less disturbing are the ones:
Warning: Variable X-DUMMY is never used.
in C I can give the compiler some #pragma directive to inform it that I
know that this particular parameter is only acting as a dummy, I think
it was #pragma argsused, or something. anything similar in CL?
a pointer to a documentation page could be enough, if that page is
readable.
thanks in advance,
Mario
Raymond Wiker
> this is working, and it allowed me to find a lot of compilation
> warnings, which I hate.
>
> the most irritating ones are of this format
>
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> most of them don't include the second line.
>
> any suggestion on what to do to give the compiler as much information
> as it needs so that it won't complain any more?
>
> less disturbing are the ones:
> Warning: Variable X-DUMMY is never used.
>
> in C I can give the compiler some #pragma directive to inform it that I
> know that this particular parameter is only acting as a dummy, I think
> it was #pragma argsused, or something. anything similar in CL?
Check the HyperSpec entries for `ignore' and `ignoreable'.
--
Raymond Wiker
Raymon...@fast.no
scha...@dfki.de
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> as it needs so that it won't complain any more?
You could try to make sure that the variable *PRECISION* is known to
the compiler when the free reference to it is compiled. I assume that
it is a global variable introduced by a defvar or defparameter
somewhere. Alternatively, there is the SPECIAL declaration
identifier. I don't know whether this is what you really want, it
seems as if the warnings might actually hint at real errors. But you
can use the declarations to prevent this sort of warnings if you wish.
> Warning: Variable X-DUMMY is never used.
> in C I can give the compiler some #pragma directive to inform it that I
> know that this particular parameter is only acting as a dummy, I think
Have a look at the IGNORE and IGNORABLE declaration identifiers.
You could start from Section 3.3.3 of the HyperSpec available at
http://www.xanalys.com/software_tools/reference/HyperSpec/
Hope this helps,
Axel
Paul F. Dietz
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> any suggestion on what to do to give the compiler as much information
> as it needs so that it won't complain any more?
Warnings like this are often a sign that the code is wrong.
At the very least, they indicate poor programming style.
It may be that you meant IDEAL::*PRECISION*, but forgot
this file was in a different package. If so, you have
a bug. Add the package prefix.
If *PRECISION* was really meant, you should add a special
declaration:
(declaim (special *precision*))
or a defvar or defparameter form.
It's a good rule to try to eliminate all warnings, so
they do not obscure future warnings that may indicate
real bugs.
Paul
Erik Naggum
| the most irritating ones are of this format
|
| This symbol may have been intended: IDEAL::*PRECISION*.
|
|
| as it needs so that it won't complain any more?
Well, why don't you declare/define your global variables?
| less disturbing are the ones:
| Warning: Variable X-DUMMY is never used.
So why is it there?
Instead of being "irritated" and "disturbed" and making references
to another language, why not try to program in the language at hand?
The warnings you get indicate that you are still thinking in another
language and your irritation communicates that you don't intend to
stop doing that because you think it is somehow correct to think in
C++ and write in Common Lisp. What I want to know is how you began
to think in C++ in the first place. Or is it that that experience
has taught you that being irritated at computers and languages is
the best approach because nothing else really works any better?
(You're not the first C++ or Microsoft victim to believe this, and
it sometimes takes a long time for people with that background to
get the same kind of warm and calming sensation that the world of
computers can be understood and mastered without mystery and pain
that comes to people who understand the laws of physics and don't
swear at the physical world when it doesn't obey their wishes.
What's so fucking irritating is that those who lack that calmness
make so many incredibly retarded decisions and statements that only
do one thing: perpetuate the mystery and pain for all others. The
best approach is to get a suitable hand-gun and use your Microsoft
and C++ books for target practice. That gives you control, again.
Then start anew with a real language and tools intended for people
to use, not whatever semi-evolved simian the commercials work on.)
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Pierre R. Mai
> If *PRECISION* was really meant, you should add a special
> declaration:
>
> (declaim (special *precision*))
>
> or a defvar or defparameter form.
Just a minor addition: If you are a beginner, use defvar or defparameter
almost exclusively. A stand-alone special declaration is almost always
not what you want.
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
Dirk Zoller
> Just a minor addition: If you are a beginner, use defvar or defparameter
> almost exclusively. A stand-alone special declaration is almost always
> not what you want.
Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
this "special" is about. In short: It changes the way the variable is looked
up from "static" (which is the default in Common Lisp) to "dynamic".
Static means like in Pascal, variables bindings are found in the environment
where the code has been written. Dynamic means in the call chain that led
to the execution of the piece of code at hand.
HTH
Dirk
--
Dirk Zoller
e-mail: d...@onlinehome.de
http://www.dirk-zoller.de
Marco Antoniotti
ma...@cs.uu.nl (Mario Frasca) writes:
> first an introduction:
>
> I was playing around with the idea of having my programs checked for
> compilation anytime I start them, and I managed to achieve this by
> using the defsystem utility (I'm not sure I understand how much that is
> a standard utility, it is included in the CLtL2 online docs, but it is
> not described in the allegro ones)
The DEFSYSTEM utility is *not* part of CLTL2. You are probably
referring to the DEFSYSTEM which come with ACL. This is not
portable.
Instead, MK-DEFSYSTEM is. You can download it from the CLOCC
http://sourceforge.net/projects/clocc
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Pierre R. Mai
> "Pierre R. Mai" wrote:
> > Just a minor addition: If you are a beginner, use defvar or defparameter
> > almost exclusively. A stand-alone special declaration is almost always
> > not what you want.
>
> Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
> this "special" is about. In short: It changes the way the variable is looked
> up from "static" (which is the default in Common Lisp) to "dynamic".
>
> Static means like in Pascal, variables bindings are found in the environment
> where the code has been written. Dynamic means in the call chain that led
> to the execution of the piece of code at hand.
defvar and defparameter also implicitly declare the variable special,
so this isn't the reason why I advise against using stand-alone
special declarations. Just think of special declarations as a more
low-level building block, just like
(setf (fdefinition 'myfun) (lambda (x y) (+ x y)))
is more low-level than
(defun myfun (x y)
(+ x y))
There are times when using (setf fdefinition) is appropriate, but only
under special circumstances and when you know exactly what you are
doing. The same IMHO goes for stand-alone special declarations.
Duane Rettig
> Dirk Zoller <d...@onlinehome.de> writes:
>
> > "Pierre R. Mai" wrote:
> > > Just a minor addition: If you are a beginner, use defvar or defparameter
> > > almost exclusively. A stand-alone special declaration is almost always
> > > not what you want.
> >
> > Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
> > this "special" is about. In short: It changes the way the variable is looked
> > up from "static" (which is the default in Common Lisp) to "dynamic".
> >
> > Static means like in Pascal, variables bindings are found in the environment
> > where the code has been written. Dynamic means in the call chain that led
> > to the execution of the piece of code at hand.
>
> defvar and defparameter also implicitly declare the variable special,
In fact, this can be seen easily by macroexpansion. I always
recommend that people use the following paradigm when trying
to figure out what is inside a macro:
(pprint (macroexpand <form>))
See examples below.
> so this isn't the reason why I advise against using stand-alone
> special declarations. Just think of special declarations as a more
> low-level building block, just like
>
> (setf (fdefinition 'myfun) (lambda (x y) (+ x y)))
>
> is more low-level than
>
> (defun myfun (x y)
> (+ x y))
>
> There are times when using (setf fdefinition) is appropriate, but only
> under special circumstances and when you know exactly what you are
> doing. The same IMHO goes for stand-alone special declarations.
Correct. For example, if you macroexpand a defining form in
Allegro CL, you see that with a special declaration or a (setf fdefinition)
form you are missing the source-file-recording that tends to occur
automatically with defining forms. Of course, this may be precisely
what you want. But usually you want to use a defining form.
Below are example expansions of several defining forms, and I
even included your setf form as well, to show that the macroexpand
technique is not limited to defining forms.
cl-user(1): (pprint (macroexpand '(defvar foo 100)))
(progn (declaim (special foo)) (or (boundp 'foo) (setq foo 100))
(record-source-file 'foo :type :variable) 'foo)
cl-user(2): (pprint (macroexpand '(defparameter bar 100)))
(progn (declaim (special bar)) (setq bar 100)
(record-source-file 'bar :type :variable) 'bar)
cl-user(3): (pprint (macroexpand '(defconstant bar 100)))
(progn (declaim (special bar))
(eval-when (compile) (excl::defconstant1 'bar 100))
(record-source-file 'bar :type :variable) (excl::defconstant2 'bar 100))
cl-user(4): (pprint (macroexpand '(defun bas () 100)))
(progn (eval-when (:compile-toplevel)
(excl::check-lock-definitions-compile-time 'bas 'function 'defun
(fboundp 'bas))
(push 'bas excl::.functions-defined.))
(progn (eval-when (:compile-toplevel)
(excl::check-de-argdecl-change 'bas 'nil))
(declaim (excl::dynamic-extent-arguments nil bas)))
(setf (fdefinition 'bas)
(let ((excl::f
(named-function bas (lambda nil (block bas 100)))))
(excl::set-func_name excl::f 'bas)
excl::f))
(remprop 'bas 'excl::%fun-documentation) (record-source-file 'bas) 'bas)
cl-user(5): (pprint (macroexpand '(setf (fdefinition 'myfun) (lambda (x y) (+ x y)))))
(let* ((#:g119 (lambda (x y) (+ x y)))) (excl::set-function-1 'myfun #:g119))
cl-user(6):
--
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)
Erik Naggum
| The DEFSYSTEM utility is *not* part of CLTL2. You are probably
| referring to the DEFSYSTEM which come with ACL. This is not
| portable.
What utter hogwash! You know better than this, Marco, so don't try
to play presidential campaigns on us, even though the rest of the
media does its best to dumb down to the level of the two jerkfaces.
Here's a hint: The implementation of the function CAR in Common Lisp
is not portable. Still, portable Common Lisp programs may use CAR.
How _can_ this be? How can we possibly use non-portable software to
write portable programs? This must be a mystery to people who buy
your line, Marco! Provided they think about it at all.
| Instead, MK-DEFSYSTEM is.
_Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
"port" the build rules to Allegro CL's defsystem and vice versa, are
you not? How f**king portable is that?
_Designing_ for multiple, incompatible defsystems so we can't move
build rules around is such an incredibly moronic thing to do that it
ought to result in public flogging while being forced to watch every
presidential campaign ad.
Weren't you the guy who only a short time ago argued that XML was a
move in the right direction? My argument against XML is that it
doesn't help squat with the real problem, which is that data is so
dependent on the interpretation of the structure being represented
that the syntax is immaterial in comparison. Now you go and prove
my whole case by having a DEFSYSTEM wherein the build rules, which
are _way_ more important to a user than whether the implementation
machinery is or is not portable, are worthless if he switches the
"application" that uses those build rules, and he has to encode his
old data in a new format, which is supposedly "portable", just like
XML is "portable" on some irrelevant scale, and therefore "better"?
Methinks you've been had, big time, by the XML hype and have missed
the opportunity to think about information representation entirely,
instead confused into thinking that some irrelevant piece of the
puzzle needs to be "portable" (the syntax or the implementation),
and that that's it, we can all relax now and ignore the cost of
conversion, irritation with subtle differences, and the mysterious
bugs that crop up because we poor humans remember too well.
This is why XML is _not_ s step in the right direction: It works
just like a pacifier on screaming babies who are duped into feeling
they got something good stuffed into their face and so they stop
screaming for whatever they _really_ wanted (love, compassion, body
contact, etc, clearly not as easy to market as some disgusting piece
of plastic, but hey, let's just shut the kids up, just like we can
make all those stupid crying users shut up with some irrelevant hype
that goes nowhere and does nothing for them!). Stop treating people
like screaming babies and grow up, damn it! It's the _information_
that needs to be portable -- to hell with "portable" implementations
that make that information non-portable or some "portable" syntax
that makes it even harder _actually_ to get portable information.
Disclaimer 1: This is why I haven't even _looked_ at MK-DEFSYSTEM,
so I'm just taking Marco's word for it that it is incompatible with
Allegro CL's defsystem and every other defsystem by implication.
Disclaimer 2: I started using Allegro CL's defsystem because it was
there, well integrated into the full system, not because I made any
conscious decision to use that defsystem in particular. It was just
there when I needed it. Having spent lots of time understanding how
to use it and extend it and how it works, I'm not going to throw it
away for some new shit just because it has a portable implementation
that's going to be a helpful feature exactly _once_ in its lifetime.
Mario Frasca
> Well, why don't you declare/define your global variables?
written by others. as long as I didn't modify it, it would just run
quietly. then I had to perform some minor changes and I discovered a
lot of compilation warnings. I'm used to having code without
warnings, or where the amount of warnings I get is exactly a known
figure, so I started modifying the code in order to remove all
warnings.
unfortunately my understanding of the compilation process in
Lisp is still far from complete, hence my questions.
>| less disturbing are the ones:
>| Warning: Variable X-DUMMY is never used.
>
> So why is it there?
wow, an easy question!
you deserve two answers:
1) as far as these warnings are coming from code which I did not write,
I just follow the rule "if it ain't broken, don't fix it".
2) look at this example:
(defun compute-coefficients (x1 p1 x2 p2 x3 p3)
(handler-bind ((DIVISION-BY-ZERO
#'(lambda (x-dummy) (return-from compute-coefficients nil))))
(gauss:solve (list (list x1 1 (- p1) (* x1 p1))
(list x2 1 (- p2) (* x2 p2))
(list x3 1 (- p3) (* x3 p3))))))
here I have to provide handler-bind with a one-parameter-function, but
in this function I really don't know what to do with this parameter. I
named x-dummy so that when reading that warning I know I can ignore
it.
Mario
Mario Frasca
>Warnings like this are often a sign that the code is wrong.
>At the very least, they indicate poor programming style.
>
>It may be that you meant IDEAL::*PRECISION*, but forgot
>this file was in a different package. If so, you have
>a bug. Add the package prefix.
I have an idea of what is going on here:
I have enclosed all (require)s in (eval-when) blocks, and replaces all
(load)s by the corresponding (require). I then tried to achieve the same
as you do when you use 'make'. but then the lisp-way, with defsystem.
now some sources are being compiled without the environment having
loaded some other required sources. I hope this is stated correctly.
I probably have to inspect the various sources and discover all
dependencies or find out where they have been stated and in which
format.
thanks,
Mario
Rainer Joswig
(Mario Frasca) wrote:
> 1) as far as these warnings are coming from code which I did not write,
> I just follow the rule "if it ain't broken, don't fix it".
>
> 2) look at this example:
> (defun compute-coefficients (x1 p1 x2 p2 x3 p3)
> (handler-bind ((DIVISION-BY-ZERO
> #'(lambda (x-dummy) (return-from compute-coefficients nil))))
> (gauss:solve (list (list x1 1 (- p1) (* x1 p1))
> (list x2 1 (- p2) (* x2 p2))
> (list x3 1 (- p3) (* x3 p3))))))
>
> here I have to provide handler-bind with a one-parameter-function, but
> in this function I really don't know what to do with this parameter.
Maybe just ignore it here. It is the condition object, which has
some information about the error. Seems like the
code does not make any use of it.
> I
> named x-dummy so that when reading that warning I know I can ignore
> it.
>
> Mario
...
(lambda (x-dummy)
(declare (ignore x-dummy))
...
The argument to the function actually is a condition.
You may leave a more descriptive variable name:
...
(lambda (condition)
(declare (ignore condition))
...
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum
| unfortunately my understanding of the compilation process in
| Lisp is still far from complete, hence my questions.
Sure, but it was your _irritation_ that I commented on. Legacy code
is _not_ a source of pain and suffering. It can be a source of
great pride and hubris: You're _so_much_better_ than the neanderthal
who wrote the code to begin with. It can be a wonderful source of
satisfaction: Almost anything you do will be an improvement. It can
be used for target practice: Just print it out, hang it up, and fire
at will. It's not like you're killing anything that deserved to
live. However, make sure that whoever hired the neanderthal who
makes you waste your time knows how you're spending your time --
most managers are unaware that they need to adjust their behavior
and their decision criteria because their inferiors are reluctant to
tell them how they went wrong in the past. Managers should be
willing to listen to and learn from the experience collected by
their inferiors, or _their_ manager(s) need to hear it. It may be
easier to move elsewhere, but that has the obvious downside of not
identifying and virtually hanging neanderthal programmers _and_ the
managers who hire them. If this is not important to you, chances
are that you are in the same category yourself. (If you were only
working with programming to get paid, bad legacy code is such a huge
source of billable hours that you can't possibly be unhappy with it.)
| >| less disturbing are the ones:
| >| Warning: Variable X-DUMMY is never used.
| >
| > So why is it there?
|
| wow, an easy question!
I'm afraid not.
| you deserve two answers:
I _deserve_ them? Geez.
| 1) as far as these warnings are coming from code which I did not write,
| I just follow the rule "if it ain't broken, don't fix it".
It _is_ broken. That's why you get warnings, and that's why you're
trying to fix it. And I _deserved_ this answer? Geez.
| 2) look at this example:
| (defun compute-coefficients (x1 p1 x2 p2 x3 p3)
| (handler-bind ((DIVISION-BY-ZERO
| #'(lambda (x-dummy) (return-from compute-coefficients nil))))
| (gauss:solve (list (list x1 1 (- p1) (* x1 p1))
| (list x2 1 (- p2) (* x2 p2))
| (list x3 1 (- p3) (* x3 p3))))))
|
| here I have to provide handler-bind with a one-parameter-function,
| but in this function I really don't know what to do with this
| parameter. I named x-dummy so that when reading that warning I know
| I can ignore it.
I suggest you look up handler-case to simplify the expression
dramatically. See? Not an easy question.
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * Marco Antoniotti <mar...@cs.nyu.edu>
> | The DEFSYSTEM utility is *not* part of CLTL2. You are probably
> | referring to the DEFSYSTEM which come with ACL. This is not
> | portable.
>
> What utter hogwash! You know better than this, Marco, so don't try
> to play presidential campaigns on us, even though the rest of the
> media does its best to dumb down to the level of the two jerkfaces.
>
> Here's a hint: The implementation of the function CAR in Common Lisp
> is not portable. Still, portable Common Lisp programs may use CAR.
> How _can_ this be? How can we possibly use non-portable software to
> write portable programs? This must be a mystery to people who buy
> your line, Marco! Provided they think about it at all.
Come on Erik! You very well that if I write an ACL DEFSYSTEM
spec it simply won't run on CMUCL. Unless somebody "ported" ACL
DEFSYSTEM (or LispWorks, or MCL DEFSYSTEM) to CMUCL.
In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
platforms. The other DEFSYS around do not (with the possible excepton
of PCL DEFSYS).
I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
will make me write things at least twice.
> | Instead, MK-DEFSYSTEM is.
>
> _Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
> "port" the build rules to Allegro CL's defsystem and vice versa, are
> you not? How f**king portable is that?
Of course you can rewrite the MK-DEFSYSTEM rules in Lispworks
DEFSYSTEM (and MCL, and PCL). You are doing at least twice the
work. "In this sense" it is not portable.
You can always write things in Scheme and then port your Scheme
program from implementation X to implementation Y by rewriting the
code that does "records" or "multi-dimensional arrays". The semantics
is pretty much the same. The syntax as well.
> _Designing_ for multiple, incompatible defsystems so we can't move
> build rules around is such an incredibly moronic thing to do that it
> ought to result in public flogging while being forced to watch every
> presidential campaign ad.
Apart the pain that just comes to my mind by your suggested torture :)
(I have a more sadistic twist: watch *italian* electoral campaign ads)
I do not understand your first sentence. It seems that you assume
that "build rule" is something primitive. I do not understand this.
As per the way I work. I organize my code in such a way that it is
easily structured using MK-DEFSYSTEM. Our group has just purchased a
version of ACL (sorry Xanalys folks :) Duane Rettig will be happy
instead - at least until I'll start bugging him :) ). Yet I do not use
ACL DEFSYSTEM because I cannot run it under CMUCL (at least I cannot
easily - and I have not even tried to think about licensing
questions).
> Weren't you the guy who only a short time ago argued that XML was a
> move in the right direction? My argument against XML is that it
> doesn't help squat with the real problem, which is that data is so
> dependent on the interpretation of the structure being represented
> that the syntax is immaterial in comparison.
And in my reply I said you are right in this respect. However, XML
somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul users
from the burden of writing an AST constructor for their documents.
Which is what you get for free when using CL. *IMHO*, this has an
immense pragmatic effect and a potential for speedup in the day-to-day
life of programmers. I may be wrong on this.
> Now you go and prove
> my whole case by having a DEFSYSTEM wherein the build rules, which
> are _way_ more important to a user than whether the implementation
> machinery is or is not portable, are worthless if he switches the
> "application" that uses those build rules, and he has to encode his
> old data in a new format, which is supposedly "portable", just like
> XML is "portable" on some irrelevant scale, and therefore
> "better"?
Erik. I really do not understand this. I am missing the use of
"build rule" that you make. If I can say something in my defense
(which may imply an interpretation of what you just wrote which may be
incorrect), I wrote CL-CONFIGURATION to address this sort of issues.
With CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written
in a number of different and incompatible DEFSYSes. In this way you
don't have to translate. I don't expect CL-CONFIGURATION to be
perfect, but I find it useful.
> Methinks you've been had, big time, by the XML hype and have missed
> the opportunity to think about information representation entirely,
> instead confused into thinking that some irrelevant piece of the
> puzzle needs to be "portable" (the syntax or the implementation),
> and that that's it, we can all relax now and ignore the cost of
> conversion, irritation with subtle differences, and the mysterious
> bugs that crop up because we poor humans remember too well.
That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
...
>
> Disclaimer 1: This is why I haven't even _looked_ at MK-DEFSYSTEM,
> so I'm just taking Marco's word for it that it is incompatible with
> Allegro CL's defsystem and every other defsystem by implication.
Yes it is. It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and --
I hope -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
> Disclaimer 2: I started using Allegro CL's defsystem because it was
> there, well integrated into the full system, not because I made any
> conscious decision to use that defsystem in particular. It was just
> there when I needed it. Having spent lots of time understanding how
> to use it and extend it and how it works, I'm not going to throw it
> away for some new shit just because it has a portable implementation
> that's going to be a helpful feature exactly _once_ in its
> lifetime.
Fine. I wrote CL-CONFIGURATION for you.
(conf:defconfiguration "ERIK-SYSTEM-CONFIGURATION"
(:require-system "MARCO-SYSTEM"
:system-file-namestring "marco.system"
:system-type :mk-defsystem)
(:require-system "ERIK-SYSTEM"
:system-file-namestring "erik.sys"
:system-type :allegro))
Running CONF:SETUP on an ACL with MK-DEFSYSTEM available will
correctly load all the required systems. On a CMUCL it will tell you
that you do not have ACL DEFSYSTEM available. (CL-CONFIGURATION does
other things as well, namely set up Logical Pathnames in a way I find
reasonable).
CL-CONFIGURATION is a new piece of software. It is by no means
perfect. But it runs at least on ACL and CMUCL (if it does not run on
other implementations it should really be easy to fix.)
BTW. I started using MK-DEFSYSTEM because I started working with
GCL and CMUCL and then I pretty much went down the road you went.
Paolo Amoroso
> _Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
> "port" the build rules to Allegro CL's defsystem and vice versa, are
> you not? How f**king portable is that?
In the following paper Kent Pitman discussed the separation of notation
from functionality in system management tools:
"The Description of Large Systems"
MIT AI Lab Memo No. 801
September, 1984
Abstract:
In this paper, we discuss the problems associated with the description
and manipulation of large systems when their sources are not maintained
as single files. We show why and how tools that address these issues,
such as Unix MAKE and Lisp Machine DEFSYSTEM, have evolved.
Existing formalisms suffer from the problem that their _syntax_ is not
easily separatable from their _functionality_. In programming languages,
standard "calling conventions" exist to insulate the caller of a function
from the syntactic details of how that function was defined, but until
now no such conventions have existed to hide consumers of program systems
from the details of how those systems were specified.
We propose a low-level data abstraction which can support notations such
as those used by MAKE and DEFSYSTEM without requiring that the
introduction of a new notation be accompanied by a completely different
set of tools for instantiating or otherwise manipulating the resulting
system.
Lisp is used for presentation, but the issues are not idiosyncratic to
Lisp.
Keywords: Compilation, Large Systems, Lisp, System Maintenance
Pitman proposed low-level protocols for supporting the creation of
different system management tools. Tim Bradshaw mentioned a similar idea as
an example of a metafeature in a paper presented at LUGM '99:
"One step beyond, or, Creeping metafeaturism"
http://www.cley.com/articles/one-step-beyond.pdf
See section 7 "One step beyond" on page 7.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Erik Naggum
| Come on Erik!
Just _fix_ your attitude problem, Marco. Unless, of course, the
_intent_ of your messages is to piss me off.
| You very well that if I write an ACL DEFSYSTEM spec it simply won't
| run on CMUCL. Unless somebody "ported" ACL DEFSYSTEM (or LispWorks,
| or MCL DEFSYSTEM) to CMUCL.
The most interesting property of a language is whether it has been
specified so that it may be implemented independently. If it can't,
don't ever use it.
Portable code is red herring when it comes to sharing information
that uses code as its vehicle of transportation and existence.
Portable code has in fact led to serious problems when languages
only exist as a single implementation that runs "everywhere".
I'm not sure whether your "If only X were in the standard" recently
was meant as a strong opinion that people should not use that which
is not in the standard, but the Standard you allude to is a document
ath allows people everywhere to implement the language and places
requirements on the implementation.
| In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
| platforms.
This is not necessarily a good thing. This means that there will be
only one implementation of it because other implementations are not
worth writing. This leads to cancer of the language it implements.
| I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
| will make me write things at least twice.
You _could_ implement the language used by Allegro CL's defsystem.
| You can always write things in Scheme and then port your Scheme
| program from implementation X to implementation Y by rewriting the
| code that does "records" or "multi-dimensional arrays". The semantics
| is pretty much the same. The syntax as well.
Why are you not getting it? You're so favorable to XML, yet you
don't even seem to grasp that the idea behind XML is that it's a
syntax standard that people implement in order for their data to be
at least parseable from implementation to implementation. You don't
want "A portable XML parser". You want "portable XML data".
| As per the way I work. I organize my code in such a way that it is
| easily structured using MK-DEFSYSTEM.
Languages tend to shape the way we think.
| And in my reply I said you are right in this respect. However, XML
| somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul
| users from the burden of writing an AST constructor for their
| documents. Which is what you get for free when using CL. *IMHO*,
| this has an immense pragmatic effect and a potential for speedup in
| the day-to-day life of programmers. I may be wrong on this.
_Why_ does it have that potential? Is it because there is a common
standard that many people _implement_ and conform to, or is it
because there is code that is portable from C to C++ to Perl to Java
to Python to Ada 95 to Intercal to Kwikkalkul or whatever?
I'm not interested in what a program does with my data when I choose
to use a syntax like XML (or SGML). I'm interested in making sure
that I can write a new application according to a specification that
will be able to read and process it without having access to the
(probably portable, too) code that processed it initially.
| Erik. I really do not understand this. I am missing the use of
| "build rule" that you make.
The information you write down in your defsystem rules are intended
to help you build the system, right? Like a makefile builds stuff.
Of course, "building" in Common Lisp also means loading it into a
Lisp system and perhaps dumping a new image, but the whole idea is
that you have a bunch of sources, a bunch of build rules, and if you
apply the build rules to the sources, you end up with a product.
Those relationships are important to preserve and describe
accurately. That's why a _common_ defsystem is important. That's
why a portable defsystem is probably not a good thing, because there
will never be anyone who argues for or against features in it, no
arguments over the implementation or the precise semantics, only
"does it work or not"-style questions, which are anathema to the
value of the described relationships.
| If I can say something in my defense (which may imply an
| interpretation of what you just wrote which may be incorrect), I
| wrote CL-CONFIGURATION to address this sort of issues. With
| CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written in a
| number of different and incompatible DEFSYSes. In this way you
| don't have to translate. I don't expect CL-CONFIGURATION to be
| perfect, but I find it useful.
Bad solution to the wrong problem. If you had written this utility
to read the language used by the various defsystems and produced
some common form that could build with your system, we might be
getting somewhere, but as long as you only identify the interpreter
of the descriptions, you help kill the information, i.e., making it
_more_ dependent on the specific interpreter of its representation.
| > Methinks you've been had, big time, by the XML hype and have
| > missed the opportunity to think about information representation
| > entirely, instead confused into thinking that some irrelevant
| > piece of the puzzle needs to be "portable" (the syntax or the
| > implementation), and that that's it, we can all relax now and
| > ignore the cost of conversion, irritation with subtle
| > differences, and the mysterious bugs that crop up because we
| > poor humans remember too well.
|
| That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
I haven't looked at them, but from what you describe, they fall in
the category of "stop-gap solutions that block real progress", like
a huge number of other software "solutions" to fundamental problems.
People will appreciate it, of course, and it does solve a problem
that people actually have, but they have it for a bad reason, and it
should not be solved for another bad reason. That way lies Perl.
| It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and -- I hope
| -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
This is good if you go for the monopoly control situation where you
want everybody to use your _implementation_, but the more you keep
telling me it runs everywhere, the more important it is to make sure
the language it interpretes is specified externally to it and
actually is implemented by someeone else, too.
| Fine. I wrote CL-CONFIGURATION for you.
I hope that one day you will at least listen enough to what I keep
telling you in more and more different ways in the hopes of one day
getting through the belief that you unquestionably do the right
thing that it may not be the right thing. So: No, you didn't.
If anything, I want a standardized defsystem whose semantics is the
object of standardization, not the code. When we have some code
that gets standardized, we all lose, because the standard becomes
"whatever the code does", and thousands of people will hack at the
code and standard means exactly nothing. When we standardize
languages, we all win, because thousands of people will have a
single, authoritative source, and will fight to have people agree
with them on what the specification should say. Since people put in
special cases in code and exploit them to no end, but can't get away
with it in specifications, the means of control over the run-away
programmer is a good specification.
From one data point, you can extrapolate in any direction.
From one implementation, you can standardize in any direction.
| BTW. I started using MK-DEFSYSTEM because I started working with
| GCL and CMUCL and then I pretty much went down the road you went.
Then how did we end up so astonishingly far apart?
Paolo Amoroso
[...about the availability of MK-DEFSYSTEM on several platforms...]
> This is good if you go for the monopoly control situation where you
> want everybody to use your _implementation_, but the more you keep
> telling me it runs everywhere, the more important it is to make sure
> the language it interpretes is specified externally to it and
> actually is implemented by someeone else, too.
MK-DEFSYSTEM comes with good documentation. Would that be a good starting
point for creating a standard? What kind of work would it take to turn that
documentation into a useful standard?
Marco Antoniotti
Hello
I apologize in advandce for the long citations.
Erik Naggum <er...@naggum.net> writes:
> | You very well that if I write an ACL DEFSYSTEM spec it simply won't
> | run on CMUCL. Unless somebody "ported" ACL DEFSYSTEM (or LispWorks,
> | or MCL DEFSYSTEM) to CMUCL.
>
> The most interesting property of a language is whether it has been
> specified so that it may be implemented independently. If it can't,
> don't ever use it.
>
> Portable code is red herring when it comes to sharing information
> that uses code as its vehicle of transportation and existence.
> Portable code has in fact led to serious problems when languages
> only exist as a single implementation that runs "everywhere".
Let's narrow dwon the issues to "DEFSYSTEM". The need for a common
DEFSYSTEM has been felt for some time. Messages were sent to the
X3J13 mailing list asking to put a DEFSYSTEM into the standard.
As per MK-DEFSYSTEM, I must say that there is a document which
describes its behavior in a pretty good way. Of course it could be
made better (actually it should), but it describes pretty well what
the intent of the package should be as well as its "semantics". The
document could be taken as a starting point for other competing
implementations.
MK-DEFSYSTEM also has - IMHO - a rather nice sematics and systems
written in it are rather straightforward (YMWL).
Reimplementing ACL-DEFSYS or LW-DEFSYS would be quite a job at this
point. The current state of affairs tells me that it is easier and
better to converge on MK-DEFSYSTEM.
> I'm not sure whether your "If only X were in the standard" recently
> was meant as a strong opinion that people should not use that which
> is not in the standard, but the Standard you allude to is a document
> ath allows people everywhere to implement the language and places
> requirements on the implementation.
No. It is not a strong opinion. Although I encourage people who start
a fresh new project in Common Lisp to use MK-DEFSYSTEM instead of the
"local" ones. Of course, if you do not plan to distribute your
software, you have less ncentives to use a tool like MK-DEFSYSTEM.
THink of my case. I just wrote a nifty piece of software which will
have to run under Linux (where I essentially will have to use CMUCL),
Windows (where I must use a "not-in-the-standard" feature of ACL -
namely OLE), and probably the Mac using MCL. The system I wrote was
fresh. Basically no code existed before May. In this case using
MK-DEFSYSTEM savesme quite a bit of work.
> | In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
> | platforms.
>
> This is not necessarily a good thing. This means that there will be
> only one implementation of it because other implementations are not
> worth writing. This leads to cancer of the language it
> implements.
I wouldn't go so far. Let's say that at this point we need a better
document describing what MK-DEFSYSTEM is and must do. Then we make
susre that the implementation is correct w.r.t. the document. People
experiment and "the invisible parenthesis" decides what is worth and
what is not. However, in this case there will be a "usable" common
reference implementation. With the power of hindsight this is on
possible reason why we are using CLOS, but not CLIM.
> | I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
> | will make me write things at least twice.
>
> You _could_ implement the language used by Allegro CL's defsystem.
Franz could implement MK-DEFSYSTEM.
...
> Why are you not getting it? You're so favorable to XML, yet you
> don't even seem to grasp that the idea behind XML is that it's a
> syntax standard that people implement in order for their data to be
> at least parseable from implementation to implementation. You don't
> want "A portable XML parser". You want "portable XML data".
I am not *that* favourable to XML. And I uderstand your argument.
>
> | As per the way I work. I organize my code in such a way that it is
> | easily structured using MK-DEFSYSTEM.
>
> Languages tend to shape the way we think.
>
> | And in my reply I said you are right in this respect. However, XML
> | somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul
> | users from the burden of writing an AST constructor for their
> | documents. Which is what you get for free when using CL. *IMHO*,
> | this has an immense pragmatic effect and a potential for speedup in
> | the day-to-day life of programmers. I may be wrong on this.
>
> _Why_ does it have that potential? Is it because there is a common
> standard that many people _implement_ and conform to, or is it
> because there is code that is portable from C to C++ to Perl to Java
> to Python to Ada 95 to Intercal to Kwikkalkul or whatever?
>
> I'm not interested in what a program does with my data when I choose
> to use a syntax like XML (or SGML). I'm interested in making sure
> that I can write a new application according to a specification that
> will be able to read and process it without having access to the
> (probably portable, too) code that processed it initially.
I agree with this. I am merely saying that, given the state of
affairs in the rest of the world before XML, XML is quite a step
forward, exactly for the reasons you mention. The fact that you will
then have access to a libxml.so which will contain a parser for the
syntax which you will eventually interpret according to a "spec
document", will save quite a bit of work. The relatively bad news for
the Lisp Community is that Lisp had the notion of Sexpr and READ for
ages.
>
> | Erik. I really do not understand this. I am missing the use of
> | "build rule" that you make.
>
> The information you write down in your defsystem rules are intended
...
>
> Those relationships are important to preserve and describe
> accurately. That's why a _common_ defsystem is important. That's
> why a portable defsystem is probably not a good thing, because there
> will never be anyone who argues for or against features in it, no
> arguments over the implementation or the precise semantics, only
> "does it work or not"-style questions, which are anathema to the
> value of the described relationships.
This is an excellent point. Basically you are saying that 'make' is
"ugly". Which is an agreeable proposition. However, how do you
proceed toward a "common defsystem"? I do not have the time and/or
resources to undertake such a task (I did not even write MK-DEFSYSTEM
to start with). But, having a common portable "reference"
implementation is a good thing. PCL fitted the bill. And now AFAIK,
ACL and LW have non-PCL CLOS system. However, note that your very
same argument applies to ACL-DEFSYSTEM and LW-DEFSYSTEM. "there will
never be anyone who argues for or against features in it, no arguments
over the implementation or the precise semantics, only "does it work
or not"-style questions, which are anathema to the value of the
described relationships."
> | If I can say something in my defense (which may imply an
> | interpretation of what you just wrote which may be incorrect), I
> | wrote CL-CONFIGURATION to address this sort of issues. With
> | CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written in a
> | number of different and incompatible DEFSYSes. In this way you
> | don't have to translate. I don't expect CL-CONFIGURATION to be
> | perfect, but I find it useful.
>
> Bad solution to the wrong problem. If you had written this utility
> to read the language used by the various defsystems and produced
> some common form that could build with your system, we might be
> getting somewhere, but as long as you only identify the interpreter
> of the descriptions, you help kill the information, i.e., making it
> _more_ dependent on the specific interpreter of its
> representation.
True. I won't argue whether this is a "bad solution to the wrong
problem". I believe that the problem the CL community has is
"bad". As per your suggestion, yes. It would have been better, but it
is a solution that is beyond my energies. After all it has only been
6 months I have been able to actually work on CL to solve my work
problems.
...
> | That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
>
> I haven't looked at them, but from what you describe, they fall in
> the category of "stop-gap solutions that block real progress", like
> a huge number of other software "solutions" to fundamental problems.
> People will appreciate it, of course, and it does solve a problem
> that people actually have, but they have it for a bad reason, and it
> should not be solved for another bad reason. That way lies Perl.
Yes. They are "stop-gap solutions". I don't beleive they are as bad
as to "stop real progress". They are up for grab and you can argue
with their semantics and implementations. Maybe down that line "lies
Perl", I surely hope people won't go all the way there. I surely
wouldn't (though I may write code that goes in that direction).
>
> | It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and -- I hope
> | -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
>
> This is good if you go for the monopoly control situation where you
> want everybody to use your _implementation_, but the more you keep
> telling me it runs everywhere, the more important it is to make sure
> the language it interpretes is specified externally to it and
> actually is implemented by someeone else, too.
The language *is* specified externally (there is a good document
describing it). I have been trying to write up another document which
will explore extensions to MK-DEFSYSTEM (e.g. loading of C libraries -
which now is a non documented and not completely working feature of
MK-DEFSYTEM). Franz and Xanalys can implement MK-DEFSYSTEM as they
want. The licensing allows them to do so. Surely I don't want to be
seen an I simply won't behave as a monopolist. CL-CONFIGURATION is
there to prove this claim of mine.
> | Fine. I wrote CL-CONFIGURATION for you.
>
> I hope that one day you will at least listen enough to what I keep
> telling you in more and more different ways in the hopes of one day
> getting through the belief that you unquestionably do the right
> thing that it may not be the right thing. So: No, you didn't.
>
> If anything, I want a standardized defsystem whose semantics is the
> object of standardization, not the code. When we have some code
> that gets standardized, we all lose, because the standard becomes
> "whatever the code does", and thousands of people will hack at the
> code and standard means exactly nothing. When we standardize
> languages, we all win, because thousands of people will have a
> single, authoritative source, and will fight to have people agree
> with them on what the specification should say. Since people put in
> special cases in code and exploit them to no end, but can't get away
> with it in specifications, the means of control over the run-away
> programmer is a good specification.
Erik, I agree with this. CL-CONFIGURATION comes with what I hope to
be a good document describing the intended semantics of the
system. I am not on par with many people on this list (yourself
included) who are capable of writing a complex standard document and
make sure that there are no loose ends (besides, I have to do other
work as well). If people wants modifications on the document, I am
perfectly willing to start arguing and bite all the necessary bullets.
E.g. on the CLOCC mailing list there has been quite a discussion about
what kind of "novel" features should be included in MK-DEFSYSTEM.
Mainly, some people wanted to include in MK-DEFSYSTEM also a notion of
"version" and have the system take care to "retrieve" the desired
version from the "repository". I am mostly against to this solution
for a number of reasons. Yet the thing did not make it in
MK-DEFSYSTEM (btw. MK-DEFSYSTEM has a form of versioning built-in)
because there was not (yet) agreement on the actual semantics of this
feature. All in all I am saying this because I want to make clear
that I am at the same time open to discussion *and* not willing to
allow unclear features in a system for which I am the caretaker (at
least allow me to exert this right).
> From one data point, you can extrapolate in any direction.
> From one implementation, you can standardize in any direction.
>
> | BTW. I started using MK-DEFSYSTEM because I started working with
> | GCL and CMUCL and then I pretty much went down the road you went.
>
> Then how did we end up so astonishingly far apart?
We are not that far apart. Cosi` vicini, cosi` lontani. ?!? :)
Cheers
marco
Erik Naggum
| MK-DEFSYSTEM comes with good documentation. Would that be a good
| starting point for creating a standard? What kind of work would it
| take to turn that documentation into a useful standard?
Some sort of agreement on (A) what the language implemented by the
system is (a specification), (B) what the language implemented by
the system is not (a scope), (C) what constitues local enhancements
and additions as opposed to basic features (a conformance clause).
Then we would have a good starting point. That we already have one
implementation is not in and by itself a negative. That we have
_only_ one, is. A specifcation must be sufficiently precise to
allow multiple implementations, even with multiple sets of local
enhancements and local features.
I think we need a standard defsystem. I don't think we should use
existing code for that job just because it's there. Therefore, the
questions you ask are very pertinent to the development of a real
standard and real formal agreement.
Mario Frasca
>* Mario Frasca
>| the most irritating ones are of this format
>|
>| Warning: Free reference to undeclared variable *PRECISION* assumed special.
>| This symbol may have been intended: IDEAL::*PRECISION*.
>|
>| most of them don't include the second line.
>|
>| any suggestion on what to do to give the compiler as much information
>| as it needs so that it won't complain any more?
>
as I told you, I'm working on code which has been developed by someone
else. I am trying to have it automatically compiled, but there were
some circular dependencies in the sources, so I had to move some
functions from one file to an other and I have 'announced' the
dependencies in a set of require clauses at the beginning of each
file, so that I can be satisfied of working with these sources.
for some reasons, I don't manage to understand all this apparent
nonsense about the current package, since which is the current package
at a certain point in my sources is not defined statically but
dynamically and I'm not -yet- used to it.
I will make here a list of the problems I encountered:
(eval-when <when> <what>)
I understand what it does, I don't understand how I can use it in a
reasonable way. are there any programming styles which have proven
good practice?
(in-package <pack>)
(require <file>)
these can be used only in an (eval-when) block, otherwise the
compiler will complain. as for the preceding point, I am not sure if
there is any way to have it work without complaints. the programs I
inherited contained the following fragment, which I modified into the
second following fragment, any comments?
>>
(defun ld-sens ()
(load "ideal:sens;sens-menu")
(in-package :sens)
(sens-menu))
<<
>>
(defun ld-sens ()
(load "ideal:sens;sens-menu")
(sens::sens-menu))
<<
(<pack>::<func>)
if I am in the evaluator (interactive session) I can write something
like sens::sens-menu), even if I already am in the sens package. As
far as I could test, this does not work in a (compiled) program. I
also noticed that (in-package <pack>), evaluated when already in
<pack_1>, behaves differently in the interactive session (goes to
<pack>) and in a program (tries to go to <pack_1::pack>.
(import <list>)
I am here just puzzled by the fact that I can use this with more
freedom than (in-package) and (require). I probably see a connection
which is non existing...
now I answer to those references of yours about which language to use
when thinking about a solution. no offence taken, none intended.
references to a language I understand are a means to understand a
language I don't yet know well enough to express the things I want to
express. If I was developing from scratch, I would use those parts of
the language I know, and study the ones I come across as I need them.
having to modify a complex interaction of poorly written sources is as
if you had to modify a bad Albanian text into a good Albanian piece of
poetry, you allow me to think in Italian while studing the subtelties
of that language? thanks.
please, don't speak M$ to me. if you know it, you avoid it.
Mario
Mario Frasca
>The DEFSYSTEM utility is *not* part of CLTL2. You are probably
>referring to the DEFSYSTEM which come with ACL. This is not
>portable.
>
>
> http://sourceforge.net/projects/clocc
I wrote down this reference, thanks.
now I understand why the core program on which the other things were
built (http://www.rpal.rockwell.com/ideal.html) also provides an
*implementation* of defsystem. I did not get it at first. but for the
time being I think I will just stay with it. when I'm done with
correcting dependencies and understanding packages and if I have no
other urgent task -which is quite likely, actually- then I'll have a
serious look at this mk-defsystem.
ciao,
Mario
Marco Antoniotti
ma...@cs.uu.nl (Mario Frasca) writes:
Your problem is more basic. You are not (yet) distinguishing between
READ time and EVALUATION time.
Consider the second DEFUN. When it is READ in by the CL environment
nothing is executed yet. The form is READ in all at once. Now what is
the "reader" doing? It looks at the symbols and tries to make sense
out of them. Now you have (at least) the following cases.
1 - you are in a fresh CL session where the SENS package does not exist.
The reader sees the following symbols in order (it does other
things as well, but let's skip it for the time being):
DEFUN LD-SENS LOAD SENS::SENS-MENU.
Now, DEFUN is looked up in the current package *PACKAGE* (which
most likely is COMMON-LISP-USER), since DEFUN is external in the
COMMON-LISP package (which is used byt the COMMON-LISP-USER
package), it is found and no problems ensue.
LD-SENS is looked up as well in the COMMON-LISP-USER package. It
is not found there and therefore, since it does not have a package
qualifier in front, it is INTERNED in the COMMON-LISP-USER
package. No further problem follow.
SENS::SENS-MENU is different. Because this symbol is qualified
with the SENS:: package qualifier, the CL reader first looks up
the SENS package. It does not find it and it signals an error.
Up to this point the SENS package does not exist.
2 - you are in a long running CL session and somehow you have already
defined the SENS package. Or maybe you are running a "dumped
image" of CL which contains the SENS package.
The reader reads the form, gets to the SENS::SENS-MENU symbol,
finds the SENS package and it is home free.
If you consider the first DEFUN, things work exactly the same in spite
of the presence of the IN-PACKAGE. First the form gest READ in and
then it is available for evaluation.
IN-PACKAGE at the top level of a file is treated specially by the
LOADer. But this is another story.
All in all, you will be better off writing a *separate* package file
with a DEFPACKAGE form in it. The system you are running is
pre-CLtL2, hence people were not used then to do this.
> (<pack>::<func>) <===
> if I am in the evaluator (interactive session) I can write something
> like sens::sens-menu), even if I already am in the sens package. As
> far as I could test, this does not work in a (compiled) program. I
> also noticed that (in-package <pack>), evaluated when already in
> <pack_1>, behaves differently in the interactive session (goes to
> <pack>) and in a program (tries to go to <pack_1::pack>.
First of all, it is not a very good thing to access symbols with the
'::' qualifier. The '::' qualifier (for lack of a better word) is
useful for debugging purposes, but not for programming. If a symbol
is exported use the ':' qualifier.
As far as the "it does not work in a compiled program, see my previous
explanation. I am sure most of your problems lie there.
>
> (import <list>)
> I am here just puzzled by the fact that I can use this with more
> freedom than (in-package) and (require). I probably see a connection
> which is non existing...
>
>
> now I answer to those references of yours about which language to use
> when thinking about a solution. no offence taken, none intended.
>
> references to a language I understand are a means to understand a
> language I don't yet know well enough to express the things I want to
> express. If I was developing from scratch, I would use those parts of
> the language I know, and study the ones I come across as I need them.
> having to modify a complex interaction of poorly written sources is as
> if you had to modify a bad Albanian text into a good Albanian piece of
> poetry, you allow me to think in Italian while studing the subtelties
> of that language? thanks.
Sono a tua disposizione :)
Cheers
Paolo Amoroso
[context: what is required to create a standard]
> Some sort of agreement on (A) what the language implemented by the
> system is (a specification), (B) what the language implemented by
> the system is not (a scope), (C) what constitues local enhancements
> and additions as opposed to basic features (a conformance clause).
I understand (A) and (C), but I fail to get the difference--if any--between
(B) and its implicit definition as a sort of "set complement" of (A) and
(C). Could you elaborate on this?
Erik Naggum
| as I told you, I'm working on code which has been developed by someone
| else. I am trying to have it automatically compiled, but there were
| some circular dependencies in the sources, so I had to move some
| functions from one file to an other and I have 'announced' the
| dependencies in a set of require clauses at the beginning of each
| file, so that I can be satisfied of working with these sources.
The way the system was compiled should be dug up. My hunch is it
was all loaded in as source, and then compiled. You can very easily
do that yourself, and it's much, much easier than what you've been
doing so far.
| for some reasons, I don't manage to understand all this apparent
| nonsense about the current package, since which is the current
| package at a certain point in my sources is not defined statically
| but dynamically and I'm not -yet- used to it.
Well, first you dispense with the opiniated bullshit that it's
"apparent nonsense". To see why, judge how likely it is that you
listen to what I said after I branded your opinion that way first.
If you're really smart, it didn't affect you at all, figuring that I
had my reasons to this very specific incident and that you could
understand them -- the converse is not quite true for your reaction
since it is not specific to anything anyone but you can determine.
You continue to display irrational elements in your behavior towards
the code you're working on. Just what does it take to make you snap
into a more rational approach?
The current package is a read-time concept. When Common Lisp loads
a file, it reads one expression at a time, then evaluates it. If
that expression changes something in the global environment, it is
available for the next expression to use. The in-package macro sets
*package* to the package named by its argument for the duration of
the file as load creates a binding of *package* that is unwound when
the file terminates.
The current package is naturally _also_ a run-time concept, but it
affects only functions that intern symbols in the current package,
among them load and read, in addition to the actual function intern.
If you don't use these functions in your own code, you don't have to
worry about the current package at run-time, as all the symbols you
need were interned at read-time.
Compilation of the files loaded does not alter these facts, as the
file compiler's responsibility is to ensure that the semantics of
loading the file is retained.
| references to a language I understand are a means to understand a
| language I don't yet know well enough to express the things I want
| to express.
How did you learn your first language? Why was that such a lousy
experience that everything must now be done relative to what you
first learned? _If_ it was such a lousy experience, I'm loathe to
believe that you know your first language all that well. If you had
no problems at all learning your first language, why not repeat the
success? Either way, to base learning a new language on old stuff
seems like a plan to lose. Part of learning that first language was
to learn to _think_ in that language. If you don't learn to _think_
in the next language you set out to "learn", you won't ever manage
to get your head around its concepts. That means what is called a
"suspension of disbelief" in reading normal literature, i.e., the
willingness to enter the universe of the book on its own premises.
If you can't do _that_ successfully, you won't ever make a good
programmer in any language.
And how come you had the patience to wait until you did know the
first language well enough before you attempted something, but now
you don't have that patience? Or _didn't_ you have that patience to
begin with? A lot of people don't really possess the tinest shred
of the personal quality of real patience that is required to be good
at _anything_, least of all precision crafts such as programming or,
say, target shooting (which I recently picked up because I run out
of patience with computer programming at times :).
| If I was developing from scratch, I would use those parts of the
| language I know, and study the ones I come across as I need them.
Why is this a bad approach if you are not developing from scratch?
| having to modify a complex interaction of poorly written sources is
| as if you had to modify a bad Albanian text into a good Albanian
| piece of poetry, you allow me to think in Italian while studing the
| subtelties of that language? thanks.
I don't believe you really understand what it means to think in a
programming language, nor have the patience to acquire that skill,
so I'll just give up now.
| please, don't speak M$ to me. if you know it, you avoid it.
I "speak M$" to you? Geez. How the hell is it possible _not_ to do
something wrong to you, Mario Frasca? I don't have the time to
pander to someone whose sensibilities are so erratical