I'm having problems figuring out the behavior of directory. I'd like to use
the return value of #'directory to traverse a directory-tree. It seems that
calling directory recursively on pathnames in the returned list,
corresponding to subdirectories, returns a list containing themselves,
instead of a listing of their contents. See e.g. the following output (LW
4.2 pro under win2000):
CL-USER 5 > (directory #p"D:/download/")
(#P"D:/download/www/" #P"D:/download/lisp/" #P"D:/download/articles/")
CL-USER 6 > (car *)
#P"D:/download/www/"
CL-USER 7 > (directory *)
(#P"D:/download/www/")
CL-USER 8 > (directory #P"D:/download/www/")
(#P"D:/download/www/xml/" #P"D:/download/www/standards/"
#P"D:/download/www/sgml/"
#P"D:/download/www/html-tools/" #P"D:/download/www/ftp/"
#P"D:/download/www/browsers/")
Can somebody explain this behavior to me? I guess it has something to do
with the results being truenames, but I cannot figure it out.
Another problem is the portability of the output of directory. In ACL6.0 the
items in the returned list, corresponding to subdirectories, miss the
trailing slashes. See e.g. the following output:
CL-USER(5): (directory #P"D:/download/www/")
(#p"D:\\download\\www\\browsers" #p"D:\\download\\www\\ftp"
#p"D:\\download\\www\\html-tools" #p"D:\\download\\www\\sgml"
#p"D:\\download\\www\\standards" #p"D:\\download\\www\\xml")
CL-USER(6): (directory (car *))
(#p"D:\\download\\www\\browsers")
CL-USER(7): (directory #p"D:\\download\\www\\browsers")
(#p"D:\\download\\www\\browsers")
CL-USER(8): (directory #p"D:\\download\\www\\browsers\\")
(#p"D:\\download\\www\\browsers\\ie5setup.exe"
#p"D:\\download\\www\\browsers\\ie6setup.exe"
#p"D:\\download\\www\\browsers\\netscape")
I thought that, given both implementations run on the smae machine, the
truenames of the files would be identical.
Hope that somebody can enlighten me,
Andre
"Andre Koehorst" <··········@mmi.unimaas.nl> writes:
> Another problem is the portability of the output of directory.
Abandon any hope of portability if you don't make _serious_ accomodations
to implementational differences. Implementations vary widely.
I have a lot more to say on this but I'm too tired today. The above is
the high-order bit, though.
#+ and #- are your friends here. Write some interfaces that better
satisfy your expectations, making heavy use of conditionals. Then use
your own better tools "portably". That's what most other successful folks
do when they deal with DIRECTORY, I think.
Sorry, but the standard just didn't cover this, in part because the
set of possible file systems in the world is not under CL's control.
It was a lot wider in the past when CL was designed than it is now.
And some though people like to think the number is now fixed and
perhaps even dwindling, some of us don't think that's either good nor
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.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
>
> 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.
Must resist the opening...no, can't hold...failing...
=====================================================
CLOSEUP ENGINEERING STATION DISPLAY SHOWING ...
---------------------------------------------------------------
VOYAGER:/Bridge> Doctor
The name specified is not recognized as an
internal or external command, operable program or batch file.
VOYAGER:/Bridge> VOYAGER:/Deck5/MedLab/EMH/Doctor.exe
The name specified is not recognized as an
internal or external command, operable program or batch file.
VOYAGER:/Bridge> cd VOYAGER:/Deck5/MedLab/EMH/
VOYAGER:/Deck5/MedLab/EMH> dir
Volume in drive VOYAGER has no label.
Volume Serial Number is NCC-74656
Directory of VOYAGER:/Deck5/MedLab/EMH
stardate 48308.5 <DIR> .
stardate 48308.5 <DIR> ..
2 File(s) 0 bytes
42 bytes free HHGTTG-DA
----------------------------------------------------------------
PULL BACK TO MID SHOT (Janeway,Torres)
TORRES: The doctor's definitely gone. If this was a Maquis ship,
I just could have safeguarded the program with something
as simple as chmod, (sarcastic) but no...fscking Starfleet
has to go with MS Viewscreen 2358.
JANEWAY: (shrugs) It came pre-installed and it's better than '55.
Besides, they're spending all its resources on getting
CMUCL ported over.
=========================================================
Like that will ever happen...what the hell, it's sci fi
Geoff
Kent M Pitman <······@world.std.com> writes:
[...]
> 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 ...
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/
I cannot change the laws of physics captain. Scandisk will still take 17
hours to complete.
-Luke
"Julian Stecklina" <··········@web.de> wrote in message
···················@blitz.comp.com...
> Kent M Pitman <······@world.std.com> writes:
>
>
> [...]
>
> > 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 ...
>
> Regards,
> Julian
> --
> Meine Hompage: http://julian.re6.de
>
> Um meinen oeffentlichen Schluessel zu erhalten:
> To get my public key:
> http://math-www.uni-paderborn.de/pgp/
On Tue, 5 Mar 2002 17:30:13 GMT, Kent M Pitman <······@world.std.com>
wrote:
> "Andre Koehorst" <··········@mmi.unimaas.nl> writes:
>
> > Another problem is the portability of the output of directory.
[...]
> #+ and #- are your friends here. Write some interfaces that better
> satisfy your expectations, making heavy use of conditionals. Then use
> your own better tools "portably". That's what most other successful folks
Since the need for libraries and standardization is often mentioned here,
it may be worth reminding that CLOCC provides something similar,
PORT:PROBE-DIRECTORY, in its portability layer:
file `src/port/path.lisp'
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clocc/clocc/src/port/path.lisp?rev=HEAD&content-type=text/vnd.viewcvs-markup
CLOCC (Common Lisp Open Code Collection)
http://clocc.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
On Tue, 5 Mar 2002 17:30:13 GMT, Kent M Pitman <······@world.std.com>
wrote:
>#+ and #- are your friends here. Write some interfaces that better
>satisfy your expectations, making heavy use of conditionals. Then use
>your own better tools "portably". That's what most other successful folks
>do when they deal with DIRECTORY, I think.
References on how to use #+ #- or any of the # constructs.
Please don't say CLHS, CLTL.
······@interaccess.com (Thaddeus L Olczyk) writes:
> On Tue, 5 Mar 2002 17:30:13 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> >#+ and #- are your friends here. Write some interfaces that better
> >satisfy your expectations, making heavy use of conditionals. Then use
> >your own better tools "portably". That's what most other successful folks
> >do when they deal with DIRECTORY, I think.
> References on how to use #+ #- or any of the # constructs.
> Please don't say CLHS, CLTL.
I am not a fan of #+ and #- as KMP is.
They are the (nice) equivalent of #ifdef #endif
They act at the level of the reader and check the content of the
*FEATURES* variable. So you may have in a file:
#+<condition> <form>
or
#-<condition> <form>
The CL Reader "checks" the <condition> against the *FEATURES* variable
and if the #+<condition> is true, then the next <form> is effectively
read in. (The <form> is read in if the #-<condition> is false).
Otherwise the <form> is skipped (i.e. the CL Reader ignores it).
Now, what is <condition>? If you check the *FEATURES* variable, you
will see that it is a list of symbols (usually keywords).
<condition> may be any symbol or a form of the kind
(and <condition1> <condition2> ...)
or
(or <condition1> <condition2> ...)
So, my CMUCL *FEATURES* list looks like
(:INFIX :CL-CONFIGURATION :MK-DEFSYSTEM-4 :CL-UTILITIES-AMBLER :MK-DEFSYSTEM
:CL-ENVIRONMENT :|18c| :MOTIF :CLX-MIT-R5 :CLX-MIT-R4 :XLIB :CLX
:CLX-LITTLE-ENDIAN :PCL-STRUCTURES :PORTABLE-COMMONLOOPS :PCL :PYTHON
:NO-HEMLOCK :GENCGC :CONSERVATIVE-FLOAT-TYPE :CONSTRAIN-FLOAT-TYPE
:PROPAGATE-FUN-TYPE :PROPAGATE-FLOAT-TYPE :RANDOM-MT19937 :I486 :MP :HASH-NEW
:CMU18 :CMU18C :X86 :LINUX :GLIBC2 :UNIX :COMMON :CMU :NEW-COMPILER :CLTL2
:COMMON-LISP :ANSI-CL :DRAFT-ANSI-CL :X3J13 :IEEE-FLOATING-POINT)
Now the question:
If I put the following code in a file
==============================================================================
#+cmu
(print "I am a CMUCL")
#+(and cmu (not motif))
(print "... but I don't have the Motif package installed")
#-(or allegro lispworks)
(print "I am not an ACL or LW")
#+allegro
(print "I am ACL")
==============================================================================
... and I loaded it in different CL implementations, what would you
get?
Cheers
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.
Hope it helps.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ······@interaccess.com (Thaddeus L Olczyk) writes:
>
> > On Tue, 5 Mar 2002 17:30:13 GMT, Kent M Pitman <······@world.std.com>
> > wrote:
> >
> > >#+ and #- are your friends here. Write some interfaces that better
> > >satisfy your expectations, making heavy use of conditionals. Then use
> > >your own better tools "portably". That's what most other successful folks
> > >do when they deal with DIRECTORY, I think.
> > References on how to use #+ #- or any of the # constructs.
> > Please don't say CLHS, CLTL.
>
> I am not a fan of #+ and #- as KMP is.
I didn't say I was a fan of #+/#-, but they have their place.
I usually create an isolated file that "normalizes" (to abuse a lambda
calculus term from another thread) a set of names and contracts so
that the rest of my files don't have to have this kind of stuff.
But when implementations differ, the choice is either conditional at
compile time or at load/run time, and for things like this, early
conditionals are mostly better.
Kent M Pitman wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>> ······@interaccess.com (Thaddeus L Olczyk) writes:
>>
>> > On Tue, 5 Mar 2002 17:30:13 GMT, Kent M Pitman <······@world.std.com>
>> > wrote:
>> >
>> > >#+ and #- are your friends here. Write some interfaces that better
>> > >satisfy your expectations, making heavy use of conditionals. Then use
>> > >your own better tools "portably". That's what most other successful
>> > >folks do when they deal with DIRECTORY, I think.
>> > References on how to use #+ #- or any of the # constructs.
>> > Please don't say CLHS, CLTL.
>>
>> I am not a fan of #+ and #- as KMP is.
>
> I didn't say I was a fan of #+/#-, but they have their place.
>
> I usually create an isolated file that "normalizes" (to abuse a lambda
> calculus term from another thread) a set of names and contracts so
> that the rest of my files don't have to have this kind of stuff.
> But when implementations differ, the choice is either conditional at
> compile time or at load/run time, and for things like this, early
> conditionals are mostly better.
I particularily do not like them used like in CLOCC Port.
Having one file where for example the network interface for >5 different CL
systems are defined at the same place is even more than a huge mess. I
prefer having one file for each of the 5 different systems and a
system-definition which uses the conditionals to load the corresponding
file for a particular CL implementation.
So I would say that CLOCC Port is a really good example on how to *not* use
#+ and #-.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> I particularily do not like [#+/#-] used like in CLOCC Port.
>
> Having one file where for example the network interface for >5 different CL
> systems are defined at the same place is even more than a huge mess. I
> prefer having one file for each of the 5 different systems and a
> system-definition which uses the conditionals to load the corresponding
> file for a particular CL implementation.
>
> So I would say that CLOCC Port is a really good example on how to *not* use
> #+ and #-.
As I've often said with "style rules", they are not hard-and-fast. They
identify weightings that drag one's decision left or right or up or down,
sort of like gravity. The presence of a style rule doesn't preclude the
presence of a countervening style rule that has stronger pull in some other
circumstance. And they're subjective in both weighting and application.
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.
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.
But, as I said, these are just subjective assessments. There is no absolute
answer.
Kent M Pitman wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I particularily do not like [#+/#-] used like in CLOCC Port.
>>
>> Having one file where for example the network interface for >5 different
>> CL systems are defined at the same place is even more than a huge mess. I
>> prefer having one file for each of the 5 different systems and a
>> system-definition which uses the conditionals to load the corresponding
>> file for a particular CL implementation.
>>
>> So I would say that CLOCC Port is a really good example on how to *not*
>> use
>> #+ and #-.
>
> As I've often said with "style rules", they are not hard-and-fast. They
> identify weightings that drag one's decision left or right or up or down,
> sort of like gravity. The presence of a style rule doesn't preclude the
> presence of a countervening style rule that has stronger pull in some
> other
> circumstance. And they're subjective in both weighting and application.
I did certainly not mean to force anyone to follow my suggestion. It was
simply meant to express my opinion and probably to start an interesting
discussion from which I and others could benefit.
> 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. 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.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> Kent M Pitman wrote:
>
> > 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.
> 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.
> (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.
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.
> 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.
> 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.
> > 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.
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.
> 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.
> 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?
This is a kind of situation where a separate protocol definition may be ok.
> 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.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> Jochen Schmidt <···@dataheaven.de> writes:
>
> > Kent M Pitman wrote:
> >
> > > 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.
Wade
In article <············@news3.cadvision.com>, Wade Humeniuk wrote:
>
> "Kent M Pitman" <······@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).
--
Kevin Rosenberg
·····@rosenberg.net
"Wade Humeniuk" <········@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".
Kent M Pitman wrote:
> Jochen Schmidt <···@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.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@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 wrote:
> Jochen Schmidt <···@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?
ciao,
Jochen
--
http://www.dataheaven.de
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...
--
http://www.dataheaven.de
From: Duane Rettig
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <4pu2eshg9.fsf@beta.franz.com>
Jochen Schmidt <···@dataheaven.de> writes:
> Kent M Pitman wrote:
>
> > Jochen Schmidt <···@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.
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 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Jochen Schmidt <···@dataheaven.de> writes:
>
> > Kent M Pitman wrote:
> >
...
> > > 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.
From: Duane Rettig
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <4g0391rlj.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Jochen Schmidt <···@dataheaven.de> writes:
> >
> > > Kent M Pitman wrote:
> > >
> ...
> > > > 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 side,
and must be weighed carefully against the advantages of the change.
At Franz, we usually try to provide a compaibility package for
interfaces that must change dramatically. For example, several years
ago we changed our foreign-function interface drastically (to use the
new defining macro ff:def-foreign-call), but even today we have users
whose code still refers to the old ff:defforeign defining function
(yes, it is essentially a fuunction, not a macro, which contributes to
only a small part of its many problems).
--
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 ·····@Franz.COM (internet)
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.
Jochen Schmidt wrote:
<snip>
> > 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.
>
> ciao,
> Jochen
>
> --
> http://www.dataheaven.de
From: Erik Naggum
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <3224437278089234@naggum.net>
* Marco Antoniotti <·······@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.
///
--
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.
Erik Naggum <····@naggum.net> writes:
> * Marco Antoniotti <·······@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.
Oooops, you are right, of course.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Erik Naggum <····@naggum.net> writes:
> * Marco Antoniotti <·······@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.
In Maclisp, we sometimes did weird stuff like
#+LISPM TV: CLEAR-SCREEN
in order to use a function named CLEAR-SCREEN in non-Lispm and TV:CLEAR-SCREEN
onthe LispM. Although that trick relied on the fact that the LispM (at least
in Zetalisp) didn't have a :/:: distinction--exporting was irrelevant, so
TV:(FOO BAR BAZ) meant the same as (TV:FOO TV:BAR TV:BAZ). The reader would
just bind the package and call READ. So you could put a space in there with
no ill effects.
There were also some historical confusions over whether #+3600 [a symbolics
model number) were supposed to look for feature 3600 (an integer) or
\3600 in *features*. Curiously, some implementations felt that :3600 would
be better because they thought it would be parsed as a symbol, but the LispM
parsed it as a number anyway. So they got into writing #+:3600 thinking this
would make it be a symbol, and t hen they wrote #+:CMU or #+:DEC to balance
this. It was all bogus because it didn't change a thing to add the : notation.
Kent M Pitman <······@world.std.com> writes:
> In Maclisp, we sometimes did weird stuff like
>
> #+LISPM TV: CLEAR-SCREEN
In Maclisp people also did weird stuff like this:
{(only-for PDP-10)
... expressions of some sort ...
}
The curly-brace thing is also used in some cases like this:
{(divert-documentation-to somewhere)
... documentation of some sort ...
}
Unsurprisingly there is some read-table hackery in CLIM which uses the
curly brace in a similarly creative way.
But what exactly what did the curly brace do? Is it the intellectual
predecessor to the #+ and #- facilities in Common Lisp?
Carl Shapiro <·············@panix.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > In Maclisp, we sometimes did weird stuff like
> >
> > #+LISPM TV: CLEAR-SCREEN
>
> In Maclisp people also did weird stuff like this:
>
> {(only-for PDP-10)
>
> ... expressions of some sort ...
>
> }
>
> The curly-brace thing is also used in some cases like this:
>
> {(divert-documentation-to somewhere)
>
> ... documentation of some sort ...
>
> }
>
> Unsurprisingly there is some read-table hackery in CLIM which uses the
> curly brace in a similarly creative way.
>
> But what exactly what did the curly brace do? Is it the intellectual
> predecessor to the #+ and #- facilities in Common Lisp?
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. So what
a lot of people do is to come up with something that works in a more
case-like fashion.
Some other people have written macros like
(feature-case
((or Genera LispWorks) (system:blah))
((or clisp allegro) (excl:blah)))
but these can't work becuase the reader can't even read the bad cases so you
STILL have to put #+/#- as in:
(feature-case
((or Genera LispWorks) #+(or Genera LispWorks) (system:blah))
((or clisp allegro) #+(or clisp allegro) (excl:blah)))
But what some people write is instead
{(or Genera LispWorks) (system:blah)
(or clisp allegro) (excl:blah)
otherwise (cl-user::blah)}
I don't know if that's the kind of thing CLIM has, but it's illustrative
of the kind of thing one might do..
Kent M Pitman <······@world.std.com> writes:
> Did it allow for multiple cases?
I am not sure. I have never been a user of Maclisp, I have only read
the source code. But, I do remember there being chunks of code which
looks like the function below, where { and } are used to enclose both
documentation (always prefixed with a "--") and conditionalized chunks
of code. I don't think there is any sort of implicit "else" clause
within the { expression . forms } clauses used to conditionalize code.
(defun xxx (yyy)
{-- this is documentation }
{(only-for Lispm)
(*catch zzz-tag (funcall yyy))}
{(except-for Lispm)
{(except-for PDP-10)
(catch (funcall yyy) zzz-tag)}
{(only-for PDP-10)
(lap-a-list
...
> I don't know if that's the kind of thing CLIM has, but it's illustrative
> of the kind of thing one might do..
Yes, the implementors of CLIM made extensive use of a #{ } read macro
which allows one to do things like:
(defun do-something (x)
#{
Lucid (lcl:do-something x)
Genera (lmfs::do-something-really-obscure x)
Minima (minima:do-something x)
otherwise (warn "No implementation of DO-SOMETHING for this system.")
}
)
Fun stuff!
Carl Shapiro <·············@panix.com> writes:
> I am not sure. I have never been a user of Maclisp, I have only read
> the source code.
..and the source code which was avaliable to me at the time was a very
limited subset of Maclisp.
From: Erik Naggum
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <3224454424845597@naggum.net>
* 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:
(defmacro maybe-provide-feature (feature &body body)
(when body
`(progn ,@body (pushnew ,feature *features*))))
Then we could simply wrap the above example in like this:
(maybe-provide-feature :momble-frotz
#+(or Genera (and (not Win32) Franz)) (foo)
#+(and CLIM (not PDP10)) (bar)
#+(or (not CLIM) linux) (baz))
#-mumble-frotz
(error "mumble-frotz is unavailable on this system") ; or whatever
///
--
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.
Erik Naggum <····@naggum.net> writes:
> (defmacro maybe-provide-feature (feature &body body)
> (when body
> `(progn ,@body (pushnew ,feature *features*))))
>
> Then we could simply wrap the above example in like this:
>
> (maybe-provide-feature :momble-frotz
> #+(or Genera (and (not Win32) Franz)) (foo)
> #+(and CLIM (not PDP10)) (bar)
> #+(or (not CLIM) linux) (baz))
>
> #-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:
(defmacro blah-blah ()
(or #+(or foo bar) '(foo)
#+(or bar zing) '(baz)
(error "Unimplemented.")))
or
#.(or #+(or foo bar) '(foo)
#+(or bar zing) '(baz)
(error "Unimplemented."))
One could even do:
(defmacro try-implentations (functionality &rest options)
(or (find-if #'identity options)
(error "Unimplemented: ~A" functionality)))
(try-implementations "Blah blah"
#+(or foo bar) (foo)
#+(or bar zing) (baz))
From: Erik Naggum
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <3224499472669088@naggum.net>
* Erik Naggum
> (defmacro maybe-provide-feature (feature &body body)
> (when body
> `(progn ,@body (pushnew ,feature *features*))))
>
> Then we could simply wrap the above example in like this:
>
> (maybe-provide-feature :momble-frotz
> #+(or Genera (and (not Win32) Franz)) (foo)
> #+(and CLIM (not PDP10)) (bar)
> #+(or (not CLIM) linux) (baz))
>
> #-mumble-frotz
> (error "mumble-frotz is unavailable on this system") ; or whatever
* Kent M Pitman <······@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.
In article <···············@shell01.theworld.com>,
Kent M Pitman <······@world.std.com> writes:
> Erik Naggum <····@naggum.net> writes:
>
>> * Marco Antoniotti <·······@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.
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <ey3u1rtek3t.fsf@cley.com>
* Thaddeus L Olczyk wrote:
> References on how to use #+ #- or any of the # constructs.
> Please don't say CLHS, CLTL.
#+ and #- do read-time conditionalisation.
#+<fc> x causes the reader to read the next form (here x) only if <fc>
#(see below) is true, and otherwise to skip to the following form. #-
#causes it to read it only if it is false.
<fc> is either a symbol which is tested by seeing if it is a member of
*FEATURES*, or a boolean combination of such symbols. There is some
complexity concerning what package is current when all this happens, I
think it's quietly safe to assume that it's the keyword package and
then gloss over how booleans work.
Thus:
(progn
#+(or com.cley/debug com.cley/verbose) (format *debug-io* "~&eek~%")
(explode-world))
will, if *FEATURES* contains :COM.CLEY/DEBUG or :COM.CLEY/VERBOSE, be
read as
(progn
(format *debug-io* "~&eek~%")
(explode-world))
and otherwise as
(progn
(explode-world))
It's OK to have forms which are only semi-legal in code so long as
they are skipped. In particular symbols on non-existent packages are
OK, so something like:
#+allegro (excl:foo)
is OK, so long as anything which has :ALLEGRO on its features also
exports the symbol FOO from EXCL.
There is more to it than this (I've glossed stuff), and,
actually, the spec is worth reading and pretty clear.
--tim
From: Erik Winkels
Subject: Re: #+,#- etc. (Re: Behaviour of #'directory)
Date:
Message-ID: <87vgc9slxz.fsf@xs4all.nl>
······@interaccess.com (Thaddeus L Olczyk) wrote:
>
> References on how to use #+ #- or any of the # constructs.
Check the sources of the CLOCC. For example src/port/net.lisp
http://clocc.sourceforge.net/
The following of course you will not be able to use (it is for CMUCL
for the letter but it could be useful:
(defun scan-dir (root &optional (items '()))
(let ((d (unix:open-dir root)))
(loop for x = (unix:read-dir d)
while x
do (let ((f (concatenate 'string (unix::directory-name d) "/" x)))
(case (unix:unix-file-kind f)
(:directory (unless (or (equal "." x) (equal ".." x))
(scan-dir f (cons x items))))
(:file (when (equal x "phys") (insert-phys f items))))))))
--
Vladimir Zolotykh
"Andre Koehorst" <··········@mmi.unimaas.nl> wrote in message
·················@rl0001.unimaas.nl...
> I'm having problems figuring out the behavior of directory. I'd like to use
> the return value of #'directory to traverse a directory-tree. It seems that
> calling directory recursively on pathnames in the returned list,
> corresponding to subdirectories, returns a list containing themselves,
> instead of a listing of their contents. See e.g. the following output (LW
> 4.2 pro under win2000):
>
> CL-USER 5 > (directory #p"D:/download/")
> (#P"D:/download/www/" #P"D:/download/lisp/" #P"D:/download/articles/")
>
> CL-USER 6 > (car *)
> #P"D:/download/www/"
>
> CL-USER 7 > (directory *)
> (#P"D:/download/www/")
>
> CL-USER 8 > (directory #P"D:/download/www/")
> (#P"D:/download/www/xml/" #P"D:/download/www/standards/"
> #P"D:/download/www/sgml/"
> #P"D:/download/www/html-tools/" #P"D:/download/www/ftp/"
> #P"D:/download/www/browsers/")
>
> Can somebody explain this behavior to me? I guess it has something to do
> with the results being truenames, but I cannot figure it out.
There are two things going on here. Firstly, truenames in LW are always fully
specified, i.e. empty components contain :UNSPECIFIC rather than NIL, because
that helps to prevent ambiguities. Secondly, DIRECTORY is defined by ANSI to
return just one pathname if the argument is a non-wild pathname that exists in
the file system.
To make a pathname suitable for inner calls to DIRECTORY you can do
(make-pathname :name nil :type nil :version nil :defaults outer-dir)
or the (LW specific) call (LW:PATHNAME-LOCATION outer-dir).
Alternatively, the :WILD-INFERIORS directory component could be used, but I
don't think that is guaranteed to be portable either.
E.g. (directory "D:/download/www/**/")
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply
"Martin Simmons" <······@xanalys.com> writes:
> "Andre Koehorst" <··········@mmi.unimaas.nl> wrote in message
> ·················@rl0001.unimaas.nl...
> > Can somebody explain this behavior to me? I guess it has something to do
> > with the results being truenames, but I cannot figure it out.
>
> There are two things going on here. Firstly, truenames in LW are always fully
> specified, i.e. empty components contain :UNSPECIFIC rather than NIL, because
> that helps to prevent ambiguities. Secondly, DIRECTORY is defined by ANSI to
> return just one pathname if the argument is a non-wild pathname that exists in
> the file system.
>
> To make a pathname suitable for inner calls to DIRECTORY you can do
>
> (make-pathname :name nil :type nil :version nil :defaults outer-dir)
Would :name :wild :type :wild :version :wild not be more portable? I
mention this because currently SBCL doesn't treat a pathname of the
above form as wild.
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
"Christophe Rhodes" <·····@cam.ac.uk> wrote in message
···················@cam.ac.uk...
> "Martin Simmons" <······@xanalys.com> writes:
>
> > "Andre Koehorst" <··········@mmi.unimaas.nl> wrote in message
> > ·················@rl0001.unimaas.nl...
> > > Can somebody explain this behavior to me? I guess it has something to do
> > > with the results being truenames, but I cannot figure it out.
> >
> > There are two things going on here. Firstly, truenames in LW are always
fully
> > specified, i.e. empty components contain :UNSPECIFIC rather than NIL,
because
> > that helps to prevent ambiguities. Secondly, DIRECTORY is defined by ANSI
to
> > return just one pathname if the argument is a non-wild pathname that exists
in
> > the file system.
> >
> > To make a pathname suitable for inner calls to DIRECTORY you can do
> >
> > (make-pathname :name nil :type nil :version nil :defaults outer-dir)
>
> Would :name :wild :type :wild :version :wild not be more portable? I
> mention this because currently SBCL doesn't treat a pathname of the
> above form as wild.
Yes, maybe, but beware that some functions such as PROBE-FILE are expected to
signal an error for wild pathnames so this isn't a good general-purpose
representation of a directory.
The spec for PATHNAME-MATCH-P kind-of implies that DIRECTORY should treat NIL
the same as :WILD.
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply