Functional programming in Python

brk@jenkon.com brk@jenkon.com
Tue, 22 May 2001 10:00:28 -0700


> -----Original Message-----
> From:	Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au]
> Sent:	Tuesday, May 22, 2001 6:55 AM
> To:	pk@cs.tut.fi
> Cc:	haskell-cafe@haskell.org
> Subject:	Re: Functional programming in Python
>=20
> Pertti Kellom=E4ki <pk@cs.tut.fi> wrote,
>=20
> > > From: Ketil Malde <ketil@ii.uib.no>
> > > "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
> > > > You want to be able to write
> > >=20
> > > >   f 1 2 + g 3 4
> > >=20
> > > > instead of
> > >=20
> > > >   (f 1 2) + (g 3 4)
> > >=20
> > > I do?  Personally, I find it a bit confusing, and I still often =
get it
> > > wrong on the first attempt.=20
> >=20
> > Same here. A while back someone said something along the lines that
> people
> > come to Haskell because of the syntax. For me it is the other way
> around.
> > My background is in Scheme/Lisp, and I still find it irritating =
that I
> cannot
> > just say indent-sexp and the like in Emacs. It is the other =
properties
> of the
> > language that keep me using it. I also get irritated when I get
> > precedence wrong, so in fact I tend to write (f 1 2) + (g 2 3), =
which to
> > my eye conveys the intended structure much better and compiles at =
first
> try.
>=20
> In languages that don't use curring, you would write=20
>=20
>   f (1, 2) + g (2, 3)=20
>=20
> which also gives application precedence over infix
> operators.  So, I think, we can safely say that application
> being stronger than infix operators is the standard
> situation.
	[Bryn Keller] =20
	There's another piece to this question that we're overlooking, I
think. It's not just a difference (or lack thereof) in precedence, it's =
the
fact that parentheses indicate application in Python and many other
languages, and a function name without parentheses after it is a =
reference
to the function, not an application of it. This has nothing to do with
currying that I can see - you can have curried functions in Python, and =
they
still look the same. The main advantage I see for the Haskell style is
(sometimes) fewer keypresses for parentheses, but I still find it =
surprising
at times. Unfortunately in many cases you need to apply nearly as many
parens for a Haskell expression as you would for a Python one, but =
they're
in different places. It's not:

		foo( bar( baz( x ) ) )
	it's:
		(foo ( bar (baz x) ) )

	I'm not sure why folks thought this was an improvement. I suppose it
bears more resemblance to lambda calculus?


> Nevertheless, the currying notation is a matter of habit.
> It took me a while to get used to it, too (as did layout).
> But now, I wouldn't want to miss them anymore.  And as far
> as layout is concerned, I think, the Python people have made
> the same experience.  For humans, it is quite natural to use
> visual cues (like layout) to indicate semantics.
	[Bryn Keller] =20
	Absolutely. Once you get used to layout (Haskell style or Python
style), everything else looks like it was designed specifically to =
irritate
you. On the other hand, it's nice to have a brace-delimited style since =
that
makes autogenerating code a lot easier.

	Bryn



> Cheers,
> Manuel
>=20
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe