So the third meeting of the Bay Area Lispniks has come and gone. We
went for Chinese at the Great China Restaurant in Berkeley. The
turnout was so great that just as we were squeezing the tenth person
in at our table, one more showed up and the restaurant staff had to
partially dismantle the table and bring in a bigger tabletop to seat
us all. Which they did with good grace and only a 30 second lecture
about how I should have called to tell them it was going to be more
than the nine I had made the reservation for.
We talked about why package nicknames should be set by the using
package, rather than the package itself; how one might get additions
to the standard actually standarized, and what would happen in a world
where for some bizarre reason Moore's law started running *backwards*.
And more. If you want in on the action, your best bet is to email me
and I'll put you on the mailing list. Or if you're not in the Bay
Area, I'd urge you to set up a local Lispniks chapter if there isn't
one already or attend the next meeting if there is.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> We talked about why package nicknames should be set by the using
> package, rather than the package itself; how one might get additions
I think we talked about that in London lately. At least, I've talked
about it with _someone_ lately, and am pretty convinced it'd be a good
idea (and far more useful than hierarchical packages). Is there/was
there an extant lisp that does this?
Interface to be decided, but my desire is for something like
(defpackage "MY-APP"
(:use "CL")
(:alias ("COM.EXAMPLE.HYPERFOO" "FOO")
;; ...
("NET.CLIKI.URL" "URL")))
then within the MY-APP package a FOO: prefix would look in the
COM.EXAMPLE.HYPERFOO package, but this would not introduce a package
nickname visible outside of MY-APP. So if I have several applications
loaded that all want different SOCKET or URL or DB package aliases,
they won't interfere with each other.
OK, you could fake it by renaming packages then compiling/loading the
file in question then renaming back again, but that doesn't sit so
well with interactive development where you might want to recompile a
single function from the editor.
> to the standard actually standarized, and what would happen in a world
(a) One or more of
(1) Write them up, giving the proposal a unique name and publishing
it somewhere accessible (e.g. Kent's substandards.org, or linked
from the ALU CLiki - which has a proto-standards section which
looks like it could use a little friendly editing)
(2) implement them in at least one lisp,
(3) make the code available for other Lisps to use
(b) Ask your vendor to implement proposal "SEIBEL-PER-PACKAGE-NICKNAMES"
It may not be blessed-by-ANSI, but if all or most implementors agree
to do it anyway according to the spec, that's good enough for the MOP
or Gray Streams.
(And if Duane has read this far, there is actually someone working on
simple-streams for SBCL, based on Paul Foley's CMUCL port . Not sure
what state it's in presently, though)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> (And if Duane has read this far, there is actually someone working on
> simple-streams for SBCL, based on Paul Foley's CMUCL port . Not sure
> what state it's in presently, though)
That's good to hear. I've heard about people intending to do this
for several versions, but have not heard status/problems/disagreements
from anyone. And I _know_ it's impossible to not disagree with or at
least question some of our design decisions, since we do this ourselves
constantly (one such realization of a Better Way resulted in the removal
of the device-extend method, as is hinted at in my ILC 2002 tutorial).
It would be good to hear from the person/people who are doing the
implementation, even (especially) if it is just to say "I'm stuck".
I'd be willing to help at the conceptual level.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
* Daniel Barlow wrote:
> I think we talked about that in London lately. At least, I've talked
> about it with _someone_ lately, and am pretty convinced it'd be a good
> idea (and far more useful than hierarchical packages). Is there/was
> there an extant lisp that does this?
I agree this is useful but doesn't hierarchical packages really fix
it, if people actually used them? The per-package package nicknames
thing seems like a hack to get around the fact that people have only
tiny brains and think it's just fine to name their package `NET' or
something, instead of doing the completely obvious thing and naming it
COM.CLEY.NET, say, where there is incredibly unlikely to be a clash.
God has given us the DNS, and it provides us with a unique namespace
for packages *for free*: I'm amazed people don't use it. Even
stranger, when I first came across hierarchical package names, the
people who were using them had names like NET.x and NET.y, because for
some reason they'd stopped half way and hadn't quite worked out that
all packages should be prefixed with the domain name of their owner.
Of course, I can say this, because I worked this out, oh, 6 months
ago, and now I get to rant on newsgroups and pretend it's obvious and
everyone else is a cretin. But once you rename all your packages to
sensible names, life does get easier.
(rule 1: never use package nicknames;
rule 2: never use package names without a dot;
rule 3: never use package names which are not prefixed by your domain
name.)
Of course, if you live in the real world you will probably find that
not everyone has seen the light, so you need nicknames, and
per-package nicknames. Or you could just kill the people who use
these stupid heretical package names.
I prefer the former, but they took my nukes away, so when I have time
I will do the latter for at least a couple of Lisps (the easy
implementability of it depends on everything going through
FIND-PACKAGE, and it being empirically possible to hook functions in
CL).
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> I prefer the former, but they took my nukes away, so when I have time
Tim> I will do the latter for at least a couple of Lisps (the easy
Tim> implementability of it depends on everything going through
Tim> FIND-PACKAGE, and it being empirically possible to hook functions in
Tim> CL).
FWIW, CMUCL will have hierarchical package names in the
soon-to-be-released-some-day release known as 18e. (Although it's
been available there since about 18d or so, but not compiled in by
default.)
Ray
On 8329 day of my life Raymond Toy wrote:
> >>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
>
> FWIW, CMUCL will have hierarchical package names in the
> soon-to-be-released-some-day release known as 18e. (Although it's
> been available there since about 18d or so, but not compiled in by
> default.)
AFAIK, CMUCL 18e was released on 24th of March.
--
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
There are 256 symbols in English alphabet.
>>>>> "Ivan" == Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
Ivan> On 8329 day of my life Raymond Toy wrote:
>> >>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
>>
>> FWIW, CMUCL will have hierarchical package names in the
>> soon-to-be-released-some-day release known as 18e. (Although it's
>> been available there since about 18d or so, but not compiled in by
>> default.)
Ivan> AFAIK, CMUCL 18e was released on 24th of March.
Not really. It was tagged as frozen for release. At least one patch
was added since then.
Perhaps it will be released on April Fool's Day. :-)
I like that idea.
Ray
Tim Bradshaw <···@cley.com> writes:
> I agree this is useful but doesn't hierarchical packages really fix
> it, if people actually used them? The per-package package nicknames
> thing seems like a hack to get around the fact that people have only
> tiny brains and think it's just fine to name their package `NET' or
> something, instead of doing the completely obvious thing and naming it
> COM.CLEY.NET, say, where there is incredibly unlikely to be a clash.
The problem is that after naming my library package
COM.METACIRCLES.K-MEANS, I either need to USE-PACKAGE it in all my
code, or I need a really wide screen. And if it has a GF called, say,
CLUSTER, USEing the package is sooner or later going to give me a
conflict with something else I want to use. Like, I don't know,
MIL.ARMY.WEAPONS::CLUSTER. So I end up giving my exported symbols
names like K-MEANS-CLUSTER - and hey, isn't maintaining namespaces
supposed to be the _package system's_ job?
Hierarchical packages only really help if all the other packages I
want to give short names to are ones I wrote. If I want to call
ORG.TFEB.HAX:WITH-DYNAMIC-STATE-ACCESS as well, all I can do is give
thanks to God (or Internic; ew, what a horrible thought) that Tim
bagged a short enough domain name that this still takes slightly less
than half my line width.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Tim Bradshaw <···@cley.com> writes:
> * Daniel Barlow wrote:
>
> > I think we talked about that in London lately. At least, I've talked
> > about it with _someone_ lately, and am pretty convinced it'd be a good
> > idea (and far more useful than hierarchical packages). Is there/was
> > there an extant lisp that does this?
>
> I agree this is useful but doesn't hierarchical packages really fix
> it, if people actually used them?
I'm not sure. Depends what you mean by hierarchical packages. (And
"fix". And "it", I guess. ;-)) If you mean naming your packages
"com.foo.net" and "com.foo.io", that does solve the name clash
problem, if everyone follows the convention. And I'm wholeheartedly in
favor of that.
That said, if I'm writing some code that uses some symbols from
com.foo.net and *also* com.bar.net, I don't want to have to use
fully-qualified symbol names everywhere. What *I* want is to be able
to say, along the lines of what Daniel suggested:
(defpackage "MY-APP"
(:use "CL")
(:alias ("COM.FOO.NET" "FNET")
("COM.BAR.NET" "BNET")))
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel wrote:
> Tim Bradshaw writes:
>
>
> >* Daniel Barlow wrote:
> >
> >
> >>I think we talked about that in London lately. At least, I've talked
> >>about it with _someone_ lately, and am pretty convinced it'd be a good
> >>idea (and far more useful than hierarchical packages). Is there/was
> >>there an extant lisp that does this?
> >
> >I agree this is useful but doesn't hierarchical packages really fix
> >it, if people actually used them?
>
>
> I'm not sure. Depends what you mean by hierarchical packages. (And
> "fix". And "it", I guess. ;-)) If you mean naming your packages
> "com.foo.net" and "com.foo.io", that does solve the name clash
> problem, if everyone follows the convention. And I'm wholeheartedly in
> favor of that.
>
> That said, if I'm writing some code that uses some symbols from
> com.foo.net and *also* com.bar.net, I don't want to have to use
> fully-qualified symbol names everywhere. What *I* want is to be able
> to say, along the lines of what Daniel suggested:
>
> (defpackage "MY-APP"
> (:use "CL")
> (:alias ("COM.FOO.NET" "FNET")
> ("COM.BAR.NET" "BNET")))
If you are willing to modify the READER, then you can do that.
You still will have the problem
(defpackage "FOO" ... (:alias ("FUNKY" "F")))
(defpackage "BAR" ... (:nicknames "F"))
(in-package "FOO")
(f:what-am-i?)
If I understood correctly this is what is happening here.
I.e. "the devil is in the details".
Cheers
--
Marco Antoniotti
Marco Antoniotti wrote:
>> (defpackage "MY-APP"
>> (:use "CL")
>> (:alias ("COM.FOO.NET" "FNET")
>> ("COM.BAR.NET" "BNET")))
>
>
> If you are willing to modify the READER, then you can do that.
>
> You still will have the problem
>
> (defpackage "FOO" ... (:alias ("FUNKY" "F")))
>
> (defpackage "BAR" ... (:nicknames "F"))
>
> (in-package "FOO")
>
> (f:what-am-i?)
I would say it is "FUNKY" because we are in "FOO".
I'm not sure but I think this could be implemented using FIND-PACKAGE.
FIND-PACKAGE can look up the current package and look if there is a defined
alias.
So I see no real conceptual problem here...
ciao,
Jochen
Jochen Schmidt wrote:
> Marco Antoniotti wrote:
>
>
> >> (defpackage "MY-APP"
> >> (:use "CL")
> >> (:alias ("COM.FOO.NET" "FNET")
> >> ("COM.BAR.NET" "BNET")))
> >
> >
> >If you are willing to modify the READER, then you can do that.
> >
> >You still will have the problem
> >
> >(defpackage "FOO" ... (:alias ("FUNKY" "F")))
> >
> >(defpackage "BAR" ... (:nicknames "F"))
> >
> >(in-package "FOO")
> >
> >(f:what-am-i?)
>
>
> I would say it is "FUNKY" because we are in "FOO".
That is legitimate. I don't know if it is the best choice.
> I'm not sure but I think this could be implemented using FIND-PACKAGE.
> FIND-PACKAGE can look up the current package and look if there is a
> defined
> alias.
>
> So I see no real conceptual problem here...
No, but you have to change the READER behavior. It is not a "portably
implementable" extension.
Cheers
--
Marco Antoniotti