In any projects one of the forms of compensation for work well done is
bragging rights.  He stole from his coworkers who did the work by
claiming he did it and he stole from franz by claiming he bore the
monatery hardship of funding this project with his time when franz
paid him to do the work.  Theft is theft and durring the course of
this discussion the only time I can remember him even attempting to be
civil is tuesday morning his time, after he probably got to work or
work calle him and had a little chat about what the fuck he was doing
this weekend,  He did make some emotional appeals after editing posts
for content to try to gain support but I do not considder that civil
but self serving nothing more or less.

Janos Blazi

marc

ps I am just learning lisp so there may be a stupid syntax error in
the above.  

That being said...

 > this discussion the only time I can remember him even
attempting to
be > civil is tuesday morning his time, after he probably got to work or

ObPersonalPreference: I'd still rather be using COND anyway.  AIF (and
a smattering of other anaphoric macros) is about my only normal use of
"syntax" macros.

-dan

--

  _I_ would consider saying that I donated something only if I had funded
  it myself, and since I have in fact funded and donated a lot of stuff
  over the years, to university computer clubs, to the SGML community, etc,
  but I did not use "donate" when in fact somebody else donated money to
  fund my work.   I expect the same standard of honesty from others when
  referring to what one gives away.  If it is not yours to donate, it is a
  bad idea to say that you did.  This applies to the funding, not the work.

  If they worry so much about upper-case versus lower-case, there are two
  easy steps: set *print-case* to :downcase and make the keyword argument
  :case-insensitive to apropos default to t.  They do neither, but seem to
  want people use their very incompatible version instead.  I have been
  working on a solution that does not destroy conformance at all -- and it
  turns out to be really easy to support in the framework that Franz Inc.
  has already built to support their special set-case-mode.  This is about
  the willingness to remain conforming while making serious changes, or
  lack thereof, to be more precise.

  But as long as we talk about this issue, it is in fact possible to let
  (common-lisp:symbol-name 'foo) return "FOO" and have something like a
  (common-lisp-lower:symbol-name 'foo) return "foo".  This is the kind of
  thing the package system should have been able to deal with, shadowing
  some of the important functions.  The reader needs to be able to deal
  with a parameterization of which functions to call, however, and the
  specification for this will have to be extra-standard.  This means that
  it should probably go in the readtable.  Since the readtable already
  supports everything we need for a lower-case Common Lisp to work, all we
  would really need is the ability to retain the standard functionality in
  addition to the lower-case versions.  This should be doable without
  having to break anything, if only you are willin to look for it.  That
  would make it possible to intermix standard and lower-case code, too,
  which is currently impossible with the separated schemes used today.

I think making the source available under an open-source license which
allows, for instance, people to port it (as they have done) to other
implementations freely is rather different than `just happening to
cost nothing' and more than adequate to classify it as open source.

I don't want to take any sides in this whole battle, but it's kind of
annoying that some people seem to be so entranced by the jkf-bashing
that they're making all sorts of misleading statements like the one I
quote above.  I guess I should expect this on usenet by now though...

The more I looked into the two languages, I started asking friends who
are developers with more experience than me who are using Delphi
(pascal - which I have used before) and VB (because of where they are
working now), about Python and Lisp.  They admitted to knowing little
about Python except that it was a scripting language which seemed to
imply saying it all (something about limited access to interfaces
which was greek to me).  Lisp on the other hand was considered a
really cool language but useless for anything except manipulating
strings.  I have to admit that this threw me off, and I was determined
to learn lisp if for no other reasons than for the way it was
improving my approach to development, and then move onto Python for
practical purposes.

I am glad that I have stuck it out as I have been finding that
although so far I haven't managed to start digging into the system
part of the implementations I have been looking at, the way in which
it allows me to code robust algorithms, and build in steps means that
I am going to be moving hell and high water to keep it as the core of
my applications, and the power is amazing...

Finally my point:   That offhand comment I took seriously because of
its source, this was an experienced developer, and if I had not been
of a sufficiently impractical bent to have spent a lot of money and
years pursuing the study of philosophy, I would have dropped looking
farther into Lisp.  It is an amazing language and facility but suffers
from some seriously bad press as an impractical language that all
these eggheads are using to try and create artificial intelligence
with, and take over the world or get us all killed in the
process(;-)).  Who would have thought it was a powerful and practical
language that could do things other languages only dream about.  Even
now I have been secretly studying it on my own time, and when I run
across a cool way of doing or thinking about a problem I have a huge
translation problem to recreate the solution at work in the languages
I have to use there.

Lisp needs a good press core:-)
At the moment as I found out there are people who have gone in
different directions who studied Lisp at uni but never really used it
being the bottom-line on Lisp's practicality, and this is not right.
At the moment I have not managed to be good enough to create anything
practical with it, and am working hard at doing this and then I will
be busy debunking the myths I run into with cold hard code, and
hopefully moving to a job where I can use it all the time.

So I am a recent convert and I hope there are more of me out there and
as I am opinionated I will have no problem telling employers that I
will be able to get that project for them in something they have heard
of, or in 1/3 the time using Lisp.......

God I do go on..

(defun do-one-conversion (....)
  ;; Returns successp, new state, optional comment.
  ;; signals CONVERSION-ERROR if something really bad happens (state
  ;; may be bad)
  (flet ((succeed (new-state &optional comment)
           (return-from do-one-conversion t new-state comment))
         (fail (&optional comment)
           (return-from do-one-conversion nil nil comment))
         (bad (...)
           (error 'conversion-error ...)))
    ....
                 (unless thing-is-ok-p
                   (fail "Thing is not OK..."))
              ....
            (when donep
              (succeed 'fishy "OK, new state slightly smelly"))))

Of course some would argue that I shouldn't write such hairy functions
that I need this kind of internal protocol, but for the system
concerned it was rather hard to see how to do it otherwise (you'd need
to see the code to see why).

(defmacro else (&body body)
  `(progn ,@body))

0. Have IF* do everything that it's currently
spec'ed to do, with the following mods:

1. Make THEN always optional -- which, among other
things, makes (IF* a b) equivalent to (IF a b).

2. If there are no THENs or ELSEs among the IF*-form's
subforms, assume an ELSE after the second subform.
Thus, (IF* a b c) is equivalent to (IF a b c).
Also, (IF* a b c d ...) is eqv to (IF a b (PROGN
c d ...)), as in Emacs.

3. Since IF* is now completely backward-compatible with
syntactically correct uses of IF (see 1 and 2
above), simply call the new construct IF.  

4. People who use the new IF as the old IF won't have a
complaint.  They can only run into problems if their
use of the IF would have been an error in the old IF.
(Minor caveat: THEN and ELSE must be known to be
macro keywords.)  

5. Add several minutes to your life from having avoided
flamage for introducing a new conditional, while
retaining all the features you want to keep you in
a happy condition (!).

6. Re-lose those minutes when users run your code in a
CL that doesn't have the new IF.

You seem to miss the context in which my reply was written.  My
message was among the very first replies, but I guess most of the
thread contents is now "above" my message in the thread.

Try to replace the definition of a special form in your favorite lisp.

If I had exported code which required people to redefine a special
form in their Lisp to run it, I would have been criticized and
correctly.  

        (if x
            (then ...)
            (else ...))

The problem was that the macros were defined just exactly as you have
them above, so there was no enforcement of the syntax at all.  So
things got completely mixed up, and you'd find things like:

        (if x
            y
            (else ...))

and even worse, there was no mechanism to prevent THEN and ELSE just
finding their way into code outside an IF, which they did on occasion
due to editing errors.

All this was apparently because the people who wrote this framework
either didn't understand or didn't want to use the package
system. They wanted you to *have* to write THEN and ELSE (they had a
kind of sub-CL dialect in which you were meant to write), but rather
than defining a SUB-CL package in which they would have their own IF
which would check for the syntax they wanted, they'd just defined
macros like this.

Well, I don't work on that system any more, and this is one of the
things I don't miss.  There were other horrors.

        (let ((then 3))
          (if t then 4))

  I guess I should have "commented" the code and explained why I thought it
  would be an obvious "bad joke", on par with #define BEGIN { in C, but
  which would illustrate that having implicit progns is not such a big deal.

  This might also be a good time to state that I really want to use progn
  in multi-form consequents and alternatives, to increase the readability
  of complex if forms.  That is, we already have all the mechanisms we need
  to identify more complex forms.  And wrapping a single form in a progn is
  real easy with a real editor.  Just like loop forms are hard to navigate,
  so are keyword-based "separators".  But I guess some people want progn to
  go away so hard they just have to reinvent it badly.