From: Richard Riley <rileyrgdev@googlemail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Working with constansts
Date: Mon, 11 May 2009 03:36:13 +0200 [thread overview]
Message-ID: <gu7vef$j7j$1@news.motzarella.org> (raw)
In-Reply-To: 874ovszuu3.fsf@galatea.local
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Richard Riley <rileyrgdev@googlemail.com> writes:
>>> [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.
>
> pprint. To me he sounds like a very good programmer. There's no point
> in doing something that a simple function can do for you...
Hold on.
I agree with concise and clean code.
But blatant showing off with NO whitespace or use of return code is the
sign of, frankly, a loony.
>
>
>>> 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?
>
>
> In the case of emacs lisp, it's because the constant is still refered
> to, even in compiled code, thru the constant name. So if the value
> bound to the symbol change, it will change instantaneously for all the
> functions that us it.
>
> If you consider that emacs is usually a long running process that the
> user is continuously modifying, it's rather a good thing: it means you
> don't have to recompile everything when you correct the value of a
> constant.
>
>
>
> But you asked about Lisp.
>
>
> We'd have to do a study of the numerous remaining lisp dialects still
> in existance, but to take the example of Common Lisp, its standard
> specifies that you shouldn't modify the value of a constant, and that
> implementations are free to do whatever they want if you do. Indeed,
> some implementation behave like emacs lisp (eg. clisp, which has
> basically the same architecture as emacs lisp: both use a virtual
> machine and a byte code compiler). On the other hand, in the case of
> sbcl, which uses a native code compiler, the constants are inlined and
> if you change them, it won't recompile automatically the code that
> depend on them, so you may get inconsistencies. But it doesn't
> matter, since you shouldn't do that anyways. If you really want to
> change the value of a constant, you should recompile your system and
> reload it. (Or else, don't use constants, so the new value of
> variables may be taken into account immediately without
> recompilation).
Which was basically my original question.
If you go to the bother of having a "const xyz" implementation then it
seems to me slightly silly not to enforce it.
Of course I understand if the answer is "history and that's the way it
is" but I would sympathise with a new programmer to Lisp that is
surprised he can modify a "const" especially if he came from a C/C++
background where we all fully understand WHY consts are useful for the
programmer but the compiler also enforced it.
--
next prev parent reply other threads:[~2009-05-11 1:36 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
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 [this message]
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='gu7vef$j7j$1@news.motzarella.org' \
--to=rileyrgdev@googlemail.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.