> So I think we'd have to analyze the question more closely at some point.
> It is not a minor change to the semantics, and it does require changing
> (as Rich points out) the translate-to-Lisp package as well as the
> debugger, and checking existing code written in the Maxima language
> (e.g. the Share directories, not to mention user code) to see how it is
> affected. It is not something we can treat as a bug fix and rush into
> production.
>
> And frankly, there are lots of other weird things in Maxima
> semantics....
Shouldn't we make a TO-DISCUSS file of all those topics? I believe that it
would be a good thing to let everybody know what is planned with respect
to semantics. Probably some changes can not be done soon, but if they were
desirable, I think it would be good if we would at least know *precisely*
what is our (maybe long-term) future aim!
Thanks for explaining those implications to me!
By the way: (I hope I'm not being too annoying - please tell me)
> Stavros has said it pretty well. The difficulty in doing semantics right
> is illustrated by the fact that there are examples of problems in much
> more recently defined CAS languages, in particular Mathematica and
> Maple. Maple actually changed its scope rules recently. Mathematica now
> has Block and Module. Module[{x}..] creates a new symbol like x$123
> with (I think) global scope. Pattern matching also provides another
> peculiar twist: how does this interact with evaluation?
Isn't this a good approach?
And finally, thank you for
>> So, given
>>
>> list:[[5,6],[7,9]];
>>
>> I have to say
>>
>> mat:matrix(list[1],list[2]);
>
> That's one way. Other ways are apply('matrix,list) and
> substpart('matrix,list,0).
>
> For the reverse, to go from mat to list, you can do
> substpart("[",mat,0).
>
> For more fun, try apply("+",list), substpart("[",x+3,0), ....
that is precisly what I was after!
All the best, Martin