suggestion for Python

Discussion in 'Python' started by =?iso-8859-1?Q?Fran=E7ois=20Miville=2DDech=EAne?=, Nov 2, 2003.

  1. 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] * [1, 2, 1, 3] 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?
    =?iso-8859-1?Q?Fran=E7ois=20Miville=2DDech=EAne?=, Nov 2, 2003
    #1
    1. Advertising

  2. =?iso-8859-1?Q?Fran=E7ois=20Miville=2DDech=EAne?=

    John Roth Guest

    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" <> wrote in message
    news:...
    > 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] * [1, 2, 1, 3] 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?
    >
    >
    John Roth, Nov 2, 2003
    #2
    1. Advertising

  3. François Miville-Dechê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/pep-0225.html

    --
    Erik Max Francis && && 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
    Erik Max Francis, Nov 2, 2003
    #3
  4. François Miville-Dechê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 1977-1986, 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] * [1, 2, 1, 3] 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.


    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 two-parameter
    > 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 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


    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
    > 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?


    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
    Alex Martelli, Nov 2, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christos TZOTZIOY Georgiou

    Suggestion for two additions to the Python FAQ

    Christos TZOTZIOY Georgiou, Nov 19, 2003, in forum: Python
    Replies:
    0
    Views:
    277
    Christos TZOTZIOY Georgiou
    Nov 19, 2003
  2. Ville Vainio

    Ruby blocks in Python, a suggestion

    Ville Vainio, Apr 7, 2004, in forum: Python
    Replies:
    37
    Views:
    922
    Michele Simionato
    Apr 17, 2004
  3. Stewart Midwinter
    Replies:
    4
    Views:
    506
  4. Anonymous Bastard

    Suggestion: Python global scope

    Anonymous Bastard, Jul 15, 2008, in forum: Python
    Replies:
    5
    Views:
    442
    alex23
    Jul 16, 2008
  5. Vlastimil Brom
    Replies:
    0
    Views:
    256
    Vlastimil Brom
    Sep 16, 2010
Loading...

Share This Page