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!howland.reston.ans.net!pipex!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.94Nov3134532@atanasoff.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: 68
Date: Sat, 5 Nov 1994 20:08:42 +0000
Message-ID: <784066122snz@wildcard.demon.co.uk>
Sender: usenet@demon.co.uk

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

> (The distinction I mean is between a single OBJECT vs a group of OBJECTS
> implementing a single conceptual entity.)

I still don't see the significance. I don't care where the pointer is,
whether it's a pointer in a list cell, or a more complex object. All
I know is, there's code that I want to write that'll need some way to
assign a new value to that pointer. Perhaps that's coz I learned C
long before learning Lisp, but I dunno.

> to appear if we are accessing "entity Z".  Of course, what makes such
> a conceptual "entity" is entirely an issue of how the human is thinking
> about the data and the things it represents.

Thanks for phrasing my point so well. It all depends on how you want
to look at it. The language, in this case CL, allows us to look at it
in many ways, and assignment is there in the form of SETF to allow us
to look at references between objects in the same way we're used to,
at least if we're used to updating pointers, as many of us are.
 
> You suggest "information hiding" as a solution to the problem.  I would
> agree, but with the following additional caveat:
> 
> The module of code dealing with a given data structure can gain
> efficiency by using either of two techniques: shared substructure and
> destructive modification.  However, if both techniques are used on
> the same parts of the data structure, expect more bugs than usual.

So? That's part of the art of programmer, surely? You have to know
what you're doing, and avoid doing two or more things with the same
code that are mutually exclusive. I don't see how this is a language
issue, or even a Lisp issue, never mind an assignment issue.

I can put that in a different way: a programmer who is determined to
screw up can't be stopped by a programming language, unless it acts
as a straght jacket, and then it won't be useful anymore. This seems
to be one of those religious issues that can be found in programming,
so I don't expect everyone to feel the same way, but it's still the
way that I look at it. Any tool which is powerful enough to do what
I want will also be powerful enough to allow me to make mistakes,
but the distinction I make is between my mistakes and the mistakes
made by the tool (or by the designer/implementor of the tool).

There are languages which allow us to program without the use of
assignment, and these are also tools. I like the idea a lot, but
until I have one that can replace the tools I'm currently using,
then I'll continue using the older tools. I can wait.

Are you _sure_ you're problem is not with the way programmers use
assignment, rather than with the tool itself? CL still includes a
number of "gotos", and a lot has been said about the horrors of
gotos, and yet they're still included in CL and other languages.
They're still useful, It's too bad that this means they're still
available to programmers who'll abuse them, but that's the
programmer's choice. I think it's a little unfair to criticise
the language for the mistakes of some of those who use it.

It also implies that we're all making those mistakes just by
using the language, which might not be the case. Like with
Political Correctness, I feel it's missing the point. It's the
attitide that matters far more.

Have I misunderstood what you're saying?
-- 
Please vote for moderation in comp.lang.visual
http://cyber.sfgate.com/examiner/people/surfer.html
