Re: Working with constansts

[Barry Margolin]

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