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