I'm intrigued that Python has some functional constructions in the language.

Discussion in 'Python' started by Casey Hawthorne, May 8, 2009.

  1. I'm intrigued that Python has some functional constructions in the
    language.

    Would it be possible to more clearly separate the pure code (without
    side effects) from the impure code (that deals with state changes,
    I/O, etc.), so that the pure code could be compiled and have
    aggressive functional transformations applied to it for efficiency.

    That way, the syntax would be a lot easier to understand, than most
    functional languages, like Haskell.

    I gave a presentation at the beginning of last year on Haskell and at
    the end, someone's comment was, "I can see the benefits of functional
    programming but why does it have to be so cryptic."
     
    Casey Hawthorne, May 8, 2009
    #1
    1. Advertisements

  2. Casey Hawthorne

    pruebauno Guest

    Don't forget that the Python interpreter is simple. It makes
    maintenance easier and allows embedding it into other programs. Good
    optimizing compilers for functional languages are not simple. Your
    idea would be something that could be added to the PyPy project in the
    future.
     
    pruebauno, May 8, 2009
    #2
    1. Advertisements

  3. Casey Hawthorne

    Carl Banks Guest

    No not really, at least not in any way that it maintains compatibility
    with Python.

    Python does either expose or mimic the parsing process to the user, so
    you could maybe exploit it to get parse trees of functions (checking
    that there is nothing that has side-effects) to feed to a specialized
    optimizer, but if you do that it might as well be a new langauge.

    A couple thoughts:

    1. It's just one person's opinion.
    2. However, functional programming is cryptic at some level no matter
    how nice you make the syntax.


    Carl Banks
     
    Carl Banks, May 8, 2009
    #3
  4. Lawrence D'Oliveiro, May 8, 2009
    #4
  5. Casey Hawthorne

    Carl Banks Guest

    For mere function application you could maybe argue that (and it'd be
    a stretch), but there is no reasonable way to claim that syntax is
    meaningless for defining functions. Unless you meant "function
    declaration", and I think you did because you don't seem to know what
    functional programming is.
    No it's nothing like that at all.
    That's not what functional programming means, nor is it remotely
    comparable to functional programming.
    Well, that's not true since I found it to be quite a different
    experience to invoke Microsoft library functions in JScript than in
    Visual Basic. (Mostly because it's a PITA even to "barely use any
    syntax or intrinsic language feature" of Visual Basic.)

    However, that has nothing to do with functional programming.


    Carl Banks
     
    Carl Banks, May 8, 2009
    #5
  6. Casey Hawthorne

    namekuseijin Guest

    namekuseijin, May 9, 2009
    #6
  7. Casey Hawthorne

    namekuseijin Guest

    My point is that when all you do is call functions, syntax is
    irrelevant. You call functions pretty much in the same way regardless
    of language: functionname, optionalOpenPar, parameters,
    optionalClosePar. Office automation is all about calling predefined
    functions in the host application, that's all my example was about.

    Functional programming is all about defining functions and applying
    functions. Core ML, Haskell and Scheme are all like that, pretty much
    an extended lambda calculus. Haskell provides a bunch of syntatic
    sugar, more so than Scheme for instance, but in the end, it all gets
    converted into lambda expressions and application of arguments to
    lambda expressions.

    Python has a bunch of handy predefined syntax, because not everything
    can be defined out of functions alone. Syntax is much more important
    here than in true functional programming languages, where pretty much
    everything besides basic "if" branching is a "userland" function --
    including looping constructs. I have written my own list
    comprehensions and generators in Scheme!

    When you read a Haskell or Scheme program, it's truly hard to spot
    predefined syntax: most of it is composable function application.
    Once in a while you spot an "if".
    Not quite Word, but here's in OpenOffice scripted either in BeanShell,
    JScript and Java:
    http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Scripting/Writing_Macros

    oDoc = context.getDocument();
    xTextDoc = (XTextDocument) UnoRuntime.queryInterface
    (XTextDocument.class,oDoc);
    xText = xTextDoc.getText();
    xTextRange = xText.getEnd();
    xTextRange.setString( "Hello World (in BeanShell)" );

    oDoc = XSCRIPTCONTEXT.getDocument();
    xTextDoc = UnoRuntime.queryInterface(XTextDocument,oDoc);
    xText = xTextDoc.getText();
    xTextRange = xText.getEnd();
    xTextRange.setString( "Hello World (in JavaScript)" );

    XTextDocument xtextdocument = (XTextDocument) UnoRuntime.queryInterface
    (
    XTextDocument.class,
    xDocModel);
    XText xText = xtextdocument.getText();
    XTextRange xTextRange = xText.getEnd();
    xTextRange.setString( "Hello World (in Java)" );

    Although this is a bad example because of the closeness of syntax
    between the languages, it would not be much different in a completely
    alien language. It would still make a call to get the data model of
    the current document, another to get the text, another to get the end
    and another to set the string. It's all function calls, really.

    No, it's not functional programming, but it illustrates what I said:
    when all you do is call functions, syntax is irrelevant.
     
    namekuseijin, May 9, 2009
    #7
  8. Casey Hawthorne

    Paul Rubin Guest

    This doesn't fit Python semantics terribly well.
    I don't think it would help much, even if it was done (see below).
    Haskell's syntax (like Python's or Lisp's) takes a little getting used
    to, but in my experience it's not really cryptic. IMHO, functional
    programming is difficult for imperative programmers to understand at
    first, because the concepts in it are really different from what
    imperative programmers are generally used to, and that take some head
    scratching to make sense of. Think of a beginning imperative
    programmer encountering recursion or coroutines for the first time, or
    how someone learning calculus deals with the concepts of limits and
    continuity. These subjects have certain hurdles that require effort
    to get past, but which expand the range of problems that someone who
    has put in the effort can solve. Functional programming presents more
    such hurdles, and more such expansion.
     
    Paul Rubin, May 9, 2009
    #8
  9. Casey Hawthorne

    Carl Banks Guest

    Yet all three use a different syntax to call functions, none of them
    the "pretty much the same way" you listed above.

    Haskell, Python, and (I think) ML can define operators with different
    syntax than function calls, that matters.

    Haskell and Python have syntax for list operations, that matters.

    Haskell nexts using indentation, the others nest using tokens(**),
    that matters.

    I can go on, but you get the idea. Point is: functional programmint
    isn't "nothing but calling functions".

    [snip irrelevant stuff about office scripting]

    Carl Banks

    (**) Python does using indentation to nest, of course, but not at the
    expression level.
     
    Carl Banks, May 9, 2009
    #9
  10. Casey Hawthorne

    Paul Rubin Guest

    I would mainly describe functional programming as programming with the
    pervasive use of higher order functions. For example, loops in
    functional programming can be implemented using recursion, but in
    practice, one doesn't see actual explicit recursion in Haskell code
    all that often. Instead we see wide use of functions like map,
    filter, and fold (a/k/a "reduce"), which can take the place of looping
    constructs.

    Python also has higher-order functions like that, but their use is
    disfavored in certain circles. With Python 3, there has actually been
    movement towards removing them from the language.
     
    Paul Rubin, May 9, 2009
    #10
  11. Casey Hawthorne

    namekuseijin Guest

    It's still functionName arguments AFAIK. Some using parentheses
    around the arguments, some around all, some not using parentheses at
    all.
    In Haskell, Lisp and other functional programming languages, any extra
    syntax gets converted into the core lambda constructs. In Lisp
    languages, that syntax is merely user-defined macros, but in Haskell
    it's builtin the compiler for convenience.
    Oh yes, functional programming is all about function definition and
    function calling. You have a point about higher order functions, but
    that's really only useful as far as your lambda expressions are useful
    -- that is, conveniently defining anonymous functions on-the-fly and
    immediately applying them.
     
    namekuseijin, May 9, 2009
    #11
  12. Casey Hawthorne

    Lie Ryan Guest

    Choosing a better algorithm usually have much more impact on efficiency
    than programming to the language's optimization scheme. A slow algorithm
    will always be slow no matter how much (functional or regular)
    optimization in it[1]. If you bother efficiency that much, maybe python
    is not the best suited language for you.
    Python's syntax is already easier to understand than most functional
    language, and it also support functional-style programming. However,
    python is still an imperative language, no matter how much functional
    functionalities (pun not intended) is in it.


    [1] of course there are certain types of optimizations -- that actually
    changes the algorithm -- that may have a significant impact, such as
    memoization. However if you know memoization well enough, you wouldn't
    want to activate it on all pure functions...
     
    Lie Ryan, May 9, 2009
    #12
  13. In message <692b7ae8-0c5b-498a-
    That was an example of functional programming.
     
    Lawrence D'Oliveiro, May 9, 2009
    #13
  14. Casey Hawthorne

    Carl Banks Guest

    Some using commas, some not, some grouping arguments by arity, some
    not, some allowing keyword argument, some not, etc. Point is, even
    the thing you claim hardly varies between languages does vary a
    significant bit, but it's not nearly as much as other syntactic
    differences in functional languages.

    So? The user still uses that syntax, so how can you claim it doesn't
    matter?

    I don't even know what you're saying here

    Fine.

    Functional programming isn't "nothing but calling functions USING
    FUNCTION-CALL SYNTAX".

    I made no such point. You may be confusing me with Paul, and I can't
    imagine what higher-order functions have to do with whether syntax is
    important or not.


    Carl Banks
     
    Carl Banks, May 9, 2009
    #14
  15. How do you call functions without syntax? By mental telepathy? By direct
    manipulation of the electromagnetic fields inside the CPU?

    But it takes syntax in order to write function composition. There's at
    least six ways of doing function composition:

    f(g(x)) # used in many programming languages and mathematics
    f . g (x) # Haskell
    f o g (x) # mathematics
    g f # stack-based languages like Forth
    g x | f # Unix-like shells
    compose(f, g)(x) # possible in many languages.
    I think your point is wrong. Without syntax, there can be no written
    communication. In Haskell, f.g is not the same as f+g -- the difference
    is one of syntax.
     
    Steven D'Aprano, May 9, 2009
    #15
  16. Casey Hawthorne

    Paul Rubin Guest

    In Haskell, (+) and (.) are both functions. (+) takes two numbers as
    arguments and returns their sum. (.) takes two functions as arguments
    and returns a new function which composes f and g. 2 + 3 is the same
    as (+) 2 3. f . g is the same as (.) f g. The infix notations
    are considered syntax sugar. The parentheses around (+) and (.)
    are so the compiler doesn't get lexically confused, but you could say

    add = (+)
    compose = (.)
    a = add 2 3
    b = compose square cube
    c = b 2

    now "print a" will print 5, and "print c" would print 64 (which is 2**6).
    (There aren't actually builtins square and cube, but pretend there are).

    So it's really true you can get rid of almost all Haskell expression
    syntax. There's actually a preprocessor called Liskell that lets you
    write Haskell as Lisp-like S-expressions, which is handy if you want
    to use a macro processor on it.
     
    Paul Rubin, May 9, 2009
    #16
  17. "Left-parens op right-parens" is syntax.
    And what you've got left is syntax. Without syntax, how can you tell the
    difference between a meaningful character string and a jumble of random
    gibberish? Without syntax, how can you tell where one token finishes and
    the next begins?
     
    Steven D'Aprano, May 10, 2009
    #17
  18. Casey Hawthorne

    Carl Banks Guest

    Nope, sorry, you're ignoring half the problem here. Syntax is only
    irrelevant if you actually do do away with it. As long as syntax is
    there and people use it, then it matters, regardless of whether it all
    reduces to function calls.

    For a very benign example, consider the ways that Python and Haskell
    write listcomps:

    [ x for x in ss ]
    [ x | x <- ss ]

    One of these might be more readable than the other (I make no
    implication which); however, readability has nothing to do with
    whether the compiler internally reduces it to a function call or not.
    Readibility counts, therefore syntax matters.

    Now, maybe readability concerns don't matter to you personally, but it
    does matter to the OP, who is trying to advocate functional
    programming but is having difficulty because most purely functional
    languages have hideous minimalist syntax that turns people off.

    If that syntax could be made a little more readable and workable,
    maybe people wouldn't turn up their noses at it on first sight.

    I think you are overstating this by a lot.


    Carl Banks
     
    Carl Banks, May 10, 2009
    #18
  19. Casey Hawthorne

    Paul Rubin Guest

    I didn't say you could get rid of absolutely all of the syntax. Just
    most of it. All that stuff you'd write in Python with loops,
    if-statements, listcomps, etc. can be done with prefix function calls
    in Haskell.

    Haskell's type system, on the other hand, is much more complex than
    Python's, and writing out type specifications does require some syntax.

    Overall though, Haskell's syntax, either at the sugared or desugared
    level, is not very complicated. The hurdles to learning Haskell
    really are because the concepts it contains are really different than
    what most programmers are familiar with. It's not like many languages
    that contain familiar concepts wrapped in new syntax.
     
    Paul Rubin, May 10, 2009
    #19
  20. Casey Hawthorne

    Carl Banks Guest

    Syntax--the thing you claim doesn't matter--got in the middle because
    it was the main factor that drove the OP to look for alternatives to
    Haskell.

    That's what makes your entire argument ridiculous; you are making this
    theoretical argument like, "everything reduces to a function so it
    doesn't matter what syntax you use," yet people in the real world are
    out there trying to find alternatives because functional languages'
    syntax sucks so bad in general.

    You totally missed the point.

    The thing that would make the syntax a lot easier to understand is
    that it's in Python and not Haskell.

    The reason the OP was asking about separating pure code from impure
    was to see if some subset of Python could be used as a pure functional
    language, that way they could employ Python and its already-much-
    better-than-Haskell's syntax as a pedagogical replacement for Haskell.

    I am sure there are many people who think that even "f a b" is cryptic
    compared to "f(a,b)", but if that's the only issue it wouldn't be that
    big of a deal. It's not the only issue. When a language requires you
    to read and write stuff like "map :: (x -> y) -> f x -> f y" or "f [email protected]
    (x:xs) = x:s" then it's going to turn a lot of people off.


    Carl Banks
     
    Carl Banks, May 10, 2009
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.