James Kanze wrote:
Damien Kick wrote:
>Noah Roberts wrote:
>>Dave Harris wrote:
ia******@hotmai l.com (Ian Collins) wrote (abridged):
>>>>What's wrong with isEmpty()? Sums up the comment and is unambiguous.
>>>"IsEmpty" is hardly better than "empty" in that both assume the reader
knows what "empty" means. As I explained, projects often develop
specialise d vocabularies that need to be documented.
>>Is "empty" a question or command? I don't see that ambiguity with
"is_empty".
>"empty" is neither a question nor a command. Merriam Websters says that
it can be an adjective, verb, or a noun.
If it's the name of a function, it can only be a verb. My
Collins gives its use as a noun as "informal"; at any rate, I
can't off hand think of a use in programming where it would be a
noun. As an adjective, of course, it could easily be part of
the name of a variable (associated with a noun).
>"is empty" is also neither a
question or a command but is rather a phrase devoid of meaning without
context. "x is empty" is perhaps a statement of fact, an implicit
question as to whether or not the statement of fact is true,
Except that we don't really have statements of fact in a
program.
Well, I had mentioned Prolog in the example and Prolog does have
statements of fact. Of course, this is c.l.c.m. However, even C++ has
statements of fact in the form of an assertion. One could even consider
something like the following
object.is_initi alized()
in which case "is_initialized " returns true/false to indicate whether or
not the object has been successfully initialized, and so acts as both a
question (did it succeed?) and a command (do it). I would not do this
myself, instead preferring a constructor, but the usage seems perfectly
valid to me from the POV of it being a valid name for such a function.
Given the context of use in a program, I don't see any
other reasonable way of interpreting x.is_empty() than as a
question, "is x empty?".
I read an interesting essay just last night, "Ambitious Evaluation: A
New Reading of an Old Issue" <http://tinyurl.com/2v5ama>, by Kent Pitman.
| It all started in 1986 when I was on staff at the MIT AI Lab and an
| undergrad studying Lisp asked me why the following piece of code
| didn't ``work'':
|
| (PROGN (SETQ *READ-BASE* 8.) 10)
| =10. ; not 8.
|
| I chuckled for a moment with the kind of easy superiority that I have
|since learned to take as a sign that it's me, not the person I'm
| answering questions for, that really has something to learn.
|
| I answered the question in the obvious way, explaining how of course
| Lisp has to read the entire form into memory before it can execute any
| of it. So by the time the expression above has been processed by READ
| and is ready to have EVAL called, it is too late for any change to the
| setting of *READ-BASE* to affect it. The student was mostly happy with
| the explanation, but the more I thought about it, I was not.
|
| Increasingly, I've always found that the phrase ``of course'' is
| bandied about far too much, especially in computer science, a
| ``science'' which sometimes deals in provable facts (like algorithmic
| complexity) but that often deals in much more subjective,
| near-religious issues (like ``Fred implemented it this way, and Fred
| is generally right on such matters so everyone should do the same.'')
| as if they were facts.
It's a very interesting essay, in my opinion. He starts with "the only
reasonable way" to answer an undergraduate question but then begins
exploring an alternate approach to the question. From the "obvious"
beginning, he actually implements a perfectly reasonable version of read
and eval for which "(PROGN (SETQ *READ-BASE* 8.) 10)" evaluates to "8".
However, after having gone through a rather elaborate explanation,
including a working implementation of such a system, he writes the
following.
| My real goal here was partly to expose people to the way parsers and
| input editors are usually modularized in Lisp. And it was also partly
| to keep us all reminded that the reason we do things the way we do
| (e.g., separating input editing from parsing, and separating READ from
| EVAL) is not because it's the only way to do things, but because it's
| one of many design choices we had.
|
| The world is full of choices. Sometime an examination of the choices
| leads you to the same conclusion as you'd have arrived at without
| examining them. But looking over all of your options when making a
| design decision is always a good idea if you can spare the time.
At the end of the day, I really do agree with the idea of using "is_" as
a prefix for the name of a predicate because I do it, too. However, I
still believe that there is nothing "obvious" to any of it and that
there are other reasonable alternative interpretations . However, I
don't think that this topic has as much potential for depth to it as
Pitman's interesting journey from the obvious answer, to a working
contradiction of the obvious, only to return to agreeing with what was
the "obvious" answer in the first place. Especially as our topic of
what is is or is not is so fiercely subjective because, unlike Pitman's
exploration of read and eval, one can not do something like writing code
as a counter example of the "obvious". The argument can really only be
a bunch of people asserting that something is or is not obvious without
any hope of supporting his/her position besides simply repeating those
assertions. Unless, of course, we would attempt to make some kind of
argument based on linguistics, psychology, or something else relatively
off topic to c.l.c.m and for which I doubt any of us are qualified. And
again, at the end of the day, I would still use "x.is_foo() " in my C++
programs as "is x foo" and not "x is foo", too. And I'll use the
"obvious" reading of "X is Foo" as <pause"X is Foo" when writing
Prolog or (is ?x ?foo) when writing Prolog in Lisp
<http://tinyurl.com/24b3uu>.
(Similarly, I don't see any other
reasonable way of interpreting x.empty() than "empty x", i.e.
remove all elements from x. And of course, conventionally,
x.clear() would generally mean to return x to the state it had
immediatly after construction by the default constructor.)
Well, except that in this case, the only "reasonable way of interpreting
x.empty()" is wrong, isn't it? So just how "the only reasonable way"
can it be? And yet even though the standard manages to get the only
reasonable way wrong, "everybody" seems to be able to write working code
somehow, so just how unreasonable can it be? I agree that it is
probably inconsistent with the way some other functions are named but
all of the irregularities and inconsistencies in natural languages would
seem to suggest that people really don't have all that hard a time with
a certain level of inconsistency in their languages.
--
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]
