P: n/a

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
definedfunction, 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 treelike 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 twoparameter
functions, would automatically correspond to the dyadic +, *, /, etc.
And conversely, any name of a twoparameter 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
illformatted 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 treeprocessing.
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?  
Share this Question
P: n/a

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 MivilleDechêne" <fm******@sympatico.ca> wrote in message
news:ma************************************@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 definedfunction, 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 treelike 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 twoparameter functions, would automatically correspond to the dyadic +, *, /, etc.
And conversely, any name of a twoparameter 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 illformatted 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 treeprocessing.
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?
 
P: n/a

François MivilleDechêne wrote: 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.
The meat of this suggestion is what PEP 225 is about : http://www.python.org/peps/pep0225.html

Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Nothing is true  all is permissible.
\__/ Hassan i Sabbah  
P: n/a

François MivilleDechêne wrote: 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
Having worked a LOT with both APL and APL2 around 19771986, I don't
really mourn them at all (except when I'm in my cups, sometimes, but
then I'm mostly mourning the fact that 20 years ago I was younger:).
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 definedfunction, 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.
import operator
map(operator.mul, [1,3,5,7], [1,2,1,3])
and you're done. Or, to taste,
[ a*b for a, b in zip([1,3,5,7], [1,2,1,3]) ]
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
Yes, we do lack a _good_ syntax for "codeblock literals"  about a
month ago we were discussing possibilities quite actively here.
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 twoparameter functions, would automatically correspond to the dyadic +, *, /, etc.
Standard library module operator has those. But I'm not sure what you
mean by "redefined onto larger mathematical objects"  you can get
operator overloading on any type by defining __add__ __mul__ etc.
And conversely, any name of a twoparameter function, let it be hypothenuse, would signify when enclosed in parentheses the corresponding dyadic operators.
so that 3(hypothenuse)4 would be 5
Yep, Haskell has something like that, except that instead of
yet another overloading for parentheses (which have too many
already!) it uses `...` which in Python are an unfortunate and
useless duplciate for repr(...). However to make sense you need
to be able to define priority and associativity and that gets hairy.
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
APL2 could have arrays with each row a different length, which helped.
Python is so good with data more to be encountered in real life such as illformatted 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 treeprocessing.
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?
They're in a separate standard library module  the criteria are laxer.
Getting into core Python demands passing MUCH stricter tests on all scores.
Alex   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 1638
 replies: 3
 date asked: Jul 18 '05
