Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-21 Thread Josiah Carlson

Nick Coghlan wrote:
> 
> Guido van Rossum wrote:
> > But as long as we are describing the
> > present state we should call a spade a spade, etc.
> 
> I guess I take a syntactic view of the status quo, because, while 
> lambdas may be implemented as anonymous functions, the current syntax 
> doesn't let me *write* an arbitrary function as a lambda.

You can write anything as a lambda, but it may not be easy.


> Regardless, I believe the balance will eventually tip in some 
> direction - either lambdas disappear entirely, become able support 
> full anonymous functions, or else the idea of a 'deferred expression' 
> becomes a defining characteristic, rather than a syntactic quirk.

I would put my money on the latter rather than the former.  The moment
functions start moving beyond a line or so is when they usually start
begging for a name.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-21 Thread Nick Coghlan
Guido van Rossum wrote:
> [Nick Coghlan]
> 
>>And here we see why I'm such a fan of the term 'deferred expression'
>>instead of 'anonymous function'.
>>
>>Python's lambda expressions *are* the former, but they are
>>emphatically *not* the latter.
> 
> Let me emphatically disagree. Your POV is entirely syntactical, which
> IMO is a shallow perspective. Semantically, lambdas ARE anonymous
> functions, and that's what counts.

Interesting. Knowing this, I think I better understand your desire to 
get rid of lambda expressions for Py3K.

> Since "deferred expression" is not defined in Python, you can't
> reasonably argue about whether that's what lambdas are, but
> intuitively for me the term refers to something more lightweight than
> lambdas.

As you say, it is a matter of looking at lambdas based on what the 
current syntax restricts them to (i.e. single expressions), rather 
than what the underlying machinery is capable of (i.e. full-fledged 
functions).

> Now, whether the use cases for lambdas are better served by anonymous
> functions or by something else that might be called deferred
> expression, I don't know yet. 

Like you (judging by your stated goals for Py3K), I don't have any use 
cases for full anonymous functions - named functions serve that role 
quite happily for me.

Where I find lambda expressions useful is the role that Python's 
current syntax restricts them too - functions which consist of a 
single (usually simple) expression. For those, pulling the expression 
out and naming it would just end up hiding the meaningful sections of 
code behind a few pieces of boilerplate

 > But as long as we are describing the
 > present state we should call a spade a spade, etc.

I guess I take a syntactic view of the status quo, because, while 
lambdas may be implemented as anonymous functions, the current syntax 
doesn't let me *write* an arbitrary function as a lambda.

Regardless, I believe the balance will eventually tip in some 
direction - either lambdas disappear entirely, become able support 
full anonymous functions, or else the idea of a 'deferred expression' 
becomes a defining characteristic, rather than a syntactic quirk.

I figure it's all Py3K type stuff though, without any great urgency 
associated with it.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-20 Thread Jim Jewett
>>>lambda x,y: x+y*y
>>>lambda x,y: y**2+x

>>> are essentialy the same functions with different implementations [1].

>> Except that they are not. Think of __pow__, think of __add__ and __radd__.

> You know the difference between the concept of a function and it's 
> infinitely many representations? That's why formal definitions exist.

To clear up the archives, the problem is that Kay and Reinhold were 
talking about different things when they said "function".  

In arithmetic (and most sane extensions), those two lines are 
essentially the same function written different ways.

In python those two lines represent two different functions, because 
x and y might not be (bound to) sane numbers.  The variables could
be bound to objects that redefine the addition, multiplication, and 
exponentiation operators.  So y*y might not be the same as y**2, 
and x+y might not be the same as y+x.  

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-20 Thread Guido van Rossum
[Nick Coghlan]
> And here we see why I'm such a fan of the term 'deferred expression'
> instead of 'anonymous function'.
> 
> Python's lambda expressions *are* the former, but they are
> emphatically *not* the latter.

Let me emphatically disagree. Your POV is entirely syntactical, which
IMO is a shallow perspective. Semantically, lambdas ARE anonymous
functions, and that's what counts.

Since "deferred expression" is not defined in Python, you can't
reasonably argue about whether that's what lambdas are, but
intuitively for me the term refers to something more lightweight than
lambdas.

Now, whether the use cases for lambdas are better served by anonymous
functions or by something else that might be called deferred
expression, I don't know yet. But as long as we are describing the
present state we should call a spade a spade, etc.

(Alas, no time to follow the rest of this thread -- vacationing with
little connectivity until EuroPython starts next week.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Reinhold Birkenfeld
Kay Schluehr wrote:
> Reinhold Birkenfeld wrote:
> 
>>>
>>>lambda x,y: x+y*y
>>>lambda x,y: y**2+x
>>>
>>> are essentialy the same functions with different implementations [1].
>> 
>> 
>> Except that they are not. Think of __pow__, think of __add__ and __radd__.
> 
> You know the difference between the concept of a function and it's 
> infinitely many representations? That's why formal definitions exist.

I must say that I don't understand what you're after.

Reinhold

-- 
Mail address is perfectly valid!

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda

2005-06-19 Thread Josiah Carlson

Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Donovan Baarda <[EMAIL PROTECTED]> wrote:
> > 
> >>Nick Coghlan wrote:
> >>
> >>>Donovan Baarda wrote:
> [...]
> >>But isn't a function just a deferred expression with a name :-)
> > 
> > 
> > A function in Python is actually a deferred sequence of statements and
> > expressions. An anonymous function in Python (a lambda) is a deferred
> > expression.
> 
> in the end though, a sequence of statements that completes with a 
> "return value" is, when treated as a black box, indistinguishable from 
> an expression. Originally I thought that this also had to be qualified 
> with "and has no side-effects", but I see now that is not the case.

Lambdas/anonymous functions are generally used when they are simple and
are either to be applied _now_, or passed as a callback to someone else
(sometimes people use the x = lambda..., but that is laziness,
def/return is clearer).  Are either of the following two examples easy
to read?

rslt = (def (arg):
#body that handles arg
...
   )(argument_passed_to_fcn)

foo((def (arg):
#body that handles arg
...
 ), foo_arg, ...)

I personally think they are horrible.  Both of the above would be easier
to read as...

def _throw_away(arg):
#body that handles arg
...

rslt = _throw_away(argument_passed_to_fcn)
foo(_throw_away, ...)


> [...]
> >>Oh yeah Raymond: on the "def defines some variable name"... are you 
> >>joking? You forgot the smiley :-)
> > 
> > 
> > 'def' happens to bind the name that follows the def to the function with
> > the arguments and body following the name.
> 
> Yeah, but we don't use "def" to bind arbitary variables, only 
> functions/procedures. So in python, they are intimately identified with 
> functions and procedures.

Being that this entire thread is about functions, perhaps there was an
implied "function" in there?  Also, with the right decorator, it becomes
an arbitrary assignment method in Python 2.4 ...

>>> def assign(val):
... return lambda a:val
...
>>> @assign(5)
... def foo(arg): pass
...
>>> foo
5
>>>


> >>If there really is a serious practical reason why they must be limited 
> >>to expressions, why not just raise an exception or something if the 
> >>"anonymous function" is too complicated...
> > 
> > 
> > Define "too complicated"?
> 
> I was thinking that this is up to the interpreter... depending on what 
> the practical limitations are that cause the limitation in the first 
> place. For example... if it can't be reduced to an "expression" through 
> simple transforms.

Care to write the transformation library for all Python statements? Care
to see that multi-line anonymous function I described above? I
certainly hope not.


 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Ron Adam
Nick Coghlan wrote:
> Donovan Baarda wrote:
> 
>>As I see it, a lambda is an anonymous function. An anonymous function is 
>>a function without a name.
> 
> 
> And here we see why I'm such a fan of the term 'deferred expression' 
> instead of 'anonymous function'.
 >
> Python's lambda expressions *are* the former, but they are 
> emphatically *not* the latter.

Lambda's have inputs and outputs like a function, so they can be used in 
place of functions.

A simple deferred expression wouldn't be the same thing since it would 
use local names directly, but not at the time the expression is created, 
and couldn't (easily) be used in place of a function call.

addxy = defer x+y  # do this later
for x in range(10):
 for y in range(10):
 print addxy# prints sums of x,y

This is basically a limited single expression macro. (Which I believe 
isn't wanted.)  A better example might be as used in a dictionary in 
place of a case statement.  ie..  case['add'] = defer x+y, etc...

Regards, Ron

(Reply to this in python-list if it would be better discussed there.)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Kay Schluehr
Skip Montanaro wrote:

> >> As I see it, a lambda is an anonymous function. An anonymous function
> >> is a function without a name. We already have a syntax for a
> >> function...  why not use it. ie:
> >> 
> >> f = filter(def (a): return a > 1, [1,2,3])
> 
> Kay> You mix expressions with statements. 
> 
> You could remove the "return" and restrict the body of the def to an
> expression: 
> 
> f = filter(def (a): a > 1, [1,2,3])
> 
> That looks almost exactly like a lambda, but uses "def" and parenthesizes
> the argument list. It seems to me that would remind people "this is a
> function".

Yes, but skipping the name of a function ( anonymizing it ) is not a 
strong reason to disallow statements in the anonymus function body. The 
crucial issue is the notation of callable expressions that are not 
statements but can be defined inside of other expressions ( e.g. inside 
a filter() call as in the example ). That's why I prefer notations that 
emphasize the expression character. Using the arrow notation
( (args) -> expr ) would be fine for me but I would not deselect Python 
in favor for Java if ( expr from (args) ) is used instead. To me it's a 
"judean popular front" vs "popular front of judea" kind of thing.

Kay


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Kay Schluehr
Reinhold Birkenfeld wrote:

>>
>>lambda x,y: x+y*y
>>lambda x,y: y**2+x
>>
>> are essentialy the same functions with different implementations [1].
> 
> 
> Except that they are not. Think of __pow__, think of __add__ and __radd__.

You know the difference between the concept of a function and it's 
infinitely many representations? That's why formal definitions exist.

> 
> Reinhold
> 
> 

Just for refresh:

"Formally, a function f from a set X of input values to a set Y of 
possible output values (written as f : X -> Y) is a relation between X 
and Y which satisfies:

1. f is total, or entire: for all x in X, there exists a y in Y such 
that x f y (x is f-related to y), i.e. for each input value, there is at 
least one output value in Y.

2. f is many-to-one, or functional: if x f y and x f z, then y = z. 
i.e., many input values can be related to one output value, but one 
input value cannot be related to many output values.

A more concise expression of the above definition is the following: a 
function from X to Y is a subset f of the cartesian product X × Y, such 
that for each x in X, there is a unique y in Y such that the ordered 
pair (x, y) is in f."

http://en.wikipedia.org/wiki/Function_%28mathematics%29

Kay



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Skip Montanaro

>> As I see it, a lambda is an anonymous function. An anonymous function
>> is a function without a name. We already have a syntax for a
>> function...  why not use it. ie:
>> 
>> f = filter(def (a): return a > 1, [1,2,3])

Kay> You mix expressions with statements. 

You could remove the "return" and restrict the body of the def to an
expression: 

f = filter(def (a): a > 1, [1,2,3])

That looks almost exactly like a lambda, but uses "def" and parenthesizes
the argument list. It seems to me that would remind people "this is a
function".

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Reinhold Birkenfeld
Kay Schluehr wrote:

> Reduction provides often the advantage to make expressions/statements 
> scriptable what they are not in Python. Python is strong in scripting 
> classes/objects ( a big plus of the language ) but you can't simply use 
> the language to prove that
> 
> lambda x,y: x+y*y
> lambda x,y: y**2+x
> 
> are essentialy the same functions with different implementations [1].

Except that they are not. Think of __pow__, think of __add__ and __radd__.

Reinhold


-- 
Mail address is perfectly valid!

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Kay Schluehr
Donovan Baarda wrote:

> I don't get what the problem is with mixing statement and expression 
> semantics... from a practial point of view, statements just offer a 
> superset of expression functionality.
> 
> If there really is a serious practical reason why they must be limited 
> to expressions, why not just raise an exception or something if the 
> "anonymous function" is too complicated...
> 
> I did some fiddling and it seems lambda's can call methods and stuff 
> that can have side effects, which kinda defeats what I thought was the 
> point of "statements vs expressions"... I guess I just don't 
> understand... maybe I'm just thick :-)

The whole point is that you are able to do all the basic control flow 
operations like IF, FOR and WHILE using simple expressions ( like in 
Pythons lambda ), the lambda statement itself and recursion. Therefore 
lambda expressions constitute a Turing complete language and they also 
do so in Python. Different to many FP languages lambda plays no central
role in Python because statements won't be reduced to lambda expressions 
( or some kind of ). They are merely an add-on.

Reduction provides often the advantage to make expressions/statements 
scriptable what they are not in Python. Python is strong in scripting 
classes/objects ( a big plus of the language ) but you can't simply use 
the language to prove that

lambda x,y: x+y*y
lambda x,y: y**2+x

are essentialy the same functions with different implementations [1]. I 
think this is a severe lack of expressibility and has nothing to do with 
the silly objection that one has to write one more line for a simple 
callback - o.k. I admit that I'm lazy too ;)

Regards,
Kay


[1] Not without hacking the parse tree. Doing so one might finally end 
up accessing the expression in a simple modifieable manner:

 >>> (lambda x,y: x+y*y).expr
('+',(x,'*',(y,y)))

 >>> (lambda x,y: y**2+x).expr
('+',(('**',(y,2)),x))




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda

2005-06-19 Thread Donovan Baarda
Josiah Carlson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> wrote:
> 
>>Nick Coghlan wrote:
>>
>>>Donovan Baarda wrote:
[...]
>>But isn't a function just a deferred expression with a name :-)
> 
> 
> A function in Python is actually a deferred sequence of statements and
> expressions. An anonymous function in Python (a lambda) is a deferred
> expression.

in the end though, a sequence of statements that completes with a 
"return value" is, when treated as a black box, indistinguishable from 
an expression. Originally I thought that this also had to be qualified 
with "and has no side-effects", but I see now that is not the case.

[...]
>>Oh yeah Raymond: on the "def defines some variable name"... are you 
>>joking? You forgot the smiley :-)
> 
> 
> 'def' happens to bind the name that follows the def to the function with
> the arguments and body following the name.

Yeah, but we don't use "def" to bind arbitary variables, only 
functions/procedures. So in python, they are intimately identified with 
functions and procedures.

>>I don't get what the problem is with mixing statement and expression 
>>semantics... from a practial point of view, statements just offer a 
>>superset of expression functionality.
> 
> 
> Statements don't have a return value.  To be more precise, what is the
> value of "for i in xrange(10): z.append(...)"?  Examine the selection of
> statements available to Python, and ask that question.  The only one
> that MAY have a return value, is 'return' itself, which really requires
> an expression to the right (which passes the expression to the right to
> the caller's frame).  When you have statements that ultimately need a
> 'return' for a return value; you may as well use a standard function
> definition.

Hmmm. For some reason I thought that these kind of things would have a 
return value of None, the same as a function without an explicit return. 
I see now that this is not true...

>>If there really is a serious practical reason why they must be limited 
>>to expressions, why not just raise an exception or something if the 
>>"anonymous function" is too complicated...
> 
> 
> Define "too complicated"?

I was thinking that this is up to the interpreter... depending on what 
the practical limitations are that cause the limitation in the first 
place. For example... if it can't be reduced to an "expression" through 
simple transforms.

But look... I've gone and created another monster thread on 
"alternatives to lambda"... I'm going to shut up now.

--
Donovan Baarda
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda

2005-06-19 Thread Josiah Carlson

Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Donovan Baarda wrote:
> > 
> >>As I see it, a lambda is an anonymous function. An anonymous function is 
> >>a function without a name.
> > 
> > 
> > And here we see why I'm such a fan of the term 'deferred expression' 
> > instead of 'anonymous function'.
> 
> But isn't a function just a deferred expression with a name :-)

A function in Python is actually a deferred sequence of statements and
expressions. An anonymous function in Python (a lambda) is a deferred
expression.


> > Python's lambda expressions *are* the former, but they are 
> > emphatically *not* the latter.
> 
> Isn't that because lambda's have the limitation of not allowing 
> statements, only expressions? I know this limitation avoids side-effects 
> and has significance in some formal (functional?) languages... but is 
> that what Python is? In the Python I use, lambda's are always used where 
> you are too lazy to define a function to do it's job.

I've generally seen people use lambdas for things that don't require
names in the current context; i.e. callbacks with simple executions.


> To me, anonymous procedures/functions would be a superset of "deferred 
> expressions", and if the one stone fits perfectly in the slingshot we 
> have and can kill multiple birds... why hunt for another stone?

Are "deferred expressions" perhaps another way of spelling "function
closure"?


> Oh yeah Raymond: on the "def defines some variable name"... are you 
> joking? You forgot the smiley :-)

'def' happens to bind the name that follows the def to the function with
the arguments and body following the name.


> I don't get what the problem is with mixing statement and expression 
> semantics... from a practial point of view, statements just offer a 
> superset of expression functionality.

Statements don't have a return value.  To be more precise, what is the
value of "for i in xrange(10): z.append(...)"?  Examine the selection of
statements available to Python, and ask that question.  The only one
that MAY have a return value, is 'return' itself, which really requires
an expression to the right (which passes the expression to the right to
the caller's frame).  When you have statements that ultimately need a
'return' for a return value; you may as well use a standard function
definition.


> If there really is a serious practical reason why they must be limited 
> to expressions, why not just raise an exception or something if the 
> "anonymous function" is too complicated...

Define "too complicated"?


> I did some fiddling and it seems lambda's can call methods and stuff 
> that can have side effects, which kinda defeats what I thought was the 
> point of "statements vs expressions"... I guess I just don't 
> understand... maybe I'm just thick :-)

There is nothing stopping anyone from modifying anything in a lambda...

a = list(...)
pop = lambda:a.pop()
lcycle = lambda: a and a.append(a.pop(0))
rcycle = lambda: a and a.insert(0, a.pop())
popany = lambda: a and a.pop(random.randrange(len(a)))


 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-19 Thread Nick Coghlan
Donovan Baarda wrote:
> Nick Coghlan wrote:
>> And here we see why I'm such a fan of the term 'deferred expression' 
>> instead of 'anonymous function'.
> 
> But isn't a function just a deferred expression with a name :-)

According to the specific meaning of 'expression' in the Python 
grammar? No.

> Isn't that because lambda's have the limitation of not allowing 
> statements, only expressions? I know this limitation avoids side-effects 
> and has significance in some formal (functional?) languages... but is 
> that what Python is?

Personally, I believe it has to do with two things, one practical and 
one more stylistic/philosophical.

Firstly, Python uses significant whitespace between statements, and to 
delineate sections of compound statements. Within expressions however, 
whitespace is essentially insignificant (except where it affects the 
tokenisation). Trying to embed suites (where whitespace can be 
significant) inside expressions (where whitespace is generally 
insiginificant) tends to result in a horrible mess, or else some 
rather unPythonic concepts (e.g. using something other than 
indentation to demarcate the suite).

Secondly, trying to cram too much functionality into a single line is 
a questionable activity. The 'deferred expression' approach taken with 
lambdas is a hint that if the thing you're trying to defer is more 
complex than a single expression, it may be worth giving it a proper 
name via 'def'.

> In the Python I use, lambda's are always used where 
> you are too lazy to define a function to do it's job.

In simple cases, naming the expression to be deferred results in it 
gaining a prominence it doesn't deserve, possibly obscuring the 
purpose of the main statement.

In such cases, deferred expressions are a better solution - it's 
merely unfortunate that Python's current syntax for the practice 
anything to write home about.

> To me, anonymous procedures/functions would be a superset of "deferred 
> expressions", and if the one stone fits perfectly in the slingshot we 
> have and can kill multiple birds... why hunt for another stone?

Because there is already a solution for the large birds - *named* 
functions.

Unfortunately, using a named function for a simple deferred expression 
is like using a catapult to kill a canary.

> If there really is a serious practical reason why they must be limited 
> to expressions, why not just raise an exception or something if the 
> "anonymous function" is too complicated...

You'd still need a definition of 'too complicated' - which we already 
have for deferred expressions. Specifically "unable to be expressed as 
a single Python expression".

>> Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant 
>> entries under 'real closures'.
> 
> Where is that wiki BTW? I remember looking at it ages ago but can't find 
> the link anymore.

http://wiki.python.org/moin/AlternateLambdaSyntax

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Donovan Baarda
Nick Coghlan wrote:
> Donovan Baarda wrote:
> 
>>As I see it, a lambda is an anonymous function. An anonymous function is 
>>a function without a name.
> 
> 
> And here we see why I'm such a fan of the term 'deferred expression' 
> instead of 'anonymous function'.

But isn't a function just a deferred expression with a name :-)

As a person who started out writing assembler where every "function" I 
wrote was a macro that got expanded inline, the distiction is kinda 
blurry to me.

> Python's lambda expressions *are* the former, but they are 
> emphatically *not* the latter.

Isn't that because lambda's have the limitation of not allowing 
statements, only expressions? I know this limitation avoids side-effects 
and has significance in some formal (functional?) languages... but is 
that what Python is? In the Python I use, lambda's are always used where 
you are too lazy to define a function to do it's job.

To me, anonymous procedures/functions would be a superset of "deferred 
expressions", and if the one stone fits perfectly in the slingshot we 
have and can kill multiple birds... why hunt for another stone?

Oh yeah Raymond: on the "def defines some variable name"... are you 
joking? You forgot the smiley :-)

I don't get what the problem is with mixing statement and expression 
semantics... from a practial point of view, statements just offer a 
superset of expression functionality.

If there really is a serious practical reason why they must be limited 
to expressions, why not just raise an exception or something if the 
"anonymous function" is too complicated...

I did some fiddling and it seems lambda's can call methods and stuff 
that can have side effects, which kinda defeats what I thought was the 
point of "statements vs expressions"... I guess I just don't 
understand... maybe I'm just thick :-)

> Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant 
> entries under 'real closures'.

Where is that wiki BTW? I remember looking at it ages ago but can't find 
the link anymore.

--
Donovan Baarda
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Kay Schluehr
Donovan Baarda wrote:

> I must admit I ended up deleting most of the "alternative to lambda" 
> threads after they flooded my in box. So it is with some dread I post 
> this, contributing to it...

I must admit you are right. And I will stop defending my proposal 
because it seems to create nothing more than pointless polemics. 
Suggesting elements of FP to python-dev may have the same chances to be 
accepted than raising a Buddha statue in a catholic church.

> As I see it, a lambda is an anonymous function. An anonymous function is 
> a function without a name. We already have a syntax for a function... 
> why not use it. ie:
> 
>   f = filter(def (a): return a > 1, [1,2,3])

You mix expressions with statements. This is a no-go in Python. 
Permitting those constructs is a radical language change not just a 
simple syntax replacement.

Kay

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Josiah Carlson

Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> 
>  > Kay Schluehr <[EMAIL PROTECTED]> wrote:
>  >> The arrow is a straightforward punctuation for function definitions. 
>  >> Reusing existing keywords for different semantics seems to me as a kind 
>  >> of inbreeding.
>  >
>  > That's starting to look like the pseudocode from old algorithms
>  > textbooks, which is very similar to bad pseudocode from modern CS theory
>  > papers.  Punctuation as a replacement for words does not always win
>  > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...)
> 
> Writing functions as arrows is very convenient not only in CS but also 
> in mathematics. Looking like pseudo-code was not one of Guidos Python 
> regrets if I remember them correctly.

Apparently you weren't reading what I typed.  I don't find '->' notation
for functions to be readable, either in code, papers, or otherwise.  In
fact, when I teach my CS courses, I use Python, and in the case where I
need to describe mathematical functions, I use a standard mathematical
notation for doing so: 'f(x) = ...'.


>  >> For pushing anymus functions forward I propose to enable explizit 
>  >> partial evaluation as a programming technique:
>  >
>  > If I remember correctly, we've got rightcurry and leftcurry for that (or
>  > rightpartial and leftpartial, or something).
>  >
> Currying usually does not perform a function evaluation in order to 
> create another more special function. Partial evaluation is a dynamic 
> programming and optimization technique. Psyco uses specialization and
> caching implicitely. I propose to use it explicitely but in a more 
> restricted context.

I never claimed that currying was partial function evaluation.  In fact,
if I remember correctly (I don't use curried functions), the particular
currying that was implemented and shipped for Python 2.4 was a simple
function that kept a list of args and kwargs that were already passed to
the curried function. When it got enough arguments, it would go ahead
and evaluate it.


>  > I'll assume that you don't actually want it to rewrite the source, or
>  > actually return the source representation of the anonymous function
>  > (those are almost non-starters).
>  >
> 
> Computer algebra systems store expressions in internal tree form, 
> manipulate them efficiently and pretty-print them in textual or latex 
> output on demand. There would be much more involved than a tree to tree 
> translation starting with Pythons internal parse tree and an evaluator 
> dedicated to it.

Right, and Python is not a CAS.  You want a CAS?  Use Mathematica, Maple,
or some CAS addon to Python.  Keeping the parse tree around when it is
not needed is a waste. In the code that I write, that would be 100% of
the time.


>  > As for all anonymous functions allowing partial evaluation via keywords:
>  > it would hide errors. Right now, if you forget an argument or add too
>  > many arguments, you get a TypeError. Your proposal would make
>  > forgetting an argument in certain ways return a partially evaluated
>  > function.
> 
> 
> That's why I like to dump the function in a transparent mode. Personally 
> I could dispense a little security in favor for cheap metainformation.

It's not about security, it's about practicality and backwards
compatibility.

Here is an example:
>>> x = lambda a,b: a+b+1
>>> x(a=1)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: () takes exactly 2 non-keyword arguments (1 given)
>>>

According to you, that should instead produce...
  lambda b: 1+b+1

New and old users alike have gotten used to the fact that calling a
function without complete arguments is an error.  You are proposing to
make calling a function with less than the required number of arguments
not be an error.

For the sake of sanity, I have to be -1000 on this.


I'm also not aware of an automatic mechanism for code compilation (in
Python) that both attaches the parse tree to the compiled function, or
allows for the conversion of that parse tree back to a source form, or
allows one to replace variable references with constants.  If you would
care to write the pieces necessary, I'm sure you will find a use for it.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Nick Coghlan
Donovan Baarda wrote:
> As I see it, a lambda is an anonymous function. An anonymous function is 
> a function without a name.

And here we see why I'm such a fan of the term 'deferred expression' 
instead of 'anonymous function'.

Python's lambda expressions *are* the former, but they are 
emphatically *not* the latter.

Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant 
entries under 'real closures'.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Donovan Baarda
Kay Schluehr wrote:
> Josiah Carlson wrote:
> 
>  > Kay Schluehr <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >> Maybe anonymus function closures should be pushed forward right now 
> not only syntactically? Personally I could live with lambda or several
>  >> of the alternative syntaxes listed on the wiki page.

I must admit I ended up deleting most of the "alternative to lambda" 
threads after they flooded my in box. So it is with some dread I post 
this, contributing to it...

As I see it, a lambda is an anonymous function. An anonymous function is 
a function without a name. We already have a syntax for a function... 
why not use it. ie:

  f = filter(def (a): return a > 1, [1,2,3])

The implications of this are that both functions and procedures can be 
anonymous. This also implies that unlike lamba's, anonymous functions 
can have statements, not just expressions. You can even do compound 
stuff like;

   f = filter(def (a): b=a+1; return b>1, [1,2,3])

or if you want you can use indenting;

   f = filter(def (a):
 b=a+1
 return b>1, [1,2,3])

It also means the following becomes valid syntax;

f = def (a,b):
   return a>b

I'm not sure if there are syntactic ambiguities to this. I'm not sure if 
  the CS boffins are disturbed by "side effects" from statements. 
Perhaps both can be resolved by limiting annonymous functions to 
expressions. Or require use of brackets or ";" to resolve ambiguity.

This must have been proposed already and shot down in flames... sorry 
for re-visiting old stuff and contributing noise.

--
Donovan Baarda
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Kay Schluehr
Josiah Carlson wrote:

 > Kay Schluehr <[EMAIL PROTECTED]> wrote:
 >
 >
 >> Maybe anonymus function closures should be pushed forward right now 
not only syntactically? Personally I could live with lambda or several
 >> of the alternative syntaxes listed on the wiki page.
 >>
 >
 >
 >
 >
 >> But asking for a favourite syntax I would skip the "def" keyword 
from your def-arrow syntax proposal and use:
 >>
 >>((a, b, c) -> f(a) + o(b) - o(c))
 >>
 >
 > ...
 >
 >
 >
 >> The arrow is a straightforward punctuation for function definitions. 
Reusing existing keywords for different semantics seems to me as a kind 
of inbreeding.
 >>
 >
 >
 > That's starting to look like the pseudocode from old algorithms
 > textbooks, which is very similar to bad pseudocode from modern CS theory
 > papers.  Punctuation as a replacement for words does not always win
 > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...)
 >
 >

Writing functions as arrows is very convenient not only in CS but also 
in mathematics. Looking like pseudo-code was not one of Guidos Python 
regrets if I remember them correctly.

 > -1 on the syntax offering.
 >
 >
 >
 >> For pushing anymus functions forward I propose to enable explizit 
partial evaluation as a programming technique:
 >>
 >
 >
 > If I remember correctly, we've got rightcurry and leftcurry for that (or
 > rightpartial and leftpartial, or something).
 >
 >

Currying usually does not perform a function evaluation in order to 
create another more special function. Partial evaluation is a dynamic 
programming and optimization technique. Psyco uses specialization and
caching implicitely. I propose to use it explicitely but in a more 
restricted context.

 >> >>> ((x,y) -> (x+1)*y**2)
 >> ((x,y) -> (x+1)*y**2)
 >>
 >> >>> ((x,y) -> (x+1)*y**2)(x=5)
 >> ((y) -> 6*y**2)
 >>
 >
 >
 > I'll assume that you don't actually want it to rewrite the source, or
 > actually return the source representation of the anonymous function
 > (those are almost non-starters).
 >
 >

Computer algebra systems store expressions in internal tree form, 
manipulate them efficiently and pretty-print them in textual or latex 
output on demand. There would be much more involved than a tree to tree 
translation starting with Pythons internal parse tree and an evaluator 
dedicated to it.

 > As for all anonymous functions allowing partial evaluation via keywords:
 > it would hide errors. Right now, if you forget an argument or add too
 > many arguments, you get a TypeError. Your proposal would make
 > forgetting an argument in certain ways return a partially evaluated
 > function.


That's why I like to dump the function in a transparent mode. Personally 
I could dispense a little security in favor for cheap metainformation.

Regards,
Kay




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Josiah Carlson

Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Maybe anonymus function closures should be pushed forward right now not 
> only syntactically? Personally I could live with lambda or several
> of the alternative syntaxes listed on the wiki page.

> But asking for a favourite syntax I would skip the "def" keyword from 
> your def-arrow syntax proposal and use:
> 
> ((a, b, c) -> f(a) + o(b) - o(c))
...

> The arrow is a straightforward punctuation for function definitions. 
> Reusing existing keywords for different semantics seems to me as a kind 
> of inbreeding.

That's starting to look like the pseudocode from old algorithms
textbooks, which is very similar to bad pseudocode from modern CS theory
papers.  Punctuation as a replacement for words does not always win
(perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...)

-1 on the syntax offering.

> For pushing anymus functions forward I propose to enable explizit 
> partial evaluation as a programming technique:

If I remember correctly, we've got rightcurry and leftcurry for that (or
rightpartial and leftpartial, or something).

>  >>> ((x,y) -> (x+1)*y**2)
> ((x,y) -> (x+1)*y**2)
> 
>  >>> ((x,y) -> (x+1)*y**2)(x=5)
> ((y) -> 6*y**2)

I'll assume that you don't actually want it to rewrite the source, or
actually return the source representation of the anonymous function
(those are almost non-starters).

As for all anonymous functions allowing partial evaluation via keywords:
it would hide errors.  Right now, if you forget an argument or add too
many arguments, you get a TypeError.  Your proposal would make
forgetting an argument in certain ways return a partially evaluated
function.

-1 on partial evaluation.


 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-18 Thread Kay Schluehr
Nick Coghlan wrote:
> Guido van Rossum wrote:
> 
>>>Recommend accepting just the basic PEP which only targets simple,
>>>obvious cases.  The discussed extensions are unattractive and should be
>>>skipped.
>>
>>
>>-1. The "unary colon" looks unPythonic to me.
>>
> 
> 
> Step 1 would be to require parentheses around the whole thing (ala 
> generator expressions) to make it easier to see where the deferred 
> expression ends.
> 
> But all my use cases that I can think off the top of my head involve 
> 'sorted', where it wouldn't help at all because of the need for an 
> argument.
> 
> So I'd rather see a serious discussion regarding giving lambdas a more 
> Pythonic syntax in general, rather than one that only applied to the 
> 'no-argument' case [1]
> 
> Cheers,
> Nick.
> 
> [1] http://wiki.python.org/moin/AlternateLambdaSyntax
> The 'expression-before-args' version using just the 'from' keyword is 
> still my favourite.
> 

Maybe anonymus function closures should be pushed forward right now not 
only syntactically? Personally I could live with lambda or several
of the alternative syntaxes listed on the wiki page.

But asking for a favourite syntax I would skip the "def" keyword from 
your def-arrow syntax proposal and use:

((a, b, c) -> f(a) + o(b) - o(c))
((x) -> x * x)
(() -> x)
((*a, **k) -> x.bar(*a, **k))
( ((x=x, a=a, k=k) -> x(*a, **k)) for x, a, k in funcs_and_args_list)

The arrow is a straightforward punctuation for function definitions. 
Reusing existing keywords for different semantics seems to me as a kind 
of inbreeding.

For pushing anymus functions forward I propose to enable explizit 
partial evaluation as a programming technique:

Example 1:

 >>> ((x,y) -> (x+1)*y**2)
((x,y) -> (x+1)*y**2)

 >>> ((x,y) -> (x+1)*y**2)(x=5)
((y) -> 6*y**2)


Example 2:

def f(x):
 return x**2

 >>> ((x,y) -> f(x)+f(y))(x=2)
((y) -> 4 + f(y))


Example 3:

 >>> ((f,x,y) -> f(x)+f(y))(f=((x)-> x**2), y=3)
((x) -> ((x)-> x**2))(x)+9)

The keyword style argument passing can be omitted in case of complete
evaluation where pattern matching on the argument tuple is applied.

Regards,
Kay











___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-17 Thread Nick Coghlan
Guido van Rossum wrote:
>>Recommend accepting just the basic PEP which only targets simple,
>>obvious cases.  The discussed extensions are unattractive and should be
>>skipped.
> 
> 
> -1. The "unary colon" looks unPythonic to me.
> 

Step 1 would be to require parentheses around the whole thing (ala 
generator expressions) to make it easier to see where the deferred 
expression ends.

But all my use cases that I can think off the top of my head involve 
'sorted', where it wouldn't help at all because of the need for an 
argument.

So I'd rather see a serious discussion regarding giving lambdas a more 
Pythonic syntax in general, rather than one that only applied to the 
'no-argument' case [1]

Cheers,
Nick.

[1] http://wiki.python.org/moin/AlternateLambdaSyntax
The 'expression-before-args' version using just the 'from' keyword is 
still my favourite.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-17 Thread Guido van Rossum
[Raymond Hettinger]
> This PEP is an excellent example of improving readability and usability
> by omitting a keyword and simplifying syntax.  It neither provides nor
> takes away functionality; instead, it is a bit of a beautification
> effort.
> 
> Essentially it creates a lighter-weight, more usable syntax for
> specifying deferred function arguments.  Like decorators, this helps out
> programmers who understand and use this technique, and it is harmless
> and invisible for the rest.  It is especially handy in the absence of an
> if-then-else expression.  The PEP is backwards compatible.
> 
> Recommend accepting just the basic PEP which only targets simple,
> obvious cases.  The discussed extensions are unattractive and should be
> skipped.

-1. The "unary colon" looks unPythonic to me.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-17 Thread Raymond Hettinger
This PEP is an excellent example of improving readability and usability
by omitting a keyword and simplifying syntax.  It neither provides nor
takes away functionality; instead, it is a bit of a beautification
effort.

Essentially it creates a lighter-weight, more usable syntax for
specifying deferred function arguments.  Like decorators, this helps out
programmers who understand and use this technique, and it is harmless
and invisible for the rest.  It is especially handy in the absence of an
if-then-else expression.  The PEP is backwards compatible.

Recommend accepting just the basic PEP which only targets simple,
obvious cases.  The discussed extensions are unattractive and should be
skipped.



Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com