From: Barry Margolin <barmar@alum.mit.edu>
To: help-gnu-emacs@gnu.org
Subject: Re: Working with constansts
Date: Wed, 13 May 2009 17:23:39 -0400 [thread overview]
Message-ID: <barmar-9F89AB.17233913052009@mara100-84.onlink.net> (raw)
In-Reply-To: 20090513.geh.3ab9xhlg.2@wachinger.fqdn.th-h.de
In article <20090513.geh.3ab9xhlg.2@wachinger.fqdn.th-h.de>,
Ralf Wachinger <rwnewsmampfer@geekmail.de> wrote:
> * Barry Margolin wrote:
>
> > In article <mailman.7052.1242121473.31690.help-gnu-emacs@gnu.org>,
> > Nikolaj Schumacher <me@nschum.de> wrote:
> >
> >> Richard Riley <rileyrgdev@googlemail.com> wrote:
> >
> >>> I don't know enough about Lisp than I can only assume that in this case
> >>> it can not be detected at compile time IF you compile to byte/p code.
> >>
> >> "Thanks" to dynamic scoping it cannot be caught at compile time.
> >
> > It could at least generate a warning.
> >
> >> (defconst xxx nil)
> >>
> >> (defun change-xxx ()
> >> (setx xxx t)) ;; const or variable?
> >>
> >> (let ((xxx nil))
> >> (change-xxx))
> >
> > This should also warn about binding a constant.
>
> This recalls the discussions on constants (general), getters and setters
> (OOP) in Python to my mind. Functions as wrappers to enforce the
> intentions of the programmers. There are no constants (and even no
> declarations) in Python, there's only the convention to write intended
> constants in capitals.
We also have naming conventions in Lisp: *var* for global variables,
+var+ for constants (although this convention postdates the Common Lisp
specification, so none of the constants defined in the language follow
it).
>
> For class and instance attributes there are no private, protected or
> public declarations (you can even add attributes from outside later) in
> Python, there's only a convention to start the intended non-public
> attributes with an underline character.
CLOS is similar, there's no information hiding. Packages are usually
used to distinguish the public vs internal interfaces, but the CL
package system doesn't prevent outsiders from accessing non-exported
symbols.
>
> "The pythonic way" informs the users about the intentions, it doesn't
> restrict the users. I see that Python and Elisp have a pretty similar
> concept on the whole, both are very dynamic and unrestricted.
The reason for Common Lisp's restrictions on constant is to give more
flexibility to implementors, to allow for better optimization. By
prohibiting assignment to constants, the compiler can perform inline
substitution.
This is less of an issue for interpreted languages, so they tend to be
more permissive.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
next prev parent reply other threads:[~2009-05-13 21:23 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
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 [this message]
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=barmar-9F89AB.17233913052009@mara100-84.onlink.net \
--to=barmar@alum.mit.edu \
--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.