«

On Fri, 21 Sep 2007 22:07:55 +0000, Cristian wrote:

> True, there is lambda, but that is very limited. It might be useful for
> key arguments, but not much else.

No, lambda is useful for anything that any other function is useful for,
provided that you can write it as a single expression and not need to use
statements. In other words, a lambda function can do anything anything
any other function can, just less conveniently.

(To pick one example at random, you can use print with lambda:
http://northernplanets.blogspot.com/...th-lambda.html
and while it is easy it isn't exactly convenient.)

And that's basically why function definitions have the syntax they do,
because trying to hammer a multi-line function definition into a single
expression is painful.


> It doesn't solve the teaching problem
> of "See, functions are just like any other data type. You can assign it
> to a variable."


Is their interactive interpreter broken?


>>> def parrot(colour='red'):
.... return "I'm a parrot with %s plumage." % colour
....
>>> bird = parrot # note the lack of brackets
>>> type(bird)
<type 'function'>
>>> bird('green')
"I'm a parrot with green plumage."


Or using lambda:


>>> parrot = lambda colour: "I'm a parrot with %s plumage." % colour
>>> parrot("purple")
"I'm a parrot with purple plumage."



> It would be a footnote if it's mentioned at all. My hope
> is to subtly reinforce the notion that functions are data and can be
> passed around. The current function declaration doesn't help with this.

Some things just need to be learnt. I'm in favour of making languages
easy for newbies to learn, but making function and method definitions
harder to use just so newbies will be given a subtle reminder of
something that 80% of them will never notice or use anyway is a bad
trade-off.


> Creating a function and assigning it to a name is exactly what Python
> does, why not have it come out in the syntax? It's not necessary, yes,
> but I think it would be helpful for teaching purposes.

If people don't get it when you EXPLICITLY show them that functions are
first-class objects, how do you expect them to notice it on their own
based on the IMPLICIT similarities in syntax?




--
Steven.

Cristian wrote:
> On Sep 21, 3:44 pm, Ron Adam <r...@ronadam.com> wrote:
>
>> I think key may be to discuss names and name binding with your friend.

Here's an idea:

import math

def sin_integral(start, finish, dx):
total = 0.0
y0 = math.sin(start)
for n in range(1, 1 + int((finish - start) / float(dx))):
y1 = math.sin(start + n * dx)
total += (y0 + y1)
y0 = y1
return total / 2. * dx


def cos_integral(start, finish, dx):
total = 0.0
y0 = math.sin(start)
for n in range(1, 1 + int((finish - start) / float(dx))):
y1 = math.cos(start + n * dx)
total += (y0 + y1)
y0 = y1
return total / 2. * dx

generalize and separate the integration technique from the
function it integrates.

On Fri, 21 Sep 2007 19:52:41 -0400, Carl Banks wrote:

> First of all, let me say that I think "functions as first class data" is
> helpful, but not crucial, to programming in Python, and there are many
> people who simply don't need the lesson. Especially someone like an
> engineer (in the classical sense), who isn't building versatile software
> packages, won't need to resort to functional programming much.

Of course you don't *need* functional programming as in "there's no way
around it", but why are engineers such an exception!? I find the stuff in
`itertools` very handy when it comes to filter, manipulate, group and
aggregate data from large log files in ad hoc scripts. I'm not an
engineer but I guess there are similar tasks with log files or measurement
results.

> For straightforward tasks, like sorting lists with a custom ordering,
> functional progamming merely a convenience, and can be done without.

``for`` loops are just a convenience, you can do without.

Ciao,
Marc 'BlackJack' Rintsch

Carl Banks <> writes:
> Especially someone like an
> engineer (in the classical sense), who isn't building versatile software
> packages, won't need to resort to functional programming much.

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

On 22 Sep., 00:36, Cristian <super.sgt.pep...@gmail.com> wrote:

> Yeah, I agree, that does look pretty ugly. Correct me if I'm wrong,
> but I thought the way Python determines a block is by the whitespace
> of the first line. So, as long as the spacing (or !tabbing!) is
> consistent from line to line the parser will know it's part of the
> same block. From that I don't think the parser would have much trouble
> extracting the function definition from the above example. I would
> change the word "def". That's never been informative enough for me.

Here is the grammar:

http://svn.python.org/projects/stack...rammar/Grammar

If you feel you can transform it into another unambigous grammar
mixing statements and expressions it's up to you. Guido at least does
not seem to show interest:

http://www.artima.com/weblogs/viewpo...?thread=147358

When you are working on it you'll need a parser generator that also
checks your changes.
EasyExtend might help

http://www.fiber-space.de/EasyExtend/doc/EE.html

You can use it with Python 2.5, create a new fiber and a Grammar.ext
file. Note that the parser generator is LL(1) so it is not all
powerfull but *very* efficient. Tokenization is performed separately.
INDENT, DEDENT are indentation token used within the definition of the
suite nonterminal. I'd provide additional help when you get stuck.

Finally the standard response to your claims: "this is all open
source". This advice might be annoying and uncomfortable and maybe you
just want to talk about some problems and make a few guesses instead
of solving them actually. We are all Web 2.0 now and discussing issues
and doing socialization might be more important than everything else
even among geeks. This can be confusing however for people who believe
that softskills are not everything.

Regards, Kay

Kay Schluehr <> writes:
> If you feel you can transform it into another unambigous grammar
> mixing statements and expressions it's up to you.

We got rid of the print statement for python 3.0. Why not get rid
of the rest of them too? Just use expressions for everything, as
works fine for plenty of other languages.

Scott David Daniels wrote:
> Cristian wrote:
>> On Sep 21, 3:44 pm, Ron Adam <r...@ronadam.com> wrote:
>>
>>> I think key may be to discuss names and name binding with your friend.
>
> Here's an idea:
>
> import math
>
> def sin_integral(start, finish, dx):
> total = 0.0
> y0 = math.sin(start)
> for n in range(1, 1 + int((finish - start) / float(dx))):
> y1 = math.sin(start + n * dx)
> total += (y0 + y1)
> y0 = y1
> return total / 2. * dx
>
>
> def cos_integral(start, finish, dx):
> total = 0.0
> y0 = math.sin(start)
> for n in range(1, 1 + int((finish - start) / float(dx))):
> y1 = math.cos(start + n * dx)
> total += (y0 + y1)
> y0 = y1
> return total / 2. * dx
>
> generalize and separate the integration technique from the
> function it integrates.


How about this?

It's based on the apple basic program example in How to Enjoy Calculus.


Ron




import math

def integrate(fn, x1, x2, n=100):
# Calculate area of fn using Simpson's rule.
width = float(x2 - x1) / n
area = fn(x1)
if n % 2 != 0: # make sure its even
n += 1
for n in range(1, n):
x = x1 + n * width
if n % 2 == 0:
area += 2.0 * fn(x)
else:
area += 4.0 * fn(x)
area += fn(x2)
return area * (width / 3.0)


def fn(x):
return x**2

print "Area of fn:", integrate(fn, 0, 2)

print "Area of cos fn:", integrate(math.cos, 1, 2)

print "Area of sin fn:", integrate(math.sin, 1, 2)




Area of fn: 2.66666666667
Area of cos fn: 0.0678264420216
Area of sin fn: 0.956449142468

Scott David Daniels wrote:
> Cristian wrote:
>> On Sep 21, 3:44 pm, Ron Adam <r...@ronadam.com> wrote:
>>
>>> I think key may be to discuss names and name binding with your friend.
>
> Here's an idea:
>
> import math
>
> def sin_integral(start, finish, dx):
> total = 0.0
> y0 = math.sin(start)
> for n in range(1, 1 + int((finish - start) / float(dx))):
> y1 = math.sin(start + n * dx)
> total += (y0 + y1)
> y0 = y1
> return total / 2. * dx
>
>
> def cos_integral(start, finish, dx):
> total = 0.0
> y0 = math.sin(start)
> for n in range(1, 1 + int((finish - start) / float(dx))):
> y1 = math.cos(start + n * dx)
> total += (y0 + y1)
> y0 = y1
> return total / 2. * dx
>
> generalize and separate the integration technique from the
> function it integrates.


How about this?

It's based on the apple basic program example in How to Enjoy Calculus.


Ron




import math

def integrate(fn, x1, x2, n=100):
# Calculate area of fn using Simpson's rule.
width = float(x2 - x1) / n
area = fn(x1)
if n % 2 != 0: # make sure its even
n += 1
for n in range(1, n):
x = x1 + n * width
if n % 2 == 0:
area += 2.0 * fn(x)
else:
area += 4.0 * fn(x)
area += fn(x2)
return area * (width / 3.0)


def fn(x):
return x**2

print "Area of fn:", integrate(fn, 0, 2)

print "Area of cos fn:", integrate(math.cos, 1, 2)

print "Area of sin fn:", integrate(math.sin, 1, 2)




Area of fn: 2.66666666667
Area of cos fn: 0.0678264420216
Area of sin fn: 0.956449142468

On 22 Sep., 08:56, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Kay Schluehr <kay.schlu...@gmx.net> writes:
> > If you feel you can transform it into another unambigous grammar
> > mixing statements and expressions it's up to you.
>
> We got rid of the print statement for python 3.0. Why not get rid
> of the rest of them too? Just use expressions for everything, as
> works fine for plenty of other languages.

One might create a new dynamic functional+OO programming language,
where small statements like print, assert, raise etc. all become
functions and statements like while, for, with etc. become anonymous
closures. I think Logix had gone once in this direction but was
abandoned due to severe technical problems. So one might eventually
revive this project with another more sound technical base. Personally
I'm not sure it's worth a large effort and whether EasyExtend is the
right toolkit at hand. So it's definitely not Guido who will revive it
and also not me. Maybe some PyPy guys? What are we talking about -
really?

On Sat, 22 Sep 2007 00:47:37 -0700, Kay Schluehr wrote:

> On 22 Sep., 08:56, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> Kay Schluehr <kay.schlu...@gmx.net> writes:
>> > If you feel you can transform it into another unambigous grammar
>> > mixing statements and expressions it's up to you.
>>
>> We got rid of the print statement for python 3.0. Why not get rid
>> of the rest of them too? Just use expressions for everything, as
>> works fine for plenty of other languages.
>
> One might create a new dynamic functional+OO programming language,
> where small statements like print, assert, raise etc. all become
> functions and statements like while, for, with etc. become anonymous
> closures.

Before someone starts to create such a thing he should take a look at Io
which has just objects and methods.

http://www.iolanguage.com/

Ciao,
Marc 'BlackJack' Rintsch