all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Richard Riley <rileyrgdev@googlemail.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: help-gnu-emacs@gnu.org, 'Richard Riley' <rileyrgdev@googlemail.com>
Subject: Re: Working with constansts
Date: Sun, 10 May 2009 19:28:43 +0200	[thread overview]
Message-ID: <4a070ecc.0c58560a.2fff.1683@mx.google.com> (raw)
In-Reply-To: <000801c9d191$22a21340$0200a8c0@us.oracle.com> (Drew Adams's message of "Sun, 10 May 2009 10:02:42 -0700")

"Drew Adams" <drew.adams@oracle.com> writes:

>> Why is it called a constant if its not enforced?
>
> As the doc says (explicitly): to signal programmer *intention*. It lets human
> readers of the code know that it is *intended* that no one and no code will
> change the value. Think of it as a comment to that effect, if you like: "Do not
> change this value."
>
> Coding with clear signals of intention is helpful, and too often overlooked.
> Conventional distinctions of intention among `defconst' vs `defvar'; `when' and
> `unless' vs `if' and `cond' vs `and' and `or'; and so on can make a big
> difference in code legibility. Which in turn eases maintenance and makes it less
> error-prone.

No two ways. I agree.

>
> Likewise, wrt names of functions, variables, etc.: good names help maintainers
> and code borrowers. Likewise, comments - good ones. Likewise, indenting and
> whitespace generally.
>
> All of these things are for human readers of code only. You, like the Lisp
> reader, can do without them if you like. YMMV.

I don't think anyone would disagree. But this is really a lecture on
clear, structured programming for beginners and not really that
relevant to the specifics of LISP constants in question.

>
> [I knew an excellent (in individual terms) Lisp programmer back in the 80s who
> never used any whitespace that wasn't strictly needed for the Lisp reader and
> never commented any code. He (almost) never hit the Return key. Needless to say,
> no one else could work with his code. He did use reasonable names, however, and
> he didn't use the same conditional (e.g. `if' or `cond') everywhere. He coded in
> the way that was easiest to him and that got the point across to the Lisp
> reader.]

He sounds like a terrible programmer. Programmers that write for
themselves are a curse. Maintenance time exceeds initial development
time by factors of 10 or 100 in most cases.

>
> Perhaps you have another question:
> Q. Why isn't it enforced?  A. Lisp.
>

Not really. It's not a constant. Having the specific type and then being
able to modify it proves that. You would be as well sticking CONST as the
name prefix as far as the language goes. As clear.

But yes, of course I agree with your comments on "intent". But it
strikes me that its no more effective than, say requiring a file called
"myconstants" that has a bunch of variables.

So really the question would be : why does Lisp not enforce constants
being, err, constant? 





  reply	other threads:[~2009-05-10 17:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-10 15:25 Working with constansts Decebal
2009-05-10 16:19 ` Pascal J. Bourguignon
2009-05-10 16:20   ` Richard Riley
2009-05-10 16:33     ` Pascal J. Bourguignon
2009-05-12 10:34       ` Nikolaj Schumacher
2009-05-10 17:02     ` Drew Adams
2009-05-10 17:28       ` Richard Riley [this message]
2009-05-11  7:39         ` Tassilo Horn
     [not found]       ` <mailman.6953.1241976532.31690.help-gnu-emacs@gnu.org>
2009-05-10 18:17         ` Pascal J. Bourguignon
2009-05-11  1:36           ` Richard Riley
2009-05-11  6:29             ` Pascal J. Bourguignon
2009-05-12 10:06               ` Nikolaj Schumacher
     [not found]               ` <mailman.7056.1242122790.31690.help-gnu-emacs@gnu.org>
2009-05-12 11:54                 ` Pascal J. Bourguignon
2009-05-18 10:55                   ` Nikolaj Schumacher
     [not found]                 ` <7ceiuuczad.fsf@pbourguignon.informatimago.com>
     [not found]                   ` <mailman.7379.1242644154.31690.help-gnu-emacs@gnu.org>
2009-05-18 12:20                     ` Pascal J. Bourguignon
2009-05-18 19:19                       ` Nikolaj Schumacher
2009-05-10 18:59         ` Barry Margolin
2009-05-11  1:38           ` Richard Riley
2009-05-12  9:44             ` Nikolaj Schumacher
     [not found]             ` <mailman.7052.1242121473.31690.help-gnu-emacs@gnu.org>
2009-05-12 11:43               ` Pascal J. Bourguignon
2009-05-13  4:59               ` Barry Margolin
2009-05-13 13:41                 ` Ralf Wachinger
2009-05-13 21:23                   ` Barry Margolin
2009-05-11  9:58     ` Thien-Thi Nguyen
     [not found]     ` <mailman.6988.1242036217.31690.help-gnu-emacs@gnu.org>
2009-05-12  1:31       ` Barry Margolin
2009-05-11  8:27   ` Decebal
2009-05-12  9:46     ` Nikolaj Schumacher
2009-05-10 16:31 ` Drew Adams

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

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

  git send-email \
    --in-reply-to=4a070ecc.0c58560a.2fff.1683@mx.google.com \
    --to=rileyrgdev@googlemail.com \
    --cc=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.