Re: [asdf-devel] :DBG

2013-11-18 Thread Didier Verna
Luís Oliveira wrote: > On Mon, Nov 18, 2013 at 2:41 PM, Faré wrote: >> 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

Re: [asdf-devel] :DBG

2013-11-18 Thread Luís Oliveira
On Mon, Nov 18, 2013 at 2:41 PM, Faré wrote: > 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 stran

Re: [asdf-devel] :DBG

2013-11-18 Thread Faré
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 m

Re: :DBG

2013-11-18 Thread Ben Hyde
On Nov 18, 2013, at 3:58 AM, Pascal Costanza wrote: > 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

Re: :DBG

2013-11-18 Thread Scott McKay
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 prop

Re: [asdf-devel] :DBG

2013-11-18 Thread Zach Beane
Faré writes: > 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 — b

Re: [asdf-devel] :DBG

2013-11-18 Thread Tamas Papp
On Mon, Nov 18 2013, kentil...@gmail.com wrote: > 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,

Re: [asdf-devel] :DBG

2013-11-18 Thread Steve Haflich
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 ot

Re: [asdf-devel] :DBG

2013-11-18 Thread Ken Tilton
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 p

Re: :DBG

2013-11-18 Thread Ken Tilton
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 On Mon, Nov 18, 2013 at 4:08 AM, Pascal Costanza wrote: > It hasn't been a problem in the past, because people stuck to the rules, > at least in publicly

Re: :DBG

2013-11-18 Thread Alessio Stalla
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!),

Re: :DBG

2013-11-18 Thread Alessio Stalla
Fair enough, I mostly agree with your reasoning, thanks for taking the time to elaborate. On Mon, Nov 18, 2013 at 9:58 AM, Pascal Costanza wrote: > 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 >

[asdf-devel] Re: :DBG

2013-11-18 Thread 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 > On 18 Nov 2013, at 10:00, Ken Tilton wrot

Re: :DBG

2013-11-18 Thread Ken Tilton
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 On Mon, Nov 18, 2013 at

[asdf-devel] Re: :DBG

2013-11-18 Thread 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

Re: :DBG

2013-11-18 Thread 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 no

[asdf-devel] Re: :DBG

2013-11-18 Thread 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 > On 18 Nov 2013, at 08:51, Hans Hübner wrote: > > Pascal, > > if you mean what you write, can

Re: [asdf-devel] :DBG

2013-11-18 Thread Stas Boukarev
Faré writes: > 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 — b