|
From: | Daniel Colascione |
Subject: | Re: Proper namespaces in Elisp |
Date: | Thu, 7 May 2020 14:56:10 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 5/7/20 2:46 PM, João Távora wrote:
On Thu, May 7, 2020 at 10:10 PM Daniel Colascione <address@hidden <mailto:address@hidden>> wrote:On 5/7/20 2:06 PM, Stefan Monnier wrote: > I thought your previous message was saying you don't like this approach > (when you said "I don't like reader magic"). Is it that I misunderstood > or that you don't much like the solution but think that from a pragmatic > point of view it's still the better option? I don't like reader magic in general, but I don't think of the CL approach as being all that magical: it has uniform rules and a long history. CL namespaces *are* reader magic all right, but it's reader magic with which a lot of people are familiar Not only that, but CL the reader itself is programmable. So it's really _not_ "magic", it's all (hyper)spec'ed!
Sure. The subject of reader macros has come up before; I used to be in favor. Regardless, symbol namespaces don't require general reader macros.
http://www.lispworks.com/documentation/HyperSpec/Body/23_a.htm However, Daniel, my proposal doesn't have much magic. Is is really dumb ;-). Here's the gist of it (a pure elisp solution using advice, very lightly tested)
It's not that your solution is bad per se --- it's that it's a bespoke solution that solves fewer problems than the general CL mechanism. Sure, the implementation is simple, but the CL approach isn't really that hard to implement either if we decide to do it.
We should prefer familiar solutions to unfamiliar ones unless the new solution comes with some compelling advantage that compensates for its novelty, and I don't see the scheme you've proposed having enough of an advantage of the CL approach (which also allows prefix aliases) to compensate for being novel.
[Prev in Thread] | Current Thread | [Next in Thread] |