Wiki article about maxima's treatment of arrays and functions?

>
>
>My suggested approach to some of these issues is to provide a model for a
>program that works, essentially deprecating certain features that you think
>will be confusing. Especially if those features have been supplanted by
>better features.  That way you don't have to go through a long explanation,
>at least at that spot, why something is "bad". 
>
>Thus I might recommend that it is good to separate your indeterminates from
>your program variables. Maybe refer to a discussion of evaluation and scope
>and such, somewhere else.
>
> Or why subst  is preferable to ev,  or how to extract pieces of an
>expression using inpart rather than part or [].
>
I think as long as the lexical vs dynamic binding issue is not resolved 
it will
be impossible to write robust programs in the maxima language anyway. 
So I don't think there is much point in trying to explaining why some  
constructs
work somewhat better than others. Lexical binding will make the evaluation
issue moot since it will be clear from the syntactic structure of a program
in which scope expressions will be evaluated.

The functions/array issue is different. This is manageable as long as 
you know
what goes on. That's why I would like to explain that.

Creating a namespace for program variables is what I do currently. I write
my variables as "some_identifier__", hoping that the user will
not  use these symbols in his expressions (maybe some type of freeof test
could enforce this, but it's messy).

Michel