Python syntax in Lisp and Scheme

[Pascal Costanza]

Carlo v. Dango wrote:

> 
>> I'd humbly suggest that if you can't see *any* reason why someone
>> would prefer Lisp's syntax, then you're not missing some fact about
>> the syntax itself but about how other language features are supported
>> by the syntax.
> 
> 
> sure, but it seems like noone was able to let CLOS have
> (virtual) inner classes,
> methods inside methods,
> virtual methods (yeah I know about those stupid generic functions :),
> method overloading,

+ Inner classes only make sense when the language requires you to put 
method definitions inside of class definitions. It doesn't make a lot of 
sense to put a class definition inside another class when it only 
consists of field definitions, as is the case in CLOS. (Except for 
having the benefit of additional namespaces, but namespaces are handled 
differently in Common Lisp.)

+ So what you want is method definitions inside of other methods. Of 
course, this is possible. Here is a little toy example that sketches how 
you can achieve this:

(defclass person ()
   ((name :accessor name :initarg :name)
    (address :accessor address :initarg :address)))

(defun make-out-method (person)
   (with-slots (name address) person
     (defmethod out ((p (eql person)))
       (format t "Name: ~A; address: ~A~%" name address))))

(defvar *pascal* (make-instance 'person :name "Pascal" :address "Bonn"))

(make-out-method *pascal*)

(out *pascal*)

=> Name: Pascal; address: Bonn

+ All methods in CLOS are virtual. What do you mean?

+ Method overloading is a way to have static dispatch, and this doesn't 
fit well with a dynamic language. (Apart from that, static dispatch is a 
source for some nasty bugs.)

What you probably really mean here is that there are some strict 
compatibility requirements wrt the lambda lists of methods that belong 
to the same generic function. I don't think Common Lispers have serious 
issues with these requirements.

In general, dynamic type checking in Common Lisp makes these things much 
easier than you might think in case you have only considered statically 
typed languages so far.

> A decent API (I tried playing with it.. it doesn't even have a freaking 
> date library as standard ;-p

No language with an official standard (ANSI, ISO, etc.) defines 
everything you might ever need in its standard. That's simply not 
possible. Standardized languages rely on vendor support, and more often 
than not, community-driven de-facto standards emerge.

Single-vendor languages follow a totally different approach in this 
regard. You are comparing apples and oranges here.

One can have a debate about language standards vs. single-vendor 
languages, but that's a different issue altogether.

Baseline: If you are looking for a decent date library, check out what 
Common Lisp vendors have to offer and/or what is available from third 
parties.

> Yes I agree with the compile time macro expansion is a nice thing. 
> However, if I want to do some serious changes to the structure of 
> objects and classes (i.e. create a new kind of objects) then I have to 
> spend a long time finding out how the CLOS people hacked together their 
> representation of classes, methods, method call etc... it has been far 
> easier for me to just do some small changes using __getattribute__ and 
> metaclasses in python. So in that respect Im not really sure the macro 
> idea is advantageous for other than 'straight away' macros...

Are you sure that you are not confusing macros and the CLOS MOP here? 
(Your remarks are too general to be able to comment on this.)

> yes this mail is provocative.. please count slowly to 10 before replying 
> if you disagree with my point of view (and I know Pascal will disagree 
> ;-) ... not that I ever seen him angry ;-)

grrr

;)


Pascal