Re: reason for having separate package.lisp?



I have seen a good deal of simple, single file lisp code that does just what
you're suggesting. Ironically, asdf.lisp itself uses precisely this
idiom!
Oops... I should have recall it before. It looks like all this thread
is redundant...
Sorry for that...

If you do so, you'll probably want to use #: to prevent the package
we're in when the file is read from being polluted with interned
symbols from the reading of your file, thus:
Yes, I do that since I have first seen it somewhere. But no reason to
(defpackage #:foo (:use :common-lisp) (:export #:bar))
I use defpackage :foo instead as I use keywords to find a package
definition.
I just type :foo at SLIME prompt and press M-. Also, it is useful to
do
(find-package :foo). Thus, it is likely that :foo will be created soon
anyway.

Nor am I am not aware of any implementation that has a bug that would
cause you a problem using this idiom.
Ok, thanks.

1. In general, you shouldn't write code to possible bugs, but to the
standard.
I've seen some ingenious code which was written to the bugs. It is
screamer and ap5.

2. Still might not be the best idea to put the package form(s) in the
same file 'cause it might make life more difficult for you down the
road.
It depends on the situation. Some files are useful even when they are
not a part
of any system, e.g. net.hexapodia.toposort. And I see no reason why it
should ever
grow. I think if such a file depends on CL only, it is reasonable to
keep it single.
Adding a package file implies creation of .asd file too. So, we get
three files
instead of one without any serious reason. Then we would need a folder
for them, symlink
to asd file, and I think it is a great redundancy. On the other hand,
if we use clbuild,
asdf-install, or want to make asd systems depend on the file, we would
likely need asd
system too. But if I had resources, I'd better subclass asdf::system
to support such
single files. As there is other annoying problem: I still know no way
in SLIME to
type :foo, press magic key and visit foo.asd.

In addition, if you're using asdf as your original question
suggests you are, why not avail yourself of its ability to load
separate files in a well defined way?
Mmm, maybe this is one other good reason to make asd system for every
file.
.



Relevant Pages

  • Re: A Question about DEFPACKAGE syntax
    ... you give is a reason NOT to use strings. ... "FOO" does not create superficial symbols in the keyword package ... not creating those extra few symbols in the KEYWORD package is ...
    (comp.lang.lisp)
  • Re: Partial classes C# 2.0
    ... >> The reason I asked this question was- VB.Net allows you not to use ... >> keyword in one of it's source file definitions; ... >> use the keyword 'partial' in all of its source files- I was trying to ... >>> Foo is the Quuz assembly ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: identifiers and modules
    ... Do you have a reason why a language should allow it? ... (let ((foo (transform-value foo))) ...)) ... working on a large nested function can easily use the wrong variable ... Given that allowing an inner declaration to override an outer ...
    (comp.lang.scheme)
  • Re: Simple noob question.
    ... No, there are certainly variables with lexical scope, but in ... > (defparameter foo 13) ... accidentally rebind one dynamically when you were intending to just ... so there's no reason to use the *...* convention in their case. ...
    (comp.lang.lisp)
  • Re: OT Baby Grace
    ... Diabetes is the excuse foir being here not the reason for being here. ... please don't crosspost support to MHD or scientifics to ASD. ... diagnosis, even though I was in other newsgroups & other places on the ...
    (alt.support.diabetes)