suggestion for Python

[John Roth]

It's an interesting thought, certainly. I like the conciseness
involved. APL certainly looked like an interesting language,
although I never took the opportunity to really play with it.

Have you looked at the NumPy extension? It does a
great deal in the area of mathematical functionality.

John Roth

"François Miville-Dechêne" <fmiville at sympatico.ca> wrote in message
news:mailman.328.1067740216.702.python-list at python.org...
> I find your language very nice, it is actually more than three quarters
> of what I had been dreaming for years a programming language should be.
> But I mourn the passing of APL, another interpreted language.  I like
> interpreted languages, for they can be used in calculator mode, testing
> function after function without bothering to code long protocols in the
> language and outside it.
>
> One suggestion I would propose would be to make common operators
> distributive by enclosing them in square brackets.  For instance:
> [1, 3, 5, 7] [*] [1, 2, 1, 3] would be equivalent to
> [[1, 3, 5, 7][i] * [1, 2, 1, 3][i] for i in range(3)]
> In APL the common operators were implicitly distributive over vectors,
> but it is not possible for Python due to the more evident concatenation
> meaning of + and *.  The map function does the job for a user
> defined-function, as would do in this instance something like
> map(multiply, [1, 3, 5, 7], [1, 2, 1, 3]), but it is cumbersome to
> redefine simple operations.
>
> The same brackets enclosing the operator with a point could be used to
> define outer product: [1, 3, 5] [*.] [1, 3, 2] would be equivalent to
> the result:
> [[1, 3, 5], [3, 9, 15], [2, 6, 10]] (a regular matrix shorter to list
> than to express in the Python way).  The same brackets enclosing two
> operators separated by a point would do the job of the vector or matrix
> product:
> [1, 3, 5, 7] [+.*] [1, 2, 1, 2] would thus be
> sum (map(multiply, [1, 3, 5, 7], [1, 2, 1, 2]))
>
> I give very straightforward examples, but it is easy to imagine that
> those operators thus enclosed would not only apply to simple lists, but
> to matrices and tree-like structures defined as lists of lists, provided
> they have a common structural basis.
>
> One problem with Python is the necessity to define very short functions
> to enable operators to be the object of function of functions such as
> map.  Another problem is that common operators cannot be easily
> redifined onto larger mathematical objects one might conceive and could
> be defined by the means of classes.  This could be solved by setting
> that such functions named as add, mult, div, defined as two-parameter
> functions, would automatically correspond to the dyadic +, *, /, etc.
>
> And conversely, any name of a two-parameter function, let it be
> hypothenuse, would signify when enclosed in parentheses the
> corresponding dyadic operators.
>
> so that 3(hypothenuse)4 would be 5
>
> This would give Python all the advantages of late APL and much more, for
> APL could process only regular data structures such as matrices whereas
> Python is so good with data more to be encountered in real life such as
> ill-formatted texts to be divided in chapters, sections and subsections
> in order to fit in a certain software, just to name one intance, by the
> means of the use of reg exps and tree-processing.
>
> Thanks for your attention.  The sole objection to the development I
> propose for Python would be a certain loss of readability for persons
> not acquainted with the language, but reg exps are not that readable
> neither and yet what would we do without them?
>
>