Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
* package-local nicknames: the ability to specify, for each package, a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of. * "Hierarchical" packages: a naming convention for packages understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions: 1) First and foremost, is anybody actually using those features? What are you using them for? 2) If yes, how useful are they for you? What shortcomings do you find in them?
Packages are over-rated. We lived (and suffered) with packages for months and when I finally rolled everything up into one package it presented zero problems and ended a steady stream of problems. As one Lisp venerable said, "It was a package problem. It is always a package problem."
On Tue, Dec 29, 2015 at 6:52 PM, Alessio Stalla alessiostalla@gmail.com wrote:
Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
- package-local nicknames: the ability to specify, for each package, a
list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
- "Hierarchical" packages: a naming convention for packages understood by
the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL ( http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions:
- First and foremost, is anybody actually using those features? What are
you using them for? 2) If yes, how useful are they for you? What shortcomings do you find in them?
Hi,
1) I believe package-local nicknames are very useful. Being able to use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.
2) I don’t believe hierarchical package names are useful. That’s a Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;). Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.
My primary CL implementation is LispWorks, so I don’t use package-local nicknames in practice, but I have used other languages with similar features (most notably Oberon), and they were just very handy.
I hope this helps.
Pascal
On 30 Dec 2015, at 00:56, Kenneth Tilton ken@tiltontec.com wrote:
Packages are over-rated. We lived (and suffered) with packages for months and when I finally rolled everything up into one package it presented zero problems and ended a steady stream of problems. As one Lisp venerable said, "It was a package problem. It is always a package problem."
On Tue, Dec 29, 2015 at 6:52 PM, Alessio Stalla <alessiostalla@gmail.com mailto:alessiostalla@gmail.com> wrote: Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
- package-local nicknames: the ability to specify, for each package, a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL (http://www.sbcl.org/manual/#Package_002dLocal-Nicknames http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
- "Hierarchical" packages: a naming convention for packages understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions:
- First and foremost, is anybody actually using those features? What are you using them for?
- If yes, how useful are they for you? What shortcomings do you find in them?
-- Kenneth Tilton 54 Isle of Venice Dr Fort Lauderdale, FL 33301
ken@tiltontec.com mailto:ken@tiltontec.com http://tiltontec.com http://tiltontec.com/ @tiltonsalgebra
646-269-1077
"In a class by itself." -Macworld
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 30/12/15 02:25, Pascal Costanza wrote:
Hi,
- I believe package-local nicknames are very useful. Being able to
use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.
- I don’t believe hierarchical package names are useful. That’s a
Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;).
You're saying that because there are only 1279 systems in quicklisp so it's still manageable as a flat list. But wait a little with tens or hundreds more systems and packages!
Probably, you've never worked with a big source base with a directory hierarchy didn't match the naming scheme.
Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
Agreed.
Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.
Oh, you're right. Now I see the light. I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.* And let's not talk about the 3 or 4 different CLON packages we have...
My primary CL implementation is LispWorks, so I don’t use package-local nicknames in practice, but I have used other languages with similar features (most notably Oberon), and they were just very handy.
On 30 Dec 2015, at 03:12, Pascal J. Bourguignon pjb@informatimago.com wrote:
On 30/12/15 02:25, Pascal Costanza wrote:
Hi,
I believe package-local nicknames are very useful. Being able to use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.
I don’t believe hierarchical package names are useful. That’s a Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;).
You're saying that because there are only 1279 systems in quicklisp so it's still manageable as a flat list. But wait a little with tens or hundreds more systems and packages!
No, I’m saying this although there are already 1279 systems in quicklisp. I actually had to rename a library twice because my name choices clashed with existing library names, so I understand the problem that people want to solve. I nevertheless stand by my statement. (I have sufficient experience with Java to know that this doesn’t help much.)
Probably, you've never worked with a big source base with a directory hierarchy didn't match the naming scheme.
You shouldn’t make too many assumptions about other people’s experiences.
Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
Agreed.
Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.
Oh, you're right. Now I see the light. I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.* And let's not talk about the 3 or 4 different CLON packages we have...
I don’t strongly object to hierarchical package names. If that’s what the community wants, I’m fine with it. Package-local nicknames are more important, though. I especially would be unhappy if hierarchical package names were adopted, but package-local nicknames weren’t.
All IMHO, YMMV, etc., etc.
;)
Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
All this discussion is fine.
FWIW I kinda like the idea of hierarchical packages although I have not really have had much use for them up to now; and, having dealt with Java, I know how easy they get out of hand. Package-local nicknames would be very nice indeed, and a must once you have hierarchical packages, but I fear that anything that required too much developers’ work (beyond SBCL) leaves the time it finds.
Having said that, I move that a *spec* is *much* more important than an *implementation*. At a minimum to gather in one place all the bits and pieces that the different implementations now have. Writing things down (in CLHS or C standard style) forces one to actually think very well about what is desirable and/or achievable; not to mention the devilish details.
Happy New Year — MA
On Dec 30, 2015, at 12:42 , Pascal Costanza pc@p-cos.net wrote:
On 30 Dec 2015, at 03:12, Pascal J. Bourguignon pjb@informatimago.com wrote:
On 30/12/15 02:25, Pascal Costanza wrote:
Hi,
I believe package-local nicknames are very useful. Being able to use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.
I don’t believe hierarchical package names are useful. That’s a Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;).
You're saying that because there are only 1279 systems in quicklisp so it's still manageable as a flat list. But wait a little with tens or hundreds more systems and packages!
No, I’m saying this although there are already 1279 systems in quicklisp. I actually had to rename a library twice because my name choices clashed with existing library names, so I understand the problem that people want to solve. I nevertheless stand by my statement. (I have sufficient experience with Java to know that this doesn’t help much.)
Probably, you've never worked with a big source base with a directory hierarchy didn't match the naming scheme.
You shouldn’t make too many assumptions about other people’s experiences.
Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
Agreed.
Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.
Oh, you're right. Now I see the light. I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.* And let's not talk about the 3 or 4 different CLON packages we have...
I don’t strongly object to hierarchical package names. If that’s what the community wants, I’m fine with it. Package-local nicknames are more important, though. I especially would be unhappy if hierarchical package names were adopted, but package-local nicknames weren’t.
All IMHO, YMMV, etc., etc.
;)
Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
Please check: http://ceac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
At 3:12 AM +0100 15/12/30, Pascal J. Bourguignon wrote:
On 30/12/15 02:25, Pascal Costanza wrote: [...]
Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that's sufficient, IMHO.
Oh, you're right. Now I see the light. I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.* And let's not talk about the 3 or 4 different CLON packages we have...
It might be useful to have the option to nickname away any package names which come over as unwelcome advertising or otherwise inappropriate. In effect renaming symbols' print form so their package name matches their purpose from our own pov.
Any standard might include an ASDF or meta declaration form which states package names used by any systems, such that others who use/integrate those systems know what package naming conflicts they face, and can side step them conveniently at top level. It can be tricky to handle some package name overlaps.
In our glorious far lisp future, there'll be many thousands of interleaved systems with a multitude of package names, hence a race to be first to bag the choice ones (as in domain name squatters, sales, extortionists, self publicists, etc). Some mechanism for disappearing unwanted package names but leaving functional state identical, might be a necessity. Then we can all have our own sys and si roots.
On 30 December 2015 at 10:12, Pascal J. Bourguignon pjb@informatimago.com wrote:
Oh, you're right. Now I see the light. I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.* And let's not talk about the 3 or 4 different CLON packages we have...
If nothing else, Pascal's packages are a great reason why local package nicknames are incredibly useful. I never USE packages, and always fully qualify symbols outside the current package. The informatimago packages clear, but when fully qualifying them it makes it a bit too much. Local package nicknames solves this.
If local package nicknames were available everywhere I'd rename all my packages to follow Pascal's conventions in a heartbeat.
On 29 December 2015 at 19:25, Pascal Costanza pc@p-cos.net wrote:
Hi,
[...]
Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
[...]
On a related note, I attempted to retrofit a 150K+ LOC application with "inferred packages"[1] and, revision time and effort aside, I think the only dependency problem it solved was the one it created. I have not tried it with a larger or smaller application, and, of course, YMMV.
Mike
[1] http://davazp.net/2014/11/26/modern-library-with-asdf-and-package-inferred-s...
The late Dan Weinreb's mileage was a lot different, mind you: http://xach.livejournal.com/278815.html
I just go completely the other way, preferring mx-what-ever to mx:what-ever by a mile.
-kt
On Wed, Dec 30, 2015 at 12:05 PM, Michael J. Forster mike@sharedlogic.ca wrote:
On 29 December 2015 at 19:25, Pascal Costanza pc@p-cos.net wrote:
Hi,
[...]
Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is
not
a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that
hierarchical
package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
[...]
On a related note, I attempted to retrofit a 150K+ LOC application with "inferred packages"[1] and, revision time and effort aside, I think the only dependency problem it solved was the one it created. I have not tried it with a larger or smaller application, and, of course, YMMV.
Mike
[1] http://davazp.net/2014/11/26/modern-library-with-asdf-and-package-inferred-s...
On 30 December 2015 at 11:13, Kenneth Tilton ken@tiltontec.com wrote:
The late Dan Weinreb's mileage was a lot different, mind you: http://xach.livejournal.com/278815.html
Thanks for the link!
I just go completely the other way, preferring mx-what-ever to mx:what-ever by a mile.
My experience with Smalltalk implementations that do and do not support namespaces lead me to see mx:what-ever as legislation of the mx-what-ever naming convention already practiced by responsible citizens. Not sure how I feel about legislation ;-)
Mike
On 30 December 2015 at 11:18, Michael J. Forster mike@sharedlogic.ca wrote:
[...]
My experience with Smalltalk implementations that do and do not support namespaces lead me to see mx:what-ever as legislation of the mx-what-ever naming convention already practiced by responsible citizens. Not sure how I feel about legislation ;-)
Mike
I should have written, "Not sure how I feel about legislation *within* an application." Exported APIs, of course, should take advantage of the package name and eschew a common prefix.
Mike
Two links:
1- The aforementioned package-inferred-system extension to ASDF, which is standard since ASDF 3.1 (from May 2014, now included with all modern maintained CL implementations, which includes ABCL, Allegro, CCL, CMUCL, ECL, LispWorks, MKCL, SBCL, but not the also supported CLISP, CormanCL, GCL, Genera, MCL, MOCL, SCL, XCL). https://common-lisp.net/project/asdf/asdf/The-package_002dinferred_002dsyste... It works well, is actually used in production by several systems, and does actually provide a more maintainable package discipline than the traditional "everything in one big package".
2- My experimental system package-renaming, which allows you to portably rename packages around some files, though it comes with some practical limitations. https://git.common-lisp.net/frideau/package-renaming I haven't actually used it, but it can portably implement local package nicknames, if you really want them.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To distinguish the real from the unreal, one must experience both. — Saul Gorn
Package-local nicknames always seem to me like a good idea, and I expect that if I ever built something really large in CL they would sooner or later become invaluable, but I have to confess that the number of times I can recall actually using them is on the order of once or twice.
I don't think I've ever used hierarchical packages, though I used to use Allegro all the time. But I have no objection if other people want to use them (as long as I can define local nicknames for them).
Broadly, I agree that packages can be very large without causing difficulties, as long as a single organization is in control of the entire contents.
-- Scott
On Tue, Dec 29, 2015 at 3:52 PM, Alessio Stalla alessiostalla@gmail.com wrote:
Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
- package-local nicknames: the ability to specify, for each package, a
list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
- "Hierarchical" packages: a naming convention for packages understood by
the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL ( http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions:
- First and foremost, is anybody actually using those features? What are
you using them for? 2) If yes, how useful are they for you? What shortcomings do you find in them?
Imagine the annoyance when our application appeared to be full of hierarchical packages, when in fact it wasn't. Oh, such fun we all had.
- nick
On 29 Dec 2015, at 23:52, Alessio Stalla alessiostalla@gmail.com wrote:
Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
- package-local nicknames: the ability to specify, for each package, a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL (http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
- "Hierarchical" packages: a naming convention for packages understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions:
- First and foremost, is anybody actually using those features? What are you using them for?
- If yes, how useful are they for you? What shortcomings do you find in them?
This is something I've been coincidentally pondering recently.
I see two advantages of hierarchical package names: 1) Uniqueness of internal package names 2) The ability to reference internal packages easily as a relative specifier, without specifying the full absolute package name
Issue 1 is always solved by simple concatenation, and doesn't necessarily require new features of the package system. Issue 2 is provided by local package nicknames, which I do support. Using local nicknames for the purpose of internal packages would also promote this features' use probably more popularly than importing external libraries, at least at first.
A third "feature" of hierarchical package names is directory organization, but as others have mentioned, I don't necessarily consider that an advantage.
That said, I've not actually used these features in a real project, as portability is important to us.
The only place that I've seen nested packages be uniquely useful is in JavaScript's npm, where a single library can be loaded into the system in completely independent multiple instantiations. I don't know if this will ever have any relevance to Lisp system configuration, though.
I've coalesced some musings about hierarchical packages as foo:bar:my-symbol (as opposed to com.org.foo:my-symbol) which would give some more real meaning to a traversable hierarchy besides just being a naming convention.
Regarding splitting a system up into multiple packages, I agree that it should it not be done lightly. I use separate internal packages generally when code sections may be optional or independently loaded. Test suites and plug-in architectures are obvious examples.
On 12/29/2015 04:52 PM, Alessio Stalla wrote:
Hi everyone,
I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
- package-local nicknames: the ability to specify, for each package,
a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL (http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
- "Hierarchical" packages: a naming convention for packages
understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
My questions:
- First and foremost, is anybody actually using those features? What
are you using them for? 2) If yes, how useful are they for you? What shortcomings do you find in them?
Hi!
On 2015-12-30 00:52:27+0100, Alessio Stalla wrote:
- package-local nicknames: the ability to specify, for each package, a
list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
Very useful, and in my view missing from the standard. I would use it all the time, but portability is important for me. There should be a CDR for this, but I think it is not trivial to make usable with read-time conditionals.
Nicknames have two purposes: making names more convenient to write and read, and sidestepping name collisions. The nicknames specified in the standard, i. e. nicknames given in a package definition for itself, only fulfill the first purpose.
- "Hierarchical" packages: a naming convention for packages understood by
the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.
I do not see this as important. Simple cases are trivially solved by package-local nicknames, and complicated cases look like an antipattern to me. Which library is that?
Aside: others have brought up Java, but note that that does not really have hierarchical package names either: there is no mechanism for relative references (code in package "foo.bar" cannot refer to symbols in package "foo.bar.baz" other than through the full package name), and no way to restrict visibility to a nontrivial “subtree” of the implied package structure.
Yours aye
Svante
On Dec 30, 2015, at 23:47 , Svante v. Erichsen Svante.v.Erichsen@web.de wrote:
Hi!
On 2015-12-30 00:52:27+0100, Alessio Stalla wrote:
- package-local nicknames: the ability to specify, for each package, a
list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
Very useful, and in my view missing from the standard. I would use it all the time, but portability is important for me. There should be a CDR for this,
Good! We have a volunteer to coordinate the efforts :) :)
Happy Holidays :)
MA
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
Please check: http://ceac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
Thanks for all your answers and pointers! I have learned a few things. I will proceed with my work with the insights you've given me and I will take local nicknames into even more careful consideration. You'll know about my work at the next ELS if you're interested and if it gets accepted.
Alessio
On Thu, Dec 31, 2015 at 9:35 AM, Antoniotti Marco < antoniotti.marco@disco.unimib.it> wrote:
On Dec 30, 2015, at 23:47 , Svante v. Erichsen Svante.v.Erichsen@web.de
wrote:
Hi!
On 2015-12-30 00:52:27+0100, Alessio Stalla wrote:
- package-local nicknames: the ability to specify, for each package, a
list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL ( http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly
other
implementations I'm not aware of.
Very useful, and in my view missing from the standard. I would use it
all the
time, but portability is important for me. There should be a CDR for
this,
Good! We have a volunteer to coordinate the efforts :) :)
Happy Holidays :)
MA
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
Please check: http://ceac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
-
Alessio Stalla -
Antoniotti Marco -
David Holz -
Elias Mårtenson -
Faré -
Kenneth Tilton -
Michael J. Forster -
Nick Levine -
Pascal Costanza -
Pascal J. Bourguignon -
peter -
Scott L. Burson -
Svante v. Erichsen