Newsgroups: comp.lang.lisp
From: cyber_surfer@wildcard.demon.co.uk (Cyber Surfer)
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!news.sprintlink.net!demon!wildcard.demon.co.uk!cyber_surfer
Subject: Re: SETF (was ... a bunch of things)
References: <Cxxwx0.1nC@rheged.dircon.co.uk> <hbakerCy17CC.vx@netcom.com> <LOU.94Oct31005920@athos.rutgers.edu>
Organization: The Wildcard Killer Butterfly Breeding Ground
Reply-To: cyber_surfer@wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 56
Date: Wed, 2 Nov 1994 11:23:50 +0000
Message-ID: <783775430snz@wildcard.demon.co.uk>
Sender: usenet@demon.co.uk

In article <LOU.94Oct31005920@athos.rutgers.edu>
           lou@cs.rutgers.edu "Lou Steinberg" writes:

> It can be, if what you are thinking of as a single conceptual entity
> is implemented by a group of objects, rather than a single object.  If
> more than one entity might share substructure, i.e. share an object,
> then yes, destructive changes to the slots of such an object is
> dangerous in much the same way that changing the car or cdr of a cons
> destructively is often dangerous.

I don't see why whether an object is a single entity or a group
of entities is an issue. I'd say that assignment is "dangerous"
in either case, since you have a side effect.

You're concerned about coding sharing. If I choose to, let's say,
write a function that builds a list, and then destructively reverses
it before making it available to another function, I don't believe
there's a big problem with that. No code is being shared.

In other words, the effects of destructive changes to a data
structure can be controlled and hidden. This is nothing new,
surely? I first read about information hiding in the early 70s,
and I didn't get the impression that it was new, even then, judging
by the copyright of the book I read it in.
 
> For instance, suppose you are writing a program that designs digital
> circuits.  Suppose an individual logic gate is represented by a set of
> objects, e.g. objects for the input and output connections and an
> object representing the boolean function computed.  Suppose that
> different individual gates might share the same "boolean function" object
> (say, some piece of code creates several AND gates, all sharing the
> same AND-function object).  Then destructively changing a
> slot in the function object of some gate is dangerous.

You're assuming that it would be a "bug", and not a "feature".
A programmer should be able to distunguish between the two ways
of viewing such code. If you're saying that assignment is dangerous
because it has a side effect, then you might prefer to use a
language without assignment, or simply choose to avoid using that
particular language feature.

Sadly, most programmers don't have that choice. We're expected to
write code that uses assignments, mainly because the alternative
in the language we're asked to use (like C) is unattractive. I'm
not even sure how many programmers share this view of assignment.

What worries me far more are the numbers of programming tutorials
that give example code that calls a function that may fail, but
doesn't bother checked the status returned by that function. I get
the impression that these "bad" examples are being taught to
programmers. At the very least, they're told that "trivial" examples
don't need error checking! That scares me far more than the use
of assignment.
-- 
Please vote for moderation in comp.lang.visual
http://cyber.sfgate.com/examiner/people/surfer.html
