Python syntax in Lisp and Scheme

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:[color=blue]
> In general, there are very few methodological studies on the
> effectiveness of different languages on general purpose
> programming problems when used by sets of people with
> roughly comparable experience. The only other one I have
> is Prechelt's "An empirical comparison ..."
> http://www.ipd.uka.de/~prechelt/Biblio/
> with the followup of Java v. Lisp at
> http://www.flownet.com/gat/papers/lisp-java.pdf
> That data also suggests that Tcl/Perl/Python/Lisp development time
> is comparable.[/color]

I'd be interested in a comparison of maintenance time. Perl feels
like a write-only language.


--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

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

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Pascal Bourguignon wrote:[color=blue]
> "Andrew Dalke" <adalke@mindspr ing.com> writes:
>[color=green]
>>And here's Table 31-2[/color]
>
>
> Sorted by statement per function point:
>
> Statements per
> Language Level Function Point
> -------- ----- --------------
> spreadsheets ~50 6[/color]

OK, this where Cells would fall, they are spreadsheets for objects.

:)

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Erann Gat wrote:
[color=blue]
> In article <bm20rh$2t$1@ne wsreader2.netco logne.de>, Pascal Costanza
> <costanza@web.d e> wrote:
>
>[color=green]
>>Christopher C. Stacy wrote:
>>
>>[color=darkred]
>>>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;
>>> ...
>>>}[/color]
>>
>>Maybe this is just a terminological issue, but in my book these are not
>>multi-methods. In Java, methods with the same name but different
>>signatures are selected at compile time,[/color]
>
>
> When the selection is done is immaterial. The point is that it's done at
> all. There's no reason why the same algorithm that is used to select
> methods at compile time can't also be used to select methods at run time.
> The claim that congruent argument lists are necessary for multi-method
> dispatch is clearly false.
>
>[color=green]
>>and this is rather like having
>>the parameter types as part of the method name.[/color]
>
>
> No. It's the "system" keeping track of the types, not the user. That's
> the key. The fact that C++ and Java just happen to do it at compile time
> rather than at run time is a red herring.
>
>[color=green]
>>This can lead to subtle bugs. Here is an example in Java:[/color]
>
>
> These "subtle bugs" are a reflection of the limitation of compile-time
> type inference in Java, not a limitation of multi-method dispatch with
> non-congruent argument lists.[/color]

OK, you're right. It seems to me that the common terminology uses
"multiple dispatch" for method selection at runtime and "method
overloading" for method selection at compile time. (for example, see
http://www.wikipedia.org/wiki/Multiple_dispatch )

However, maybe it would be better to instead talk about static and
dynamic dispatch, which also reflects the analogy to static and dynamic
typing.

According to this proposed terminology, Java would be a language that
uses single dynamic dispatch and multiple static dispatch. C++ would be
a language that generally uses multiple static dispatch but allows for
single dynamic dispatch. Smalltalk uses single dynamic dispatch and no
multiple dispatch whatsoever.

Sounds good. ;)


Pascal

[Dave Benjamin]

Re: Code block literals

Mike Rovner wrote:
[color=blue][color=green][color=darkred]
>>> >>> print mylist.map({ |x| return x + 2 }, range(5))
>>>0, 2, 4, 6, 8[/color]
>>
>>Duh... sorry, that should read:
>>print range(5).map({ |x| return x + 2 })[/color]
>
> I either case it will be [2, 3, 4, 5, 6] :)[/color]

Yeah yeah yeah, I really should read what I write before I post. But you
know what I mean, damnit! =)
[color=blue]
> Instead of lambda use list comprehensions:
>
> print [x+2 for x in range(5)]
>
> Unnamed code blocks considered evil :), use named instead (functions).[/color]

Why are they evil? Does being anonymous automatically make you evil?

For instance, I always thought this was a cooler alternative to the
try/finally block to ensure that a file gets closed (I'll try not to
mess up this time... ;) :

open('input.txt ', { |f|
do_something_wi th(f)
do_something_el se_with(f)
})

Rather than:

f = open('input.txt ')
try:
do_something_wi th(f)
do_something_el se_with(f)
finally:
f.close()

Now, I suppose you could always do:

def with_open_file( filename, func):
f = open(filename)
try:
func(f)
finally:
f.close()

# ...

def thing_doer(f):
do_something_wi th(f)
do_something_el se_with(f)
with_open_file( 'input.txt', thing_doer)

But the anonymous version still looks more concise to me.
[color=blue]
> With nested scopes you can do amazing things. I myself was used to code
> blocks due to perl background, but python idiom are not worse to say the
> least.
> For example:
>
> class C(object):
> ...
> def aprop():
> def reader(self): return 0
> def writer(self,new val): pass
> return reader, writer
> aprop=property( aprop())[/color]

Yeah, wasn't something like that up on ASPN? That's an interesting
trick... are you sure it's not supposed to be "property(*apro p())"
though? (who's being pedantic now? =)

Dave

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

Pascal Bourguignon <spam@thalassa. informatimago.c om> writes:
[color=blue]
> Alexander Schmolck <a.schmolck@gmx .net> writes:
> I was criticising the graphical aspect on a discrimination stand-point.
>
> For example, the difference between the latin glyphs for "ka" and "ga"
> is bigger than that between the corresponding kana glyphs.[/color]

Hear, hear: a lisper arguing for trading off simplicity, extensibility[1] and
regularity for discriminatabil ity :)

Maybe someone more proficient in Japanese might want to correct me, but I
really suspect it isn't worth it, actually. I don't think the heightened
discrimnatibili ty is needed that much and in fact would often even be
detrimental because a certain semantic compound often changes from
unvoiced to voiced (or from "big" to "little" TSU) in a fairly regular manner
in compound words (e.g. TETSU
(iron); $BE4!($F$D(B and HAN $BHD!($O$s(B( plate, inter alia) ->
TEPPAN, $BE4HD!((B $B$F$C$Q$s(B' iron plate/teppan cooking';
there is no TETSUHAN to confuse it with, AFAIK, so the fact that the
similarity between compound and parts is retained in the kana (unlike the
romanji transliteration ) is likely to be rather desirable).

'as

[hmm, never tried embedding japanese characters in usenet posting, hope it
works :|]



[1] yep, I mean it: katakana have actually be straighforwardl y extended
relatively recently to provide better transliteration s for (mainly
English) loan words.

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Edi Weitz wrote:
[color=blue]
> On Wed, 08 Oct 2003 23:05:28 GMT, Dave Benjamin <dave@3dex.co m> wrote:
>
>[color=green]
>>Python Myth: Python's only problem is the whitespace thing.
>>Reality: Python's only problem is that it is not Common Lisp.
>>
>>How about that?[/color]
>
>
> A good one... :)[/color]

I think Python's problem is its success. Whenever something is
succesful, the first thing people want is more features. Hell, that is
how you know it is a success. The BDFL still talks about simplicity, but
that is history. GvR, IMHO, should chased wish-listers away with "use
Lisp" and kept his gem small and simple.


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Doug Tolton:[color=blue]
> 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]

I disagree with your summary. Compare:

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.

Notice the "can". Now your summary is:

...allowing expressiveness via high level constructs detracts
from the effectiveness of the group

That implies that at least I assert that *all* high level constructs
detract from group effectiveness, when clearly I am not saying
that.

[color=blue][color=green]
> > 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]

Nor can you, because I did not say that. I said that the arguments you
use to justify your assertions could be stronger if you were to include
cases in your history and experience which show that you understand
the impacts of a language feature on both improving and detracting from
a group effort. Since you do have that experience, bring it up. But
since your arguments are usually along the lines of "taking tools out
of your hands", they carry less weight for this topic.

(Ambiguity clarification: "your hands" is meant as 2nd person singular
possessive and not 2nd person plural. :)
[color=blue]
> 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.[/color]

McConnell's book has the same study, with outliers for assembly
and APL. Indeed, I mentioned this in my reply:[color=blue][color=green]
> > ... and that LOC has a
> > good correlation to development time, excluding extremes like APL
> > and assembly.[/color][/color]
[color=blue]
> 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]

I assume you refer to "Succinctne ss is Power" at

http://www.paulgraham.com/power.html

It does not make as strong a case as you state here. It argues
that "succintnes s == power" but doesn't make any statement
about how much more succinct Lisp is over Python. He doesn't
like Paul Prescod's statement, but there's nothing to say that
Python can't be both easier to read and more succinct. (I am
not making that claim, only pointing out that that essay is pure
commentary.)

Note also that it says nothing about group productivity.
If it takes me 5% longer to write a program in language X
then language Y, but where I can more easily use code and
libraries developed by others then it might be a good choice
for me to use a slightly less succinct language.

Why don't people use APL/J/K with it's succinctness?

I also disagree with Graham's statement:[color=blue]
> the most accurate measure of the relative power of
> programming languages might be the percentage of
> people who know the language who will take any job
> where they get to use that language, regardless of the
> application domain.[/color]

I develop software for computational life sciences. I would
do so in Perl, C++, Java, even Javascript because I find
the domain to be very interesting. I would need to be very
low on money to work in, say, accounting software, even if
I had the choice of using Python.

[color=blue]
> 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]

Yes. In this I have a large body of expertise by which to compare
things. Perl dominates bioinformatics sofware development, and the
equivalent Python code is quite comparable in side -- I argue that
Python is easier to understand, but it's still about the same size.
[color=blue]
> 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.[/color]

"Can't be located"!?!?! I gave a full reference to the secondary material,
included the full quote (with no trimming to bias the table more my way),
gave the context to describe the headings, and gave you a reference
to the primary source! And I made every reasonable effort to find both
sources online.

Since you can't be suggesting that I tracked down and destroyed
every copy of McConnell's book and of the primary literature (to make
it truely unlocatable) then what's your real complaint? That things exist
in the world which aren't accessible via the web? And how is that my
fault?
[color=blue]
> If you want some real world numbers on program length check here:
> http://www.bagley.org/~doug/shootout/[/color]

If I want some real world numbers on program length, I do it myself:

http://pleac.sourceforge.net/

I wrote most of the Python code there

Still, since you insist, I went to the scorecard page and changed
the weights to give LOC a multipler of 1 and the others a multiplier
of 0. This is your definition of succinctness, yes? This table
is sorted (I think) by least LOC to most.

SCORES
Language Implementation Score Missing
Ocaml ocaml 584 0
Ocaml ocamlb 584 0
Ruby ruby 582 0
Scheme guile 578 0
Python python 559 0
Pike pike 556 0
Perl perl 556 0
Common Lisp cmucl 514 0
Scheme bigloo 506 1
Lua lua 492 2
Tcl tcl 478 3
Java java 468 0
Awk mawk 457 6
Awk gawk 457 6
Forth gforth 449 2
Icon icon 437 7
C++ g++ 435 0
Lisp rep 427 3
Haskell ghc 413 5
Javascript njs 396 5
Erlang erlang 369 8
PHP php 347 9
Emacs Lisp xemacs 331 9
C gcc 315 0
SML mlton 284 0
Mercury mercury 273 8
Bash bash 264 14
Forth bigforth 264 10
SML smlnj 256 0
Eiffel se 193 4
Scheme stalin 131 17

So:
- Why aren't you using Ocaml?
- Why is Scheme at the top *and* bottom of the list?
- Python is right up there with the Lisp/Scheme languages
- ... and with Perl.

Isn't that conclusion in contradiction to your statements
that 1) "Perl is *far* more compact than Python is" and 2)
the implicit one that Lisp is significantly more succinct than
Python? (As you say, these are small projects .. but you did
point out this site so implied it had some relevance.)
[color=blue]
> 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]

I invite you to dig up the original paper (which wasn't McConnell)
and enlighten us. Until then, I am as free to agree with McConnell --
more so because his book is quite good and comprehensive with
sound arguments comparing and contrasting the different
approaches and with no strong hidden agenda that I can detect.
[color=blue]
> It still wasn't relevant to Macros. However, because neither of you
> understand Macros, you of course think it is relevant.[/color]

My lack of knowledge not withstanding, the question I pose to
you is, in three parts:
- is it possible for a language feature to make a single programmer
more expressive/powerful while hindering group projects?
- can you list three examples of situations where that's occured?
- can you list one example where the increased flexibility was, in
general, a bad idea? That is, was there a language which would
have been better without a language feature.

Note that I did not at all make reference to macros. Your statements
to date suggest that your answer to the first is "no."

Andrew
dalke@dalkescie ntific.com

[Lulu of the Lotus-Eaters]

Re: Code block literals

Dave Benjamin <dave@3dex.co m> wrote previously:
|return { |x, y|
| print x
| print y
|}
|It's unambiguous because no dictionary literal would ever start with
|'{|', it looks almost identical to a certain other language <g>

Btw. I think Dave is thinking of Ruby as that "certain other language."
But Clipper/xBase used the same syntax for the same thing before Ruby
was a glimmer in Matz' eye. I'm not sure if that's where he got it
though... it might be from somewhere older I don't know about.

Yours, Lulu...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.c x> ]--------------------------

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net:[color=blue]
> So either the syntax doesn't make a whole hell of a lot of difference
> in readability, or readability doesn't make a whole hell of a lot of
> difference in utility.[/color]

Or the people who prefer the awesome power that is Lisp and
Scheme don't find the limited syntax to be a problem.

Andrew
dalke@dalkescie ntific.com

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Doug Tolton:
>[/color]
[color=blue][color=green]
>> 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]
>
>
> I assume you refer to "Succinctne ss is Power" at
> http://www.paulgraham.com/power.html
>
> It does not make as strong a case as you state here. It argues
> that "succintnes s == power" but doesn't make any statement
> about how much more succinct Lisp is over Python.[/color]

He provides more information at http://www.paulgraham.com/icad.html


Pascal

[Rayiner Hashem]

Re: Python syntax in Lisp and Scheme

> Lisp doesn't let you do that, because it turns out to be a bad idea.
Only if you subscribe to the Java-mentality that power is bad. Operator
overloading is a must in languages that strive to make user-defined types
fully equal to built-in types (like Dylan, and Goo, maybe CLOS). Besides,
prohibiting operator-overloading is not orthogonal in languages with
generic dispatch, because it creates a pointless schism between built-in
operators and user-defined types.
[color=blue]
> When you go reading someone's program, what you really want is for
> the standard operators to be doing the standard and completely
> understood thing.[/color]
Why? Usually, you cannot overload operators on built-in types. So an integer
plus an integer will always have a specific meaning. However a matrix plus
a matrix can have a user-defined meaning, assuming matricies are
user-defined types. Now, a programmer could go ahead and make an overload
of operator+ that actually subtracted matricies, but he could just as well
write a function "add-matrix" that actually subtracted matricies. And
assuming that the programmer isn't trying to lie to you, its much easier to
understand

(+ m1 m2 m3)

than

(add-matrix m1 m2 m3)

because '+' carries with it an expected set of semantics, while the reader
has to go to the definiton of add-matrix to fully understand its semantics.
[color=blue]
> Lisp has carefully defined those operations to do all the things
> that are both well-understood (like complex numbers) and missing
> from languages like C++.[/color]
Actually, C++ has a complex number class in its standard library. Why not in
the language proper? There is no need for it to be in the language, because
it can be implemented in the library just as easily. Its the same reason
'loop' is a macro and not built into the language. Besides, what do you do
when you need quaternions? Wait for the next version of the standard?

[Paul Rubin]

Re: Python syntax in Lisp and Scheme

Kenny Tilton <ktilton@nyc.rr .com> writes:[color=blue]
> I think Python's problem is its success. Whenever something is
> succesful, the first thing people want is more features. Hell, that is
> how you know it is a success. The BDFL still talks about simplicity,
> but that is history. GvR, IMHO, should chased wish-listers away with
> "use Lisp" and kept his gem small and simple.[/color]

That's silly. Something being successful means people want to use it
to get things done in the real world. At that point they start
needing the tools that other languages provide for dealing with the
real world. The real world is not a small and simple place, and small
simple systems are not always enough to cope with it. If GVR had kept
his gem small and simple, it would have remained an academic toy, and
I think he had wide-reaching ambitions than that.

[Sean Ross]

Re: Code block literals


"Dave Benjamin" <dave@3dex.co m> wrote in message
news:u%0hb.113$ _f.1@news1.cent ral.cox.net...[color=blue]
> Yeah, wasn't something like that up on ASPN? That's an interesting
> trick... are you sure it's not supposed to be "property(*apro p())"
> though? (who's being pedantic now? =)[/color]

Hi.

The idiom/recipe is at

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183

Sean

[Rayiner Hashem]

Re: Python syntax in Lisp and Scheme

> sure, but it seems like noone was able to let Cconceivable(vi rtual) inner
classes,
That's because Lisp has closures, and because CL doesn't mandate access
protections for classes.
[color=blue]
> methods inside methods,[/color]
You can use a lambda to accomplish the same thing.
[color=blue]
> virtual methods (yeah I know about those stupid generic functions :),[/color]
Generic functions are just virtual methods generalized to multiple dispatch.
[color=blue]
> method overloading[/color]
Method overloading is just a special case of generic dispatch in situations
where the types of the dispatch arguments are known at compile-time. In
situations where method overloading could be applicable, GF dispatch
doesn't even have a performance hit over static method overloading because
the compiler can optimize-out the generic dispatch.
[color=blue]
> A decent API (I tried playing with it.. it doesn't even have a freaking
> date library as standard ;-p[/color]
Google for one! What's the point of having every conceivable library in the
language?
[color=blue]
>
> Yes I agree with the compile time macro expansion is a nice thing.
> However, if I want to do some serious changes to the structure of objects
> and classes (i.e. create a new kind of objects) then I have to spend a
> long time finding out how the CLOS people hacked together their
> representation of classes, methods, method call etc...[/color]
There is a MOP provided expressly for this purpose.

[Dave Benjamin]

Re: Code block literals

Sean Ross wrote:
[color=blue][color=green]
>>Yeah, wasn't something like that up on ASPN? That's an interesting
>>trick... are you sure it's not supposed to be "property(*apro p())"
>>though? (who's being pedantic now? =)[/color]
>
> Hi.
>
> The idiom/recipe is at
> http://aspn.activestate.com/ASPN/Coo.../Recipe/205183[/color]

Thanks, Sean.