Python syntax in Lisp and Scheme

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
> For all I know, CLisp's macros are SO head and shoulders above any of a
> quarter century ago that any vaguely remembered technical problem from
> back then may be of purely historical interest. I do believe that the
> divergence problem has more to do with human nature and sociology, and
> that putting in a language features that encourage groups and subgroups
> of users to diverge that language cannot be compensated by technical
> enhancements -- it _will_, in my opinion, cause co-workers in any middle-
> or large-sized organization to risk ending up standing on each others'
> feet, rather than on each others' shoulders.[/color]

That's not an opinion, that's a fear.


Pascal

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Matthias wrote:
[color=blue]
> Why the smiley? Many hours of discussions could be spared if there
> were real, scientific, solid studies on the benefit of certain
> language features or languages in certain domains or for certain types
> of programmers.[/color]

This presumes that language features can be judged in isolation. I think
it's rather more likely that good programming languages are holistic
systems, in the sense that the whole language is more than the sum of
its features.


Pascal

[Bengt Richter]

Re: Code block literals

On Wed, 08 Oct 2003 21:29:09 GMT, Dave Benjamin <dave@3dex.co m> wrote:
[color=blue]
>Alex Martelli wrote:[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
>> 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
>[/color]
Why not just a nameless def with otherwise identical syntax?

def(x, y):
print x
print y

You can use parens to enclose the entire expression if context is not otherwise unambiguous.
The indents would be referenced to the def, so any nonblank line starting at or to the left
would start the continuing expression.
[color=blue]
>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=green][color=darkred]
> >>> print mylist.map({ |x| return x + 2 }, range(5))[/color][/color]
>0, 2, 4, 6, 8
>[/color]

Or fairly vanilla:

print map((def(x):ret urn x+2), range(5))

or using indentation instead of closing expression paren to end the suite,

print map(def(x):
return x+2
, range(5))

or if you need space for deeper indentation, put the def on its own line further to the left

print map(
def(x):
return x+2
, range(5))

[color=blue]
>If you wanted to span multiple lines, just take the first indentation
>you find and start from there:
>
>closure = True
>some_screen_ob ject.on_click = { |e|
> print 'got an event: ' + e
> handle_screen_o bject_click()
> if closure = True:
> go_home_happy()
>}
>[/color]
Don't know what the closure bool is about, but, blindly translating,

some_screen_obj ect.on_click = (
def(e):
print 'got an event: ' + e
handle_screen_o bject_click()
if closure: #XXX# = True:
go_home_happy()
)

The closing paren could also go on the end of the previous line,
since it is a closing expression paren around the whole nameless def,
(which means it closes all suites (and optional trailer may follow)).

This way lambda would only be needed for backwards compatibility, and
since "def(" is a syntax error now, IWT it could be introduced cleanly.

Regards,
Bengt Richter

[A.M. Kuchling]

Re: Python syntax in Lisp and Scheme

On Thu, 09 Oct 2003 20:56:01 GMT,
Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
> or not. The similar statement which bristles me the most is at the
> top of biolisp.org, ...[/color]

Yee-*ouch*. For those not reading the site: it modifies an aphorism from
Henry Spencer to "Those who do not know Lisp are condemned to reinvent
it.... poorly," and hyperlinks it to biopython.org. Tacky. Sheesh, the
Perl/Python squabbling has pretty much died down these days; maybe they
missed the memo.

--amk

[Lulu of the Lotus-Eaters]

The compiler canard

|> |Do they ever plan to do a compiler for it [Python]?
|> You mean like Psyco?

Kenny Tilton <ktilton@nyc.rr .com> wrote previously:
|Oh, excellent name. OK, the context was "what are Python's
|aspirations?" Is Python now no longer content to be a (very powerful)
|scripting language? Or is it just tired of being ragged on for being
|slow?

Python never had an "aspiration " of being "just a scripting language",
nor WAS it ever such a thing. From its release, Python was obviously a
language very well suited to large scale application development (as
well as to short one-off scripts).

There -is- sometimes a misguided allegation that Python is slow. It's
not. Certainly Python is faster than most of the languages with
commercial backers who make such claims (e.g. Java, VB). But indeed,
for a class of applications, pure Python is not a good choice--for
long-running, complex, scientific calculation, Fortran or C are much
better (becaue they run many times faster).

There are several approaches, however, to making applications written
mostly in Python faster (in the fairly unusual case that it needs to be
faster). One is to use extension modules--usually coded in C--to handle
the bottlenecks. Y'know, 90% of program time spent in 10% of the code,
or whatever--rewrite that 10% in C. Numerical Python is a widely used
example of this approach.

A second approach is similar: You can use Pyrex to write these
extension modules in a language that is *almost* Python. While Pyrex
syntax is close to Python, under-the-hood, it acts like a code generator
for C... so in the end, you still get an extension module.

A third approach is the simplest of all (for the end programmer, not for
Armin Rigo :-)): Use the Python Specializing Compiler (Psyco). Psyco
is a cool tool to dynamically generator x86 assembly for code paths in
Python bytecodes. Basically, the same thing as a JIT/HotSpot
environment for Java (there are some differences in exactly how it
works, but from 30,000 feet it's the same idea). Of course, no one has
ported Psyco to my Macs yet... but using it on my PCs amounts to adding
less than a half dozen (boilerplate) lines to my existing applications,
and speeds up many applications by 5-10x.

Even with the ease of Psyco, I only bother adding it to maybe 5% of the
apps I write. My 3 year old CPU runs faster than I generally need for
most pure-Python tasks. Sure, maybe I could speed up some command-line
tool that runs in 5 seconds so that they only take 1 second--but it's
quite rare that I care. And all the apps that mostly wait on sockets,
keystrokes, etc. just couldn't go any faster either way, since the
constraint is external.

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...idea s have nothing to lose but their chains. Unite
| against "intellectu al property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Kenny Tilton]

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]

Hey! No pulling rank! :) Actually, I think we heard Mr. Martelli say
something along these lines at one point, tho I grok that he does know
his stuff. As for having "a better understanding", hmmm, check your
lotus, I think you'll find something in there about Beginner's Mind.

Alex reports his experience of The Divergence Problem and blames macros.
Hell, I worked in Tall Buildings for years. I saw Divergence,
Convergence, /and/ the dread Regurgitation Problems everywhere I went.
No macros, tho, just groups of programmers.

So I think the groups are the problem.


--

http://tilton-technology.com

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

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

[Kenny Tilton]

Re: The compiler canard



Lulu of the Lotus-Eaters wrote:
[color=blue]
> |> |Do they ever plan to do a compiler for it [Python]?
> |> You mean like Psyco?
>
> Kenny Tilton <ktilton@nyc.rr .com> wrote previously:
> |Oh, excellent name. OK, the context was "what are Python's
> |aspirations?" Is Python now no longer content to be a (very powerful)
> |scripting language? Or is it just tired of being ragged on for being
> |slow?
>
> Python never had an "aspiration " of being "just a scripting language",
> nor WAS it ever such a thing. From its release, Python was obviously a
> language very well suited to large scale application development[/color]

Oh. Well then you better add macros. <g>

(as[color=blue]
> well as to short one-off scripts).
>
> There -is- sometimes a misguided allegation that Python is slow.[/color]

Welcome to the club. :)

kenny

--

http://tilton-technology.com

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

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

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


"Kenny Tilton" <ktilton@nyc.rr .com> wrote in message
news:Jsmhb.2796 8$pv6.19754@twi ster.nyc.rr.com ...[color=blue]
>[color=green]
> > You mean like Psyco?
> >
> > Been there, done that. (and it's great, and getting better).[/color]
>
> Oh, excellent name.[/color]

PYthon Specializing COmpiler, slightly permuted. Also somehow apt for
something that dynamically compiles bytecode to type-specific machine
code. Many of us did not quite believe it until the pudding was
cooked.
[color=blue]
> OK, the context was "what are Python's aspirations?"
> . Is Python now no longer content to be a (very powerful) scripting
> language?[/color]

Prime focus is still correct and readable code with execution speed
somewhat secondary but not ignored. The interpreter slowly speeds up;
more compiled C extension modules appear; other compilation options
appear; and 3 gig processors run Python about as fast as P125s did
with compiled C.
[color=blue]
> Or is it just tired of being ragged on for being slow?[/color]

I suspect that that pushes a bit too, but I can't speak for anyone in
particular.

Terry J. Reedy

[David Eppstein]

Re: Python syntax in Lisp and Scheme

In article <bm4uf6$6oj$1@n ewsreader2.netc ologne.de>,
Pascal Costanza <costanza@web.d e> wrote:
[color=blue]
> It's probably just because the Common Lisp community is still relatively
> small at the moment. But this situation has already started to improve a
> lot.[/color]

It's only been out, what, twenty years? And another twenty before that
for other lisps... How much time do you think you need?

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



David Eppstein wrote:[color=blue]
> In article <bm4uf6$6oj$1@n ewsreader2.netc ologne.de>,
> Pascal Costanza <costanza@web.d e> wrote:
>
>[color=green]
>>It's probably just because the Common Lisp community is still relatively
>>small at the moment. But this situation has already started to improve a
>>lot.[/color]
>
>
> It's only been out, what, twenty years? And another twenty before that
> for other lisps... How much time do you think you need?
>[/color]

Hey, we've been dead for thirty years, give us a break.

The bad news for other languages is that the evolution of programming
languages, like baseball, is a game played without a clock. And the game
is going our way: languages are evolving towards dynamism, reflection,
and everything else Lisp invented and still does better than anyone.
Python is promoting that sea change, and we Lispniks are forever grateful.

But will one of Perl, Python, Ruby, Dylan or Smalltalk steal the prize?
The only way to do that is to adopt sexprs and macros, and you can't do
those without becoming Lisp, at which point you lose if you do not match
the CL spec.

All your bases are us!


--

http://tilton-technology.com

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

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

[Greg Ewing (using news.cis.dfn.de)]

Re: Python syntax in Lisp and Scheme

Daniel P. M. Silva wrote:[color=blue]
> Nice! I was alluding to MzScheme's class.ss but I guess that's a fun hobby
> to have. :) Do you have your class systems available anywhere to download?
> I would be especially interested in them if they allow multiple
> inheritance, run-time pillaging of class contracts, and explicit "this"
> arguments to methods...[/color]

I might be able to dig up the most recent one, but it was
quite a few years ago.

It didn't have multiple inheritance, though, and very little
in the way of introspection abilities. Basically it just
stuffed the whole class into a big lambda expression. And
"self" wasn't really an argument, as far as I remember --
more like a sort of predefined instance variable that
always pointed to the instance itself.
[color=blue]
> You still can't add new binding constructs or safe parameterizatio ns like a
> with_directory form:
>
> with_directory( "/tmp", do_something())
>
> Where do_something() would be evaluated with the current directory set to "
> tmp" and the old pwd would be restored afterward (even in the event of an
> exception).[/color]

That's true, although you don't really need macros for that,
just something like Smalltalk-style code blocks -- if anyone
can come up with a way of grafting them into the Python
syntax...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Me:[color=blue][color=green]
> > 2 of 6 is better than random, so Jones' work can't be
> > complete bunkum.[/color][/color]

Jon S. Anthony:[color=blue]
> 2 of 6 is worse than flipping a coin.[/color]

Since I said "Of the 6 languages there are two major misorderings"
I suspect this discussion has reached the point of weariness.

Nevertheless, the ordering is 1 3 5 6 2 4

Assume a cost metric based on simple transpositions, where
neighbors can be exchanged. This is the familiar interchange
(or Shell, or bubble, or ..) sort. The degree of disorder is
the number of exchanges needed to sort the list. For the
above it is ||{2-6, 2-5, 2-3, 4-6, 4-5}|| = 5

The average number of exchanges needed to sort a randomly
arranged list with the Shell sort is N*(N-1)/4 == 7.5 for
this list of size 6, so it's already better than average.

From Knuth, Searching and Sorting, 5.1.1, Table 1, the
distribution of the number of permutations with k inversions
of a list of length 6 is
1 way to be ordered
5 to have one transpositions to be ordered
14 to be off by 2 transpositions
29
49
71
90
101
101
90
71
49
29
14
5
1 to be completely reversed

Thus there are 720 possible random orderings of a list of
size 6 and only 169 ways to be off by 5 or fewer transpositions.
meaning that there is only a 24% chance of being this good
randomly.

If I understand 5.1.1(13) well enough, the variance is
sqrt(6*(2*6+5)* (6-1)/72) == 2.66 which means we're
right on the 1 sigma threshold, or about a 75% chance
that his table was not randomly generated.

Again, this suggests Jones' work can't be complete
bunkum.

Andrew
dalke@dalkescie ntific.com
P.S.
That's the first time in 5 years I've had to pull out Knuth. ;)

[Greg Ewing (using news.cis.dfn.de)]

Re: Significant whitespace

Marcin 'Qrczak' Kowalczyk wrote:[color=blue]
> Having failed with significant indents, I tried to use significant line
> breaks in next incarnations of my language, which looked like a good
> compromise. ... I had
> troubles with designing a good syntax for some constructs, mainly
> if-then-else, being constrained to syntaxes which can be nicely split
> into lines.[/color]

While pondering that sort of problem one day I devised a scheme for
handling syntaxes where some line breaks are required and others are
optional.

The idea is that instead of the scanner returning line breaks as
tokens of their own, there is a flag associated with the current
token that indicates whether it is followed by a line break.

When parsing something that doesn't care whether it has line
breaks in it or not, the parser ignores this flag. But when it
gets to a point where a line break could be significant, it takes
notice of it.

For instance, when parsing

a = b +
c

the parser would ignore the line break flag while looking at
the '+' because it knows there must be more of the expression
coming. But when it gets to the 'c', it would check the line
break flag, find it set, and conclude that the expression is
finished.

This ought to allow extra line breaks to be placed wherever
they don't lead to any ambiguity.

I haven't had a chance to try this out, however, so there
may be some problems that I haven't anticipated!

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> Furthermore note that this is not an implementation difference. The ANSI
> standard defines the function COMPILE.[/color]

Is the implementation free to *not* compile the code when the
COMPILE function is called? That is, to leave it as is? How
would a user tell the difference without running a timing test?
[color=blue]
> I simply don't believe that this will work out in the long run. Not in a
> truly general-purpose language.[/color]

Indeed. That viewpoint (agree or disagree) really is one of
underlying cultural differences which have helped .... um....
invigorate this discussion.

Andrew
dalke@dalkescie ntific.com

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme


"Andrew Dalke" <adalke@mindspr ing.com> writes:[color=blue][color=green]
> > It's
> > just a reaction to Python (a perfectly nice little scripting language)
> > trying to morph into a language with the sophistication of Lisp.[/color]
>
> Python isn't doing that. It's lives in a perfectly good niche wherein
> Lisp is not the most appropriate language. At least not until there's a
> macro which works like
>
> (#python '
> for i in range(100):
> print "Spam, ",
> print
> )[/color]

This is trivial:

(DEFUN SPLIT-ARGUMENTS (STRING)
(DO ((CHUNKS '()) (START 0) (POS 0))
((<= (LENGTH STRING) POS)
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(NREVERSE CHUNKS)))
(IF (CHAR= (CHAR STRING POS) (CHARACTER " "))
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(INCF POS) (SETQ START POS))
(INCF POS)))
);;SPLIT-ARGUMENTS


(SET-DISPATCH-MACRO-CHARACTER
(CHARACTER "#") (CHARACTER "!")
(LAMBDA (STREAM CHAR ARG)
(DECLARE (IGNORE CHAR ARG))
;; first read the interpreter path and arguments.
;; next read the script up to a line beginning with "!#".
;; then generate statements to the interpreter and feed it the script.
(DO ((INTERPRETER (SPLIT-ARGUMENTS (READ-LINE STREAM NIL NIL T)))
(SCRIPT '())
(LINE (READ-LINE STREAM NIL NIL T)
(READ-LINE STREAM NIL NIL T)))
((AND (<= 2 (LENGTH LINE)) (STRING= "!#" LINE :END2 2))
`(LET ((INTERP-INPUT (EXT:RUN-PROGRAM ,(CAR INTERPRETER)
:ARGUMENTS ',(CDR INTERPRETER)
:INPUT :STREAM :OUTPUT :TERMINAL)))
;; Sorry, clisp specific. Please replace ext:run-program by
;; your favorite hook.
(DOLIST (LINE ',(NREVERSE SCRIPT))
(FORMAT INTERP-INPUT "~A~%" LINE))
(CLOSE INTERP-INPUT)))
(PUSH LINE SCRIPT))))



[27]> #!/usr/bin/python
for i in range(100):
print "Spam, ",
print ""
!#


T
[28]> Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,


Therefore Python lives in a perfectly good niche wherein Lisp IS the
most appropriate language. QED you can forget Python.



And of course, while trivial when implemented in Lisp, it's so
powerfull it's not limited to python:

[29]> #!/bin/bash
ls -m *.lisp
!#

T
[31]> ai.lisp, antispam-test.lisp, antispam.lisp, ascii.lisp, basic.lisp,
benford.lisp, bits-old.lisp, bits.lisp, bottle.lisp, brent.lisp, c-order.lisp,
clos-test.lisp, clx-sample.lisp, clx-tutorial.lisp, compare-lts.lisp,
copy-over.lisp, dbc.lisp, ddj-combin.lisp, dec.lisp, def-if-undef.lisp,
defstrmacro.lis p, deriv.lisp, diagram.lisp, directory-and-pathname.lisp,
dot.clisprc.lis p, douze.lisp, exemple-cloture.lisp, expert.lisp, fast-io.lisp,
fibonacci.lisp, fixed-point.lisp, four.lisp, html.lisp, ib.lisp, ig.lisp,
inferior-lisp.lisp, integ.lisp, lecture-au-vol.lisp, lisp1-in-cl.lisp,
livre-qui-rend-fou.lisp, lpt-bug.clisprc.lis p, marienbad.lisp, num.lisp,
old-marienbad.lisp, packages.lisp, pg-psql.lisp, pg.lisp, pi.lisp,
picture-test.lisp, posix-dirent.lisp, protocoles.lisp , pttp-1i.lisp,
python.lisp, quine.lisp, scratch.lisp, sdraw.lisp, sum.lisp, symbol.lisp,
test-format.lisp, test-special.lisp, test.lisp, text.lisp, tree.lisp,
turing.lisp, wang.lisp, word-count.lisp



Personnaly, I prefer to write, consistently:

(dotimes (i 100)
(format t "Spam, "))
(format t "~%")


That is, consistently with the rest of my programs.

The question being whether it's better to be needing several different
languages to solve a set of problems because none of them languages is
powerful enough, or if it's better to have one good and powerful
language that helps you solve all your problems?

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

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