all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: pjb@informatimago.com (Pascal J. Bourguignon)
To: help-gnu-emacs@gnu.org
Subject: Re: Working with constansts
Date: Sun, 10 May 2009 20:17:08 +0200	[thread overview]
Message-ID: <874ovszuu3.fsf@galatea.local> (raw)
In-Reply-To: mailman.6953.1241976532.31690.help-gnu-emacs@gnu.org

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...


>> 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).


-- 
__Pascal Bourguignon__


  parent reply	other threads:[~2009-05-10 18:17 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 [this message]
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=874ovszuu3.fsf@galatea.local \
    --to=pjb@informatimago.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.