unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Kelly Dean <kelly@prtime.org>
Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, emacs-devel@gnu.org
Subject: Re: Elisp terminology
Date: Sun, 25 Jan 2015 10:49:26 +0100	[thread overview]
Message-ID: <87k30b42c9.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <LySD7OX54l9XPMaliKoqOCL3roUX6KbxGKBFYrmANMp@local> (Kelly Dean's message of "Sat, 24 Jan 2015 23:30:11 +0000")

Kelly Dean <kelly@prtime.org> writes:

> Stephen J. Turnbull wrote:
>>> will need to understand or modify, so using a technical
>>> abbreviation isn't a problem. Emacs already has abbreviated names
>>> such as ⌜fboundp⌝ and ⌜fmakunbound⌝ for programmer-only things,
>>> instead of ⌜function-bound-predicate⌝ and ⌜function-make-unbound⌝.
>>
>> And the recent trend is to deprecate such ancient usage, including the
>> venerable `car', `cdr', and `cons'.
>
> Look what happened when I proposed changing the names of set-default,
> setq-default, and default-value. They're misleading,

No, they aren't, but you are not willing to hear any explanation in
conflict with your preconceptions.

> but you and Eli say they're too old to change. IOW, bugs with
> seniority are features.
>
> The names of car and cdr are even older. And they're not misleading;
> they're just archaic.

I have my problems seeing how "Contents of address register" and
"Contents of decrement register" are accurate concerning the current
implementations.  In their _archaic_ sense, those terms are not
accurate.  It's just that they have grown into terms of their own.

> There's both less need and less ability to change them than there is
> to change the former three.

In contrast to car/cdr however, the _default_ value is still an accurate
description.

> And yes, the abbreviations ⌜cons⌝, ⌜fboundp⌝, and ⌜fmakunbound⌝ are
> old, but they're neither misleading nor archaic.

fboundp is sort of an archaic feature of the language.  Lisp symbols
have 4 slots by default: value, function value, property list, name.

In Scheme, symbols don't have any slot.  They are semantically the same
as keywords, just being an internment of their name.  That makes it
possible to implement a module system establishing the relation between
symbols and values in the _global_ lexical space.

> I'm a good benchmark, since I'm easily fooled by misleading names and
> I have bad memory, yet these names don't cause me problems.

The problem is that you consider yourself the only benchmark, not just
for the naming but also for the meaning and implementation of terms.
That's not unusual for programmers, which is why there are regularly
scheduled shouting events under the title of "standards committee".

With regard to Emacs Lisp, we don't have such official events.

-- 
David Kastrup



  reply	other threads:[~2015-01-25  9:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22  3:44 [PATCH] Desktop mode saves mark-ring too verbosely Kelly Dean
2013-11-23 13:40 ` Stefan Monnier
2015-01-21 12:11   ` Kelly Dean
2015-01-21 15:04     ` Stefan Monnier
2015-01-22  5:43       ` Kelly Dean
2015-01-22  8:20         ` Ivan Shmakov
2015-01-23 13:20           ` Kelly Dean
2015-01-23 14:09             ` Ivan Shmakov
2015-01-24  3:08             ` Stephen J. Turnbull
2015-01-24 23:30               ` Elisp terminology (was: Re: [PATCH] Desktop mode saves mark-ring too verbosely) Kelly Dean
2015-01-25  9:49                 ` David Kastrup [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-01-23  2:59 Rant - Elisp terminology is deceptive Kelly Dean
2015-01-23 20:15 ` Stefan Monnier
2015-01-24  0:41   ` Kelly Dean
2015-01-24  0:48     ` Óscar Fuentes
2015-01-24  3:28     ` Stephen J. Turnbull
2015-01-24  8:51       ` Eli Zaretskii
2015-01-24 10:32         ` Kelly Dean
2015-01-24 11:26           ` Eli Zaretskii
2015-01-24 10:30       ` Kelly Dean
2015-01-24 11:03         ` David Kastrup
2015-01-24 23:24           ` Kelly Dean
2015-01-25  9:16             ` David Kastrup
2015-01-26  3:52               ` Kelly Dean
2015-01-26  8:28                 ` Thien-Thi Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k30b42c9.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kelly@prtime.org \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).