Python syntax in Lisp and Scheme

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Andreas Rossberg wrote:[color=blue]
> Dirk Thierbach wrote:
>[color=green]
>>
>> you can use macros to
>> do everything one could use HOFs for (if you really want).[/color]
>
>
> Really? What about arbitrary recursion?[/color]

When you need arbitrary recursion you use HOF. When macro are more
appropriate you use them. If you don't have both you are out of luck.

Cheers
--
Marco

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Rainer Joswig wrote:[color=blue]
> In article <6CZgb.3273$dn6 .860@newsread4. news.pas.earthl ink.net>,
> "Andrew Dalke" <adalke@mindspr ing.com> wrote:
>
> snip
>
>[color=green]
>>And here's Table 31-2
>>
>> Statements per
>>Language Level Function Point
>>-------- ----- --------------
>>Assembler 1 320
>>Ada 83 4.5 70
>>AWK 15 25
>>C 2.5 125
>>C++ 6.5 50
>>Cobol (ANSI 85) 3.5 90
>>dBase IV 9 35
>>spreadsheet s ~50 6
>>Focus 8 40
>>Fortran 77 3 110
>>GW Basic 3.25 100
>>Lisp 5 65
>>Macro assembler 1.5 215
>>Modula 2 4 80
>>Oracle 8 40
>>Paradox 9 35
>>Pascal 3.5 90
>>Perl 15 25
>>Quick Basic 3 5.5 60
>>SAS, SPSS, etc. 10 30
>>Smalltalk (80 & V) 15 20
>>Sybase 8 40
>>Visual Basic 3 10 30
>>
>> Source: Adapted from data in 'Programming Languages
>> Table' (Jones 1995a)[/color]
>
>
> I thought these numbers were bogus. Weren't many
> of them just guesses with actually zero data
> or methodology behind them???[/color]

Apart from that, what does the author mean by "Lisp"? Is it Common Lisp
or some other Lisp dialect? Scheme?

According to this table, Modula-2 and Lisp are in the same league - I
have used both languages, and this just doesn't align with my experience.

Furthermore, CLOS can be regarded as a superset of Smalltalk. How can it
be that Smalltalk is more than three times better than Lisp? Even if you
take Scheme that doesn't come with an object system out of the box, you
can usually add one that is at least as powerful as Smalltalk. Or did
they add the LOC of infrastructure libraries to their results?


Pascal

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:[color=blue]
> And here's Table 31-2[/color]

Sorted by statement per function point:

Statements per
Language Level Function Point
-------- ----- --------------
spreadsheets ~50 6
Smalltalk (80 & V) 15 20
AWK 15 25
Perl 15 25
SAS, SPSS, etc. 10 30
Visual Basic 3 10 30
Paradox 9 35
dBase IV 9 35
Focus 8 40
Oracle 8 40
Sybase 8 40
C++ 6.5 50
Quick Basic 3 5.5 60
Lisp 5 65
Ada 83 4.5 70
Modula 2 4 80
Cobol (ANSI 85) 3.5 90
Pascal 3.5 90
GW Basic 3.25 100
Fortran 77 3 110
C 2.5 125
Macro assembler 1.5 215
Assembler 1 320
[color=blue]
> Source: Adapted from data in 'Programming Languages
> Table' (Jones 1995a)
>
>
> I'll use Perl as a proxy for Python; given that that was pre-OO
> Perl I think it's reasonable that that sets a minimum level for
> Python. Compare the Lisp and Perl numbers
>
> Lisp 5 65
> Perl 15 25
>
> and the differences in "statements per function point" (which isn't
> quite "LOC per function point") is striking. It suggests that
> Python is more than twice as concise as Lisp, so if LOC is
> used as the estimate for implementation time then it's a strong
> recommendation to use Python instead of Lisp because it
> will take less time to get the same thing done. And I do believe
> Lisp had macros back in the mid-1990s.[/color]


Some differences in this table look suspect to me. Perhaps they did
not take into account other important factors, such as the use of
libraries.

For example, when I write awk code, I really don't feel like I'm
programming in a higher level languange than LISP... (and I won't
mention perl).

Also, the ordering of Fortran vs. C fell strange (given the libraries
I use in C and the fact that I don't use Fortran).


--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[Peter Seibel]

Re: Python syntax in Lisp and Scheme

Rainer Joswig <joswig@lispmac hine.de> writes:
[color=blue]
> In article <6CZgb.3273$dn6 .860@newsread4. news.pas.earthl ink.net>,
> "Andrew Dalke" <adalke@mindspr ing.com> wrote:
>
> snip
>[color=green]
> > And here's Table 31-2
> >
> > Statements per
> > Language Level Function Point
> > -------- ----- --------------
> > Assembler 1 320
> > Ada 83 4.5 70
> > AWK 15 25
> > C 2.5 125
> > C++ 6.5 50
> > Cobol (ANSI 85) 3.5 90
> > dBase IV 9 35
> > spreadsheets ~50 6
> > Focus 8 40
> > Fortran 77 3 110
> > GW Basic 3.25 100
> > Lisp 5 65
> > Macro assembler 1.5 215
> > Modula 2 4 80
> > Oracle 8 40
> > Paradox 9 35
> > Pascal 3.5 90
> > Perl 15 25
> > Quick Basic 3 5.5 60
> > SAS, SPSS, etc. 10 30
> > Smalltalk (80 & V) 15 20
> > Sybase 8 40
> > Visual Basic 3 10 30
> >
> > Source: Adapted from data in 'Programming Languages
> > Table' (Jones 1995a)[/color]
>
> I thought these numbers were bogus. Weren't many of them just
> guesses with actually zero data or methodology behind them???[/color]

Well, here are some other interesting entries (from the table on p.89
of Jones's _Applied Software Measurement_):

Language Level Function Point
-------- ----- --------------
CLOS 12.0 27
KSH 12.0 27
PERL 12.0 27 [it had 27, while the the other table had 25]
MAKE 15.0 21

I'm not sure what to make of CLOS being separate from Common Lisp, but
there it is. But it's sort of moot because by this measure, MAKE is a
higher level language than either Lisp, Perl, or C++. Personally, I
think I'll be looking for another metric.

-Peter

--
Peter Seibel peter@javamonke y.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Doug Tolton:
>[color=green]
>>I believe the crux of our difference is that you don't want to give
>>expressive power because you believe it will be misused. I on the
>>other hand want to give expressive power because I believe it could be
>>used correctly most of the time. For the times when it's not, well
>>that's why I have debugging skills. Sadly not eveyone uses looping
>>the way I would, but using my brain I can figure out what they are
>>doing.[/color]
>
>
> That point has been made over and over to you. The argument is
> that expressive power for a single developer can, for a group of
> developers and especially those comprised of people with different
> skill sets and mixed expertise, reduce the overall effectiveness of the
> group.[/color]

Do you have some empirical data and/or references that back this claim?


Pascal

[Joe Marshall]

Re: Python syntax in Lisp and Scheme

David Rush <drush@aol.ne t> writes:
[color=blue]
> You know I think that this thread has so far set a comp.lang.* record
> for civilitiy in the face of a massively cross-posted language
> comparison thread. I was even wondering if it was going to die a quiet
> death, too.
>
> Ah well, We all knew it was too good to last. Have at it, lads!
>
> Common Lisp is an ugly language that is impossible to understand with
> crufty semantics
>
> Scheme is only used by ivory-tower academics and is irerelevant to
> real world programming
>
> Python is a religion that worships at the feet of Guido vanRossum
> combining the syntactic flaws of lisp with a bad case of feeping
> creaturisms taken from languages more civilized than itself
>
> There. Is everyone pissed off now?[/color]

No, that seems about right.

[Joe Marshall]

Re: Python syntax in Lisp and Scheme

"Carlo v. Dango" <oest@soetu.e u> writes:
[color=blue][color=green]
>> I'd humbly suggest that if you can't see *any* reason why someone
>> would prefer Lisp's syntax, then you're not missing some fact about
>> the syntax itself but about how other language features are supported
>> by the syntax.[/color]
>
> Sure, but it seems like no one was able to let CLOS have
> (virtual) inner classes,[/color]

Um. What on earth would that mean? I know what it means in Java
and such, but since CLOS classes are not conflated with lexical
scope, there's nothing to be `inner' to.
[color=blue]
> methods inside methods,[/color]

What would one do with one of those? How would that differ
from, say, FLET or LABELS?
[color=blue]
> virtual methods (yeah I know about those stupid generic functions :),[/color]

Since all CLOS is dynamic dispatch (i.e. virtual), what are you
talking about?
[color=blue]
> method overloading,[/color]

Now I'm *really* confused. I thought method overloading involved
having a method do something different depending on the type of
arguments presented to it. CLOS certainly does that.
[color=blue]
> A decent API (I tried playing with it.. it doesn't even have a
> freaking date library as standard ;-p[/color]

I was unaware that a date library was so critical to an
object-oriented implementation.
[color=blue]
> yes this mail is provocative.. please count slowly to 10 before
> replying if you disagree with my point of view (and I know Pascal will
> disagree ;-)[/color]

I'll wait until you have a coherent point of view to disagree with.

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Doug Tolton:
>[color=green]
>>I believe the crux of our difference is that you don't want to give
>>expressive power because you believe it will be misused. I on the
>>other hand want to give expressive power because I believe it could be
>>used correctly most of the time. For the times when it's not, well
>>that's why I have debugging skills. Sadly not eveyone uses looping
>>the way I would, but using my brain I can figure out what they are
>>doing.[/color]
>
>
> That point has been made over and over to you. The argument is
> that expressive power for a single developer can, for a group of
> developers and especially those comprised of people with different
> skill sets and mixed expertise, reduce the overall effectiveness of the
> group.[/color]
Yes and I have repeatedly stated that I disagree with it. I simply do
not by that allowing expressiveness via high level constructs detracts
from the effectiveness of the group. That argument is plainly
ridiculous, if it were true then Python would be worse than Java,
because Python is *far* more expressive.[color=blue]
>
> If this is indeed the crux, then any justification which says "my brain"
> and "I" is suspect, because that explicitly ignores the argument.[/color]
Apparently you can't read very well. I simply stated that I believe our
point of contention to be that issue, I never stated I believe that
because it's some vague theory inside my head.
[color=blue]
> By
> comparison, Alex's examples bring up
> - teaching languages to others
> - interference between his code and others' (the APL example)
> - production development
> "Imagine a group of, say, a dozen programmers, working together ...
> to develop a typical application program of a few tens of thousands
> of
> function points -- developing about 100,000 new lines of delivered
> code
> plus about as much unit tests, and reusing roughly the same amount"
> - writing books for other people[/color]
With the exception of writing books for other people, I have done all of
those things. I have worked on fairly large development teams > 20
people. I have built multi-million dollar systems. I have taught
people programming languages, both on the job and as a University
Course. So don't come off with this attitude of I have no idea what I'm
talking about.

Macro's are precisely better for large groups of people. Any time you
are building systems with Large groups of people, and you want to have
re-usable code, you abstract it. There are all kinds of ways to do
that, Macros are just one. I have never seen any large successful
coding project that does not abstract things well. If you are incapable
of abstracting software successful and usefully then no project will be
successful, not if it's non-trivial.[color=blue]
>
> which at the very least suggests the expertise and background
> by which to evaluate the argument. It may be that his knowledge of
> how and when to use macros is based on the statements of people he
> respects rather than personal experience, but given the discussions on
> this topic and the exhibited examples of when macros are appropriately
> used, it surely does seem that metaclasses, higher-level functions, and
> iterators can be used to implement a solution with a roughly equal amount
> of effort and clarity. Th only real advantage to macros I've seen is the
> certainty of "compile-time" evaluation, hence better performance than
> run-time evaluation[/color]
As I said to Alex, that's because you don't understand Macros. Relying
on what someone else says about Macros only gets you so far. At some
point, if you don't want to look like a complete idiot, you might want
to really learn them or just shut up about them. It's very difficult to
have a conversation with someone who really doesn't know what they are
talking about, but is instead just spouting an opinion they picked up
from someone else. The discussion doesn't go anywhere at that point.

Macros are like any things else, a tool in your tool box. If you know
how to use them they can be used very effectively. If you don't, you
can probably work around the problem and solve it a different way.
However as the toolset differential gets bigger, the person with more
tools in their arsenal will be able to outperform the people with less
tools.[color=blue]
>
> Alex:
>[color=green][color=darkred]
>>>For some (handwaving-defined) "appropriat e" approach to measuring
>>>"length" (and number of lines is most definitely not it), it is ONE[/color][/color]
>
>
> You:
>[color=green]
>>Both from my experience and Fred Brooks it's the only actual way I've
>>seen of measuring the time it will take to write a program.[/color]
>
>
> You mean "estimating "; for measuring I suspect you can use a
> combination of a clock and a calendar. (This from a guy who recently
> posted that the result of 1+1 is 4. ;)[/color]
No, what I was referring to wasn't estimation. Rather I was referring
to the study that found that programmers on average write the same
number of lines of code per year regardless of the language they write
in. Therefore the only way to increase productivity is to write
software in a language that uses less lines to accomplish something
productive. See Paul Grahams site for a discussion.[color=blue]
>
> You should use McConnell as a more recent reference than Brooks.
> (I assume you are arguing from Mythical Man Month? Or from his
> more recent writings?) In any case, in Rapid Development McConnell
> considers various alternatives then suggests using LOC, on the view
> that LOC is highly correlated with function points (among 3rd
> generation programming languages! see below) and that LOC has a
> good correlation to development time, excluding extremes like APL
> and assembly. However, his main argument is that LOC is an easy
> thing to understand.
>
> The tricky thing about using McConnell's book is the implications
> of table 31-2 in the section "Using Rapid Development Languages",
> which talks about languages other than the 3rd generation ones used
> to make his above estimate.
>
> Table 31-2 shows the approximate "language levels" for a wider
> variety of languages than Table 31-1. The "language level" is
> intended to be a more specific replacement for the level implied
> by the phrases "third-generation language" and "fourth-generation
> language." It is defined as the number of assembler statements
> that would be needed to replace one statement in the higher-level
> language. ...
>
> The numbers ... are subject to a lot of error, but they are the best
> numbers available at this time, and they are accurate enough to
> support this point: from a development poing of view, you should
> implement your projects in the highest-level language possible. If
> you can implement something in C, rather than assembler, C++
> rather than C, or Visual Basic rather than C++, you can develop
> faster.
>
> And here's Table 31-2
>
> Statements per
> Language Level Function Point
> -------- ----- --------------
> Assembler 1 320
> Ada 83 4.5 70
> AWK 15 25
> C 2.5 125
> C++ 6.5 50
> Cobol (ANSI 85) 3.5 90
> dBase IV 9 35
> spreadsheets ~50 6
> Focus 8 40
> Fortran 77 3 110
> GW Basic 3.25 100
> Lisp 5 65
> Macro assembler 1.5 215
> Modula 2 4 80
> Oracle 8 40
> Paradox 9 35
> Pascal 3.5 90
> Perl 15 25
> Quick Basic 3 5.5 60
> SAS, SPSS, etc. 10 30
> Smalltalk (80 & V) 15 20
> Sybase 8 40
> Visual Basic 3 10 30
>
> Source: Adapted from data in 'Programming Languages
> Table' (Jones 1995a)
>
>
> I'll use Perl as a proxy for Python; given that that was pre-OO
> Perl I think it's reasonable that that sets a minimum level for
> Python. Compare the Lisp and Perl numbers
>
> Lisp 5 65
> Perl 15 25[/color]
You are saying that Python and Perl are similarly compact?!?
You have got to be kidding right?
Perl is *far* more compact than Python is. That is just ludicrous.[color=blue]
>
> and the differences in "statements per function point" (which isn't
> quite "LOC per function point") is striking. It suggests that
> Python is more than twice as concise as Lisp, so if LOC is
> used as the estimate for implementation time then it's a strong
> recommendation to use Python instead of Lisp because it
> will take less time to get the same thing done. And I do believe
> Lisp had macros back in the mid-1990s.
>
> Sadly, this is a secondary reference and I don't have a
> copy of
> Jones, Capers, 1995a. "Software Productivity Research
> Programming Languages Table," 7th ed. March 1995.
> and the referenced URL of www.spr.com/library/langtbl.htm
> is no longer valid and I can't find that table on their site.
>[/color]
It's always nice just to chuck some arbitrary table into the
conversation which conveniently backs some poitn you were trying to
make, and also conveniently can't be located for anyone to check the
methodology.

If you want some real world numbers on program length check here:

http://www.bagley.org/~doug/shootout/

Most of those programs are trivially small, and didn't use Macros.
Macros as well as high order functions etc only come into play in
non-trivial systems.

I just don't buy these numbers or the chart from Mcconell on faith. I
would have to see his methodolgy, and understand what his motivation in
conducting the test was.
[color=blue]
>
>[color=green]
>>Well that was a long winded digression into something that is
>>completely un-related to Macros. Seems like a good argument why
>>re-binding the buildins is bad though[/color]
>
>
> It was a long winded digression into how LOC can be a
> wrong basis by which to judge the appropriateness of a
> language feature.[/color]
It still wasn't relevant to Macros. However, because neither of you
understand Macros, you of course think it is relevant.[color=blue]
>
>[color=green][color=darkred]
>>>a plus -- and Java's use of { } for example ensures NON-uniformity
>>>on a lexical plane, since everybody has different ideas about where
>>>braces should go:-).
>>>[/color]
>>
>>Where braces should go is a trivial issues. However if braces is an
>>issue that seriously concerns you then I can see why macros are giving
>>you a heart attack.[/color]
>
>
> See that smiley and the "--"? This is a throwaway point at the end
> of the argument, and given Alex's noted verboseness, if it was a
> serious point he would have written several pages on the topic.[/color]
This is something we are very much in agreement on.
My response was just a little dig, because it does seem to be indicative
of his attitude in general IMO.[color=blue]
>
> Andrew
> dalke@dalkescie ntific.com
>
>[/color]


--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[David Mertz]

Re: Python syntax in Lisp and Scheme

There's something pathological in my posting untested code. One more
try:

def categorize_join tly(preds, it):
results = [[] for _ in preds]
for x in it:
results[all(preds)(x)].append(x)
return results

|Come on. Haskell has a nice type system. Python is an application of
|Greespun's Tenth Rule of programming.

Btw. This is more nonsense. HOFs are not a special Lisp thing. Haskell
does them much better, for example... and so does Python.

Yours, David...

--
mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
..cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s

[Lulu of the Lotus-Eaters]

Re: Python syntax in Lisp and Scheme

Alex Martelli:
|>Why, thanks! Nice to see that I'm getting on the nerves of _some_
|>people, too, not just having them get on mine.

Doug Tolton <doug@nospam.co m> wrote previously:
|Yes, this discussion is frustrating. It's deeply frustrating to hear
|someone without extensive experience with Macros arguing why they are
|so destructive.

If that is meant to address Alex Martelli, it is very deeply misguided.
If there is anyone who I can say with confidence has much more
experience--and much better understanding--of macros (or of all things
Lisp) than does Doug Tolton, it is Alex.

Yours, Lulu...

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

David Mertz wrote:
[color=blue]
> There's something pathological in my posting untested code. One more
> try:
>
> def categorize_join tly(preds, it):
> results = [[] for _ in preds]
> for x in it:
> results[all(preds)(x)].append(x)
> return results
>
> |Come on. Haskell has a nice type system. Python is an application of
> |Greespun's Tenth Rule of programming.
>
> Btw. This is more nonsense. HOFs are not a special Lisp thing. Haskell
> does them much better, for example... and so does Python.
>[/color]
What is your basis for that statement? I personally like the way Lisp
does it much better, and I program in both Lisp and Python. With Python
it's not immediately apparent if you are passing in a simple variable
or a HOF. Whereas in lisp with #' it's immediately obvious that you are
receiving or sending a HOF that will potentially alter how the call
operates.

IMO, that syntax is far clearner.
[color=blue]
> Yours, David...
>
> --
> mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
> gnosis _/_/ Postmodern Enterprises _/_/ s r
> .cx _/_/ MAKERS OF CHAOS.... _/_/ i u
> _/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
>
>[/color]


--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Lulu of the Lotus-Eaters wrote:
[color=blue]
> Alex Martelli:
> |>Why, thanks! Nice to see that I'm getting on the nerves of _some_
> |>people, too, not just having them get on mine.
>
> Doug Tolton <doug@nospam.co m> wrote previously:
> |Yes, this discussion is frustrating. It's deeply frustrating to hear
> |someone without extensive experience with Macros arguing why they are
> |so destructive.
>
> If that is meant to address Alex Martelli, it is very deeply misguided.
> If there is anyone who I can say with confidence has much more
> experience--and much better understanding--of macros (or of all things
> Lisp) than does Doug Tolton, it is Alex.
>
> Yours, Lulu...
>[/color]

That was an interestingly ingorant statement. I'm very suprised that
you would feel the *least* bit qualified to offer that statement. You
don't know me or my background. Alex has stated on many occasions that
he has not worked with Macros, but that he is relying on second hand
information.

I don't claim to be a guru on Lisp, however I believe I understand it
far better than Alex does. If the people who actually know and use
Common Lisp think I am mis-speaking and mis-representing Lisp, please
let me know and I will be quiet.

What is your background with Common Lisp David? Why do you feel so
eminently qualified to offer yourself as the expert on Lisp? I have
seen some FP from you, but I haven't seen much in the way of Lisp code.
Did you study it in school? Have you really tried to build production
quality system with Lisp?

Like I said, I'm not an expert at Lisp, but I think I understand the
spirit and semantics of Lisp far better than Alex, and from what I've
seen you say I wouldn't be suprised if I knew it better than you do as well.

--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Christopher C. Stacy]

Re: Python syntax in Lisp and Scheme

>>>>> On 08 Oct 2003 11:47:45 -0700, Thomas F Burdick ("Thomas") writes:
Thomas> How could you have both noncongruent argument lists, and multiple
Thomas> dispatch? With an either/or like that, Lisp chose the right one.

This reason that Common Lisp made this choice is not because non-congruent
multiple-dispatch methods are impossible. To dispatch: instead of just
matching the types of the args, consider only those handler entries that
have the correct shape (length) as well.

JAVA has multi-methods with non-congruent arglist.
(It doesn't have multiple inheritence, but that doesn't
matter to dynamic type dispatching, except maybe in how
you implement searching your handler tables.) In JAVA,
the correspondance of the "signature" of the function call
and the method definition are what's important;
and there are no restricting "generic functions".

public class RandomAccessFil e extends Object,implemen ts DataOutput {
public void write(byte[] b) throws IOException;
public void write(byte[] b, int off, int len) throws IOException;
...
}

CLOS imposes an aesthetic design restriction on the programmer:
methods with the same name should be conceptually doing the
same function, and therefore should be all taking the same args.
The generic function is the documentation of that mono protocol.
This is one of the few places that Lisp takes a facist attitude.

[Dave Benjamin]

Code block literals

Alex Martelli wrote:[color=blue]
> The only annoyance here is that there is no good 'literal' form for
> a code block (Python's lambda is too puny to count as such), so you
> do have to *name* the 'thefunc' argument (with a 'def' statement --
> Python firmly separates statements from expressions).[/color]

Here's my non-PEP for such a feature:

return { |x, y|
print x
print y
}

Which would be the equivalent of:

def anonymous_funct ion(x, y):
print x
print y
return anonymous_funct ion

It's unambiguous because no dictionary literal would ever start with
'{|', it looks almost identical to a certain other language <g>, and
instead of being a special case for a function, it would just be a plain
old HOF. No more talk of puny lambda:, and we can all go home and
happily write visitor patterns and event callbacks all day long.

Then, merge map, filter, and reduce into the list type, so we can play
Smalltalk and write stuff like:
[color=blue][color=green][color=darkred]
>>> print mylist.map({ |x| return x + 2 }, range(5))[/color][/color][/color]
0, 2, 4, 6, 8

If you wanted to span multiple lines, just take the first indentation
you find and start from there:

closure = True
some_screen_obj ect.on_click = { |e|
print 'got an event: ' + e
handle_screen_o bject_click()
if closure = True:
go_home_happy()
}

You're welcome,
Dave ;)

[Dave Benjamin]

Re: Code block literals

Dave Benjamin wrote:
[color=blue][color=green][color=darkred]
> >>> print mylist.map({ |x| return x + 2 }, range(5))[/color][/color]
> 0, 2, 4, 6, 8[/color]

Duh... sorry, that should read:
print range(5).map({ |x| return x + 2 })

(and yes, I realize a lambda would work here)

Dave