Re: Lisp-likeness
> "Michele" == michele simionato <[EMAIL PROTECTED]> writes: Michele> But then why he agreed to have the loop variable Michele> disappear outside a generator comprehension? I think Michele> there is something more than a backward compatibility Michele> concern. With normal for-loop (as opposed to genexps and LCs), the "last" value of the loop variable might be useful outside the loop if the loop was exited prematurely through 'break' statement or exception. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
But then why he agreed to have the loop variable disappear outside a generator comprehension? I think there is something more than a backward compatibility concern. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Michele Simionato wrote: However this approach has a drawback (which is not there in Scheme, since Scheme has set!): if a new scope was created at each iteration (which is what the function call is doing) we could not reassign variables (i.e. they would become names locals to the "for" scope, touching them would not affect variables outside the scope). There is a middle way: the for-loop could be made to create a new binding for its control variable on each iteration, while the body continues to execute in the outer scope as before. It would actually be very easy to implement this in CPython the way it currently works. Guido seems to be against this sort of thing, though, as he seems to regard it as a useful feature that the for-loop control variable is not local to the loop. -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
> I'm surprised that Michele >hasn't yet referenced the thread where we exposed the gory details, as >was his custom for a while :-) >Message-ID: <[EMAIL PROTECTED]>, for >this particular >aspect, in case anyone gives a monkey's left testicle. I had forgot the title of that thread and also I wanted to spare the poor monkeys :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
"Carl Banks" <[EMAIL PROTECTED]> writes: > Michele Simionato wrote: > > Carl Banks: > > > If Python did it the way Scheme did, this would be pretty useless. > > > > But notice that Scheme has no problems whatsoever: > > > > (define (toplevel) > > (define a 1) > > (define (f) > > (display a)) > > (set! a 2) > > (f)) > > > > (toplevel) > > > > prints 2 the same as in Python. > > Hmm. On closer inspection, I'm going to have to amend my implictation > of Scheme: the example poster was cheating. Scheme and Python both do > closures the same way. However, the Scheme snippet in the original > example used a let-block. I.e., it introduced a new scope, whereas the > Python example did not (because it doesn't have anything like let). Yes, we've been over this many times. I'm surprised that Michele hasn't yet referenced the thread where we exposed the gory details, as was his custom for a while :-) Message-ID: <[EMAIL PROTECTED]>, for this particular aspect, in case anyone gives a monkey's left testicle. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Marcin 'Qrczak' Kowalczyk wrote: > The issue is about the semantics of loops: whether they introduce > a new variable for each iteration, or change the value of a single > variable. Yes, I see what you are saying now. Good point. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Michele Simionato wrote: > Carl Banks: > > If Python did it the way Scheme did, this would be pretty useless. > > But notice that Scheme has no problems whatsoever: > > (define (toplevel) > (define a 1) > (define (f) > (display a)) > (set! a 2) > (f)) > > (toplevel) > > prints 2 the same as in Python. Hmm. On closer inspection, I'm going to have to amend my implictation of Scheme: the example poster was cheating. Scheme and Python both do closures the same way. However, the Scheme snippet in the original example used a let-block. I.e., it introduced a new scope, whereas the Python example did not (because it doesn't have anything like let). -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
"Carl Banks" <[EMAIL PROTECTED]> writes:
>> BTW, the fact that a closure refers to a variable itself rather to
>> its current value can be used to check the true attitude of
>> languages with respect to functional programming, by observing how
>> they understand their basic loops :-)
> Closing on a value rather than a variable would have been a lot easier
> to implement.
To be clear: closing on the variable is the only sane choice. Closing
on its current value would be inconsistent with global variables and
no language does this.
The issue is about the semantics of loops: whether they introduce
a new variable for each iteration, or change the value of a single
variable.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED] (Peter Lewerin) writes: > Fred Gilham <[EMAIL PROTECTED]> wrote > > > > And Lisp's "macro language" isn't involved at all here. > > > Also, #' is a read-macro. > > A read-macro and a macro aren't the same thing. > > > Then there's the "defun" macro . . . . > > There is IMHO a difference between using a macro and using the > "macro language". What macro language? Common-Lisp? -- __Pascal Bourguignon__ http://www.informatimago.com/ I need a new toy. Tail of black dog keeps good time. Pounce! Good dog! Good dog! -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Carl Banks: > Python might lose when it comes to functional programming, > but it wins when it comes to nested functions like this (where a,b,c,d > are in the enclosing scope and presumably changing): > def print_variables(): >print a,b,c,d Yes, clearly if I have def toplevel(): a = 1 def f(): print a a = 2 f() toplevel() I want 2 to be printed, not 1. > If Python did it the way Scheme did, this would be pretty useless. But notice that Scheme has no problems whatsoever: (define (toplevel) (define a 1) (define (f) (display a)) (set! a 2) (f)) (toplevel) prints 2 the same as in Python. > IMO, this sort of usage is FAR more common than the functional usage as > a closure inside a loop. Maybe, but for me it is quite common to have closures inside loops (typically for callbacks in Tkinter or a Web framework). > Closing on a value rather than a variable would have been a lot easier > to implement. I'm sure there was talk about which way to do it in the > discussions about adding nested scopes to the language, and if the > Python gods felt closing on a variable wasn't significantly more useful > than closing on a value, I doubt they would have done that. I have no doubt about that. Still, there are people who disagrees with Guido's choice, even on python-dev. This was a tough decision to make, with pros and contras. It would be possible to change the current default and have a more Schemish/Haskellish syntax for loops: it would be enough to internally convert something like result = [] for i in range(10): result.append(lambda : i) into result = [] def for_block(i): result.append(lambda : i) for i in range(10): for_block(i) However this approach has a drawback (which is not there in Scheme, since Scheme has set!): if a new scope was created at each iteration (which is what the function call is doing) we could not reassign variables (i.e. they would become names locals to the "for" scope, touching them would not affect variables outside the scope). So this idiom a = "" for i in range(10): if i == 5: a = "5 was reached" print a would not work. So, as I said, there are pros and contros. Personally, I like better the Scheme way (what I do not like in Scheme is the issue of inner defines vs. toplevel defines, but this is another story). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Or, just to impress Lispers, >>> def add(x,y): ... return x + y >>> closures = [] >>> for i in range(10): ...closures.append(add.__get__(i)) ... >>> closures[5](1000) 1005 Remember, in Python do not have functions, we have descriptors! ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
>
>
>BTW, the fact that a closure refers to a variable itself rather to its
>current value can be used to check the true attitude of languages with
>respect to functional programming, by observing how they understand
>their basic loops :-)
>
>Python loses:
>
closures = []
for i in range(10):
>...def add(x):
>... return x + i
>...closures.append(add)
>...
closures[5](1000)
>1009
>
[snip]
>Scheme wins:
>
>> (let ((closures (make-vector 10)))
>(do ((i 0 (+ i 1)))
>((= i 10))
>(vector-set! closures i (lambda (x) (+ x i
>((vector-ref closures 5) 1000))
>1005
>
>and what is perhaps surprising, Perl wins:
>
>$ perl -e '
> foreach my $i (0..9) {
> push @closures, sub {$_[0] + $i}
> }
> print $closures[5](1000), "\n"'
>1005
Smalltalk 'loses' too:
closures := Array new: 10.
1 to: 10 do: [:i |
closures at: i put: [:x| x + i]].
(closures at: 5) value: 1000
returns 1011
>If you think it's unlikely that one would want to keep a closure
>referring to a loop control variable longer than the loop iteration
>which has created it, think about the loop body spawning a thread.
I'm still not convinced this is really useful, but Scheme's behavior
seems more intuitive.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Fred Gilham <[EMAIL PROTECTED]> wrote > > And Lisp's "macro language" isn't involved at all here. > Also, #' is a read-macro. A read-macro and a macro aren't the same thing. > Then there's the "defun" macro . . . . There is IMHO a difference between using a macro and using the "macro language". -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk <[EMAIL
PROTECTED]> wrote:
>[EMAIL PROTECTED] (Thomas A. Russ) writes:
>
>>> >(defun addn (n)
>>> > #'(lambda (x)
>>> > (+ x n)))
>>>
>>> The same as
>>> def addn(n):
>>> def fn(x):
>>> return n + x
>>> return fn
>>
>> Is this really equivalent?
>>
>> What happens if you call addn more than once with different
>> parameters. Will you get different functions that you can
>> use simultaneously?
>
>Yes.
>
>It also behaves correctly when a variable it refers to is later
>mutated.
>
>
>BTW, the fact that a closure refers to a variable itself rather to its
>current value can be used to check the true attitude of languages with
>respect to functional programming, by observing how they understand
>their basic loops :-)
>
>Python loses:
>
closures = []
for i in range(10):
>...def add(x):
>... return x + i
>...closures.append(add)
>...
closures[5](1000)
>1009
Fire the coach -- the team can do it ;-)
One way is with the help of a byte-code-hacking decorator:
>>> from ut.presets import presets
>>> closures = []
>>> for i in range(10):
... @presets(i=i)
... def add(x):
... return x + i
... closures.append(add)
...
>>> closures[5](1000)
1005
>>> import dis
>>> dis.dis(closures[5])
2 0 LOAD_CONST 1 (5)
3 STORE_FAST 1 (i)
4 6 LOAD_FAST0 (x)
9 LOAD_FAST1 (i)
12 BINARY_ADD
13 RETURN_VALUE
>>> dis.dis(closures[3])
2 0 LOAD_CONST 1 (3)
3 STORE_FAST 1 (i)
4 6 LOAD_FAST0 (x)
9 LOAD_FAST1 (i)
12 BINARY_ADD
13 RETURN_VALUE
Of course, if you want to do it without byte code hacking, you can:
>>> closures2 = list((lambda i: lambda x: x + i)(i) for i in xrange(10))
>>> closures2[5](1000)
1005
>>> dis.dis(closures2[5])
1 0 LOAD_FAST0 (x)
3 LOAD_DEREF 0 (i)
6 BINARY_ADD
7 RETURN_VALUE
>>> closures2[3](1000)
1003
Or same thing without lambda:
>>> def mkadd(i):
... def add(x): return x + i
... return add
...
>>> closures3 = [mkadd(i) for i in xrange(10)]
>>> closures3[5](1000)
1005
>>> closures3[3](1000)
1003
>>> dis.dis(closures3[5])
2 0 LOAD_FAST0 (x)
3 LOAD_DEREF 0 (i)
6 BINARY_ADD
7 RETURN_VALUE
>
>as does Ruby:
>
>$ ruby -e '
> closures = []
> for i in 0..9 do
> closures.push(proc {|x| x + i})
> end
> puts closures[5][1000]'
>1009
>
>but Lisp loses too:
>
>> (let ((closures (make-array 10)))
>(do ((i 0 (+ i 1)))
>((= i 10))
>(setf (svref closures i) #'(lambda (x) (+ x i
>(funcall (svref closures 5) 1000))
>1010
>
>
>Scheme wins:
>
>> (let ((closures (make-vector 10)))
>(do ((i 0 (+ i 1)))
>((= i 10))
>(vector-set! closures i (lambda (x) (+ x i
>((vector-ref closures 5) 1000))
>1005
>
>and what is perhaps surprising, Perl wins:
>
>$ perl -e '
> foreach my $i (0..9) {
> push @closures, sub {$_[0] + $i}
> }
> print $closures[5](1000), "\n"'
>1005
>
>
>If you think it's unlikely that one would want to keep a closure
>referring to a loop control variable longer than the loop iteration
>which has created it, think about the loop body spawning a thread.
>
Just do what you need to do. Python usually provides a way ;-)
Or do you just want what you want using your idea of the right spelling? ;-)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Marcin 'Qrczak' Kowalczyk wrote: > [EMAIL PROTECTED] (Thomas A. Russ) writes: > > >> >(defun addn (n) > >> >#'(lambda (x) > >> >(+ x n))) > >> > >> The same as > >> def addn(n): > >>def fn(x): > >>return n + x > >>return fn > > > > Is this really equivalent? > > > > What happens if you call addn more than once with different > > parameters. Will you get different functions that you can > > use simultaneously? > > Yes. > > It also behaves correctly when a variable it refers to is later > mutated. > > > BTW, the fact that a closure refers to a variable itself rather to its > current value can be used to check the true attitude of languages with > respect to functional programming, by observing how they understand > their basic loops :-) > > Python loses: > > >>> closures = [] > >>> for i in range(10): > ...def add(x): > ... return x + i > ...closures.append(add) > ... > >>> closures[5](1000) > 1009 I had a minor discussion on this a couple weeks ago, wherein I suggested that Python does it that way because nested scopes weren't specifically done to enhance functional programming. (It's not a secret that Python is moving away from abstract functional support.) For example, Python might lose when it comes to functional programming, but it wins when it comes to nested functions like this (where a,b,c,d are in the enclosing scope and presumably changing): def print_variables(): print a,b,c,d If Python did it the way Scheme did, this would be pretty useless. IMO, this sort of usage is FAR more common than the functional usage as a closure inside a loop. Closing on a value rather than a variable would have been a lot easier to implement. I'm sure there was talk about which way to do it in the discussions about adding nested scopes to the language, and if the Python gods felt closing on a variable wasn't significantly more useful than closing on a value, I doubt they would have done that. > If you think it's unlikely that one would want to keep a closure > referring to a loop control variable longer than the loop iteration > which has created it, think about the loop body spawning a thread. Yes, it does happen here and there. I've needed to do that in GUI programming. But I would say it's not remotely as common as it other uses, and is easy to work around: > >>> closures = [] > >>> for i in range(10): > ...def defineadder(y): > ... def add(x): > ... return x + y > ... return add > ...closures.append(defineadder(i)) > ... > >>> closures[5](1000) > 1005 -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes: > BTW, the fact that a closure refers to a variable itself rather to its > current value can be used to check the true attitude of languages with > respect to functional programming, by observing how they understand > their basic loops :-) The thread "Midfunction Recursion"¹ from October 2002 sounds relevant here, exploring options for bindings in iteration. Footnotes: ¹ http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/46bb18e56cad/0590de10f975a059 -- Steven E. Harris -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Marcin 'Qrczak' Kowalczyk wrote: [EMAIL PROTECTED] (Thomas A. Russ) writes: (defun addn (n) #'(lambda (x) (+ x n))) The same as def addn(n): def fn(x): return n + x return fn Is this really equivalent? What happens if you call addn more than once with different parameters. Will you get different functions that you can use simultaneously? Yes. It also behaves correctly when a variable it refers to is later mutated. BTW, the fact that a closure refers to a variable itself rather to its current value can be used to check the true attitude of languages with respect to functional programming, by observing how they understand their basic loops :-) None of the examples you show close over values. The difference is in whether the loop constructs use one binding for their control variable or create new bindings in each iteration: (loop for i below 10 collect (lambda (x) (setq i x)) into setters collect (lambda () i) into getters finally (print (funcall (elt getters 0))) (funcall (elt setters 4) 42) (print (funcall (elt getters 9 => 10 => 42 If this difference matters to you, just be more explicit. Pascal -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED] (Thomas A. Russ) writes:
>> >(defun addn (n)
>> > #'(lambda (x)
>> > (+ x n)))
>>
>> The same as
>> def addn(n):
>> def fn(x):
>> return n + x
>> return fn
>
> Is this really equivalent?
>
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
Yes.
It also behaves correctly when a variable it refers to is later
mutated.
BTW, the fact that a closure refers to a variable itself rather to its
current value can be used to check the true attitude of languages with
respect to functional programming, by observing how they understand
their basic loops :-)
Python loses:
>>> closures = []
>>> for i in range(10):
...def add(x):
... return x + i
...closures.append(add)
...
>>> closures[5](1000)
1009
as does Ruby:
$ ruby -e '
closures = []
for i in 0..9 do
closures.push(proc {|x| x + i})
end
puts closures[5][1000]'
1009
but Lisp loses too:
> (let ((closures (make-array 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(setf (svref closures i) #'(lambda (x) (+ x i
(funcall (svref closures 5) 1000))
1010
Scheme wins:
> (let ((closures (make-vector 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(vector-set! closures i (lambda (x) (+ x i
((vector-ref closures 5) 1000))
1005
and what is perhaps surprising, Perl wins:
$ perl -e '
foreach my $i (0..9) {
push @closures, sub {$_[0] + $i}
}
print $closures[5](1000), "\n"'
1005
If you think it's unlikely that one would want to keep a closure
referring to a loop control variable longer than the loop iteration
which has created it, think about the loop body spawning a thread.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Thomas A. Russ wrote: > Fernando <[EMAIL PROTECTED]> writes: > > >>On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> >>wrote: >> >> >>>Maybe You can answer my question what this simple LISP function does ? >>> >>>(defun addn (n) >>> #'(lambda (x) >>> (+ x n))) >> >>The same as >>def addn(n): >> def fn(x): >> return n + x >> return fn > > > Is this really equivalent? AFAIK, yes. I admit that I know almost nothing about Lisp though. And I'm not a Python guru either. > What happens if you call addn more than once with different > parameters. Will you get different functions that you can > use simultaneously? Yes. Using the addn function defined above, you can do for example: >>> add4 = addn(4) >>> add10 = addn(10) >>> add4(5) 9 >>> add10(7) 17 >>> add4(add10(28)) 42 And so on. At least, I think that's what you mean. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED] (Thomas A. Russ) writes:
>> >(defun addn (n)
>> > #'(lambda (x)
>> > (+ x n)))
>>
>> The same as
>> def addn(n):
>> def fn(x):
>> return n + x
>> return fn
>
> Is this really equivalent?
>
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
Yes.
It also behaves correctly when a variable it refers to is later
mutated.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Thomas A. Russ <[EMAIL PROTECTED]> wrote: > > >(defun addn (n) > > > #'(lambda (x) > > > (+ x n))) > > > > The same as > > def addn(n): > > def fn(x): > > return n + x > > return fn > > Is this really equivalent? yes > What happens if you call addn more than once with different > parameters. Will you get different functions that you can > use simultaneously? yes > The lisp snippet creates new functions each time the addn function is > called, so one can interleave calls to the individual functions. In [21]: a = addn(4) In [22]: b = addn(5) In [23]: c = addn(25) In [24]: a(1) Out[24]: 5 In [25]: b(1) Out[25]: 6 In [26]: c(1) Out[26]: 26 -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.3.8 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
On Tue, 15 Mar 2005 14:16:09 -0800, Thomas A. Russ wrote: > The lisp snippet creates new functions each time the addn function is > called, so one can interleave calls to the individual functions. Yes, I believe them to be equivalent. Each call to addn creates an activation record which is closed over by fn. foo = addn(5) bar = addn(6) foo(4) => 9 bar(4) => 10 Matt -- "You do not really understand something unless you can explain it to your grandmother." â Albert Einstein. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Fernando <[EMAIL PROTECTED]> writes: > > On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> > wrote: > > >Maybe You can answer my question what this simple LISP function does ? > > > >(defun addn (n) > > #'(lambda (x) > > (+ x n))) > > The same as > def addn(n): > def fn(x): > return n + x > return fn Is this really equivalent? What happens if you call addn more than once with different parameters. Will you get different functions that you can use simultaneously? The lisp snippet creates new functions each time the addn function is called, so one can interleave calls to the individual functions. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
> (defun addn (n) > (lambda (x) > (+ x n))) > > And Lisp's "macro language" isn't involved at all here. (macroexpand-1 '(lambda (x) (+ x n))) => #'(LAMBDA (X) (+ X N)) Also, #' is a read-macro. Fully expanded the #'(lambda expression would be (function (lambda (x) (+ x n))) Then there's the "defun" macro . . . . :-) -- Fred Gilham[EMAIL PROTECTED] A common sense interpretation of the facts suggests that a superintellect has monkeyed with physics, as well as with chemistry and biology, and that there are no blind forces worth speaking about in nature. --- Fred Hoyle -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> wrote: >Maybe You can answer my question what this simple LISP function does ? > >(defun addn (n) > #'(lambda (x) > (+ x n))) The same as def addn(n): def fn(x): return n + x return fn >This is correct LISP-syntax if You bear in mind LISPs powerwull macro >language... defun is a macro but I don't think that's what you mean... -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Peter Lewerin wrote: "Kay Schluehr" <[EMAIL PROTECTED]> wrote > Maybe You can answer my question what this simple LISP function does ? It obviously returns a function adding n to the function's parameter, n being bound into the functions's closure during the call to ADDN. It's simple and straightforward. This is off-topic for comp.lang.python. Follow-ups set. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
"Kay Schluehr" <[EMAIL PROTECTED]> wrote > Maybe You can answer my question what this simple LISP function does ? It obviously returns a function adding n to the function's parameter, n being bound into the functions's closure during the call to ADDN. It's simple and straightforward. > This is correct LISP-syntax if You bear in mind LISPs powerwull macro > language... Actually, this suffices: (defun addn (n) (lambda (x) (+ x n))) And Lisp's "macro language" isn't involved at all here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED], Tue, 15 Mar 2005 13:10:52 +0100]: > It's indeed correct CL syntax, but I don't see much macro usage in there. defun? Albert. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Kay> Maybe You can answer my question what this simple LISP function does ? Kay> (defun addn (n) Kay> #'(lambda (x) Kay> (+ x n))) Is that a real question or are you making a rhetorical point here? Kay> This is correct LISP-syntax if You bear in mind LISPs powerwull macro Kay> language... It's indeed correct CL syntax, but I don't see much macro usage in there. Try (mapcar (addn 4) (list 1 2 3))... Ole -- http://mail.python.org/mailman/listinfo/python-list
Lisp-likeness
Maybe You can answer my question what this simple LISP function does ? (defun addn (n) #'(lambda (x) (+ x n))) This is correct LISP-syntax if You bear in mind LISPs powerwull macro language... I think Guido and python-dev are very carefull in adding new power to Python. They have to balance the needs for powerfull language features on the one hand, simplicity on the other hand. That this relation drifts towards more power and more complexity since Python 2.2. is a correct observation, but You probably may have notized that the number of large projects using Python as their primal language is growing. The boundary between that what was formerly called "systems programming" and "scripting" is blurred ( if Your mindset reduces "systems-programming" on the availability of pointers You certainly don't have any problems with the common public prejudices ). > The real problem with Python is that it has been very successful as a > scripting language in the static-typing/C/C++ world. Those > programmers, instead of adapting their evil ways to Python, and > realizing the advantages of a dynamic language, are influencing > Python's design and forcing it into the static-typing mold. Python is > going the C++ way: piling feature upon feature, adding bells and > whistles while ignoring or damaging its core design. Maybe You should explain what You regard as Pythons "core design", what belongs to the core and what to the periphery? Otherwise Your statement seems to be plain emotional. > The new 'perlified' syntax for decorators, the new static type bonds > and the weird decision to kill lambda instead of fixing it are good > examples that show that Python is going the wrong way. My hypothesis about lambda: lambda will be trashed because it is an alien in the language. It is impure. Trashing it is an expression of Pythons rassism. There is no way of "doing it right" without exceeding it's power and making it less controlable. When Guido once stated that the generator way of doing things is Pythons future it was also a renouncement of lambda. Compared with this ideological orientation the introduction of the @-syntax is a minor sacrilege on syntax esthetics - though this special character may hurd the souls of the believers more that everything else introduced into the language. Kay -- http://mail.python.org/mailman/listinfo/python-list
