>> * Marco Antoniotti <marc...@cs.nyu.edu> >> | PS. There is one extra thing to note, that may or may not be >> | obvious. The CL reader actually checks the SYMBOL-NAME of the symbols >> | in *FEATURES*, so that #+:cmu works exactly like #+cmu in my setup.
>> Not so. The #+ and #- readers bind *package* to the keyword package. >> Using #+:cmu is just plain ugly, and preobably reflects an old bug that >> somebody got hurt running into.
> Either that or it reflects some compatibility with very old > pre-package-system code.
I use #+:cmu for consistancy. Although #+:cmu and #+cmu are equivalent, (push :cmu *features*) and (push 'cmu *features*) may not be. Personally, I like all of my kerwords to start with a :, whether absolutely needed or not.
Kent M Pitman wrote: > Jochen Schmidt <j...@dataheaven.de> writes: >> This is more a problem of not defining a common interface. It is always a >> bad solution to let the common interface be some fuzzy common denominator >> of all systems.
> I don't agree. If the interface is one-off, I find the thing you are > pejoratively describing as a "fuzzy common denominator of all systems" > is superior. The reason is that if you want to go and modify the > interface, you can immediately see without a lot of research whether it's > going to be hard for others affected by other "implementations"/"branches" > of the > inteface are doomed to lose. This means you can move ahead where your > change is probably safe and be held back where not. In the case of a > separately defined protocol, you create the need for more work. The whole > point of defining a "protocol" is to make the modification hard, but > that's not always what one wants.
I think we have probably misunderstood each other. As I said in the first answer to you I dislike how it is done in a particular case: CLOCC Port. CLOCC Port being a standard portability layer is IMHO one of those uses where one does _not_ want much protocol changes.
I did not claim anything about all uses of #+ and #- as you might have understood it.
>> Having it all in one file does not really help to get a >> reasonable common interface because it drives people to lower the quality >> of the interface at a whole
> This kind of statement is a subjective judgment only possible to make in > view of specific code. I reject it as unreasonable if there is no such > code > in view. It is as if to say "there is no possible system in which the > code > quality is not lowered", and I don't believe that to be true. If it's not > true, then we're just talking statistics of use, and I don't think that's > an issue of science.
Again this probably subjective view was directed at the one case I mentioned in my first posting. It was _not_ a statement about the whole world.
>> (if that implementation does not _directly_ >> support this then we cannot include it...). If you specify a common >> interface _seperate_ from the implementations there is exactly one place >> to look at if you want to know how something needs to get done.
> No, there is not. This is for several reasons:
> First, if there are four implementations, there will always be four > implementations but now there's a fifth place that you have to look which > is the protocol definition.
This does not make much sense in the particular case I mentioned. It is possible but not necessary to look into the definitions for the other implementations if you code for one system. You are right that it is necessary to look at all implementations when changing the specified interface - but I think such things should be avoided it a project that tries to define a common standard interface. It may happen but it should thing that gets done most of the time...
> Second, it would be inadvisable to change the protocol definition > without examining the users so it's not saving you any time. You still > have to look at all the users.
Again - I thought that my example would make clear that changing the protocol definition is _not_ a common action.
>> Seperating the >> implementations in my experience encourages the people to _implement_ >> missing functionality (differences to the specified common base).
> What it does is encourage stability, which is sometimes desirable and > sometimes not. It depends a great deal on how well-understood the thing > is that's spanning these dialects. For some things, there is a great deal > of stability, and so a separated protcol may be fine. For some things, > there is a lot of continual change, and so for those I think separating > interface definitions from implementation just slows everything down > needlessly.
I thought it would be clear that one wants to encourage a stable interface for a common standard interface definition. You are right that there are uses of reader conditionals in which this is not the case - but I did not claim anything about such cases.
>> If an abstraction layer begins to contain substantial code (more than >> fixing some little argument differences) it gets really messy if code of >> different systems is mixed all over.
> I don't agree that's it's necessarily messier than separating it.
It depends on what one wants to abstract and in my experience abstracting stuff like MP, sockets a.s.o. begins to get messy if it is done all in one place. This may be a subjective view but nobody is forced to agree.
>> That is not necessarily true. Besides of having different files for the >> really system-dependent stuff you can also have _one_ file for sharing >> common functionality.
> Well, you have to have as many files as there are patterns of sharing. > Not necessarily just one. And the creating of a file is a heavyweight > activity, so it encourages people not to "notice" new sharing.
This is not the case the way I imagine it.
>> Bugs in the system-dependent code must in no way mean >> that other systems may have the same bug!
> If F1 and F2 are system-dependent but use the same definition in an > implementation A and B but not C, then any bug fix in A might be a > bug fix in B.
This is certainly a problem. As far as I have seen it this happens very seldom. In most cases you have either distinct code for each implementation or nearly the same code. In the first code separating it pays off while maintaining it. In the second case one can fix this minor differences in the common definitions file.
>> I personally decided against CLOCC Port because of several reasons: >> - It is messy (because of the already stated reasons) >> - It implements a fuzzy (implementation-) defined interface which is >> not compatible to any of the other existing interfaces (short: it is >> yet another incompatible interface)
>> I now prefer using ACL-COMPAT which is an opensource library that tries >> to provide an ACL compatible interface for other systems. Until now it >> runs on LispWorks and CMUCL and MCL is underway. Corman Lisp would be no >> big deal since it already has very similar interfaces. AllegroCL is >> supported by being AllegroCL ;-) . The good thing with ACL-COMPAT is that >> it uses a well >> defined and documented interface. It's development caused additions to >> the codebase of CMUCL to make the multiprocessing layer easier (added >> some missing facilities like run-reasons and initial-bindings).
> Of curiosity, does ACL have an ACL-COMPAT binding?
I think I do not really understand this question. One answer might be that ACL-COMPAT being compatible to ACL would not make much sense to have for ACL. On the other hand you might have meant that there should be a package that fixes the differences of ACL to ACL-COMPAT. Another intention could have been that you implied what to do when the ACL definition changes incompatible.
> This is a kind of situation where a separate protocol definition may be > ok.
This is the kind of situation I talked about from the very beginning... Probably I may have expressed that not good enough.
Jochen Schmidt <j...@dataheaven.de> writes: > > Of curiosity, does ACL have an ACL-COMPAT binding?
> I think I do not really understand this question. One answer might be that > ACL-COMPAT being compatible to ACL would not make much sense to have for > ACL. On the other hand you might have meant that there should be a package > that fixes the differences of ACL to ACL-COMPAT. Another intention could > have been that you implied what to do when the ACL definition changes > incompatible.
I bit of all of these, I guess. I asked this question because I've been wrestling with some naming convention issues related to this.
Suppose some Lisp called QCL and the need for placing QCL:FOO in my code. Clearly, this is a problem to load into non-QCL systems.
I might make a QCL package for other systems. But I am not Q Inc., and I perhaps don't have a right to the trademark QCL.
So I make up the name QCL-COMPAT. I might put QCL-COMPAT:FOO inline into my code. The only problem is that QCL does not have a QCL-COMPAT package. And it might be that one day QCL changes and needs its own different interface.
In a sense, QCL-COMPAT becomes an abstract protocol interface.
This problem is actually made worse if you have, as I do, a package scheme like Java's. So QCL becomes COM.QCORP.CL and QCL-COMPAT becomes DE.DATAHEAVEN.QCL but if someone else wants to add an implementation, the question is whether they may write into DE.DATAHEAVEN.QCL or whether they should create ORG.NAGGUM.QCL ...
Even if some central organization produces a standard, as in ORG.W3C.QCL, there's still a question of how to address the issue of naming the protocol vs naming the definition. In a sense, naming is a two-dimensional space and our definitional naming doesn't address this distinction.
It's a subtle issue and I'm perhaps not expressing it well because I've not yet settled personally on a definition the problem/issue space that I'm happy with. But I think it matters to issues of quality & reputation, liability, and intellectual property.
For example, my understanding is that the name "Java" cannot be attached to a purported implementation without approval from Sun, for exactly reasons such as these.
* Kent M Pitman | Did it allow for multiple cases? The usual problem that alternatives to | #+/#- try to address is the desire for #+otherwise. That is, when you | have | | #+(or Genera (and (not Win32) Franz)) (foo) | #+(and CLIM (not PDP10)) (bar) | #+(or (not CLIM) linux) (baz) | | you sometimes wonder what cases are not handled. of course you could | write: | | #-(or Genera (and (not Win32) Franz) (and CLIM (not PDP10)) (not CLIM) linux) | | but you might forget to edit it if another case is inserted.
Suppose this is used to support a particular feature, say mumble-frotz. Each positive form could then provide the feature. A minute amount of macrology should make it possible to provide a feature more easily. Maybe something like this:
> > > HOWEVER, for myself, I don't tend to do the thing you're talking about > > > because in my experience, this tends to mean that people are not aware > > > of the requirements of other ports and they will change interfaces in > > > ways that aren't properly maintained for competing ports because they > > > don't see the original reason for having chosen the abstraction that was > > > chosen. I find it tends to produce an us-vs-them mentality rather than > > > promoting common understanding and a pressure for vendors to close ranks > > > on small differences.
> > This is more a problem of not defining a common interface. It is always a > > bad solution to let the common interface be some fuzzy common denominator > > of all systems.
> I don't agree. If the interface is one-off, I find the thing you are > pejoratively describing as a "fuzzy common denominator of all systems" > is superior. The reason is that if you want to go and modify the interface, > you can immediately see without a lot of research whether it's going to be > hard for others affected by other "implementations"/"branches" of the > inteface are doomed to lose. This means you can move ahead where your > change is probably safe and be held back where not. In the case of a > separately defined protocol, you create the need for more work. The whole > point of defining a "protocol" is to make the modification hard, but that's > not always what one wants.
I do not agree, but agree with Jochen. In the case of ACL-COMPAT, the interface than Franz has defined is thought out and tested (and in active use). As Jochen as pointed out this has pushed CMUCL to implement more functionality for multi-processing. If a common interface library was maintained CMUCL probably would not have changed and nothing would have happened. It does not look like Franz waits for others to implement enough correponding functionality to decide what to implement. You move on ahead, there is not enough time to wait for consensous, and not enough wisdom to see the results of all decisions. To innovate you need the preceived freedom that you can do things that you will not be jumped on for. Hats off Jochen.
Kent M Pitman wrote: > Jochen Schmidt <j...@dataheaven.de> writes:
>> > Of curiosity, does ACL have an ACL-COMPAT binding?
>> I think I do not really understand this question. One answer might be >> that ACL-COMPAT being compatible to ACL would not make much sense to have >> for ACL. On the other hand you might have meant that there should be a >> package that fixes the differences of ACL to ACL-COMPAT. Another >> intention could have been that you implied what to do when the ACL >> definition changes incompatible.
> I bit of all of these, I guess. I asked this question because I've > been wrestling with some naming convention issues related to this.
> Suppose some Lisp called QCL and the need for placing QCL:FOO in my > code. Clearly, this is a problem to load into non-QCL systems.
> I might make a QCL package for other systems. But I am not Q Inc., > and I perhaps don't have a right to the trademark QCL.
This is a rather interesting point. I really do not know if Franz Inc. would have an interest to sue me for creating ACL-COMPAT. AFAIK they have created a LispWorks compatibility library which probably would create the same problem. I personally think that the whole Lisp community profits from a library like ACL-COMPAT and the synenergies created by it.
> So I make up the name QCL-COMPAT. I might put QCL-COMPAT:FOO inline > into my code. The only problem is that QCL does not have a QCL-COMPAT > package. And it might be that one day QCL changes and needs its own > different interface.
Actually I already have a problem like this with ACL-COMPAT. There are several vendors with a package named "MP" (either package-name or nickname). It would be a very bad idea for example, to intern ACL-COMPAT stuff into a vendor-provided package like LispWorks MP package. Therefore I created a package ACL-COMPAT-MP with a nickname ACL-MP where I implemented the ACL like interface. Now we actually have the problem that using ACL-MP as package-prefix is not compatible to ACL and MP cannot really get used by ACL-COMPAT.
I could now try to get in contact with Franz and ask them if they think it would be a good idea to add ACL-MP as a common package nickname to ACL too. Maybe Duane could say something about Franz' position to this topic?
> In a sense, QCL-COMPAT becomes an abstract protocol interface.
> This problem is actually made worse if you have, as I do, a package scheme > like Java's. So QCL becomes COM.QCORP.CL and QCL-COMPAT becomes > DE.DATAHEAVEN.QCL but if someone else wants to add an implementation, the > question is whether they may write into DE.DATAHEAVEN.QCL or whether they > should create ORG.NAGGUM.QCL ...
I guess this practical problem could be solved (or at least reduced) by using hierarchical packages like ACL (and CMUCL optionally) already have. Franz has a document on how to implement this so it should be doable. I'm sure this topic has been discussed in the past - were there any reasons against using that facility?
> Even if some central organization produces a standard, as in ORG.W3C.QCL, > there's still a question of how to address the issue of naming the > protocol > vs naming the definition. In a sense, naming is a two-dimensional space > and our definitional naming doesn't address this distinction.
This is true, but sometimes it is a good idea to use a good solution now instead of searching forever what the best solution is. The question is if a hierarchical package system would be a good enough solution to this problem.
> It's a subtle issue and I'm perhaps not expressing it well because > I've not yet settled personally on a definition the problem/issue > space that I'm happy with. But I think it matters to issues of > quality & reputation, liability, and intellectual property.
I know nearly nothing about the issues of liability and intellectial property. I guess that it to some degree will depend on trusting each other.
> For example, my understanding is that the name "Java" cannot be > attached to a purported implementation without approval from Sun, for > exactly reasons such as these.
Isn't that too the reason for the "javax" toplevel package name?
Jochen Schmidt wrote: > This is a rather interesting point. I really do not know if Franz Inc. > would have an interest to sue me for creating ACL-COMPAT. AFAIK they have > created a LispWorks compatibility library which probably would create the > same problem. I personally think that the whole Lisp community profits > from a library like ACL-COMPAT and the synenergies created by it.
Oops.. I meant "synergies" of course - it's time to go to bed I fear...
> #-mumble-frotz > (error "mumble-frotz is unavailable on this system") ; or whatever
This is cute but doesn't address the issue that (a) the maybe-provide-feature form could get more than one form in its body [which could almost be dealt with] and (b) there might be spurious #.'s in there [which can't be]. A failing #-conditional doesn't execute #. So a form that actually does reading and evaluating as it accumulates its forms, as would {...} or #{...} discussed earlier has some advantages.
Btw, that isn't fatal. Just something I thought I'd mention in defense of the conditional notation those people do use.
I effectively use the thing you suggest, but just not with features. I often just do things like:
In article <a66h3h$id...@news3.cadvision.com>, Wade Humeniuk wrote:
> "Kent M Pitman" <pit...@world.std.com> wrote in message >> I don't agree. If the interface is one-off, I find the thing you are >> pejoratively describing as a "fuzzy common denominator of all systems" >> is superior. The reason is that if you want to go and modify the >> interface, you can immediately see without a lot of research whether >> ...
> I do not agree, but agree with Jochen. In the case of ACL-COMPAT, the > interface than Franz has defined is thought out and tested (and in active > use). ...
I think you are talking about two different goals. For the ACL-COMPAT library, Wade addresses the essential point: the interface is well-defined. The goal then is the best possible implementation on the interface on each platform.
For the project I'm currently on, I find it is much more efficient taking the approach Kent is discussing. In this project, there is not a defined interface. Rather, I'm creating an interface based on a subset of common functionality currently provided by implementations. Though the package in now in beta test, I expect the interface to grow, and maybe change, as it becomes more complete. To try to create this common subset in a top-down approach would not be efficient.
The project is called UFFI (http://www.med-info.com/uffi.shtml). Beta code and some brief examples on are on the SourceForge CVS server. It seeks to be a universal foreign function interface. By design, it can't take advantage of the full features on any one implementions FFI. But, the subset that it does provide is quite useful. I've already rewritten MaiSQL to support MySQL and PostgreSQL API's on Allegro (Windows/Linux), Lispworks (Windows/Linux), and CMUCL (Linux).
"Wade Humeniuk" <humen...@cadvision.com> writes: > I do not agree, but agree with Jochen. In the case of ACL-COMPAT, the > interface than Franz has defined is thought out and tested (and in active > use).
IMO, interfaces this stable can be counted on one hand.
However, almost every serious application has the same issues arise, and mostly in my experience the interfaces are badly thought out and need to change all the time by the implementors. Organizing your code in a way that is dictated by style rules appropriate to these very few situations where someone has thought hard enough about an interface to really freeze it is going to, I think, encourage people not to change code that badly needs to be changed on an ongoing basis as experience is gained. I think it will lead to people saying "no, we agreed on that interface and shouldn't second guess it now" when really it's only accidental that it's viewed as an interface; more properly, it's just another piece of code--just one that happens to depend on issues dictated by other groups rather than on issues in the application's data domain.
It's fine with me for there to be a strong difference of opinion on this. That will mean people setting up systems will have to stop and think hard when they start about the implications of freezing their system definition vs the issue of letting it vary dynamically. I think that's what decides it. But the idea should not be decided on the basis of "I like to lay out the files this way"; rather, it should be decided on the basis of "I want this particular dynamic among programmers" and "I'm this degree of confident that the following will never have to change".
> #-mumble-frotz > (error "mumble-frotz is unavailable on this system") ; or whatever
* Kent M Pitman <pit...@world.std.com> | This is cute but doesn't address the issue that (a) the | maybe-provide-feature form could get more than one form in its body | [which could almost be dealt with]
Almost? Just change &body to &optional and ,@body to ,body, and the macro call will refuse to work with more than one "actual" body.
| and (b) there might be spurious #.'s in there [which can't be].
What is the difference between this and the code without the maybe-provide-feature wrapper?
| A failing #-conditional doesn't execute #.
But since I rely on the specified functionality of #+ and #- to produce only whitespace if the conditions are not met, I fail to see what you think would make a failing #-condition execute #. in my code.
| So a form that actually does reading and evaluating as it accumulates its | forms, as would {...} or #{...} discussed earlier has some advantages.
But that is not what maybe-provide-feature does. All it does is make sure that it pushes the new feature symbol onto *features* if at least one of the conditionally read (with the normal reader functionality) expressions are actually read, and not treated as whitespace.
| Btw, that isn't fatal. Just something I thought I'd mention in defense | of the conditional notation those people do use.
I am not quite certaint what you have replied to.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
> > necessarily even true for all time. It would be a crying shame if on > > Star Trek, the underlying file system was still the present day unix > > file system or DOS or ... if it is, they need an episode that shows > > everyone's lives hanging in the balance over this.
> Scotty? Is the warp drive library in /usr/lib or /usr/local/lib? > Perhaps we should write some shell scripts to get them running ...
My own experience runs exactly counter to yours. I worked on a commercial lisp system that was ported to more than 11 different machines and operating systems/windowing systems. Putting compiler directives in one file for all the functionality of a given module was the only way we could maintain our sanity.
Re the "fuzzy [lowest] common denominator" - that is always a temptation, but seeing what other packages offer beyond the lowest denominator inspired our people to code implementations of that functionality in other less capable systems. So our common interface tended to work at the highest, not the lowest, level.
Discussions on this subject were often heated, but once everyone agreed that functionality should be the union of the capabilities of the systems used rather than the intersection, life became much better. Having all of the implementations of a particular function in one file made it easier to edit if an arglist changed.
> > promoting common understanding and a pressure for vendors to close ranks > > on small differences.
> This is more a problem of not defining a common interface. It is always a > bad solution to let the common interface be some fuzzy common denominator > of all systems. Having it all in one file does not really help to get a > reasonable common interface because it drives people to lower the quality > of the interface at a whole (if that implementation does not _directly_ > support this then we cannot include it...). If you specify a common > interface _seperate_ from the implementations there is exactly one place to > look at if you want to know how something needs to get done. Seperating the > implementations in my experience encourages the people to _implement_ > missing functionality (differences to the specified common base). > If an abstraction layer begins to contain substantial code (more than > fixing some little argument differences) it gets really messy if code of > different systems is mixed all over.
> > Also, separate files doesn't allow sharing of commonality of > > implementation > > where there is any. Multiple implementations makes it more likely that > > bugs will creep in, and less likely that when a bug is fixed, the fix will > > get propagated to all the implementations that could accept the fix.
> That is not necessarily true. Besides of having different files for the > really system-dependent stuff you can also have _one_ file for sharing > common functionality. Bugs in the system-dependent code must in no way mean > that other systems may have the same bug!
> I personally decided against CLOCC Port because of several reasons: > - It is messy (because of the already stated reasons) > - It implements a fuzzy (implementation-) defined interface which is > not compatible to any of the other existing interfaces (short: it is yet > another incompatible interface)
> I now prefer using ACL-COMPAT which is an opensource library that tries to > provide an ACL compatible interface for other systems. Until now it runs on > LispWorks and CMUCL and MCL is underway. Corman Lisp would be no big deal > since it already has very similar interfaces. AllegroCL is supported by > being AllegroCL ;-) . The good thing with ACL-COMPAT is that it uses a well > defined and documented interface. It's development caused additions to the > codebase of CMUCL to make the multiprocessing layer easier (added some > missing facilities like run-reasons and initial-bindings).
> I'm working on making the socket layer more compatible by ensuring that the > same conditions like in ACL get thrown.
> Now that the number of supported platforms (and the number of users) is > increasing I try to clean the code up in ways to make maintaining and > porting easier.
> >> > Of curiosity, does ACL have an ACL-COMPAT binding?
> >> I think I do not really understand this question. One answer might be > >> that ACL-COMPAT being compatible to ACL would not make much sense to have > >> for ACL. On the other hand you might have meant that there should be a > >> package that fixes the differences of ACL to ACL-COMPAT. Another > >> intention could have been that you implied what to do when the ACL > >> definition changes incompatible.
> > I bit of all of these, I guess. I asked this question because I've > > been wrestling with some naming convention issues related to this.
> > Suppose some Lisp called QCL and the need for placing QCL:FOO in my > > code. Clearly, this is a problem to load into non-QCL systems.
> > I might make a QCL package for other systems. But I am not Q Inc., > > and I perhaps don't have a right to the trademark QCL.
> This is a rather interesting point. I really do not know if Franz Inc. > would have an interest to sue me for creating ACL-COMPAT.
An interesting question, which can be approached from a couple of directions:
- Franz Inc. does not own the term "acl" or "ACL"; it is an acronym which has many different meanings, among them being "Ansi Common Lisp" or "Access Control List". Even the name "Allegro" is not trademarked by us by itself, because it is too general. The trademarked name we use (and the one I always try to use when I represent Franz Inc officially) is the full name "Allegro CL". That said, it is usually easy to understand the terms "acl" or "Allegro" when used in context to mean "Allegro CL", and I do not generally correct the users of that term. Sometimes we Franz developers ourselves get sloppy and use the contractions as well.
- The name acl-compat cannot have anything but positive connotations toward Franz; it connotes a de-facto standard to which to target. Why would we even want to consider such a suit?
> AFAIK they have > created a LispWorks compatibility library which probably would create the > same problem. I personally think that the whole Lisp community profits from > a library like ACL-COMPAT and the synenergies created by it.
Absolutely.
> > So I make up the name QCL-COMPAT. I might put QCL-COMPAT:FOO inline > > into my code. The only problem is that QCL does not have a QCL-COMPAT > > package. And it might be that one day QCL changes and needs its own > > different interface.
> Actually I already have a problem like this with ACL-COMPAT. There are > several vendors with a package named "MP" (either package-name or nickname). > It would be a very bad idea for example, to intern ACL-COMPAT stuff into a > vendor-provided package like LispWorks MP package. Therefore I created a > package ACL-COMPAT-MP with a nickname ACL-MP where I implemented the ACL > like interface. Now we actually have the problem that using ACL-MP as > package-prefix is not compatible to ACL and > MP cannot really get used by ACL-COMPAT.
Yes, we've seen this problem beore, as well. For example, our DEBUG package by default has a DB nickname, but because of some external usages of package names in our code, the DB name was clashing with a customer's usage of their own DB package, which was some sort of database package. Our initial solution was to change all of the externalizable references to DB to instead refer to the full package name (DEBUG) and that would allow the customer to use rename-package to effectively remove the DB nickname from our package. That might be something to do in this situation, as well. However, that does not solve the basic problem of package namespaces and conflicts therein.
> I could now try to get in contact with Franz and ask them if they think it > would be a good idea to add ACL-MP as a common package nickname to ACL too. > Maybe Duane could say something about Franz' position to this topic?
We don't yet have a position, but Steve Haflich has been working on a proposal for an upward compatible extension to packages that would help to mitigate this kind of conflict in package namespaces. I think he is almost ready to propose it on this forum. He and I have discussed it, and it is looking promising. Look for his post within the next week or so.
> > In a sense, QCL-COMPAT becomes an abstract protocol interface.
> > This problem is actually made worse if you have, as I do, a package scheme > > like Java's. So QCL becomes COM.QCORP.CL and QCL-COMPAT becomes > > DE.DATAHEAVEN.QCL but if someone else wants to add an implementation, the > > question is whether they may write into DE.DATAHEAVEN.QCL or whether they > > should create ORG.NAGGUM.QCL ...
> I guess this practical problem could be solved (or at least reduced) by > using hierarchical packages like ACL (and CMUCL optionally) already have. > Franz has a document on how to implement this so it should be doable. > I'm sure this topic has been discussed in the past - were there any reasons > against using that facility?
Heirarchical packages don't remove the necessity of having to actually go in and change the source code. It would be nice be able to have an extension which in fact does allow one to specify the interfaces and implementations, without having to use an awk or sed script to remanufacture a set of sources. I think that Steve's proposal will cover this desire.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
... > > > I might make a QCL package for other systems. But I am not Q Inc., > > > and I perhaps don't have a right to the trademark QCL.
> > This is a rather interesting point. I really do not know if Franz Inc. > > would have an interest to sue me for creating ACL-COMPAT.
I was speaking more abstractly. If it were LISPWORKS-COMPAT or ALLEGRO-COMPAT, it could become an issue.
Further, I recently saw a McDonald's commercial in which they were referring to themselves as "Mickey D's" which is an informal name created by users of the product that has been factored back up into the company and I wouldn't be surprised to see a trademark attempt on later... So these things work in both directions.
> An interesting question, which can be approached from a couple of > directions:
> - Franz Inc. does not own the term "acl" or "ACL"; it is an acronym > which has many different meanings, among them being "Ansi Common Lisp" > or "Access Control List". Even the name "Allegro" is not trademarked > by us by itself, because it is too general. The trademarked name we use > (and the one I always try to use when I represent Franz Inc officially) > is the full name "Allegro CL". That said, it is usually easy to understand > the terms "acl" or "Allegro" when used in context to mean "Allegro CL", > and I do not generally correct the users of that term. Sometimes we Franz > developers ourselves get sloppy and use the contractions as well.
Well, and at Harlequin we had CCL (Cambridge Common Lisp, though there were at least two other dialects that also used this acronym. Short names are just dangerous. And as you expand them, you trample on the trade name. I can't remember what happened to the lawsuit over the use of the name "anti-monopoly" for a game, nor the use of Zetalisp Plus as a product name by LMI, I think it was, after Symbolics had registered Zetalisp as a trademark. Suffice to say it gets murkey.) No one wants to sue anyone as a first line of attack, but when a name appears to an uninformed observer to portray, by its name, a particular source, and when that source doesn't control the quality of the item, they sometimes have to protect their trade image, like it or not. Allegro CL might be the tradename, but I bet if I started marketing "Allegro Lisp", and refused to stand down, the Franz lawyers would be at my door wanting a "chat".
> - The name acl-compat cannot have anything but positive connotations > toward Franz; it connotes a de-facto standard to which to target. Why > would we even want to consider such a suit?
My remarks weren't meant to inspire fear of Franz, but more to address the general notion of consistent naming schemes, where such naming schemes might necessarily seem to incorporate some likeness of the thing they seek to copy. The question is whether the modifier is sufficient to avoid confusion.
> > AFAIK they have > > created a LispWorks compatibility library which probably would create the > > same problem. I personally think that the whole Lisp community profits from > > a library like ACL-COMPAT and the synenergies created by it.
> Absolutely.
Especially if it works. If it started failing, due to poor implementation, and people started badmouthing "that ACL compatibility stuff", it might get more tricky.
Again, my remarks were aimed at the issue of a robust solution to the naming problem that didn't leave people wondering.
> > > So I make up the name QCL-COMPAT. I might put QCL-COMPAT:FOO inline > > > into my code. The only problem is that QCL does not have a QCL-COMPAT > > > package. And it might be that one day QCL changes and needs its own > > > different interface.
> > Actually I already have a problem like this with ACL-COMPAT. There are > > several vendors with a package named "MP" (either package-name or nickname). > > It would be a very bad idea for example, to intern ACL-COMPAT stuff into a > > vendor-provided package like LispWorks MP package. Therefore I created a > > package ACL-COMPAT-MP with a nickname ACL-MP where I implemented the ACL > > like interface. Now we actually have the problem that using ACL-MP as > > package-prefix is not compatible to ACL and > > MP cannot really get used by ACL-COMPAT.
And you have the problem that ACL-MP might look like it came from the ACL guys.
> Yes, we've seen this problem beore, as well. For example, our DEBUG > package by default has a DB nickname, but because of some external > usages of package names in our code, the DB name was clashing with a > customer's usage of their own DB package, which was some sort of > database package. Our initial solution was to change all of the > externalizable references to DB to instead refer to the full package > name (DEBUG) and that would allow the customer to use rename-package to > effectively remove the DB nickname from our package.
I am coming to the following set of conclusions about styling that I think vendors should adopt:
File externalization should always externalize the name, not nickname, of a package.
No one should ever change the name of a package.
Nicknames should be the only changeable names of a package, and should just change any time without warning. Nicknames should be used only for loading code that is preceded by a defpackage that sets up the correct nicknames; in all other cases, long names should be used.
I've been using only package names like COM.HYPERMETA.NET.HTTP.SERVER and have had no problem with this. I've found for myself that using very long packages with structured names makes me feel free enough about making new names that I make lots of little package names. This, in turn, means I can usually import just the right set of names because I don't get names I don't want. This, in turn, means I rarely if ever use package prefixes inline in code, so I don't mind them being long.
> That might be > something to do in this situation, as well. However, that does not > solve the basic problem of package namespaces and conflicts therein.
> > I could now try to get in contact with Franz and ask them if they think it > > would be a good idea to add ACL-MP as a common package nickname to ACL too. > > Maybe Duane could say something about Franz' position to this topic?
> We don't yet have a position, but Steve Haflich has been working on > a proposal for an upward compatible extension to packages that would > help to mitigate this kind of conflict in package namespaces. I think > he is almost ready to propose it on this forum. He and I have discussed > it, and it is looking promising. Look for his post within the next > week or so.
This can be solved on a case-by-case basis, but my original question was more general and is not able to be solved by such an analysis.
> > > In a sense, QCL-COMPAT becomes an abstract protocol interface.
> > > This problem is actually made worse if you have, as I do, a package scheme > > > like Java's. So QCL becomes COM.QCORP.CL and QCL-COMPAT becomes > > > DE.DATAHEAVEN.QCL but if someone else wants to add an implementation, the > > > question is whether they may write into DE.DATAHEAVEN.QCL or whether they > > > should create ORG.NAGGUM.QCL ...
> > I guess this practical problem could be solved (or at least reduced) by > > using hierarchical packages like ACL (and CMUCL optionally) already have. > > Franz has a document on how to implement this so it should be doable. > > I'm sure this topic has been discussed in the past - were there any reasons > > against using that facility?
> Heirarchical packages don't remove the necessity of having to actually > go in and change the source code. It would be nice be able to have > an extension which in fact does allow one to specify the interfaces > and implementations, without having to use an awk or sed script to > remanufacture a set of sources. I think that Steve's proposal will > cover this desire.
It might be that this just has to be managed by an interactive tool or some sort of multi-d lookup that says "get me any company's implementation of the following interface". Part of the issue is that any package can be viewed as an interface. Yet some interfaces really are interfaces (things very well documented and not likely to change). Like CL. Whereas what ACL or LispWorks is varies from release to release, so calling it an interface has certain difficulties for those purporting compatibility without citing version.
> ... > > > > I might make a QCL package for other systems. But I am not Q Inc., > > > > and I perhaps don't have a right to the trademark QCL.
> > > This is a rather interesting point. I really do not know if Franz Inc. > > > would have an interest to sue me for creating ACL-COMPAT.
[...]
> > - The name acl-compat cannot have anything but positive connotations > > toward Franz; it connotes a de-facto standard to which to target. Why > > would we even want to consider such a suit?
> My remarks weren't meant to inspire fear of Franz, but more to address the > general notion of consistent naming schemes, where such naming schemes might > necessarily seem to incorporate some likeness of the thing they seek to > copy. The question is whether the modifier is sufficient to avoid confusion.
Right. I wasn't responding to your original thesis, but to Jochen's specific question. In fact, I would not have otherwise answered his article at all, except that he specifically asked me to do so.
> > > AFAIK they have > > > created a LispWorks compatibility library which probably would create the > > > same problem. I personally think that the whole Lisp community profits from > > > a library like ACL-COMPAT and the synenergies created by it.
> > Absolutely.
> Especially if it works. If it started failing, due to poor implementation, > and people started badmouthing "that ACL compatibility stuff", it might get > more tricky.
> Again, my remarks were aimed at the issue of a robust solution to the naming > problem that didn't leave people wondering.
Right. I think Steve's proposal will address the issue.
[ ... ]
> > Yes, we've seen this problem beore, as well. For example, our DEBUG > > package by default has a DB nickname, but because of some external > > usages of package names in our code, the DB name was clashing with a > > customer's usage of their own DB package, which was some sort of > > database package. Our initial solution was to change all of the > > externalizable references to DB to instead refer to the full package > > name (DEBUG) and that would allow the customer to use rename-package to > > effectively remove the DB nickname from our package.
> I am coming to the following set of conclusions about styling that I think > vendors should adopt:
Before I even comment on these style guidelines there are a couple of points I want to make about even bringing them up (just to be sure we are making the same assumptions):
- Style guidelines are not rules. Unless an implementation enforces such guidelines, it is impossible to completely ensure that they are followed. Thus, they must be constructed with ample treatment of the contingencies (i.e., what if someone simply refuses or forgets to follow the guideleines).
- By "vendor", I assume that you mean any provider of a package/interface, and not limiting your comments to CL vendors.
> File externalization should always externalize the name, not nickname, > of a package.
Yes, this is the conclusion we've drawn, though obviously it is easy to violate, even when the intentions are good. Nicknames tend to be smaller than full package names, and thus are much more conducive to use, because longer names tend to clutter up code. However, even if the name of a package is externalized, it doesn't solve the problem:
> No one should ever change the name of a package.
This would only work if each "vendor" named their package uniquely. I think you implied this as a style guideline in a comment below, but I'm somewhat surprised that you didn't make it explicit; it seems like an obvious one. I didn't look up what each vendor calls their multiprocessing package name, but since multiprocessing is not a standard, we would probably want to call ours excl-multiprocessing, allegro-multiprocessing, or something similar. If you created a mp system, you could call yours kmp-multiprocessing, or maybe kmp-mp... Otherwise, there would be a clash between two "vendors" who have both happened to name their packages multiprocessing. Thye hierarchical package naming conventions might be useful here.
> Nicknames should be the only changeable names of a package, and should just > change any time without warning. Nicknames should be used only for loading > code that is preceded by a defpackage that sets up the correct nicknames; > in all other cases, long names should be used.
Steve's proposal will deal with nicknames specifically, so I won't go into this.
> I've been using only package names like COM.HYPERMETA.NET.HTTP.SERVER > and have had no problem with this. I've found for myself that using very > long packages with structured names makes me feel free enough about > making new names that I make lots of little package names. This, in turn, > means I can usually import just the right set of names because I don't get > names I don't want. This, in turn, means I rarely if ever use package > prefixes inline in code, so I don't mind them being long.
Yes, this is a perfectly valid way to code. But it would not be fair to require that only this style be used; I am thinking specifically about the choice that some programmers make to explicitly remove all implied imports (via use-package and/or explicit importing) and to thus force the explicit qualification of all external interface usage. This style has the advantage of allowing recognition of the usage of a library without having to scroll up to the import list in the defpackage, and without having to look at either the exporting package definition or the documentation to even know what interface the function comes from. [I don't know if this previous paragraph is understandable; it seems opaque to me, so let me know and if necessary I'll expand with an example]
> > That might be > > something to do in this situation, as well. However, that does not > > solve the basic problem of package namespaces and conflicts therein.
> > > I could now try to get in contact with Franz and ask them if they think it > > > would be a good idea to add ACL-MP as a common package nickname to ACL too. > > > Maybe Duane could say something about Franz' position to this topic?
> > We don't yet have a position, but Steve Haflich has been working on > > a proposal for an upward compatible extension to packages that would > > help to mitigate this kind of conflict in package namespaces. I think > > he is almost ready to propose it on this forum. He and I have discussed > > it, and it is looking promising. Look for his post within the next > > week or so.
> This can be solved on a case-by-case basis, but my original question was > more general and is not able to be solved by such an analysis.
Actually, though, Steve's proposal will be a proposal to change the actual behavior of the package system, and not just a usage guide. So of course, if nobody implements his proposal, nothing is solved; it would probably take two CL vendors to implement it in order to make it useful to anyone for cross-CL-vendor usage. However, if such a solution is implemented by even one vendor, then yes, I think that your original issues can be addressed. I think that Steve is intending to at least address your questions, if not solve them.
> > > > In a sense, QCL-COMPAT becomes an abstract protocol interface.
> > > > This problem is actually made worse if you have, as I do, a package scheme > > > > like Java's. So QCL becomes COM.QCORP.CL and QCL-COMPAT becomes > > > > DE.DATAHEAVEN.QCL but if someone else wants to add an implementation, the > > > > question is whether they may write into DE.DATAHEAVEN.QCL or whether they > > > > should create ORG.NAGGUM.QCL ...
> > > I guess this practical problem could be solved (or at least reduced) by > > > using hierarchical packages like ACL (and CMUCL optionally) already have. > > > Franz has a document on how to implement this so it should be doable. > > > I'm sure this topic has been discussed in the past - were there any reasons > > > against using that facility?
> > Heirarchical packages don't remove the necessity of having to actually > > go in and change the source code. It would be nice be able to have > > an extension which in fact does allow one to specify the interfaces > > and implementations, without having to use an awk or sed script to > > remanufacture a set of sources. I think that Steve's proposal will > > cover this desire.
> It might be that this just has to be managed by an interactive tool or > some sort of multi-d lookup that says "get me any company's > implementation of the following interface". Part of the issue is that > any package can be viewed as an interface. Yet some interfaces really > are interfaces (things very well documented and not likely to change).
And to the extent that there is an interface, it should be possible to use it in this manner. I think that that is what Jochen's acl-compat is all about; it goes out and grabs (or manufactures) whatever interfaces are avaliable on the host which are also necessary to implement the portable version of aserve.
> Like CL. Whereas what ACL or LispWorks is varies from release to > release, so calling it an interface has certain difficulties for those > purporting compatibility without citing version.
I would call neither Allegro CL nor LispWorks "an interface". Each is a product with multiple interfaces, starting with CL, and extended with many distinct interfaces. Those interfaces that are exported and documented are in effect promises to their customers, and variances in this interface must thus be thought out extremely carefully. There may be good reasons why an interface must change from one version to another, but always, such changes carry with them a negative
...
