Subject: Re: Matrix type... question on Lisp implementation..
From: Erik Naggum <erik@naggum.no>
Date: 1999/12/22
Newsgroups: comp.lang.lisp
Message-ID: <3154816073744645@naggum.no>

* Kenneth P. Turvey
| I noticed some limitations in Common Lisp that seem to be arbitrary and
| rather unfortunate in this process and I was hoping someone could
| provide me with an explanation.

  you seem to ignore the obvious solution to your problems, and that makes
  you believe you have a limitation in Common Lisp when you actually don't.

| Lisp seems to avoid these kinds of limitations more than most languages.

  indeed.

| The first has to do with the appropriate place for a matrix type in the
| class hierarchy.  It should be a descendent of the number class.  This
| seems obvious to me.

  it seems obviously wrong to me.  if I were implementing matrices in C++,
  however, it would seem obviously right, but that's because C++ has a very
  different class concept that IMNSHO is an insurmountable liability for
  that language alone and should not impact any other languages.

| It should support the same set of methods that are supported by numbers.
| Functions such as #'+ and #'* should accept a matrix as an argument and
| if possible return the correct answer.

  this, however, seems reasonable, but methods are not members of classes
  in CLOS, and class hierarchies are less tightly coupled with method
  selection than in C++.  in brief, you don't need to be a subclass to
  implement methods whose meaning is defined for some other classes.

| Here's the problem.
| 
| 1) It is not legal to derive a class from a built-in-class.  

  whether a built-in-class is a superclass of a class or the class of a
  slot in a class is largely an implementation detail.

| 2) There is no way to extend built in functions like #'+ to handle new
| types of numbers. 

  this is both true and false.  it's true in the trivial sense that if you
  try to do it directly, you can't.  it's false in that you _can_ get the
  effect you want.  at issue is _which_ + you refer to.  Common Lisp does
  not do overloading the way C++ does, and does not do namespaces like C++,
  either, but you can shadow the symbols whose meaning you want to change,
  and _completely_ change their meaning if you so wish.  in other words,
  you can use functions named MATRIX:+ instead of COMMON-LISP:+, but what
  your code contains may still be +, depending on the value of *PACKAGE*.

  getting the compiler to be as efficient with MATRIX:+ as with CL:+ may be
  hard, but it's doable, and if you need very high performance you will
  most probably get help from the vendor in achieving it.

| 3) There is no way to declare a method with a variable number of
| arguments that are all members of some subset of the existing classes.

  "declare"?  my bogometer indicates that you're really programming in some
  other language and trying to force Common Lisp into your mindset.  this
  won't work.  the limitations you experience are due to friction you see
  when you attempt the impossible.

  Common Lisp programmers are generally aware that the functions they
  define do a lot of work behind the scenes and that lambda lists aren't
  free, that method combination and dispatch aren't free, and that if they
  need special powers, that _they_ are free to define new macros or other
  forms that do similar expensive operations behind the scene.  in your
  case, you need do no more than define a macro to define methods that
  accept _one_ argument of the appropriate class, then, perhaps depending
  on some optimization settings, checks to see if the rest of the arguments
  are of the same class as whatever made that method be selected.  this is
  a fairly trivial extension to the existing features in the language.

| I am sure that these limitations are not arbitrary, but what cost is
| associated with them?  Why were they left out of the language? 

  a more appropriate question is: why didn't you program them back in when
  you needed them?  this is Common Lisp, the programmable programming
  language.  C++ is the language you sit around and wait to evolve yet
  another feature that might be used "close enough" to what you need.

  your complaints reduce to syntactic issues.  you can do all you want to
  do, but you might need to be more verbose to make it perform well.  this
  is not a _semantic_ language limitation in my book, which is what you
  imply that this is.  since the syntax of Common Lisp is eminently
  customizable, your complaints reduce to a question of how to program the
  syntax to fit your preconceptions of what the syntax should look like.
  I'm sure this can be achieved, but if you limit _yourself_ to particular
  ways of doing things, such as remaining stuck in the C++ world, that's
  where you need to make some changes first.

  incidentally, asking why things are "left out of the language" is a good
  sign that the asker is fairly clueless.  first of all, it's a question
  that can be asked only in retrospect, and as such it's an anachronistic
  accuation, meaning: you think somebody is at fault for not having done
  what you think they should have done because you need something since you
  can't (easily) do what you want and that must be somebody's fault.
  second, anything is possible, so leaving something out of a language is a
  fairly meaningless thing to do in the first place.  the matter at hand is
  _convenience_.  all you actually ask is "why isn't _this_ convenient?".
  it's hard to answer that question without answering the implied general
  question: "why haven't all programming problems been solved already?"
  
#:Erik