From: Charles Hixson <charleshixsn@...>
Date: 2004-10-09T06:17:22+09:00
Subject: Re: ANN: Free-form-operators patch

Randy W. Sims wrote:

> Charles Hixson wrote:
>
>> | .< 1 + 3, 5 * 2, 6 / 3 >. .<n21, n22, n23>. .<n31, n32, n33>. | .*. M
>
>
> A perfect example of why free-form-operators are a bad idea. ;-)
>
> No offense intended. It's just that custom notations are not obvious 
> to readers/maintainers of the code. Also, adding such flexibility to 
> the parser means it is probably less capable of recognizing and 
> diagnosing errors. Then there is the problem of clashes when multiple 
> extensions try to define the same ops for entirely different operations.
>
> Regards,
> Randy.

And your proposed method of representing a matrix is??
I don't find:

M.backCross([[1 + 3, 5 * 2, 6 / 3 ], [n21, n22, n23], [n31, n32, n33] ] )

to be very intelligible, even if I wrote it.  Do remember that matrix 
multiplication isn't commutative, so the order is very significant.  The 
list ISN'T a matrix.  It's a double list.  Quite a different beast.  One 
can't make the same assumptions about it's organization, contents, etc.  
And one doesn't want to define a matrix mulitplication on a list, 
without being certain that it's a matrix.

I suppose one could do
Matrix([[1 + 3, 5 * 2, 6 / 3 ], [n21, n22, n23], [n31, n32, n33] ] 
).cross(M)
which is a bit better, but not very good.  (It couldn't really be the 
Matrix class.  That name is already taken, and doesn't act the way I 
want.  I use it because it's intelligible with minimal explanation.)

Specialized areas create specialized representations for very good 
reasons.  That you don't want to use them doesn't make them bad 
representation, it means that you don't work in that area.  Logicians 
worked a long time developing good representation for symbolic logic.  
They still don't have good translations into programming languages, even 
though programming is an outgrowth of the same field.  Not being able to 
create representations for specialized forms cripples the development of 
a field.  That some bad representations will be created along the way 
is, unfortunately, inevitable.  It doesn't mean that allowing the 
expression is bad, merely that developing good expressions is difficult.

Consider the number of flawed programs that are written.  Extending your 
argument only slightly would argue against allowing any programming 
languages to exist.