Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl,comp.lang.lisp.franz,comp.lang.lisp.x,comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!gatech!news.sprintlink.net!EU.net!news2.EUnet.fr!news.fnet.fr!ilog!news
From: davis@ilog.fr (Harley Davis)
Subject: Re: Lisp considered too hard
In-Reply-To: Scott Wheeler's message of Mon, 03 Jul 1995 18:57:21 +0000
Message-ID: <DAVIS.95Jul4112334@passy.ilog.fr>
Followup-To: comp.lang.lisp,comp.lang.lisp.mcl,comp.lang.lisp.franz,comp.lang.lisp.x,comp.lang.clos
Lines: 52
Sender: news@ilog.fr
Nntp-Posting-Host: passy
Organization: Ilog SA, Gentilly, France
References: <hbaker-0206950511260001@192.0.2.1> <SMH.95Jun6210656@vapor.Franz.COM>
	<creedy-1406951118240001@128.29.151.94> <jyndnl@bmtech.demon.co.uk>
	<3t8kjm$qkk@info.epfl.ch> <jyploy@bmtech.demon.co.uk>
Date: 04 Jul 1995 09:23:34 GMT
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:18280 comp.lang.lisp.mcl:7355 comp.lang.lisp.franz:555 comp.lang.lisp.x:1602 comp.lang.clos:3274


In article <jyploy@bmtech.demon.co.uk> Scott Wheeler <scottw@bmtech.demon.co.uk> writes:

   In Article <3t8kjm$qkk@info.epfl.ch> Stefan Monnier"  writes:
   >In article <jyndnl@bmtech.demon.co.uk>,
   >Scott Wheeler  <scottw@bmtech.demon.co.uk> wrote:
   >] I find it awkward to bear in mind that something returned from a
   >] function is the thing itself, not a copy. In practice it doesn't
   >] usually make a difference, but it always feels unsafe. I'm left with
   >] the uneasy feeling that if I modify a variable it could have side
   >] effects I haven't anticipated. Not being used to GC languages, 
   I prefer the C++ version where you can decide whether to take a copy or 
   a
   >] reference to the original. The worst (i.e. hardest for me personally 
   to
   >] work with) version seems to be Eiffel, where copy or reference
   >] semantics are specified on a class by class basis.

The original objection seems a little odd for someone used to
programming in Lisp.  Most Lisp libraries do not document the
internals of an object, and there is no equivalent to C/C++ header
files.  All access to objects is via functions (although the use of
setf with an accessor-like function certainly provides a hint that an
object may be modified).  In any case, and in any language, it is
certainly up to the library designer to decide what objects should and
shouldn't be modified --- not up to the user to decide if he "takes" a
copy or pointer; after all, what if some object is *intended* to be
modified? It is therefore also the library designer's responsibility
to document any potentially side-effects that might crop up.

In Lisp, primary application objects don't seem to have this problem
very often since their high-level API provides the necessary security
to avoid unwanted low-level modifications.  However, sometimes there
is a temptation on the part of a library designer to expose an
internal list maintained by the library for efficiency reasons, with
big warnings not to destructively modify the list.  Unfortunately,
beginners don't always know when they are destructively modifying
lists and this can lead to very obscure bugs.  So most mature Lisp
libraries never expose internal structures and bugs of this sort are
avoided.

I don't see how this issue connects much with GC.

-- Harley Davis
-- 

------------------------------------------------------------------------------
Harley Davis                            net: davis@ilog.fr
Ilog S.A.                               tel: +33 1 46 63 66 66
2 Avenue Gallini, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France            url: http://www.ilog.com/

