Hi everyone...

        first of all i want to thank you all for your answers, i have make disappear the "." from my
procedure (our-reverse) and will check other thinks, but know i have a question, in one mail i'm told
why i don't use if instead of cond, this is basically because in the book i'm studing lisp at least till chapter
four they don't use it; is it that cond is know like deprecated or something ?? i mean because i think if you
have something like:

        (cond (.....) (.....) ...
                      (......) (....)....
                      (.....)....     .....)

        that is better that something like:
        (if (...) ...)
        (if (......) .....)
        .......

        (I don't write the if's sintactically right because as i said i still have not use it :) )
        We could use else's too (if there's else in lisp... i suppose there is)
        But of course i think that if you have just one condition it's better write:
        (if (....) ......)

        that just put (cond (....) ....)....i mean it looks better the if but i suppose you get the same with any
them...... What do you think ????

        Thanks.....

i found lisp to be very weird (since i am very used to c, fortran,
assembly &c).  i basically had to read the whole of grahams book, let
it sink in, and read it again.  *then* i started to program in lisp.
i am still limping along.  the standard language pathways in my brain
need a long time to be overridden (maybe this is what the zen koans
are supposed to help with).

so given that i am a newbie like yourself (i didn't do much lisp
before december), this may not be the authoritative word on the
subject.

if you have a simple if (only a then clause), use when

(when (it-is-time)
  (do-some-thing))

(when (it-is-time)
  (do-first-thing)
  (do-another-thing))

when has an implicit progn, i.e., you can simply list all the stuff
you want to do.

use unless when you want to reverse the sense of condition (an if with
only an else part).

(unless (you-have-it-covered)
  (cover-it))

(unless (x ... is the same as (if (not (x ....

unless also has an implicit progn.

for decisions with two options, i use if.

(if (decision)
    (then-part)
  (else-part))

notice that you can't just make a list of things or the then-part
would bleed over into the else.

(if (decision)
    (progn             ; the then part
      (do-1)
      (do-2))
  (else-form))

you would need a progn for a list in the else form.

use cond when you would have a bunch of nested ifs.

(defun my-sign-1 (x)
  (if (zerop x)
      (princ "zero")
    (if (> x 0)
        (princ "positive")
      (princ "negative"))))

(defun my-sign-2 (x)
  (cond
   ((zerop x) (princ "zero"))
   ((> x 0) (princ "positive"))
   (t (princ "negative"))))

here, i prefer the cond format, but sometimes the if can be good too
(if it doesn't get too deep).

to sum up, it's not that cond is bad.  it's just wordy (or paren-happy
if you like) and therefore not very clear in the common simple cases.

when, if and unless are often (always?) macros and get made into cond
expressions for you.

(if x
    (then-form)
  (else-form))

gets made into

(cond
  (x (then-form))
  (t (else-form)))

by an expansion.

i didn't mean to flame you about the if.  i just think that lisp gives
a bad impression when you are exposed to cond first and do not see the
simpler when, unless and if formats.

similarly, some problems are nicely solved by recursion, but some you
will find easier to do using dolist or dotimes or perhaps loop.
forcing recursion down your throat when it doesn't fit isn't a good
way to sell lisp.  (although i do understand that if you're familiar
with do loops, you may keep applying the dotimes hammer even in the
face of a screw.)

i think common lisp is a nice language.  the 1970s vintage lisp
presented in a lot of classrooms leaves a bad impression and only
serves to make people think lisp is awkward, slow and useless.  this
is not the case.

hope this helps.

also when and unless are nice in that you know that they only take one
clause.

these two work identically

(when x (then-form))

(if x (then-form))

however, in the first case you know immediately that there's no
else-form lurking about (easy to see here, but you can immagine if the
then-form is complicated...).

this removes the need for checking indentation, hoping indentation is
right and resorting to counting parentheses just to see if the `if'
has an else-part or not.

therefore, as a matter of style, i use `when' whenever possible and
`if' when i need both `then' and `else' clauses.

(if (listp x) ...)

Or just use a single construct

(if {condition}
  then  {then-form}*
 [ elseif {condition} {then-form}* ]*
 [ else {else-form}* ]
  )

i.e.
(if test
  then (print "the test was true")
 elseif (not test)
  then (print "the test was false")
  else (print "the test was using fuzzy logic")
       (sqrt -3) ;; return sqrt of -3
  )

and most programmers would understand how it works...

;)

    Kelly> (if {condition}
    Kelly>   then  {then-form}*
    Kelly>  [ elseif {condition} {then-form}* ]*
    Kelly>  [ else {else-form}* ]
    Kelly>   )

    Kelly> i.e.
    Kelly> (if test
    Kelly>   then (print "the test was true")
    Kelly>  elseif (not test)
    Kelly>   then (print "the test was false")
    Kelly>   else (print "the test was using fuzzy logic")
    Kelly>        (sqrt -3) ;; return sqrt of -3
    Kelly>   )

    Kelly> and most programmers would understand how it works...

    Kelly> ;)

While I understand what Kelly is trying to do, this reminds of the
days when (Turbo) Pascal was the "in" language and C was the new kid
on the block.  I've seen code for C like

#define BEGIN {
#define END }

and so on.  Those familiar with C couldn't read it because it broke
their expectations, and those familiar with Pascal couldn't read it
either because it wasn't really Pascal.

If you're going to learn a language, *learn* the language![1][2]

Ray

Footnotes:
[1]  With apologies to the funny Hardy's "Go all out" commercials,
     which aren't being made anymore.

  *laugh*  even I don't think Scheme is _that_ braindamaged a language.

Oh yes. And w/o #+, #-supported by your Scheme implementation, forget it.
I also had to add that (to Gambit too). Which reminds me that Matt Flatt
oposed
with reason to *features*, suggesting the thing be based on a `parameter'
instead.
So I guess that writing *features* directly in your program is equally bad.

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira acm "You know the rest"
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

To me, if the current package uses the COMMON-LISP package, CL:IF would
indicate that IF has been shadowed by the current package, and the time
has come to use the original IF.  (Of course, this might be more likely
to happen with other symbols from COMMON-LISP than IF.)

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

Anyway, I was not objecting but adding another case which seemed to me to
be left unmentioned.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

It's not just CL:IF et al. but also CL:DO.
And CL:CAR, CL:CDR, CL:CADR etc. when
you might be accessing NIL.

Maybe the real issue here is that, in general, both communities
just go their own way and they don't care about each other.

Maybe it's time to specify a `Core Lisp' that contains only the barebones
to implement both Scheme and CL (the F#, Lisp-1, continuation issue is
left unspecified to you can choose which way to go).
Perhaps that way we would start seeing new CL compilers, instead of just
one Scheme variant after the other. CL is perceived as `too big', but in
fact, you can just take all the high-level stuff from CMUCL (BTW, factorizing

CMUCL so that such a thing becomes pretty plug-and-play would be a good too).

And in an ideal world, CL vendors would just maintain the common CMUCL
library
(calling functions like %DONT-USE-THIS-IT-MIGHT-GO-AWAY would be OK),
to avoid duplication of effort so they have more time/money to spend on their

proprietary compilers. If a certain CL can just use the open implementation
for
something, instead of having to provide another primitive for performance,
that
means the compiler should be also better at your own code
(no benchmark-style tricks, please).

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

You are free to design and document and implement and sell your new
massively underspecified core language that does not commit itself in
anything that either of the two present communities does not buy. And
why not generalize further, to include other interesting languages?

When will I be able to write  an NT DLL (ugh) in Scheme? When will a
Haskell program be free to use the clipboard (double ugh)? When will I
be able to use Smalltalk to write an X based mail reader? When will I
be able to cleanly mix-n-match code from code in CLOS, C++ and CAML in
one app? Not today, that's for sure.

True, most compilers and environments have some capacity for importing
libraries, but this is far too limited. We need to have tools that can
be treated the same as others, that are as integrated with the
platform they run on as possible. One of the reasons that these
languages are seen as inefficient is because they try to exist so much
in a vaccuum; even though it is possible to write optimizing LISP
compilers that far exceed any for C++, C++ runs better on, say, Linux,
because it fits the system better. The only real innovation in Java is
that it is an interpreted language that still behaves (for the most
part) like a native one, while even compiled LISP usually needs
additional support that makes such transparency impossible.

An unreasonable man tries to change his environment.
Therefore only unreasonable men will produce changes.
In my view, that change is to have another operating system where
reasonable men can use Lisp.

On topic, a Core Lisp doesn't address the real needs in my view,
which is to generate better applications faster and get more
people writing those applications.
Even a $300 palmtop computer has 8mb today.  What great advantage
is there in fitting a lisp implementation in 1mb?

The big issue is getting more people to program in Lisp,
and that means making it easier for them to learn and use Lisp,
and to give them some advantage for doing so.

[snip]

<quote>
Integration is God

In the worse-is-better world, integration is linking your .o files together,
freely intercalling functions, and using the same basic data
representations. You don't have a foreign loader, you don't coerce types
across function-call boundaries, you don't make one language dominant, and
you don't make the woes of your implementation technology impact the entire
system.

The very best Lisp foreign functionality is simply a joke when faced with
the above reality. Every item on the list can be addressed in a Lisp
implementation. This is just not the way Lisp implementations have been done
in the right thing world.

The virus lives while the complex organism is stillborn. Lisp must adapt,
not the other way around. The right thing and 2 shillings will get you a cup
of tea.
</quote>

If you want to use something else, please do so.  Lisp is an excellent tool
for solving certain kinds of problems.  If the tool doesn't match your
problem, choose one that does.

<http://www.dejanews.com/[ST_rn=ps]/dnquery.xp?search=thread&recnum=%3cMPG.e
240a6bb1556995989...@news.demon.co.uk%3e%231/1&svcclass=dnserver>

As Erik pointed out in several postings to the recent "Barriers to Lisp
Acceptance" thread, you can influence the behavior of your Lisp vendor by
committing your own resources (time and money) to get the things you really
want.  Or you can take whatever you get for "free", go wherever that
particular ride takes you (where _did_ you want to go today? :\ ), and whine
about the destination.

--
David B. Lamkins <http://www.teleport.com/~dlamkins/>

Scheme took the `single namespace way'. That breaks CL code but I don't
care.
It doesn't happen too often, and I don't mind occasional fix, because
Scheme is right
here, and, above all, Scheme is supposed to be _clean_.
The #f,NIL thing is probably the most religious Lisp issue ever. It just
broke
with lisp tradition, a certain style. How would you like a lisp that
replaces
'(" with "["? Doesn't seem very important. You can automatically translate
that,
and you could even keep a repository in `norma form'. But it's just a
pain. And
does not fix anything.
What does #f fix? I don't think traditional lisp is wrong. It is
consistent with lambda calculus,
i.e., `null is a subtype of all types'. So NIL is a boolean, different
from #t. But there are 2 boolean
values, so NIL == #f (alternatively, NIL could be #t and everything else,
false).

In the same sense that lisp syntax generates a nice and simple coding
style (which everyone here likes),
NIL == #f, (CAR NIL) == NIL, (CDR NIL) == NIL also do. Following the
above, NIL
is a strange thing, and its little peculiarities make it interesting and
probably useful.

But I think future standards should be based on
L<NIL=#t, 1, x>
Scheme gives up on #f. CL gives up on the `f property'.

It is not supposed to be practical to program in. `user-level' forms
take care of that. Of course, nothing prevents a language implementor
to optimize the compiler by adding a CLOS kernel to it, or whatever
else he sees fit (futures, OCCAM-style channels, etc.).

As an example, the template would definitely not specify DO (Scheme's
and CL's are incompatible) but TAGBODY.

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

I also got used to flames, as people have been telling for years that I
can't be doing this stuff. The second line of my sigfile is flamebait, if
you've never used Lisp. I've wasted too many years trying to communicate
with closed minds, or searching for open minds with a job to offer.

This isn't meant to be a troll, just a small point. It sound like the
ultimate whine, and I won't be suprised if it does. It can get a little
lonely out here in the wilderness. It helps to find a newsgroup like
this, full of people who understand Lisp. I can't describe how wonderful
it was to discover this oasis in the desert, back in 1992. I found that I
wasn't not as mad as most people think. After all, they think the same
thing about _anyone_ who uses Lisp.

So, now I don't care anymore. After more than 15 years, I've given up
trying to be a professional programmer. I'll accept being an unemployed
Lisp programmer, as it beats the hell out of the alternatives. No amount
of money can compensate for that kind of agony. Instead, I'll write the
code I know how to write, and take all the ecstasy I can handle.

Q. Does LWW support DLLs?

A. Yes. LWW can now generate standalone DLLs, as well as loading and executing
   DLLs via the FLI.

This Harlequin's Lispworks for Windows.

cheers, Bernhard

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

In any case, the tougher nut to crack is the reverse
directon: the ability to run CL code in Scheme (either
via an embedding or through a filter program).  I don't
think it is technically undoable, but it will require a
good bit of clever but tedious and thankless coding,
and it does not look like enough people will find use
for it to justify the pain.

I'd have use for such a package.  It'd be nice if Scheme and Lisp code
could co-exist, especially in the GNU world.  I myself am a pretty
hard-core CL fanatic, but most others working on GNU stuff gravitate
towards Scheme (er, GUILE), and I can see people wanting to mix code
in a non-painful fashion.