RE: map-put! and (setf (map-elt ...) ..) on lists

[Drew Adams <drew.adams@oracle.com>]

> > My point was that there is no need for a function
> > name to signal that the function so named is
> > "destructive".  The doc string should do that,
> > however.
> 
> It can be very important to know that a function is destructive, I don't
> think it's a should be seen as an internal detail of the function.  IOW,
> I think that whether a function is destructive or not is part of what
> the function does, not how it does it.

It's not an internal detail - agreed.  It's
an important part of what it does (can do).
Very important.

And yet you don't know such behavior from
99.9999% of the existing function names,
do you?

When you write a function that makes use of a
destructive function, and whose action might
itself change something, including, e.g.,
list structure, do you name it in a special
way?  Do you think that others do so?

You can't rely on such naming, because it
Just. Doesn't. Happen.

And if it did happen then such name suffixes
would be all over the place - more noise than
signal - like ignored legalistic warnings
that serve only to protect the warners from
lawsuits.

Much such rightfully gets relegated to the
fine print.  Can we guess why?  Because it's
noise, not signal.  How does it happen that
something _very important_ can become noise?
Too much of it.  When you are warned about
everything you are really not warned about
anything.

Lisp is an imperative, procedural language.
Like that or hate it; it's a fact.  If you
want a declarative language, Lisp ain't it.

One might argue that there are different
degrees or kinds of state modification /
mutation, and thus different sorts of "danger".
Maybe only some kinds merit a DANGER! suffix?

Perhaps you feel that `setq' and `set' are
not sufficiently dangerous to merit renaming
to `setq!' and `set!' (oops, the latter is
Scheme's `setq', it doesn't correspond to
Lisp's `set').  Or perhaps not. `setf!'?
`put!'?  `push!'? `load-library!'?  On and
on...

Or perhaps you'd propose we reserve `!'
for (possible) list modification? sequence
modification?  Something else?

If we're going to have a naming convention
then hey, let's really have a convention.
Seriously.

Regardless of whether we decide to rename
existing functions, if we're going to have
a convention then we should apply it for
everything new.

And we should document it for users,
encouraging them too to respect it.
Otherwise users will fall into pitfalls -
unexpected (because unwarned) gotchas.
Truth in labeling, after all.

Do I think we should have such a convention?
Nope.  Do I think we should use suffix `!'
just here and there, for only a few new
functions?  Nope.  Do I think we should call
`map-put' `map-put!' because it can modify
list structure, hash tables, arrays...?
Nope.

The choices really are these, I think:

1. Put up one big general sign saying,
   "Lisp may be hazardous to your health."

   Oops, I mean, "Lisp is an imperative,
   procedural language.  Be aware that data
   mutation and other state CHANGE HAPPENS."

2. Rigorously put warning signs on everything
   that might modify state, which means
   pretty much everything that might come
   into contact with something that might
   modify state, which means most everything.

I vote for #1.