1. I like making protect available, since it solves a problem.
And if someone wants to read lisp code into his Maxima that works
for him, who can order him to stop?!?
2. I agree that there are issues, some of which have not yet
been mentioned, so I'll mention those that come to mind.
If p is protected, can you do assume(p>0)? declare(p,float)?
That is, do
you protect only the value, but not other properties?
Can you protect local symbols (e.g. within a block([p:34],protect(p)..))?
Can you protect one entry in an array or the whole array? or
neither?
The assume database has contexts. maybe the package issue is
related to this.
For what it is worth, I have always found the common lisp
package system to be difficult to understand, explain, and
use. Only some of these problems have to do with the fact
that it is different in CLtl1 and CLtL2.
RJF
C Y wrote:
>--- Stavros Macrakis <stavros.macrakis@verizon.net> wrote:
>
>
>>>if people are going to start creating custom packages for
>>>Maxima, this is likely to be a feature that will be of
>>>interest to at least some of them.
>>>
>>>
>>Whenever I hear a request for a new feature, the first thing I want
>>to know is *why* people want it. Because often it turns out that it
>>reflects a broader design issue, which could better be handled some
>>other way. For example, currently there is no such thing in Maxima
>>as a package with its own private information. There is no way to
>>declare some functions or variables "internal" and some "external".
>>
>>
>
>
>Um. By "internal" and "external" do you mean variables not accessable
>from the command prompt and used only internally, or variables defined
>(like the physical constant symbols) which are intended to be used at
>the command line and which it would be preferable to prevent or make
>difficult accidental assignment of new values?
>
>
>
>>Is that part of the motivation for protected variables? -- to avoid
>>accidental stomping on private information?
>>
>>
>
>In my particular case, it would be to avoid accidental stomping on
>public definitions made by a loaded package. I suspect the other case
>would also be of interest.
>
>
>
>>There is no such thing as persistent local state (own variables or
>>object state).
>>
>>
>
>That would be desirable, but how much of a redesign would be needed to
>accomidate it? Also I don't think a persistent local package state
>would allow for protected global definitions.
>
>
>
>>So instead of asking for features, I'd prefer it if people would
>>discuss the problem they are facing. If they can propose mechanisms
>>(features) for addressing those problems, that is good, too. But
>>those only make sense in the context of the original problem.
>>
>>
>
>OK, true. I guess my problem would be that I would like a way to
>define a constant a1, and then assign it a property so that if I
>inadvertantly reassign it later on in my session it doesn't just
>quietly get reassigned, but asks me first. That way, if I happen to be
>working on a problem involving lightspeed and have made the definition
>%c : 3*10^8*m/s I can't change the value of %c later in the problem
>without being aware of it. It is not essential, but would be a very
>convenient tool for larger problems where keeping track of all the
>assigned values is a bit tricky.
>
>CY
>
>P.S. One other trick that would be useful in this context is some kind
>of rollback command where I could say rollback(%c) and %c would be
>assigned the previous value it had. Does Maxima have anything like that?
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free web site building tool. Try it!
>http://webhosting.yahoo.com/ps/sb/
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>
>