Re: Working with constansts

[Richard Riley <rileyrgdev@googlemail.com>]

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.


--