Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp]) 
Author Message
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])



Quote:
> Making the syntax be (foo integer) is bad, though.
> There is an issue a lot of people don't talk about but that many of
> us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs)
> really wants the cadr position of definition forms to be "names".

  That sounds like a pretty poor reason. It's not that hard to get emacs to
take the car if the cadr is a list. In zemacs, you'd just have your new defun
macro make a call to that function that registers the definition. (Sorry I
can't remember the name of it and my Schema sources are off line at the
moment.)

  Mike McDonald



Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:

> CLOS provides a world view where we have extended functions to
> overload based on the class of its operators.

You mean 'operands' presumably? The function itself is the operator
according to conventional use of these terms.

Quote:
> The object abstraction of data and methods has been lost;

It has not been lost. In fact, it is much stronger than in most OO
languages. In typical use, all access to an object's state is via
functions, called accessors. The client of a class doesn't have to
know whether an attribute is stored as data (corresponding to a C++
data member), or is computed by a function. the implementation can be
changed from data member to function and vice versa without affecting
clients.

Lisp doesn't enforce information hiding in the same strict manner that
C++ does, which is simply a different philosophy. It has nothing to do
with abstraction, though. Also note that classes are not the primary
tool for information hiding in Lisp. Lisp uses classes as types, and
packages for modularity.

Quote:
> CLOS methods are not methods, but functions,

C++ methods are also functions. Just think about it a little more:
When you call a C++ (non-static) method the outcome is a function (in
the mathematical sense) of the target object and all other method
arguments. C++ syntax simply puts one of the function arguments in a
different place from others. The argument singled out in this way is
the one used for dynamic dispatch. Note, that nobody would have
proposed using this syntax if the more general case of multiple
dispatch had been considered from the start.

Quote:
> and CLOS does not protect encapsulated data from the "outside world"
> of functions and methods.

Common Lisp lets you circumvent abstraction layers if you insist, but
this is also true in C++, just requires a little more
effort. Abstraction doesn't require dictatorial enforcement.

Quote:
> 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.

You may not realize that CLOS accessors are, in fact, methods. You can
choose not to generate any accessors, in which case the corresponding
slots are not considered part of the class' interface.

Encapsulation is not underpromoted, Lisp simply takes the more general
view that methods can be sent to more than one object. Look at binary
functions: the natural way to express the semantics of the binary
function + doesn't single out one argument over the other. In C++ and
other single-dispatch languages one must awkwardly make such functions
methods of one or the other argument.

Quote:
> The syntax, although it is often trivialized by many people, is also
> fairly important.

Syntax is a metter of taste.

Quote:
> 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.

Yes. why, in general, would you want to force us to single out one of
them?

Quote:
> And object-oriented version, i.e. "(send-msg-to obj (do-something a
> b c d))" shows you which object is being operated upon,

But sometimes you operate on more than one!

Quote:
> and although you could (easily) still specialize on the remaining
> variables (i.e. a b c and d) to call a different method,

Not as easily as you make it out, it is certainly much more painful
than with multiple dispatch. And on this point the whole issue of
covariant argument redefinition raises its head, you may want to read
some of the heated discussions in comp.lang.eiffel on this topic. As I
mentioned before, even Stroustrup believes multiple dispatch is a good
feature to have.

Joachim

--




Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:



> > Making the syntax be (foo integer) is bad, though.
> > There is an issue a lot of people don't talk about but that many of
> > us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs)
> > really wants the cadr position of definition forms to be "names".

>   That sounds like a pretty poor reason. It's not that hard to get emacs to
> take the car if the cadr is a list. In zemacs, you'd just have your new defun
> macro make a call to that function that registers the definition. (Sorry I
> can't remember the name of it and my Schema sources are off line at the
> moment.)

I don't agree.  It's not just Emacs but all potential programs that
operate on this.  And it's not just cadr, but a table that the program
would have to magically have and which there is no mechanism to
provide.

On the Lisp Machine, there is an elaborate protocol for informing the
system of how to extract the name from the other stuff.  But
I have to say that I think it's infinitely better just to have that
be unnecessary.

Lisp has gotten a huge amount of its power not out of "picking the
best or most interesting way to do things" but out of "picking a known,
predictable way of doing something".  The power comes NOT from the goodness
of the choice, but from the lack of infinite quibbling over it.
I claim that this is an example of such.  Pushing for a change is
pushing for a life of infinite quibbling.

Don't accept that taking cadr to get the name is the right thing because
we've always done it that way.  Accept that we've always done it that way
because it's really the right thing.

JMO.



Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:

> Yes, picking your own syntax is fine up to a point, but other code may
> have used the same syntax for a differnt purposes and you then run
> into problems if you want to combine your code with such.

But with Vassil's solution, the package system would solve those
problems for you[1], whereas with reader-macros, you'd have to do
much more to keep out of trouble.

The only problem the package system can't solve IMHO is that code
not written by you will most likely not have the amount of type
declarations you'd like, which in some circumstances will weaken
your implementation's ability to do type-inference and type-checking
considerably.  But short of changing the standard to require type
declarations, no solution will help you here.  Of course you can
still declaim ftype's for those functions from the outside, but I'd
consider this practice fairly rude...

BTW: Vassil's syntax (optionally extended to allow specifiying a
return type) is not a lot of work to implement, since you can most
probably snarf a defun-lambda-list-parser from either CMUCL or PCL.

Regs, Pierre.

Footnotes:
[1]  In fact I'd claim that this area of use is one of the main
strengths of the package system. See the Symbolics Lisp machines,
which for a long time had a large number of different dialects
available at the same time, in the same address space...

You'd just define a package "RUDIN-CL", which would import&re-export
all the CL symbols, with the exception of defun&co., which would get
their own definitions in RUDIN-CL.  In fact in a previous discussion
some time ago, Tim Bradshaw posted a nice macro, which makes the task
of defining dialect packages a lot nicer.  Just search via DejaNews

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:

> what about optional arguments with default values?

It is still possible to do this a long those lines, but IMHO it gets a
bit messy:

(defun myfun ((a double-float) &optional ((b double-float) 0.0d0) (x 0.1d0))
  (* a b x))

The same might apply to &key args, &aux and even &rest, if one so
likes.  One could even extend the syntax to allow the specification of
a return type:

(defun myfun (integer 42 42) ((a (integer 1 42)) (b (integer 1 42)))
  (* a b))

Regs, Pierre.

PS: I'd agree with anyone who might find the above syntax slightly
perplexing.  I still prefer (declare ...) inside the function body.
The only addition I think would be nice was a "values" declaration
like CMU CL's, which would allow me to declare the return type of my
function within the body as well.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

[other confusions elided]

Quote:
> 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.

So in effect you are complaining that CLOS doesn't restrict your world
view enough.  Interesting complaint.  This reminds me of the following
two prayers (see Douglas Adams, Mostly Harmless):

Protect me from knowing what I don't need to know. Protect me from
even knowing that there are things to know that I don't know.  Protect
me from knowing that I decided not to know about the things that I
decided not to know about. Amen.

Lord, lord, lord. Protect me from the consequences of the above
prayer. Amen...

Regs, Pierre.

PS: Hmmm, somehow I get the feeling we are in the middle of another
Turing-Test again.  Craving for restricted world views might be what
AIs dream of at night... ;)

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])


Quote:

> Lisp has gotten a huge amount of its power not out of "picking the
> best or most interesting way to do things" but out of "picking a known,
> predictable way of doing something".  The power comes NOT from the goodness
> of the choice, but from the lack of infinite quibbling over it.
> I claim that this is an example of such.  Pushing for a change is
> pushing for a life of infinite quibbling.

  I wasn't arguing that the standard should be changed to that but that if one
wanted to make their one "extension", that's a fairly reasonable way to
represent it.

Quote:
> Don't accept that taking cadr to get the name is the right thing because
> we've always done it that way.  Accept that we've always done it that way
> because it's really the right thing.

  But there is precedance to the CADR being a list, namely DEFSTRUCT.
(Didn't one of the New/Old Flavors also have the CADR to defmethod being a
list at times? Seems like I remember it having somethingto do with specifying
before or after methods. Gnuemacs didn't like them either but a simple hack to
ctags fixed that.)

  Mike McDonald



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:

> > what about optional arguments with default values?

> It is still possible to do this a long those lines, but IMHO it gets a
> bit messy:

> (defun myfun ((a double-float) &optional ((b double-float) 0.0d0) (x 0.1d0))
>   (* a b x))

> The same might apply to &key args,

Except that keywords already use this, as in:

 ((lambda (&key ((:fu foo) 3 foo-p)) foo) :fu 4) => 4

so you'd do

 ( ... &key (((:b bee) integer) 3 b-p) ...)
or
 ( ... &key ((:b bee integer) 3 b-p) ... )
or
 &key (bee 3 b-p integer)
but any way you cut it, it's messy... and somewhat inconsistent.

Declaration syntax is less messy, IMO.



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])
On Fri, 7 May 1999 23:01:39 GMT, Kent M Pitman

Quote:

>Maybe he only meant to say "many lisp environments produced for casual
>use are suitable only for casual use, and only those lisp environments
>that intend to be commercial quality address this commercial concern".

Being able to build an executable program which can run
on different computers that don't have Lisp is not just a
commercial concern.  Even if you just want to write
educational software for your kids, you want them to be
able to run it on their own computer.  The reason why most
people never even bother to learn Lisp is because they
perceive it as being an elephant when they want a tiger.
Having to pay $3000 to be able to build simple executable
programs is part of that perception.


Wed, 24 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software