Especially in the CLOS area, where the language already requires a lot
more type checking than in other parts of CL, I find the behaviour of
the commercial implementation I'm using rather puzzling. Take this
example:

(defclass foo () ())
(defgeneric bla ((self foo) (num integer)))
(defmethod bla ((self foo) arg2 arg3))

The last call raises an error because the method bla doesn't conform
to the generic function's signature. Good.

But when I do this:

(defun bob () (bla (make-instance 'foo) 1 2))

which includes an incorrect call to the same generic function there is
no error and no warning. The environment clearly has the information
to warn me about this error here and now, but it doesn't. Instead, I
or the QA department get an exception when (bob) is called at runtime.

So, I'm not asking for any deep change in Lisp, the language, just
some early warnings from the implementation's compiler about my
frequent blunders :-(

Joachim

  could you give some examples of the types that CMUCL allows that are not
  the ANSI standard?

  that's funny -- I read it exactly that opposite way.  Lispers care about
  typing, including static type information, and because they care, they
  know what kind of costs are involved in them relative to the benefits and
  why the C++ model is so fundamentally braindamaged as to become totally
  unpalatable and useless.  _because_ we value static type information, but
  also know the costs, we have decided against anal-retentive tools, but
  would use tools that can utilize such information productively.  however,
  the kinds of mistakes that you seem to think are so important do not in
  fact occur often enough to be a significant problem, so the value would
  lie in optimization across function calls.  this is dangerous territory
  in an environment where you can change function definitions dynamically.

Try:
http://www.franz.com
http://www.harlequin.com
http://www.corman.net (Free with source-code + 30-day shareware IDE).
http://clisp.cons.org (GNU GPL)

Or my personal recommendation:
http://www.debian.org (get _real_ OS)

then visit franz.com to get the Linux Trial Edition and also grab the
Debian CMU CL packages. If you like visual IDEs there is also
Harlequin's new Linux Personal Edition.

Of course, efficiency is no longer an issue with LISP, the dynamic
comiler technology keeps up well enough with C++ or whatever.

More important issues are things like packaging; many lisp environment
do not compile executables, and many of the ones that do still dont
provide full functionality of the interpreter for the environment, and
so your generated program can lack the features you typically desire
from a LISP program, like the ability to dynamically self-modify, or
allow the user to type in custom algorithms.  This basically means that
a lot of useful programs are undeliverable without including the lisp
environment itself.

Other places where lisp falls severely short currently is the areas that
interest mainstream programmers the most: database access, sockets,
threading, IPC, and 3d graphics.  None of these interfaces are
standardised or even discussed, and while most implementations now have
some or all of these facilities, they are not cohesive in their
interface, and are sometimes poorly documented and incomplete to boot.

Some LISP implementations still do not interface well with other
languages, while "popular" languages (C/C++/Objective-C, Java, Ada,
Pascal) generally have a relatively safe way of communiating between
languages (although the interface definitions in Ada can be fairly
arduous).

LISP's object-oriented paradigm is powerful and yet... It's essentially
dynamic operator overloading, which is about as interesting to an object
modeller as a stack of bricks.  Although this is certainly only an
opinion and perhaps a trend, object orientation is centered on message
passing, while LISP's object orientation is based on function calls
(still).  I won't say its not USEFUL, but its not attractive, and its
not a step forward unless you are writing "toy" applications.

This is only the beginning of a long list of language weaknesses on
LISP.  Its important to realise that each language has its own use, and
LISP as it stands is great for writing small tests of algorithms before
porting them to a real language.

I have a hierachy of classes where I implement some manipulation
methods.

Then I have a separate hierarchy which implements some operation to be
dispatched in terms of the first one.

I can't escape doing the following

class Clazz
{
        type_t do_something(A a);
        type_t do_something(B b);
        type_t do_something(C c);
        type_t do_something(D d);
        ...
        // You get the idea...
        // Suppose you also have A -> B -> C-> D -> as your hierarchy.

        void do_something_appropriate(A a)
          {
                do_something(a);
          }

{
        Clazz clazz = new Clazz();
        B myB = new B();

        clazz.do_something_appropriate(myB);

Now, what do you expect gets printed?

In Common Lisp it is exactly what you'd expect.

Cheers

You claim that CLOS style object orientation is only for 'toy'
systems.

If you went along with my example and did some extra playing around,
you will have noticed that you soon introduce a lot of "tag"
statements (which, AFAIK Java supports much better that C++) in order
to achieve your goals.  You can always claim that I designed my
hierarchies in a poor way, but that is begging the question.

In CL you do

        (defmethod do-somethin ((c clazz) (an-a a)) ...)
        (defmethod do-somethin ((c clazz) (a-b b)) ...)
        (defmethod do-somethin ((c clazz) (a-c c)) ...)

        (defmethod do-somethin-approriate ((c clazz) (an-a a))
           (do-something c an-a))

end of story.

Now go ahead, extrapolate and maintain this and the C++ or Java
versions.  Better yet, add a new class to the a->b->c hierarchy. What
would you have to do, had you written the beast in C/C++? What do you
have to do if it was written in CL?

Cheers

I /responded/ to the above by suggesting that carefully avoiding
interesting CLOS features allows you to emulate the "attractive"
OO style the original author prefers.

Cheers

  in all my years on USENET, I have seen a lot of destructive idiots post
  their favorite drivel in the guise of facts, and some even manage to look
  like they have a clue, but I cannot recall anyone quite so destructive or
  quite so willing to lie and misrepresent as Dobes Vandermeer of the aptly
  named MINDLESS.COM.  _nothing_ he says is true or even relevant to what
  Lisp can offer today or why this offer is not widely accepted.

  Lisp does have a problem: it doesn't come with a big enough stick with
  which to hit the ignorant fucks so they get out of their retarded state.

While doing it for one potential customer, I made a typo that invoked
behavior I hadn't handled.  The application went into the debugger
with a `segmentation violation' error.

Imagine what would have happened if this were a C or C++ program.  But
this was lisp.  I just made a few conciliatory noises and re-invoked
the main entry point of the application.  Total time: 10 seconds.  I'm
not even sure the person watching the demo realized it had crashed.

Note that this was a (simple) logic error that static typing would not
have caught.

The moral is that lisp is DIFFERENT from other languages, and things
you need to give great attention to with other languages are
relatively unimportant in lisp.

Unless I'm mistaken, it's already possible to declare everything in
lisp.  It's also possible to give optimization settings that will warn
you about type problems at compile time (at least, CMUCL will do
this).  You can get run-time checks with appropriate optimization
settings, and disable them selectively if you need speed.  You can get
the best of both styles of programming.  So I don't see what the fuss
is about.

Is it multiple dispatch? Well, other languages are envious of this
feature, so it can hardly be a disadvantage. Stroustrup himself says
in one of his books that multiple dispatch is the one major feature he
would have liked to add to C++, if only he had found the time to
integrate it without compromising the performance of virtual function
calls.

Is it the difference in syntax? This can hardly be responsible for
limiting the usefulness to toy applications, and again there are
others who recommend to migrate to the more symmetric placement of
arguments, e.g. see Chris Date's recent book which proposes a database
language along these lines. And in case you haven't noticed: using the
STL with C++ methods would have been much less awkward if the target
argument of C++ method calls was in the natural place.

And unlike other parts of CL, CLOS even requires a fair amount of
static type checking by requiring consistent lambda lists in the
methods of a generic function, although some implementations could
provide more help with type checking than they do (at least warnings),
see my other postings on this subject.

Joachim

Joachim

  (defun (foo integer) ((lyst cons) (x integer) ...)
    ...)

And the really good thing is that one doesn't have to change
the implementation to do that (if one wants that syntax): the
_user_ can do their own version of DEFUN which expands the above
into something like:

  (progn
    (declaim (ftype (cons integer ...) integer) foo)
    (cl:defun foo (lyst x ...)
      (declare (type cons lyst)
               (type integer x))
      ...))

(I am neither for nor against such syntax, at the time of this
writing; just want to show it can be done without the need for
a new compiler for the new syntax.)

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

USER> (defun foo (x y) (+ x y))
FOO
USER> (compile 'foo)
FOO
NIL
NIL
USER> (defun bar (x y z) (foo x y z))
BAR
USER> (compile 'bar)
; While compiling BAR:
Warning: FOO should be given exactly 2 arguments.  It was given 3 arguments.
Problem detected when processing
       (FOO X Y ...)
inside (BLOCK BAR (FOO X Y ...))
inside (PROGN (BLOCK BAR (FOO X Y ...)))

BAR
T
T

----------------------------------------

Is there something about generic functions that makes it harder to do
the same sort of argument count analysis?  

I agree that your example is more in keeping with the style of CL and
therefore probably better. I was, however deliberately vague about
exactly what the syntax given should be equivalent to. There are a
number of things that might be desirbale, and you might what different
syntaxes (is that the plural form of syntax?) for these and
combinations thereof.

what about optional arguments with default values?

A "better" object world view would allow for only acessing fields in the
object directly inside of methods for the object, thus providing the
mystical "encapsulation" that is currently underpromoted in CLOS.  I
hesitate to say that CLOS does not allow you to think in this way, yet I
will assert that typical examples I have encountered make no effort to
do so.

The syntax, although it is often trivialized by many people, is also
fairly important.  In a LISP function call, all arguments are weighted
equally, and so you are led to think about specialising based on any or
all of the parameters.  And object-oriented version, i.e. "(send-msg-to
obj (do-something a b c d))" shows you which object is being operated
upon, and although you could (easily) still specialize on the remaining
variables (i.e. a b c and d) to call a different method, the
message-passing paradigm is preserved.