[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working with constansts
From: |
Barry Margolin |
Subject: |
Re: Working with constansts |
Date: |
Wed, 13 May 2009 17:23:39 -0400 |
User-agent: |
MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) |
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 ***
- Re: Working with constansts, (continued)
- Message not available
- Message not available
- Message not available
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/18
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/18
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/10
- Re: Working with constansts, Richard Riley, 2009/05/10
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/12
- Message not available
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/12
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/13
- Re: Working with constansts, Ralf Wachinger, 2009/05/13
- Re: Working with constansts,
Barry Margolin <=
- Re: Working with constansts, Thien-Thi Nguyen, 2009/05/11
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/11
Re: Working with constansts, Decebal, 2009/05/11