Discussion:
:DBG
Faré
2013-11-18 05:17:41 UTC
Permalink
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.

:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.

I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.

Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.

I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.

It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Pascal Costanza
2013-11-18 07:37:18 UTC
Permalink
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?

This will be setting a very bad precedence. Just don't. Really!

Pascal

Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Hans Hübner
2013-11-18 07:51:29 UTC
Permalink
Pascal,

if you mean what you write, can you give some reasoning?

-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Pascal Costanza
2013-11-18 08:28:45 UTC
Permalink
Hm, just when I thought this the mailing list for professional Common Lisp users.

Off the top of my hat: http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm

Pascal

Sent from my iPad
Post by Hans Hübner
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Alessio Stalla
2013-11-18 08:44:44 UTC
Permalink
Well, Faré is obviously well aware of that, and has given an explanation
for why he is willing to "break the rules" this particular time. So "don't
dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug macro
nobody won't ever use in production code, why make it available in a
library at all? Why couldn't it simply live in your rc file? Or, you could
include it in uiop with a non-keyword name, and only bind it to :dbg in
your own environment. I fail to understand why you'd want to it be
available everywhere, everytime... and for everyone as well!

Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to
make
Post by Faré
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
--
Some gratuitous spam:

http://ripple.com <http://ripple-project.org> Ripple, social credit system
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my Lisp open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven
Java web application framework
Pascal Costanza
2013-11-18 08:58:33 UTC
Permalink
Last time I checked, asdf was not a debugging or utilities library.

Fare's reasoning is also flawed. The problem stated in the claim "because when you need it, you need it now" is not solved with his suggestion, because it assumes that you have the right version of asdf loaded. Otherwise it is actually not available "now".

How people debug code is a highly personal and subjective choice. No matter how much Fare tries to make a variant that "gets everything right", he will fail, because what is right for him may not be right for others.

His hidden agenda seems to be to piggy back on the widespread use of asdf and force his views on how things "should" be done on the Lisp community.

I have already considered removing asdf completely from my workflow in the past. If asdf starts to mess with such fundamental rules for allowing indepently developed code to coexist, then it will be the final blow for me.

Pascal

Sent from my iPad
Well, Faré is obviously well aware of that, and has given an explanation for why he is willing to "break the rules" this particular time. So "don't dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug macro nobody won't ever use in production code, why make it available in a library at all? Why couldn't it simply live in your rc file? Or, you could include it in uiop with a non-keyword name, and only bind it to :dbg in your own environment. I fail to understand why you'd want to it be available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
Off the top of my hat: http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Post by Hans Hübner
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
--
http://ripple.com Ripple, social credit system
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my Lisp open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
Alessio Stalla
2013-11-18 09:09:24 UTC
Permalink
Fair enough, I mostly agree with your reasoning, thanks for taking the time
to elaborate.
Post by Pascal Costanza
Last time I checked, asdf was not a debugging or utilities library.
Fare's reasoning is also flawed. The problem stated in the claim "because
when you need it, you need it now" is not solved with his suggestion,
because it assumes that you have the right version of asdf loaded.
Otherwise it is actually not available "now".
How people debug code is a highly personal and subjective choice. No
matter how much Fare tries to make a variant that "gets everything right",
he will fail, because what is right for him may not be right for others.
His hidden agenda seems to be to piggy back on the widespread use of asdf
and force his views on how things "should" be done on the Lisp community.
I have already considered removing asdf completely from my workflow in the
past. If asdf starts to mess with such fundamental rules for allowing
indepently developed code to coexist, then it will be the final blow for me.
Pascal
Sent from my iPad
Well, Faré is obviously well aware of that, and has given an explanation
for why he is willing to "break the rules" this particular time. So "don't
dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug macro
nobody won't ever use in production code, why make it available in a
library at all? Why couldn't it simply live in your rc file? Or, you could
include it in uiop with a non-keyword name, and only bind it to :dbg in
your own environment. I fail to understand why you'd want to it be
available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to
make
Post by Faré
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Ben Hyde
2013-11-18 14:20:29 UTC
Permalink
asdf ... not a debugging or utilities library.
Good news, uiop is a utility library

While I think this is cute and it makes me chortle, I find it to be too cute.

I think it "models a bad behavior." I don't want to have to fight back against other
less skilled dev's using this trick. :dbg+ :dsc :! :?

I'm glad Faré floated the idea, implicitly asking for options. I might try it for a while.

- ben
Ken Tilton
2013-11-18 09:00:34 UTC
Permalink
I for one have never understood the anal compulsiveness* of many Lispers
over package sanctity.

* Does it solve a problem, or is it just aneatness obsession?

Dis donc, francois, how did you handle source that might be a good-sized
little sexpr?

-- His Professionalness
Post by Alessio Stalla
Well, Faré is obviously well aware of that, and has given an explanation
for why he is willing to "break the rules" this particular time. So "don't
dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug macro
nobody won't ever use in production code, why make it available in a
library at all? Why couldn't it simply live in your rc file? Or, you could
include it in uiop with a non-keyword name, and only bind it to :dbg in
your own environment. I fail to understand why you'd want to it be
available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to
make
Post by Faré
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
--
http://ripple.com <http://ripple-project.org> Ripple, social credit system
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my Lisp open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework
Pascal Costanza
2013-11-18 09:08:24 UTC
Permalink
It hasn't been a problem in the past, because people stuck to the rules, at least in publicly available libraries, which is why you didn't observe any problems. If people stop sticking to the rules, it will become a problem.

Pascal

Sent from my iPad
I for one have never understood the anal compulsiveness* of many Lispers over package sanctity.
* Does it solve a problem, or is it just aneatness obsession?
Dis donc, francois, how did you handle source that might be a good-sized little sexpr?
-- His Professionalness
Well, Faré is obviously well aware of that, and has given an explanation for why he is willing to "break the rules" this particular time. So "don't dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug macro nobody won't ever use in production code, why make it available in a library at all? Why couldn't it simply live in your rc file? Or, you could include it in uiop with a non-keyword name, and only bind it to :dbg in your own environment. I fail to understand why you'd want to it be available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
Off the top of my hat: http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Post by Hans Hübner
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
--
http://ripple.com Ripple, social credit system
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my Lisp open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
Alessio Stalla
2013-11-18 09:16:13 UTC
Permalink
Right; I think it avoids the problem altogether, rather than solving it.
I.e. if you (and the libraries you use) do things right, you don't have to
think about the problem at all. In languages without packages, when people
want to "solve" the same problem, they end up prefixing every symbol
(ugh!), or fake namespaces in some hackish way (see JavaScript).

Lately I'm thinking more and more that keywords are a hack and shouldn't
have been in CL at all. 'foo is just as easy to type as :foo, but it allows
'my:foo to coexist with 'your:foo.
Post by Pascal Costanza
It hasn't been a problem in the past, because people stuck to the rules,
at least in publicly available libraries, which is why you didn't observe
any problems. If people stop sticking to the rules, it will become a
problem.
Pascal
Sent from my iPad
I for one have never understood the anal compulsiveness* of many Lispers
over package sanctity.
* Does it solve a problem, or is it just aneatness obsession?
Dis donc, francois, how did you handle source that might be a good-sized little sexpr?
-- His Professionalness
Post by Alessio Stalla
Well, Faré is obviously well aware of that, and has given an explanation
for why he is willing to "break the rules" this particular time. So "don't
dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug
macro nobody won't ever use in production code, why make it available in a
library at all? Why couldn't it simply live in your rc file? Or, you could
include it in uiop with a non-keyword name, and only bind it to :dbg in
your own environment. I fail to understand why you'd want to it be
available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to
make
Post by Faré
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Ken Tilton
2013-11-18 09:18:59 UTC
Permalink
It might be a better idea to have a new debugging project where lispers can
share their best & brightest utilities. I have some beauts.

-hp
Post by Pascal Costanza
It hasn't been a problem in the past, because people stuck to the rules,
at least in publicly available libraries, which is why you didn't observe
any problems. If people stop sticking to the rules, it will become a
problem.
Pascal
Sent from my iPad
I for one have never understood the anal compulsiveness* of many Lispers
over package sanctity.
* Does it solve a problem, or is it just aneatness obsession?
Dis donc, francois, how did you handle source that might be a good-sized little sexpr?
-- His Professionalness
Post by Alessio Stalla
Well, Faré is obviously well aware of that, and has given an explanation
for why he is willing to "break the rules" this particular time. So "don't
dare touch the keywords package!" does not seem the right answer to me...
Faré, I understand your points, what fails me is: if this is a debug
macro nobody won't ever use in production code, why make it available in a
library at all? Why couldn't it simply live in your rc file? Or, you could
include it in uiop with a non-keyword name, and only bind it to :dbg in
your own environment. I fail to understand why you'd want to it be
available everywhere, everytime... and for everyone as well!
Alessio
Post by Pascal Costanza
Hm, just when I thought this the mailing list for professional Common Lisp users.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abcb.htm
Pascal
Sent from my iPad
Pascal,
if you mean what you write, can you give some reasoning?
-Hans
Post by Pascal Costanza
DON'T TOUCH THE KEYWORDS PACKAGE! Are you crazy?!?
This will be setting a very bad precedence. Just don't. Really!
Pascal
Sent from my iPad
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to
make
Post by Faré
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Post by Faré
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
--
http://ripple.com <http://ripple-project.org> Ripple, social credit system
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my Lisp open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework
Stas Boukarev
2013-11-18 07:56:35 UTC
Permalink
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
Thanks for breaking my :dbg macro.
--
With best regards, Stas.
Ken Tilton
2013-11-18 09:24:30 UTC
Permalink
packages do not obviate the need for prefixes, essential to code
readability. And then we do need packages, the worst thing that ever
happened to lisp..

but the problem here originates from a desire to share a debug hack, so the
solution prolly involves a way to share debug hacks. Could be a fun
project. We could call it :dbg.

-kt
Post by Faré
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from
everywhere
Post by Faré
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
Thanks for breaking my :dbg macro.
--
With best regards, Stas.
Steve Haflich
2013-11-18 11:34:44 UTC
Permalink
I'm jumping into this a little late, but writing as an X3J13 member who
voted on these things, the reason for not placing definitions on keyword
symbols is the same as the prohibition against placing special variable or
global operator definitions on symbols inherited from the CL package, or
any other package of which one I'd not the author.

The arguments why one might want to do this were expounded early in the
thread. The danger is collision. When an acknowledged CL expert like Hans
or Kenny places a definition on an inherited symbol, he obviously knows
what he is doing, has good reason, so it should be ok. But when some idiot
neophyte comes along and does exactly the same thing, it may be hard to
remember which is who.
:-)
Tamas Papp
2013-11-18 11:59:35 UTC
Permalink
Post by Ken Tilton
but the problem here originates from a desire to share a debug hack, so the
solution prolly involves a way to share debug hacks. Could be a fun
project. We could call it :dbg.
Or use something like Quickutil ( http://quickutil.org/ ).

Best,

Tamas
Zach Beane
2013-11-18 13:57:30 UTC
Permalink
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
This clashes with a :DBG macro I have already in my local
configuration. Would you please not define your own :DBG it in ASDF by
default?

Zach
Faré
2013-11-18 14:41:52 UTC
Permalink
OK, that's exactly the kind of feedback I needed — thanks.

I am convinced by the general feedback: defining this macro in the
keyword package is a great idea, but just not as part of asdf.

Thanks to stassats and Xach in particular for mentioning that they
were already using that trick.

In asdf master, I've renamed it back to a normal symbol. I'll add a
wrapper in the keyword package in my .sbclrc or some such.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Common Lisp makes it easy for you to grow your own language; however, it
makes it difficult for that language to be the same as anyone else's.
Luís Oliveira
2013-11-18 14:52:07 UTC
Permalink
Post by Faré
In asdf master, I've renamed it back to a normal symbol. I'll add a
wrapper in the keyword package in my .sbclrc or some such.
These utilities are definitely worth sharing. I have a few of my own,
and I also use the keyword package. ASDF is a strange place to share
them, though. My first idea is that a SLIME contrib might be a better
place, but these tools are not SLIME-specific.
--
Luís Oliveira
http://kerno.org/~luis/
Didier Verna
2013-11-18 15:08:29 UTC
Permalink
Post by Luís Oliveira
Post by Faré
In asdf master, I've renamed it back to a normal symbol. I'll add a
wrapper in the keyword package in my .sbclrc or some such.
These utilities are definitely worth sharing. I have a few of my own,
and I also use the keyword package. ASDF is a strange place to share
them, though. My first idea is that a SLIME contrib might be a better
place, but these tools are not SLIME-specific.
Personally, I like the quickutil approach and I think we should all
support it.
--
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info
Michael Wolber
2013-11-21 14:22:39 UTC
Permalink
Hi Guys,

it seems that the cliki.net domain has expired.
Is anybody here on the list involved in that project?

Regards,
Michael
Anton Vodonosov
2013-11-21 14:36:09 UTC
Permalink
Vladimir Sedach maintains the cliki project.
CC'ing him.
Post by Michael Wolber
Hi Guys,
it seems that the cliki.net domain has expired.
Is anybody here on the list involved in that project?
Regards,
Michael
Dave Cooper
2013-11-21 14:49:49 UTC
Permalink
The domain is listed by "whois" as being with Drew Crampsie's email (and
the name of Chris Palecek), registered with sibername.com. Apparently it
has expired but there is some kind of grace period before it goes up for
sale again.

I sent Drew an email this morning asking if he would care to transfer it to
Common Lisp Foundation as has been done with common-lisp.net.

It's still 6:48am in Vancouver so it might be a while before we hear back
from Drew...
Post by Anton Vodonosov
Vladimir Sedach maintains the cliki project.
CC'ing him.
Post by Michael Wolber
Hi Guys,
it seems that the cliki.net domain has expired.
Is anybody here on the list involved in that project?
Regards,
Michael
--
My Best,

Dave Cooper, Genworks Support
david.cooper-LlVAWi/yG7NWk0Htik3J/***@public.gmane.org, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
Dave Cooper
2013-11-21 17:21:42 UTC
Permalink
I spoke with Drew C and alerted him to the name expiration of cliki.net. He
went ahead and logged into sibername.com and renewed the domain for
two years, so it should be back online for everyone now.

He also mentioned that he would be in favor of putting the domain under the
stewardship of the CLF. So I will bring this up with the CLF board at our
next meeting, and if approved, we'll extend him an official offer.
Post by Dave Cooper
The domain is listed by "whois" as being with Drew Crampsie's email (and
the name of Chris Palecek), registered with sibername.com. Apparently it
has expired but there is some kind of grace period before it goes up for
sale again.
I sent Drew an email this morning asking if he would care to transfer it
to Common Lisp Foundation as has been done with common-lisp.net.
It's still 6:48am in Vancouver so it might be a while before we hear back
from Drew...
Post by Anton Vodonosov
Vladimir Sedach maintains the cliki project.
CC'ing him.
Post by Michael Wolber
Hi Guys,
it seems that the cliki.net domain has expired.
Is anybody here on the list involved in that project?
Regards,
Michael
--
My Best,
Dave Cooper, Genworks Support
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
--
My Best,

Dave Cooper, Genworks Support
david.cooper-LlVAWi/yG7NWk0Htik3J/***@public.gmane.org, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
Scott McKay
2013-11-18 14:14:15 UTC
Permalink
I'd like to second a number of people's opinions on this:
No individual should be making a decision to define any
functionality in a global namespace. It just invites clashes,
and it sets a bad precedent. This is entirely irrespective of
the person making the decision and the usefulness of the
proposed functionality.

And plus, functions in the keyword package are gross. ;-)

--Scott
Post by Faré
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Loading...