Trying to do this:
;; doesn't work
(defmacro in-defpackage (name &rest options)
(values
`(defpackage ,name ,@options)
`(in-package ,name)))
(in-defpackage
:my-package
;;etc.
)
;; want to be in :my-package
Is VALUES not the correct approach?
I'm not sure what else would work.
--
Dan
www.prairienet.org/~dsb
On Mar 2, 1:41 am, Dan Bensen <··········@cyberspace.net> wrote:
> Trying to do this:
>
> ;; doesn't work
> (defmacro in-defpackage (name &rest options)
> (values
> `(defpackage ,name ,@options)
> `(in-package ,name)))
>
> (in-defpackage
> :my-package
> ;;etc.
> )
> ;; want to be in :my-package
>
> Is VALUES not the correct approach?
> I'm not sure what else would work.
Unfortunately, intuition fails us here. What does
(macroexpand-1 '(in-defpackage :my-package))
return?
PROGN is the preferred way for multiple forms to be run within one
form. Macros expand into one form; all but the main value is ignored.
Tayssir
Tayssir John Gabbour wrote:
> Unfortunately, intuition fails us here. What does
> (macroexpand-1 '(in-defpackage :my-package))
> return?
Ah, I see. It only returns the DEFPACKAGE form.
> PROGN is the preferred way for multiple forms to be run within one
> form. Macros expand into one form; all but the main value is ignored.
This confirms my suspicion that CL likes multiple values only when
they're received by an appropriate MULTIPLE-VALUE-FOO function.
Thanks for the help.
You too, Ken.
--
Dan
www.prairienet.org/~dsb
On Thu, 01 Mar 2007 20:42:21 -0600, Dan Bensen <··········@cyberspace.net> said:
| Tayssir John Gabbour wrote:
| ...
|| PROGN is the preferred way for multiple forms to be run within one
|| form. Macros expand into one form; all but the main value is ignored.
| This confirms my suspicion that CL likes multiple values only when
| they're received by an appropriate MULTIPLE-VALUE-FOO function.
Multiple values are a red herring here. Note that you want forms
such as IN-PACKAGE [1] to be top-level forms, and it is PROGN that
preserves that (as returned by the macroexpansion, of course, not
as computing the macroexpansion: (DEFMACRO # (...) `(PROGN ...)),
not (DEFMACRO # (...) (PROGN `...))).
[1] i.e. forms that macroexpand into EVAL-WHEN
---Vassil.
--
mind mate, n.
One of two persons mentally compatible with each other (cf. soul mate).
On Mar 2, 3:42 am, Dan Bensen <··········@cyberspace.net> wrote:
> This confirms my suspicion that CL likes multiple values only when
> they're received by an appropriate MULTIPLE-VALUE-FOO function.
Off the top of my head, CL is only rarely interested, in the sense you
mean...
* Reader macros, where zero values results in no forms created. You
can define comments this way.
* Define-setf-expander, where you're supposed to return 5 values.
Pretty weird.
Of course, this can all be implemented using MULTIPLE-VALUE-FOO,
underneath the covers.
Can't think offhand of other places where multiple values are
particularly desired by Lisp...
Tayssir
On 1 Mar 2007 21:09:23 -0800, "Tayssir John Gabbour" <············@googlemail.com> said:
| On Mar 2, 3:42 am, Dan Bensen <··········@cyberspace.net> wrote:
|| This confirms my suspicion that CL likes multiple values only when
|| they're received by an appropriate MULTIPLE-VALUE-FOO function.
| Off the top of my head, CL is only rarely interested, in the sense you
| mean...
| * Reader macros, where zero values results in no forms created. You
| can define comments this way.
Or #+ and #-.
| * Define-setf-expander, where you're supposed to return 5 values.
| Pretty weird.
Why _weird_? Setf expansion has five aspects that need to be
customized (everything else is handled in the same standard way
for any form), or think of it as a five-hook protocol.
A language with "out" parameters (in Ada terminology) would
have instead called the setf expander with five of those.
| Of course, this can all be implemented using MULTIPLE-VALUE-FOO,
| underneath the covers.
| Can't think offhand of other places where multiple values are
| particularly desired by Lisp...
For the sake of completeness, the REPL is prepared to receive
and print in some suitable way multiple values from each form.
---Vassil.
--
mind mate, n.
One of two persons mentally compatible with each other (cf. soul mate).
On Mar 2, 6:31 am, Vassil Nikolov <···············@pobox.com> wrote:
> On 1 Mar 2007 21:09:23 -0800, "Tayssir John Gabbour" <············@googlemail.com> said:
> | * Define-setf-expander, where you're supposed to return 5 values.
> | Pretty weird.
>
> Why _weird_? Setf expansion has five aspects that need to be
> customized (everything else is handled in the same standard way
> for any form), or think of it as a five-hook protocol.
>
> A language with "out" parameters (in Ada terminology) would
> have instead called the setf expander with five of those.
Dunno. It's just weird. ;) I guess the argument is it's speedwise
preferable to building a list/plist, structure, or a standard-
object... in cases where expanding a SETF form is performance-
critical?
I'm fine with it, and here, weird = cool + odd, but it's kind of like
one of the weird rooms at Hogwarts one stumbles across one day... a
room which is hard for most to remember in any serious detail.
Tayssir
--
Some quote the western canon, I cite Harry Potter...
On Mar 1, 4:41 pm, Dan Bensen <··········@cyberspace.net> wrote:
> ;; doesn't work
Aside from the fact that you probably want PROGN, you may want to
stick with IN-PACKAGE for other reasons, depending on what your
development environment is.
"Also, many Lisp development environments, particularly Emacs-based
ones such as SLIME, look for an IN-PACKAGE to determine the package
they should use when communicating with Common Lisp. Multiple IN-
PACKAGE forms per file may confuse these tools as well."
- Peter Siebel, Practical Common Lisp
http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html
"Ben Morse" <········@gmail.com> writes:
> On Mar 1, 4:41 pm, Dan Bensen <··········@cyberspace.net> wrote:
>> ;; doesn't work
>
> Aside from the fact that you probably want PROGN, you may want to
> stick with IN-PACKAGE for other reasons, depending on what your
> development environment is.
>
> "Also, many Lisp development environments, particularly Emacs-based
> ones such as SLIME, look for an IN-PACKAGE to determine the package
> they should use when communicating with Common Lisp. Multiple IN-
> PACKAGE forms per file may confuse these tools as well."
>
> - Peter Siebel, Practical Common Lisp
> http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html
To say nothing of the fact that you really want to define all your
packages in advance of reading (i.e. loading or compile-filing) the
sources that need to be read in those packages. I talk about this in
the section "Packaging Mechanics" in the chapter cited above.
-Peter
Peter Seibel wrote:
> ... you really want to define all your
> packages in advance of reading (i.e. loading or compile-filing) the
> sources that need to be read in those packages. I talk about this in
> the section "Packaging Mechanics" in the chapter cited above.
Thanks, I'll start doing it that way.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Peter Seibel wrote:
>
>> ... you really want to define all your
>> packages in advance of reading (i.e. loading or compile-filing) the
>> sources that need to be read in those packages. I talk about this in
>> the section "Packaging Mechanics" in the chapter cited above.
>
>
> Thanks, I'll start doing it that way.
>
No, that is completely wrong. All you have to do, as even the PCL
chapter says, is load things in the right order. Oh, the horror! If that
is impossible, one has screwed up the code /badly/, referring to
packages one should not be referring to. Indeed, first setting things up
to load in the right order and then hunting down all the things that
just broke is a nice semi-automatic way of straightening out ones code.
If you cannot load code in the right order, btw, I hope you do not
believe in macros.
Defining all expected packages up front is just a way of saying one
should not be a programmer, because one views doing it right as a
nuisance. Programming is too damn hard as it is, let's not start
papering over badly organized code.
I am starting to understand why strait-jacket languages get invented.
hth, kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
>> Peter Seibel wrote:
>>> ... you really want to define all your
>>> packages in advance of reading (i.e. loading or compile-filing) the
>>> sources that need to be read in those packages. I talk about this in
>>> the section "Packaging Mechanics" in the chapter cited above.
> Dan Bensen wrote:
>> Thanks, I'll start doing it that way.
Ken Tilton wrote:
> No, that is completely wrong. All you have to do, as even the PCL
> chapter says, is load things in the right order. Oh, the horror!
> Indeed, first setting things up to load in the right order and
> then hunting down all the things that just broke is a nice
> semi-automatic way of straightening out ones code.
The section entitled "Packaging Mechanics" states
> Some folks like to create a foo-package.lisp file for each individual
> package, ... though the one-file-per-package approach also requires
> that you arrange to load the individual files in the right order
> according to the interpackage dependencies.
Would you rather have programmers maintain lots of booger-sized
single-package definition files? Or do you reject the entire notion
of separating definition from implementation? Also, does one of
these approaches work with asdf better than the others?
> If you cannot load code in the right order, btw, I hope you do not
> believe in macros.
My life would not be complete without macros. Please don't take them
away from me :(
> Defining all expected packages up front is just a way of saying one
> should not be a programmer, because one views doing it right as a
> nuisance. Programming is too damn hard as it is, let's not start
> papering over badly organized code.
What about mutually dependent packages? Is that allowed? And if so,
would you still prefer the booger-file system?
> I am starting to understand why strait-jacket languages get invented.
Let's not go there. The straight-jacket is sometimes worse than the
original problem.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
>>> Peter Seibel wrote:
>>>
>>>> ... you really want to define all your
>>>> packages in advance of reading (i.e. loading or compile-filing) the
>>>> sources that need to be read in those packages. I talk about this in
>>>> the section "Packaging Mechanics" in the chapter cited above.
>
>
>> Dan Bensen wrote:
>>
>>> Thanks, I'll start doing it that way.
>
>
> Ken Tilton wrote:
>
>> No, that is completely wrong. All you have to do, as even the PCL
>> chapter says, is load things in the right order. Oh, the horror!
>> Indeed, first setting things up to load in the right order and then
>> hunting down all the things that just broke is a nice semi-automatic
>> way of straightening out ones code.
>
>
> The section entitled "Packaging Mechanics" states
>
>> Some folks like to create a foo-package.lisp file for each individual
>> package, ... though the one-file-per-package approach also requires
>> that you arrange to load the individual files in the right order
>> according to the interpackage dependencies.
>
>
> Would you rather have programmers maintain lots of booger-sized
> single-package definition files?
You just said something different than "one-file-per-package", and
boogers are small whereas ofpp would be huge, so I have no idea what you
are asking me. I'll say, "No."
> Or do you reject the entire notion
> of separating definition from implementation?
I wonder what that means. I'll say, "yes". Not sure why I have to say it
since not only did I protest it but I further invited tfb the elder to
melt down anyone so inclined. (If my guess at your meaning works.)
> Also, does one of
> these approaches work with asdf better than the others?
Unrelated. And nothing works with asdf. They broke it to support mcclim,
which must be broken if they had to break asdf to support it. We may
have here an uninterrupted cycle of breakage. Cool.
>
>> If you cannot load code in the right order, btw, I hope you do not
>> believe in macros.
>
>
> My life would not be complete without macros. Please don't take them
> away from me :(
>
>> Defining all expected packages up front is just a way of saying one
>> should not be a programmer, because one views doing it right as a
>> nuisance. Programming is too damn hard as it is, let's not start
>> papering over badly organized code.
>
>
> What about mutually dependent packages? Is that allowed?
Please. What part of "package" do you not understand? I think Escher
could draw two packages each both inside and outside the other, other
than that the idea is self-contradicting. If A depends on B and B
depends on A, then there exists an undiscovered C depending on A and B
to be culled from A and B leaving no mutual dependencies. Anywhere. The
culling would be "the nice semi-automatic way of straightening out ones
code" mentioned earlier.
Me, I got lazy on my current project and merged A and B. God is not
finished with me yet.
> And if so,
> would you still prefer the booger-file system?
I think you left out a qualifying "and if in fact you do prefer...",
which would save me from having to answer given my earlier answer
indicating not.
>
>> I am starting to understand why strait-jacket languages get invented.
>
>
> Let's not go there. The straight-jacket is sometimes worse than the
> original problem.
>
I don't know. If a great programmer like Peter Seibel can throw up his
hands at the first package error and create a bogus all-defining hack
just to make his day go a little faster, there may be no hope for the
human race. Reminded me of people who say "never use destructive functions".
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Ken Tilton wrote:
>> Would you rather have programmers maintain lots of booger-sized
>> single-package definition files?
> You just said something different than "one-file-per-package", and
> boogers are small whereas ofpp would be huge, so I have no idea what you
> are asking me.
By "definition" I mean the package API, i.e. just the defpackage form.
There are three approaches I'm wondering about:
1. Package definition together in the same file with at least some
of the implementation, as I'm doing with my in-defpackage macro.
2. Separate defpackage and implementation files, one defpackage/booger
file per package (containing a single defpackage form).
3. One central multi-defpackage file for all packages together.
My understanding is that you reject #3, but I'm not sure which of the
other two you prefer.
>> What about mutually dependent packages? Is that allowed?
> Please. What part of "package" do you not understand?
Nevermind, it's not important. I was thinking of loosely coupled
sub-packages that might do well with separate namespaces. You're
right, though, it's not very modular.
> Reminded me of people who say "never use destructive functions".
In CL? I've never seen that in this newsgroup.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Ken Tilton wrote:
>
>>> Would you rather have programmers maintain lots of booger-sized
>>> single-package definition files?
>>
>> You just said something different than "one-file-per-package", and
>> boogers are small whereas ofpp would be huge, so I have no idea what
>> you are asking me.
>
>
> By "definition" I mean the package API, i.e. just the defpackage form.
>
> There are three approaches I'm wondering about:
>
> 1. Package definition together in the same file with at least some
> of the implementation, as I'm doing with my in-defpackage macro.
Right on, brother.
>
> 2. Separate defpackage and implementation files, one defpackage/booger
> file per package (containing a single defpackage form).
There is no reason the defpackage has to be lonely. But this file cries
out for having no more than defvars and defparameters and init
functions, if you get my drift.
>
> 3. One central multi-defpackage file for all packages together.
>
> My understanding is that you reject #3, but I'm not sure which of the
> other two you prefer.
>
>>> What about mutually dependent packages? Is that allowed?
>>
>> Please. What part of "package" do you not understand?
>
>
> Nevermind, it's not important. I was thinking of loosely coupled
> sub-packages that might do well with separate namespaces. You're
> right, though, it's not very modular.
>
>> Reminded me of people who say "never use destructive functions".
>
> In CL? I've never seen that in this newsgroup.
>
Oh, they are out there. Google might reveal their identities. Context
was probably "not until you are an expert" or something.
kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Sat, 03 Mar 2007 10:26:02 +0100, Ken Tilton <·········@gmail.com> wrote:
>> Also, does one of
>> these approaches work with asdf better than the others?
>
> Unrelated. And nothing works with asdf. They broke it to support mcclim,
> which must be broken if they had to break asdf to support it. We may
> have here an uninterrupted cycle of breakage. Cool.
>
>>
>>> If you cannot load code in the right order, btw, I hope you do not
>>> believe in macros.
>> My life would not be complete without macros. Please don't take them
>> away from me :(
>>
>>> Defining all expected packages up front is just a way of saying one
>>> should not be a programmer, because one views doing it right as a
>>> nuisance. Programming is too damn hard as it is, let's not start
>>> papering over badly organized code.
>> What about mutually dependent packages? Is that allowed?
>
> Please. What part of "package" do you not understand? I think Escher
Example:
(in-package :cl-user)
(defpackage :time-asd
(:use :cl :asdf))
(in-package :time-asd)
(defsystem :time
:serial t
:components ((:file "packages")
(:file "universal-time")
(:file "timezone")
(:file "date"))
:depends-on (:rdnzl))
Seems to me you think you need a (depends-on..)
for everthing.
Did you miss the :serial option?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dan Bensen wrote:
> Trying to do this:
>
> ;; doesn't work
> (defmacro in-defpackage (name &rest options)
> (values
> `(defpackage ,name ,@options)
> `(in-package ,name)))
>
> (in-defpackage
> :my-package
> ;;etc.
> )
> ;; want to be in :my-package
>
> Is VALUES not the correct approach?
> I'm not sure what else would work.
>
PROGN.
hth,kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Ken Tilton wrote:
> Dan Bensen wrote:
>> Is VALUES not the correct approach?
>> I'm not sure what else would work.
> PROGN.
It works! Kenny, you're a genius.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Ken Tilton wrote:
>
>> Dan Bensen wrote:
>>
>>> Is VALUES not the correct approach?
>>> I'm not sure what else would work.
>>
>> PROGN.
>
>
> It works! Kenny, you're a genius.
>
No, I an hour on the same problem twelve years ago.
One reassurance you might have insisted on and would have received is
that forms in a toplevel progn are treated as toplevel.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Ken Tilton wrote:
>>> PROGN.
> One reassurance you might have insisted on and would have received is
> that forms in a toplevel progn are treated as toplevel.
You mean before you answered me, or after? Before, I was sort of
fixated on VALUES, so PROGN didn't occur to me. After, I didn't doubt
it would work. I've never seen anything about PROGN creating a lexical
scope the way LET does, so I wasn't worried about that.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Ken Tilton wrote:
>
>>>> PROGN.
>>
>> One reassurance you might have insisted on and would have received is
>> that forms in a toplevel progn are treated as toplevel.
>
>
> You mean before you answered me, or after?
After.
> Before, I was sort of
> fixated on VALUES, so PROGN didn't occur to me. After, I didn't doubt
> it would work. I've never seen anything about PROGN creating a lexical
> scope the way LET does, so I wasn't worried about that.
>
I always worry. :) I think the sequence was "oh, good, it worked" and
then ten years later I saw somewhere deep in the bowels of the CLHS that
not only did it work, it /had/ to work.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Mar 2, 3:12 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> Try:
>
> (defmacro in-defpackage (name &body options)
> `(values
> (defpackage ,name ,@options)
> (in-package ,name)))
>
> cl-user> (in-defpackage :blah
> (:use :cl))
> #<package "BLAH">
> #<package "BLAH">
> blah>
Would that work under compile-file? As I understand, PROGN is
preferable to VALUES because each of PROGN's body forms are processed
as top-level forms, which is what we want during compile-time for all
this package stuff.
<http://www.lispworks.com/documentation/HyperSpec/Body/03_bca.htm>
Or am I missing something?
Tayssir
On Mar 2, 3:34 am, "Tayssir John Gabbour"
<············@googlemail.com> wrote:
> On Mar 2, 3:12 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> > (defmacro in-defpackage (name &body options)
> > `(values
> > (defpackage ,name ,@options)
> > (in-package ,name)))
>
> > cl-user> (in-defpackage :blah
> > (:use :cl))
> > #<package "BLAH">
> > #<package "BLAH">
> > blah>
>
> Would that work under compile-file? As I understand, PROGN is
> preferable to VALUES because each of PROGN's body forms are processed
> as top-level forms, which is what we want during compile-time for all
> this package stuff.
> <http://www.lispworks.com/documentation/HyperSpec/Body/03_bca.htm>
Nevermind, just saw your next post.
Tayssir