Python syntax in Lisp and Scheme

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme


tfb@famine.OCF. Berkeley.EDU (Thomas F. Burdick) writes:[color=blue]
> (defconstant -> '-> "More sugar")
>
> ;; Example usage
> (convert *thing* -> (class-of *other-thing*))
>
> Of course, these are lame examples, but they show that Lisp *can*
> incorporate little ascii-picture-symbols. Good examples would
> necessarily be very domain-dependant.[/color]

Have a look ad DrScheme. There, you can use real images (gif, jgp) as
values. It should not be too difficult to use them as symbol names
too...

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

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

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Daniel P. M. Silva wrote:
...[color=blue][color=green][color=darkred]
>>> with_directory( "/tmp", do_something())[/color][/color][/color]
...[color=blue][color=green]
>> Right: you need to code this very differently, namely:
>> with_directory( "/tmp", do_something)[/color][/color]
...[color=blue][color=green]
>> 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[/color][/color]
...[color=blue]
> That was my point. You have to pass a callable object to with_directory,
> plus you have to save in that object any variables you might want to use,
> when you'd rather say:
>
> x = 7
> with_directory( "/tmp",
> print "well, now I'm in ", os.getpwd()
> print "x: ", x
> x = 3
> )[/color]

I'm definitely NOT sure I'd "rather" use this specific syntax to pass
a block of code to with_directory (even in Ruby, I would delimit the
block of code, e.g. with do/end).

I *AM* sure I would INTENSELY HATE not knowing whether

foo('bar', baz())

is being evaluated by normal strict rules -- calling baz and passing
the result as foo's second argument -- or rather a special form in
which the 'baz()' is "a block of code" which foo may execute zero or
more times in special ways -- depending on how foo happens to be
bound at this time. *SHUDDER*. Been there, done that, will NEVER
again use a language with such ambiguities if I can possibly help it.

[color=blue][color=green]
>> the details. Consensus is culturally important, even though in the end
>> Guido decides: we are keen to ensure we all keep using the same language,
>> rather than ever fragmenting it into incompatible dialects.[/color]
>
> The point is that the language spec itself is changed (along with the
> interpreter in C!) to add that statement. I would be happier if I could
> write syntax extensions myself, in Python, and if those extensions worked
> on CPython, Jython, Python.Net, Spy, etc.[/color]

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?

[color=blue]
> I think changing the meaning of __new__ is a pretty big language
> modification...[/color]

Surely you're jesting? Defining a class's __new__ and __init__
just means defining the class's *constructor*, to use the term
popular in C++ or Java; as I can change any other method, so I
can change the constructor, of course (classes being mutable
objects -- by design, please note, not by happenstance). "Pretty
big language modification" MY FOOT, with all due respect...


Alex

[Thomas F. Burdick]

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 noone was able to let CLOS have
> (virtual) inner classes,[/color]

This is kind of like saying we weren't able to have setjmp/longjmp;
yeah, but doing so makes no sense.
[color=blue]
> methods inside methods,[/color]

There was a proposal to add lexically-scoped methods, but it got
tossed because no one liked it.
[color=blue]
> virtual methods (yeah I know about those stupid generic functions :),[/color]

As has been already stated, we only have "virtual methods".
[color=blue]
> method overloading,[/color]

How could you have both noncongruent argument lists, and multiple
dispatch? With an either/or like that, Lisp chose the right one.
[color=blue]
> A decent API (I tried playing with it.. it doesn't even have a freaking
> date library as standard ;-p[/color]

Who does? Have all that stuff standard, I mean. Python doesn't even
have a standard. We have some date support in ANSI -- get the rest from your
vendor (commercial or free).
[color=blue]
> yes this mail is provocative..[/color]

Seems more ignorant, to me. I guess when you're conversing on an
archived forum, that can seem like the same thing, though.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Thomas F. Burdick]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> Pascal Bourguignon <spam@thalassa. informatimago.c om> writes:
>[color=green]
> > The voyels are composed with consones[/color]
>
> And the blanket claim that Japanese spelling in kana is badly
> designed compared to say, English orthography seems really rather
> dubious to me.[/color]

And you can tell by his phrasing that he was straining against writing
that in English ;-)

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Joe Marshall]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Yeah, right. Kindly explain that 'with-condition-maintained'
> example and the exhalted claims made and implied for it, then.[/color]

I posted some lisp macros used in a production environment.
(the msgid <llrx7ob8.fsf@c omcast.net> )

The `with-condition-maintained' was a hypothetical, but the ones I
posted are in actual use. The claim is that these macros
significantly *reduce* the intellectual burden of the people that
write and maintain the code that uses them.

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Wed, 8 Oct 2003, Alex Martelli wrote:[color=blue]
> Daniel P. M. Silva wrote:[color=green][color=darkred]
> >>> with_directory( "/tmp", do_something())[/color][/color]
> ...[color=green][color=darkred]
> >> Right: you need to code this very differently, namely:
> >> with_directory( "/tmp", do_something)[/color][/color]
> ...[color=green][color=darkred]
> >> 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[/color][/color]
> ...[color=green]
> > That was my point. You have to pass a callable object to with_directory,
> > plus you have to save in that object any variables you might want to use,
> > when you'd rather say:
> >
> > x = 7
> > with_directory( "/tmp",
> > print "well, now I'm in ", os.getpwd()
> > print "x: ", x
> > x = 3
> > )[/color]
>
> I'm definitely NOT sure I'd "rather" use this specific syntax to pass
> a block of code to with_directory (even in Ruby, I would delimit the
> block of code, e.g. with do/end).
>
> I *AM* sure I would INTENSELY HATE not knowing whether
>
> foo('bar', baz())
>
> is being evaluated by normal strict rules -- calling baz and passing
> the result as foo's second argument -- or rather a special form in
> which the 'baz()' is "a block of code" which foo may execute zero or
> more times in special ways -- depending on how foo happens to be
> bound at this time. *SHUDDER*. Been there, done that, will NEVER
> again use a language with such ambiguities if I can possibly help it.[/color]

My mistake in choosing stx_id(stmt). Maybe foo{'bar', baz()} would be
better, or
foo bar:
baz()
[color=blue][color=green][color=darkred]
> >> the details. Consensus is culturally important, even though in the end
> >> Guido decides: we are keen to ensure we all keep using the same language,
> >> rather than ever fragmenting it into incompatible dialects.[/color]
> >
> > The point is that the language spec itself is changed (along with the
> > interpreter in C!) to add that statement. I would be happier if I could
> > write syntax extensions myself, in Python, and if those extensions worked
> > on CPython, Jython, Python.Net, Spy, etc.[/color]
>
> 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?[/color]

Yes, we disagree about how we use a language. It's too bad the choice
isn't left to the programmer, though.
[color=blue][color=green]
> > I think changing the meaning of __new__ is a pretty big language
> > modification...[/color]
>
> Surely you're jesting? Defining a class's __new__ and __init__
> just means defining the class's *constructor*, to use the term
> popular in C++ or Java; as I can change any other method, so I
> can change the constructor, of course (classes being mutable
> objects -- by design, please note, not by happenstance). "Pretty
> big language modification" MY FOOT, with all due respect...[/color]

__init__ is the constructor, but isn't __new__ the allocator or factory?

A mutable __new__ means you are not guaranteed that Cls() gives you a Cls
object.

- Daniel

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

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

If this is indeed the crux, then any justification which says "my brain"
and "I" is suspect, because that explicitly ignores the argument. 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

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

Alex:[color=blue][color=green]
> >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=blue]
> 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. ;)

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

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

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Marco Antoniotti:[color=blue]
> Come on. Haskell has a nice type system. Python is an application of
> Greespun's Tenth Rule of programming.[/color]

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 understandabili ty) on Python's development; a topic which
is for the most part ignored in Lisp.

Andrew
dalke@dalkescie ntific.com

[Frode Vatvedt Fjeld]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> 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]

This is true for all abstractions: Syntactic, linguistic, or
functional. Good abstractions are good, bad abstractions are bad,
regardless.

--
Frode Vatvedt Fjeld

[Rainer Joswig]

Re: Python syntax in Lisp and Scheme

In article <6CZgb.3273$dn6 .860@newsread4. news.pas.earthl ink.net>,
"Andrew Dalke" <adalke@mindspr ing.com> wrote:

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


snip

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <xcvfzi3r2ge.fs f@famine.OCF.Be rkeley.EDU>,
tfb@famine.OCF. Berkeley.EDU (Thomas F. Burdick) wrote:
[color=blue][color=green]
> > method overloading,[/color]
>
> How could you have both noncongruent argument lists, and multiple
> dispatch?[/color]

C++ seems to manage it somehow.

#include <stdio.h>

void foo(int x, int y) { printf("1\n"); }
void foo(double x, int y) { printf("2\n"); }
void foo(char* x) { printf("3\n"); }

main() {
foo(1,2);
foo(1.2,2);
foo("foo");
}

compiles and runs without complaint.

E.

[David Mertz]

Re: Python syntax in Lisp and Scheme

Marco Antoniotti <marcoxa@cs.nyu .edu> wrote previously:
|As for your comments on methods and generic functions it is obvious
|that you do not know what multiple dispatching is (yes, there is an ugly
|hacked up Python library to do that floating around; I do not know if it
|will make it it 3.0), so you comment looses value immediately.

This is absolutely replete with ignorance. The multimethods module I
present at:

http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html

Is neither ugly nor hacked, and is just as general as what you would do
in Lisp (but with nicer looking syntax). Neel Krishnaswami, and
probably other folks, have written similar modules before I did; I don't
claim to be all that original--it's not that difficult to do, after all.

You can grab it directly, btw, at:

http://www.gnosis.cx/download/gnosis/magic/multimethods.py

Now OF COURSE, multimethods.py will not "make it into 3.0"--it's not in
2.3 or any other version either. It's a 3rd party library... and it
will continue to work just fine whenever 3.0 comes out. Most likely
with no changes, but I'll update it if needed (unless I get hit by a
bus, I suppose, but someone else could easily do the same).

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

[Erik Max Francis]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck wrote:
[color=blue]
> Huh? You seem to be confused (BTW French is misleading here: it's
> vowels and
> consonants in English). *Kanji* are not phonetic, you seem to be
> talking about
> *kana*. And the blanket claim that Japanese spelling in kana is badly
> designed
> compared to say, English orthography seems really rather dubious to
> me.[/color]

Yes, indeed. Kana is a far more efficient alphabet -- in terms of
graphemes mapping to the same sounds consistently -- than English. Of
course, its orthography fits the Japanese language, not English, so kana
is not nearly as effective for writing English words (of course, the
Japanese happily do it).

But if someone is writing Japanese in kana (rather than kanji), it is
far easier to accurately read back what is written based only on the
kana. The exceptions are some transformations done for brevity, usually
at the end of a sentence (desu ~= "dess"; "shita" ~= "shta"), and the
grammatical particles which for historical reasons are written different
than they're pronounced.

I saw a figure quoted for the efficiency (in that grapheme-phoneme
consistency mapping I mentioned earlier) of kana that put it well above
95%. I can't fathom how low English's efficiency would be.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ That's what I'm about / Holding out / Holding out for my baby
\__/ Sandra St. Victor

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> Pascal Bourguignon <spam@thalassa. informatimago.c om> writes:
>[color=green]
> > Well, I would say that kanji is badly designed, compared to latin
> > alphabet. The voyels are composed with consones (with diacritical
> > marks) and consones are written following four or five groups with
> > additional diacritical marks to distinguish within the groups. It's
> > more a phonetic code than a true alphabet.[/color]
>
> Huh? You seem to be confused (BTW French is misleading here: it's vowels and
> consonants in English). *Kanji* are not phonetic, you seem to be talking about
> *kana*.[/color]

Yes, I was. Thank you.

[color=blue]
> And the blanket claim that Japanese spelling in kana is badly designed
> compared to say, English orthography seems really rather dubious to me.
>
> 'as[/color]

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.

But it does not matter since the topic was kanji...


--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

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

[Alexander Schmolck]

Re: Significant whitespace

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
[color=blue]
> Moral: Haskell and Python happen to succeed with significant indents
> but their rules are hard to adapt to other languages. Significant
> indentation constrains the syntax - if you like these constraints, fine,
> but it would hurt if a language were incompatible with these constraints.[/color]

I'm not surprised -- as I said it is not straighforward to map the significant
indentation scheme to a language that doesn't have python(C/Pascal)'s
statement/expression distinction. My main point is that it is an excellent
choice for a language such as python (and far superior to the alternatives a
la Pascal/C).

I'm not whitespace bigot: although I abhor C/Pascal I like the syntaxes of
smalltalk, prolog and lisp (maybe I could even partially warm to something in
the APL familiy) :)

'as