From: Sam S. <sd...@gn...> - 2004-06-22 13:59:03
|
Suppose a function FOO-BAR in module ZOT calls a function foo_bar() in library zot.so. Function foo_bar() expects a flags argument - an OR of zero or more CPP constants ZOT_BAZONK, ZOT_FOO_SLONG, ZOT_FEP_BLICKET. These flags are passed to ZOT:FOO-BAR as boolean keyword arguments. The question is: how should these keyword arguments be named? 1. :ZOT_BAZONK :ZOT_FOO_SLONG :ZOT_FEP_BLICKET most obvious, but not too lispy, and somewhat longish. 2. :BAZONK :FOO_SLONG :FEP_BLICKET shorter, but not too lispy either 3. :BAZONK :FOO-SLONG :FEP-BLICKET looks best and the most lispy opinions? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Booze is the answer. I can't remember the question. |
From: Bruno H. <br...@cl...> - 2004-06-22 14:26:37
|
Sam wrote: > The question is: how should these keyword arguments be named? > > 1. :ZOT_BAZONK :ZOT_FOO_SLONG :ZOT_FEP_BLICKET > most obvious, but not too lispy, and somewhat longish. > > 2. :BAZONK :FOO_SLONG :FEP_BLICKET > shorter, but not too lispy either > > 3. :BAZONK :FOO-SLONG :FEP-BLICKET > looks best and the most lispy > > opinions? I would vote for 3, if the symbols have no property specific to ZOT. If there is such a property, for example you want to have the symbol-value reflect the numerical value of the CPP constant or if they are part of a FFI:DEF-C-ENUM, then they cannot be keywords: 4. ZOT:BAZONK ZOT:FOO-SLONG ZOT:FEP-BLICKET Bruno |
From: Sam S. <sd...@gn...> - 2004-06-22 15:59:28
|
> * Bruno Haible <oe...@py...t> [2004-06-22 16:16:47 +0200]: > > Sam wrote: >> The question is: how should these keyword arguments be named? >> >> 1. :ZOT_BAZONK :ZOT_FOO_SLONG :ZOT_FEP_BLICKET >> most obvious, but not too lispy, and somewhat longish. >> >> 2. :BAZONK :FOO_SLONG :FEP_BLICKET >> shorter, but not too lispy either >> >> 3. :BAZONK :FOO-SLONG :FEP-BLICKET >> looks best and the most lispy >> >> opinions? > > I would vote for 3, if the symbols have no property specific to > ZOT. If there is such a property, for example you want to have the > symbol-value reflect the numerical value of the CPP constant or if > they are part of a FFI:DEF-C-ENUM, then they cannot be keywords: > > 4. ZOT:BAZONK ZOT:FOO-SLONG ZOT:FEP-BLICKET I thought about it. On one hand, it is nice to export as much as possible. On the other hand, these numeric values cannot be used in any way. there is also another issue: DEFCHECKER in modprep.lisp. right now is follows [1]. I guess if we switch to [3], it would need to be changed. Note also mixed-case constants like "AF_DECnet" in sys/socket.h (DEFCHECKER converts AF_DECnet to :AF_DECNET) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The paperless office will become a reality soon after the paperless toilet. |
From: Pascal J.B. <pj...@in...> - 2004-06-24 13:52:02
|
Sam Steingold writes: > > * Bruno Haible <oe...@py...t> [2004-06-22 16:16:47 +0200]: > > > > Sam wrote: > >> The question is: how should these keyword arguments be named? > >> > >> 1. :ZOT_BAZONK :ZOT_FOO_SLONG :ZOT_FEP_BLICKET > >> most obvious, but not too lispy, and somewhat longish. > >> > >> 2. :BAZONK :FOO_SLONG :FEP_BLICKET > >> shorter, but not too lispy either > >> > >> 3. :BAZONK :FOO-SLONG :FEP-BLICKET > >> looks best and the most lispy > >> > >> opinions? > > > > I would vote for 3, if the symbols have no property specific to > > ZOT. If there is such a property, for example you want to have the > > symbol-value reflect the numerical value of the CPP constant or if > > they are part of a FFI:DEF-C-ENUM, then they cannot be keywords: > > > > 4. ZOT:BAZONK ZOT:FOO-SLONG ZOT:FEP-BLICKET > > I thought about it. > On one hand, it is nice to export as much as possible. > On the other hand, these numeric values cannot be used in any way. I'd agree if it was numeric arguments. (That would even be: 5. ZOT:+BAZONK+ ZOT:+FOO-SLONG+ ZOT:+FEP-BLICKET+ But instead of writting: (zot:foo-bar (+ ZOT:+BAZONK+ ZOT:+FEP-BLICKET+)) Sam wants to write: (zot:foo-bar :BAZONK t :FEP-BLICKET nil) So I guess the best is indeed to put them in KEYWORD and option 3 is tastier. -- __Pascal Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him. -- Robert Heinlein |
From: lin8080 <li...@fr...> - 2004-09-16 09:49:00
|
Hallo Running Aurox 9.4 (red-hat clone) with amd-550-cpu on a gigabyte-board with ali-chipset and 128mb ram. Some scsi hds to keep things easy. Found on suse 8.2 dvd a clisp-2.30-36.i586.rpm and installed it. It say: libcrypto.so.0.9.6 and libssl.so.o.0.6 is needed. (else NOKEY, KeyID 9c800aca, when important). But it installs without this and runs by typing clisp in the console-windows from kde 3.2. (As I also tested other linux-systems with cl, all want some extra software files in order to run correct, (suse 7.3 with cl2.28 over 100 - record) only rpms that comes with the distribution will not do so) Now. Searching for clisp components in a linux os shows, the installed files are mixed (will not say wildly) among the systems usualy install paths. Docs, executable, .rc initfile, newclx, impnotes and at least a gz hyperspec (seperat), (.. scripts, other modules and what else a user may create) all stored in different paths. Doing the same with win98, (download the 2.30.zip from sourceforge in May04) the install needs a dll-file (wldap32.dll?) and a start.bat (which creates a start.pif) and it works (even without cygwin and co.). The point is, I can place all in one folder, where I want. (by default, also I do that with gcl.rpm (2.6 newest), and no, I never compile anything, this is too horrible and time-invest is not so profitable for me) Look arround in the Linux distris and see, how it is handeled different. See forward and note, more versions will come up. And this leads me to type this mail. (of course I say it 3 times stronger, to make my point clear) Clisp is a seperat software, it is not part of the linux world - but linux can be part of the cl-world. You can see, on a linux os clisp runs out of order and is easyly mixed nearly everywhere. This is not, what I mean is good for clisp. You may think about this and hopfuly do something ... (sure, there are links and pipes and gagaga) My wish is to keep cl-parts together as stand-alone software. This is not only win and linux, there are coming up 64-bit versions, rumors about lisp-os going on, amiga-version in the past, some apple portables, interactions with other soft-packages and what ever the future will make or a user will do. When I type here, there is an other sensible part I want to point out. Look in the history files of new cl-versions. Present for me is back to 1999, (2.24). Every update I saw the sentence: "... need to compile old fas files for the new version..." Come on, is that realy neccesarry? Please write a small routine in the next update that informs the user that he/she is loading an older version fas file and spend a 'recompile (yes-no)' to it. (sounds easy...) stefan repeat reading readmes till next update is comming :) |