Re: delete command weirdness

Nathaniel Calloway <ntc6@xxxxxxxxxxx> writes:

"Steven M. Haflich" <smh@xxxxxxxxxxxx> writes:

Nathaniel Calloway wrote:
Anyone have an explanation for the inability of the delete command to

Common Lisp does not have "commands". It does have functions.
Thinking of a function as a command may warp your expectations.
Functions may have documented side effects, but you need to
examine whether you are expecting side effects that are not
guaranteed by documentation.

Comp.lang.lisp does not have "discussions". It does have pedants.

He's is not making a pedantic point here. There is a front-and-center
connotation to the notion of command, specifically that of "side effect",
that is misleading the OP here.

From the American Heritage Dictionary...

pedant
1. One who pays undue attention to book learning and formal rules.
2. One who exhibits one's learning or scholarship ostentatiously.

I don't see Steve's use as undue, since it's on topic. The attempt at
formality underscores important and relevant truth here. And as to
ostentation [not sure I've ever had occasion to use that word before],
I've known him a long time and while he's often a stickler for detail,
I think the purpose of his being so isn't to make a show, but rather to
make a helpful point and to document his reasons for making such a point.

delete exists exclusively for its side effects because there is
another function *with the exact same behavior* and no side effects.

Actually, this is definitely not true. The notion of

destructive adj. (of an operator) capable of modifying some
program-visible aspect of one or more objects that are either
explicit arguments to the operator or that can be obtained
directly or indirectly from the global environment by the
operator.

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#destructive

The sense of "capable of" is critical here. It does not imply an
obligation, and conforming implementations have existed in which
there has been no side-effect. (They weren't very popular in the
market, mind you, but not because they didn't work by side-effect.)

The purpose of DELETE is not to do the impossible [which would be to
accomplish the OP's concern given CL's data model] but rather to
permit an implementation to perform the action done by REMOVE but
without the need to create new cells.

And for the record, simply because the behavior of a function is in the
documentation, doesn't mean it isn't retarded.

"Once you eliminate the impssible, whatever remains, no matter
how improbable, must be the truth."
--Sherlock Holmes

You may substitute "retarded" for "improbable" if you like. Personally,
I thought your tone somewhat really unnecessarily acid for civil discussion.
But your mileage may vary.

Anyway, back to Holmes, it seems to me that the strategies chosen by Lisp
really proceed by analysis of the fixed constraints of the language, and
that only ways to "fix" DELETE are:

* Change the basic linked-list data structure of CL to a more
complicated structure that does not permit a great deal of
other sharing that CL has. (Other languages have chosen to offer
different structures and to call them lists; that's ok, but it has
implications beyond DELETE.)

* Not offer the function DELETE and instead offer a SETF-like
abstraction atop it. (This would basically require you to
have the equivalent of DELETE but not advertise it; you might
call it DELETE-INTERNAL and then use DEFINE-MODIFY-MACRO in
order to make yourself a DELETE you like. This can,
incidentally, be done by making your own package and doing
appropriate symbol shadowing. But while doing so is easily
feasible, its consequent implication would be that DELETE
was not a simple function but rather a piece of syntax. This
would seem to me to complicate use of your then-modified DELETE
in the context of the functional programming style that some
try to use in CL [even in the presence of side-effect, since
"style" does not have to imply "ubiquitous use", or to re-use
your chosen term, being a "pedant"].)

This ain't scheme or haskel we're talking about.

At the risk of accusations of pedantry, but really just to enable
search engines to find this thread better, I believe the correct
spelling is Haskell.

CL has quite its fair
share of imperative commands...wait, no...operations, that's it.....I
mean methods...oh ***...FUNCTIONS.

The issue has nothing to do with Lisp's imperative nature.

Although I've used functional languages, I've not done a detailed
analysis of how they get away without this, so someone correct me if
I'm wrong, but the way they get away without the DELETE/REMOVE
distinction has always appeared to me to be through leaning more
heavily on the GC. The sense of imperative nature that DELETE
provides in CL seems to me to be not one imperative of action but one
of politely commanded (and, strictly speaking, ignorable) trust--that
is--to suggest that it is a reasonable and appropriate to prematurely
optimize the recycling of certain cells even when the dynamic
untangling of their availability has not yet been dynamically
detectable.

My intuition has always been (though I've not ever thought this
through in rigorous detail, so a theoretician who has is welcome to
correct me) that it is undecidable in general (it seems to me likely
subject to the Halting Problem) whether a compiler can detect
statically, even in the "relaxed comfort" of a strictly functional
language, that such an optimization is appropriate in all cases where
a user might decide it is useful in CL because it effectively promises
a mode of use of certain dynamically interconnected conses in the
future that doesn't seem to be knowable in all cases statically
(especially since in the general case it could depend on external data
not apparent to the compiler).

So I suspect this is more analogous to the question of whether
malloc/free is more efficient than cons/gc. Probably it is in some
cases. But the cost may be program error. Some people regard the use
of explicit allocation an important speed issue, and some regard it as
a foolish reliance on fallible human judgment. The two claims both
each some merit and the result is that an apples-to-apples (rather
than apples-to-oranges) comparison of the two [malloc/free and cons/gc]
is therefore difficult, just as a comparison of a functional language
and its use of remove-only + gc is hard to compare to a side-effecting
world and remove/delete are hard to compare.

Or so it seems to me. (I was up in the middle of the night for a few
minutes and I admit the possibility that I could just be tired and
missing something... But there are a great many thoughtful people in
this forum and I've rarely been ill-served by putting such mullings out
for conversation--someone will usually correct me when I'm wrong.)
.

Loading