Dear Vardim san, James Amundson san,
Sorry for the late replay... and thanks for your comments.
Yes. That is what I am proposing.
There are several issues regarding this approach, so this change needs
further considerations.
- There are more places in which the function INTERN is used other than
the function IMPLODE in commac.lisp. Actually simple grep found 57
use cases of the INTERN function. I need to look into them if I need to
modify them or not.
- I need a way to determine which are system symbols and which are not.
James suggested in other mail to modify defmfun to export all the maxima
functions. But clearly that is not enough. Symbols such as "do", "in",
"for"
also should be exported as well. I actually think that all the symbols
that
are defined in the manual (and that are well tested) should be exported.
- This changes the relation between packages used in maxima. I feel,
before designing the modification of maxima along this line, I should
write up current status of packages used in maxima, how they are related
with each other.
- It looks like maxima supports maxima to lisp translator. I haven't
looked into
this part of maxima and don't know anything at all. I need to consider
which
package (maxima-user or maxima) to be used for translated lisp code and
modify the translator to properly generate package related declarations.
- I feel I should also consider the future package rules for the
extensions
written in lisp (such as numerical routines for special functions as
discussed
in other threads). Should such extensions use their own package? Should
such a package be imported into maxima-user package? I need to have
answers (or proposals).
Anyway, I think this is a very correct way to clarify the symbol
treatment
in Maxima. I will write up:
(1) Current package usage in Maxima, and
(2) Modification design document which covers above issues.
Yasuaki Honda
Independent Developer
Chiba, Japan
On 2002.03.21, at 19:18, Vadim V. Zhytnikov wrote:
> Do I understand correctly the scheme you propose -
> all global system symbols like sin, tan etc.
> must be explicitly exported?
>
> After some thinking over it seems that
> this is right approach.
>
> Yasuaki Honda wrote:
>
>> Dear all,
>>
>> I have started to do a feasibility study along the line with what
>> Raymond Toy san has suggested, namely the use of maxima-user
>> package to solve this issue (recorded as bug No. 530030).
>>
>> Attached is a short lisp program which implements suggested
>> maxima-user package system and a simplified maxima top level
>> to see if it works at least theoretically.
>>
>> If this way looks good for other people, too, then I will start to
>> design
>> necessary modifications to maxima.
>>
>> Any comments are welcome.
>>
>> Yasuaki Honda
>> Independent Developer,
>> Chiba, Japan
>>
>> -----------------------------------------------------------------
>> Name: maxima-user-package.lisp
>> maxima-user-package.lisp Type: unspecified type
>> (application/octet-stream)
>> Encoding: 7bit
>>
>> -----------------------------------------------------------------
>>
>> On 2002.03.15, at 04:02, James Amundson wrote:
>>
>>> The summary given below is very good. I especially like the short
>>> version:
>>>
>>>> I believe this is somewhere in between a bug and spec.
>>>
>>> Exactly.
>>>
>>> I think the time has come to address this surprising behavior in
>>> Maxima.
>>> Suggestions are welcome. (Thank you Ray, for starting...)
>>>
>>> --Jim
>>>
>>> On Thu, 2002-03-14 at 09:05, Yasuaki Honda wrote:
>>>> Dear Daniel,
>>>>
>>>> I believe this is somewhere in between a bug and spec.
>>>>
>>>> In the Maxima manual "Lisp and Maxima" it says:
>>>>
>>>> "If you intend to write lisp functions to be called at macsyma level
>>>> you
>>>> should name them by names beginning with a "$". Note that all symbols
>>>> typed at lisp level are automatically read in upper case, unless you
>>>> do
>>>> something like |$odeSolve| to force the case to be respected. Maxima
>>>> interprets symbols as mixed case, if the symbol has already been read
>>>> before or at the time it was first read there was not an already
>>>> existing symbol with the same letters but upper case only. Thus if
>>>> you
>>>> type
>>>>
>>>>
>>>> (C1) Integrate;
>>>> (D1) INTEGRATE
>>>> (C2) Integ;
>>>> (D2) Integ
>>>>
>>>>
>>>> The symbol Integrate already existed in upper case since it is a
>>>> Maxima
>>>> primitive, but INTEG, does not already exist, so the Integ is
>>>> permitted.
>>>> This may seem a little bizarre, but we wish to keep old maxima code
>>>> working, which assumes that Maxima primitives may be in upper or
>>>> lower
>>>> case. An advantage of this system is that if you type in lower case,
>>>> you
>>>> will immediately see which are the maxima keywords and functions. "
>>>>
>>>> So, in your example, y1 is regarded as a Maxima primitive while y0 is
>>>> not. How this happens?
>>>> The answer is also in the above quote. A lisp symbol $Y1 is already
>>>> read
>>>> before Maxima starts
>>>> the command line input, while $Y0 is never read before. If you take a
>>>> look at line 853 of ode2.lisp,
>>>> lisp symbols such as $Y1, $Y2, $Y3, $Y4, $WR, $HEURISTIC, $%K1, $%K2
>>>> are
>>>> used. This is where
>>>> these symbols are read (or interned, in the lisp language term).
>>>>
>>>> You may try:
>>>> (C11) [y0, y1, y2, y3, y4, y5];
>>>> (D11) [y0, Y1, Y2, Y3, Y4, y5]
>>>>
>>>> This is exactly the behavior specified in the manual as quoted above.
>>>> So
>>>> someone may call
>>>> it a part of the spec. At the same time, any of y0 through y5 cannot
>>>> be
>>>> regarded as Maxima
>>>> primitives. So someone may call it a bug.
>>>>
>>>> The logic above is implemented by the lisp function bothcase-implode
>>>> defined in commac.lisp.
>>>>
>>>> Yasuaki Honda
>>>> Independent Developer,
>>>> Chiba, Japan
>>>>
>>>> On 2002.03.13, at 09:00, Daniel Lemire wrote:
>>>>
>>>>> From a recent CVS build:
>>>>>
>>>>> (C5) [y0,y1];
>>>>>
>>>>> (D5) [y0, Y1]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Maxima mailing list
>>>>> Maxima@www.math.utexas.edu
>>>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Maxima mailing list
>>>> Maxima@www.math.utexas.edu
>>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>
>>> _______________________________________________
>>> Maxima mailing list
>>> Maxima@www.math.utexas.edu
>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>
>
> --
> Vadim V. Zhytnikov
>
> <vvzhy@mail.ru>
> <vvzhy@td.lpi.ac.ru>
> <vvzhy@yandex.ru>
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>