Python syntax in Lisp and Scheme

[Christopher C. Stacy]

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 RandomAccessFile extends Object,implements 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]

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).

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

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

Which would be the equivalent of:

def anonymous_function(x, y):
print x
print y
return anonymous_function

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:
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_object.on_click = { |e|
print 'got an event: ' + e
handle_screen_object_click()
if closure = True:
go_home_happy()
}

You're welcome,
Dave

 

[Dave Benjamin]

0, 2, 4, 6, 8

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

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

Dave

 

[Rainer Joswig]

snip


I thought these numbers were bogus. Weren't many of them just
guesses with actually zero data or methodology behind them???

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

Just look at this:

http://www.theadvisors.com/langcomparison.htm

And read:

The languages and levels in Table 2 were gathered in four ways.

* Counting Function Points and Source Code
* Counting Source Code
* Inspecting Source Code
* Researching Languages

and

Researching Languages

Research was done by reading descriptions and genealogies
of languages and making an educated guess as to their levels. KL,
CLOS, TWAICE, and FASBOL are examples of languages that were
assigned tentative levels merely from descriptions of the
language, rather than from actual counts.

Well, I guess CLOS is, ... about, say, hmm, scratching my head, hmm,
let's say 73.

Right?

Let's say it differently, the comparison is a BAD joke.

 

[Pascal Costanza]

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 RandomAccessFile extends Object,implements DataOutput {
public void write(byte[] b) throws IOException;
public void write(byte[] b, int off, int len) throws IOException;
...
}

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, and this is rather like having
the parameter types as part of the method name.

This can lead to subtle bugs. Here is an example in Java:

public class test {

static void m(Object o) {
System.out.println("m/Object");
}

static void m(String s) {
System.out.println("m/String");
}

static void n(Object o) {
m(o);
}

public static void main(String[] args) {
n("test");
}

}

This prints "m/Object", instead of "m/String" as you might expect. (This
is one of the reasons why the Visitor pattern is relatively tedious to
implement in Java.)


Pascal

 

[Karl A. Krueger]

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?

This seems like a good juncture to post my list of common myths and
misconceptions about popular programming languages. Contributions are
welcome; flames only if they're funny. Anyone who needs to see on
things to know they're meant in jest should stop reading now.


== Programming Language Myths ==

BASIC Myth: People who learn BASIC go on to learn other languages.
Reality: Most people who learn BASIC go on to find less nerdy ways of
writing "Mr. Gzabowski is a lame teacher" over and over again.

C Myth: C programs are insecure, full of buffer overflows and such.
Reality: C programs are only insecure if written by imperfect programmers.
Since all C programmers know that they are perfect, there's no
problem.

COBOL Myth: COBOL is dead.
Reality: It stalks from out the ancient vaults of death, its putrid mind
drawn to the blood of the living.

Forth Myth: Forth makes no sense.
Reality: backwards. think to have just you sense, perfect makes Forth

Java Myth: You need Java to do business applications.
Reality: You need Java to get a job.

Lisp Myth: Lisp is an interpreted language.
Reality: Lisp is COMPILED DAMMIT COMPILED! IT'S IN THE FUCKING STANDARD!!!

Pascal Myth: Pascal is a toy.
Reality: Oh, wait, that is not a myth, it is true ...

Perl Myth: Perl is impossible to read.
Reality: You are not taking enough psychedelics.

Python Myth: Python's only problem is the whitespace thing.
Reality: Python's only problem is that it is fucking slow.

 

[Andrew Dalke]

Peter Seibel:

PERL 12.0 27 [it had 27, while the the other table

had 25]

I double checked. McConnell lists "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.

McConnell said that if you *could* do it in a given higher level
language then you should. Eg, spreadsheets are listed as a very
high level language, but you wouldn't write a word processor
in one.

I don't know the background behind the paper you referenced.
I suspect is has the same qualifier. If so, it's quite true that
using make for its domain is more appropriate than a more general
general purpose language.

Andrew
(e-mail address removed)

 

[Christopher C. Stacy]

Joe> Now I'm *really* confused. I thought method overloading involved
Joe> having a method do something different depending on the type of
Joe> arguments presented to it. CLOS certainly does that.

He probably means "operator overloading" -- in languages where
there is a difference between built-in operators and functions,
their OOP features let them put methods on things like "+".

Lisp doesn't let you do that, because it turns out to be a bad idea.
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. Most commonly, the operators that people in C++
like to overload are the mathematical ones, like "*" and "+".
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++. And in Lisp if you want to do some
other kind of arithmetic, you must make up your names for those
operators. This is considered to be a good feature.

Not surprisingly, the designers of JAVA understood this as well:
JAVA doesn't let you overload operators, either.

 

[Lulu of the Lotus-Eaters]

|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...

 

[Bengt Richter]

No, that seems about right.

LOL ;-)

Regards,
Bengt Richter

 

[Andrew Dalke]

Rainer Joswig
Pascal Costanza

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

As I mentioned, I don't have the primary sources, so I can't
give any more information about the data.

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.

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.

Good thing I didn't try to skew the data by leaving that out.

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?

Again, I don't have the primary source.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Pascal Bourguignon:

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.

Anyone here know more about the original reference?

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).

The specific definition of "higher level language" is the number
of assembly instructions replaced. Eg, spreadsheets are in that
table despite not being a good general purpose programming
language.

I also suspect the numbers were taken from the analysis
of existing programs, and people would have used awk
for cases where it was appropriate.

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).

Hmm... You don't do scientific programming, do you.

Andrew
(e-mail address removed)

 

[Erann Gat]

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 RandomAccessFile extends Object,implements DataOutput {
public void write(byte[] b) throws IOException;
public void write(byte[] b, int off, int len) throws IOException;
...
}

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,

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.

and this is rather like having
the parameter types as part of the method name.

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.

This can lead to subtle bugs. Here is an example in Java:

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.

E.

 

[Mike Rovner]

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

I either case it will be [2, 3, 4, 5, 6]

Instead of lambda use list comprehensions:

print [x+2 for x in range(5)]

Unnamed code blocks considered evil , use named instead (functions).

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,newval): pass
return reader, writer
aprop=property(aprop())


Mike

 

[Dave Benjamin]

This seems like a good juncture to post my list of common myths and
misconceptions about popular programming languages. Contributions are
welcome; flames only if they're funny. Anyone who needs to see on
things to know they're meant in jest should stop reading now.

Haha... that's really funny... except the last one. Not that I'm a
Python purist (a big fan, yes, but not a purist), but I rarely complain
about its slowness. Java is too easy of a target for that one... =)

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?

Dave

 

[Robin Becker]

So, I hope the cultural difference is sharply clear. To us, consensus
is culturally important, we are keen to ensure we all keep using the
same language; *you* would be happier if you could use a language that
is different from those of others, thanks to syntax extensions you
write yourself. Since I consider programming to be mainly a group
activity, and the ability to flow smoothly between several groups to
be quite an important one, I'm hardly likely to appreciate the divergence
in dialects encouraged by such possibilities, am I?

.......
I'm fairly sure I agree with the central point. Average programming
should be understandable by a large population ie concensus.

However, I don't think that the comprehensibility argument is reasonable
against the far corners of a language.

I know that that that that that boy said is OK. There are deep corners
even in English.

Perhaps a truly expressive programming language should be allowed to
express truths about itself.

This statement is false. This language is inconsistent. Let's do Geo.
Bool and have no far corners. No sir!

 

[Edi Weitz]

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?

A good one...

Edi.

 

[prunesquallor]

Marco Antoniotti:

Oh? Where's the "bug-ridden" part?

That assertion also ignores the influence of user studies (yes,
research into how the syntax of a language affects its readabilty
and understandability) on Python's development; a topic which
is for the most part ignored in Lisp.

For some reason people who don't like fully parenthesized polish
notation seem to think that Lisp hackers don't know any better,
haven't seen anything else, and that if we were only shown the light,
we'd switch in an instant.

Allow me to point out that `standard algabraic notation' has been
available in Lisp for 40 years. McCarthy designed M-expressions for
Lisp in 1962 (if not earlier) and the Lisp 1.5 manual is written using
them.

Vaughn Pratt's CGOL (which I mentioned before) was written in 1977.

Dylan adopted an algabraic syntax sometime in the late 80's

In every one of these cases, algabraic syntax never quite caught on.

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.

 

[Pascal Bourguignon]

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.

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

 

[Kenny Tilton]

Sorted by statement per function point:

Statements per
Language Level Function Point
-------- ----- --------------
spreadsheets ~50 6

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