On Sun, 2008-10-12 at 14:57 -0700, ·············@gmail.com wrote:
> On 12 oct, 18:52, Pascal Costanza <····@p-cos.net> wrote:
> > ·············@gmail.com wrote:
> >
> > > I think that Lisp compiler get their power because in Lisp you
> > > usually declare implicitely the type of the argument:
> >
> > > (person-name "John")
> > > (char "sure I'm a string" 1)
> > > (car '(sure this is a list))
> > > (= A B) ;; sure A is a number....
> >
> > > That is instead of declaring the type of the argument, Lisp language
> > > use multiple names for the same operation:
> >
> > > a[1] versus (aref a 1),
> > > a[1] versus (gethash 1 a) ...
> >
> > > This mean that Lisp compiler should be more and more powerful since
> > > the programmer take a lot of care to declare implicitely the type of
> > > the arguments.
> >
> > > A = "John Smith"
> >
> > > A.name versus (person-name "John Smith")
> >
> > > So I should say that Lisp is weakly implicitely typed.
> >
> > > So you pay this feature to get a fast compiler by creating a lot of
> > > names for functions.
> >
> > > In order to appreciate Lisp you must realize that this is a trade-
> > > off fast speed, no static typing versus more reserved words.
> >
> > > Example: =, eq, eql, string=, equal, equalp ...
> >
> > > Do you agree?
> >
> > No.
> >
> > First reason: Functions like char and car have to check that the type of
> > the passed argument is correct. If it's not correct, these functions
> > have to signal an error. Conceptually, this means more overhead,
> > although there are a number of quite clever implementation techniques to
> > remedy the situation.
> >
> > Second reason: In Lisp, many functions are actually generic. Arithmetic
> > operations operate well on different kinds of numbers (fixnum, integer,
> > rational, float, complex), many functions accepting strings as arguments
> > also accept string designators, print functions can print all kinds of
> > arguments, and so on. This doesn't create a lot of additional overhead,
> > since the type checks have to be performed anyway (see above), but
> > instead of signalling errors, different branches of functionality can be
> > executed. This is actually one of the corner stones of dynamic
> > languages, that functionality can be selected based on dynamic
> > properties. This is so important, that Common Lisp actually provides a
> > systematic way for defining (and extending) generic functions.
> >
> > If you really want to get rid of runtime typecheck overhead, Lisp
> > implementations do the same as any other language: Infer static types by
> > doing control flow analysis, allowing programmers to declare types
> > statically, and rearranging typechecks at runtime such that branches
> > that are typically taken most of the time are tested for first and are
> > encoded as fast checks.
> >
> > Pascal
> >
> > --
> > Lisp50:http://www.lisp50.org
> >
> > My website:http://p-cos.net
> > Common Lisp Document Repository:http://cdr.eurolisp.org
> > Closer to MOP & ContextL:http://common-lisp.net/project/closer/
>
> I agree that Lisp have generic functions CLOS and not CLOS, for
> example
> arithmetic operations. I think all the computer languages have in
> some sense generic functions. The point of my post is that if we
> compare
> modern languages like python or ruby with Lisp, we see that, in many
> cases, Lisp requires the type of the argument:
>
> "a" + "b" for python, ruby, javascript, ...
>
> (concatenate 'string "a" "b") that is not (concatenate "a" "b").
CL-USER> (defpackage #:my-lisp
(:use :cl)
(:shadow #:+))
#<PACKAGE "MY-LISP">
CL-USER> (in-package #:my-lisp)
#<PACKAGE "MY-LISP">
MY-LISP> (defmethod + ((first t) &rest rest)
(apply #'cl:+ first rest))
STYLE-WARNING: Implicitly creating new generic function +.
#<STANDARD-METHOD + (T) {C16C051}>
MY-LISP> (defmethod + ((first string) &rest rest)
(apply #'concatenate 'string first rest))
#<STANDARD-METHOD + (STRING) {E86CD09}>
MY-LISP> (+ 1 2 3)
6
MY-LISP> (+ "hello" "world")
"helloworld"
..or your own my-lisp:concatenate .. whatever.
>
> The only way I see of "proving" my point is to take two libraries,
> one in python and one in Lisp and analyze the average generality of
> the functions in both.
>
> Another prove of this point is that python is slower than Lisp and
> the reason of this is not simply bad programming.
>
> I should say that in a mature language
> ---------------------------------------------------------------
> more dynamic functions is proportional to slower code.
> ----------------------------------------------------------------
>
> But a low level language can construct libraries to use generic
> functions (Lisp use CLOS) but this is not the point.
?
--
Lars Rune Nøstdal || AJAX/Comet GUI type stuff for Common Lisp
http://nostdal.org/ || http://groups.google.com/group/symbolicweb