Subject: [clisp-list] keyword argument naming poll

From: Sam Steingold <[email-masked]>
Date: Thu Jun 24 06:13:02 2004

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 Haible <[email-masked]>
Date: Thu Jun 24 06:13:02 2004

>    looks best and the most lispy

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 Steingold <[email-masked]>
Date: Thu Jun 24 06:13:03 2004

> * Bruno Haible <[email-masked]> [2004-06-22 16:16:47 +0200]:
>
> Sam wrote:
> 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:
>

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.Bourguignon <[email-masked]>
Date: Thu Jun 24 06:53:00 2004

> 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 <[email-masked]>
Date: Thu Sep 16 02:49:16 2004

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 :)