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

[Casey Hawthorne]

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."

 

[pruebauno]

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."

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.

 

[Carl Banks]

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.

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.

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."

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

 

[Lawrence D'Oliveiro]

Carl Banks escreveu:


When your program is nothing but function definition and function
application, syntax is meaningless.

On the contrary, syntax is vital to the correct interpretation of functional constructs. See, for example,
<http://mail.python.org/pipermail/python-list/2008-October/683816.html>.

 

[Carl Banks]

Carl Banks escreveu:


When your program is nothing but function definition and function
application, syntax is meaningless.

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.

It's kinda like scripting, say, Microsoft Word in either Visual Basic,
Python, Haskell or whatever:

No it's nothing like that at all.

 you're just calling functions provided by
the host,

That's not what functional programming means, nor is it remotely
comparable to functional programming.

barely using any syntax or intrinsic language feature anyway.
  Any language will do just fine.

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

 

[namekuseijin]

On the contrary, syntax is vital to the correct interpretation of functional constructs. See, for example,
<http://mail.python.org/pipermail/python-list/2008-October/683816.html>.

Yeah, it's important in an imperative language to have predefined
syntax to allow you to do things. Point taken.

 

[namekuseijin]

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.


That's not what functional programming means, nor is it remotely
comparable to functional programming.

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".

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.)

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.

 

[Paul Rubin]

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.

This doesn't fit Python semantics terribly well.

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

I don't think it would help much, even if it was done (see below).

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."

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.

 

[Carl Banks]

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.
then...

Functional programming is all about defining functions and applying
functions.  Core ML, Haskell and Scheme are all like that,

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.

 

[Paul Rubin]

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

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.

 

[namekuseijin]

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

It's still functionName arguments AFAIK. Some using parentheses
around the arguments, some around all, some not using parentheses at
all.

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

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

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.

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

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.

 

[Lie Ryan]

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.

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.

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

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

 

[Lawrence D'Oliveiro]

In message <692b7ae8-0c5b-498a-

Yeah, it's important in an imperative language ...

That was an example of functional programming.

 

[Carl Banks]

It's still functionName arguments AFAIK.  Some using parentheses
around the arguments, some around all, some not using parentheses at
all.

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.

In Haskell, Lisp and other functional programming languages, any extra
syntax gets converted into the core lambda constructs.

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

 In Lisp
languages, that syntax is merely user-defined macros, but in Haskell
it's builtin the compiler for convenience.

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

Oh yes, functional programming is all about function definition and
function calling.

Fine.

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

 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.

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

 

[Steven D'Aprano]

I'm saying syntax is nothing special. They are user-defined, as
functions. And it all gets converted into functions. Functions matter,
syntax is irrelevant because you can do away with it.

How do you call functions without syntax? By mental telepathy? By direct
manipulation of the electromagnetic fields inside the CPU?

In Haskell, point free style of programming shows almost no signs of
predefined syntax at all. It's all function composition.

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.

In functional programming languages, predefined syntax is mostly
irrelevant. In Python and other imperative languages, it's absolutely
necessary. That's my point.

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.

 

[Paul Rubin]

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.

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.

 

[Steven D'Aprano]

In Haskell, (+) and (.) are both functions.

"Left-parens op right-parens" is syntax.

So it's really true you can get rid of almost all Haskell expression
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?

 

[Carl Banks]

I'm saying syntax is nothing special.  They are user-defined, as
functions.  And it all gets converted into functions.  Functions matter,
syntax is irrelevant because you can do away with it.

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.

In Haskell, point free style of programming shows almost no signs of
predefined syntax at all.  It's all function composition.

In functional programming languages, predefined syntax is mostly
irrelevant.  In Python and other imperative languages, it's absolutely
necessary.  That's my point.

I think you are overstating this by a lot.


Carl Banks

 

[Paul Rubin]

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?

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.

 

[Carl Banks]

BTW, rereading it again, the OP was originally questioning about
compiler optimizations for purely functional constructs within Python,
but somehow syntax got in the middle.

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.

I don't see how "syntax would be a lot easier to understand" if it would
"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."

Syntax would remain the same, I guess.

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 s@
(x:xs) = x:s" then it's going to turn a lot of people off.


Carl Banks