Python syntax in Lisp and Scheme

[mike420]

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

[Paul Rubin]

mi*****@ziplip.com writes:

If the answer is yes, would many Python programmers switch to Lisp
or Scheme if they were offered identation-based syntax?

I don't think the syntax is that big a deal. But programming in lisp
or scheme has a creaky feeling these days, because the traditional
runtime libraries in those languages have fallen so far behind the
times.

[Dominic]

mi*****@ziplip.com wrote:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

Well, there's always a programming language which has
more features than another. However documentation,
libraries, software-engineering tools and developer
community have also to be accounted for.

So whenever a special features is deemed necessary
but not available in the language I suggest to use
code generators.

E.g. you cannot express grammars in C/Java for
parsing so usually you stick to yacc/bison/flex/cups etc.

In C++ BOOST provides capabilites to express a parser
by means of template metaprogramming but compile times
are huge. In my opinion are old fashioned parser
generators more transparent.
So it's probably not worth the trouble.

I have successfuly implemented a simple code generator
for real-time control applications in Python
which outputs C-source.
http://www-user.rhrk.uni-kl.de/~hillbr/public/

Today I'd suggest to use XML-files to describe
the problem and generate source code from it.
Source code needed for assembling the final
result could also be embedded into the XML-files.

Eclipse uses a kind of JSP to generate code
from templates. (Examples exist
for generating source code for enumerations
which are not yet supported by Java)
However it's still very primitive.
At the rapid pace at which Eclipse
is developed I am curious what way it is going to take.
Ciao,
Dominic

[prunesquallor]

mi*****@ziplip.com writes:

I think everyone who used Python will agree that its syntax is
the best thing going for it.
I've used Python. I don't agree.
It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

Yes, you would be able to add macros to Python. No, it isn't anywhere
as easy as it is with Lisp.

I imagine you could come up with a readtable hack for reading
pythonesque syntax in lisp. *shudder*

[Oren Tirosh]

On Thu, Oct 02, 2003 at 10:23:16PM -0700, mi*****@ziplip.com wrote:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

Search the comp.lang.python archives for the word "macros" and you will
find lots and lots of threads discussing this issue over the years. The
concensus seems to be that macros are neither compatible with the Python
Way nor necessary for the vast majority of everyday programming tasks.

Implementing Python-like syntax in LISP or even a full Python
implementation in LISP would be a worthwhile goal (LPython?). BTW, this
kind of implementation is one of the relatively few programming tasks
that can benefit greatly from macros. The Python semantics can be mostly
done using macros and a preprocessor would translated Python syntax to
s-expression code that uses those macros.

Oren

[Tomasz Zielonka]

mi*****@ziplip.com napisa³:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately.

Well, there is Haskell which also offers indentation-base syntax and one
of it's compilers (GHC) recently added the Template Haskell extension.

This is a statically typed, non-strict purely functional language with
higher order and polymorphic functions, algebraic datatypes, etc. so
it's a BIT different than Python, but it's worth trying :)

PS. Haskell also allows to use {, } and ; instead of indentation. I
wonder why Python doesn't.

Best regards,
Tom

--
..signature: Too many levels of symbolic links

[Tomasz Zielonka]

mi*****@ziplip.com napisa³:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately.

Well, there is Haskell which also offers indentation-based syntax and one
of its compilers (GHC) recently added the Template Haskell extension.

This is a statically typed, non-strict, purely functional language with
higher order and polymorphic functions, algebraic datatypes,
type-classes base overloading, etc. so it's a BIT different than Python,
but it's worth trying IMO.
:)

PS. Haskell also allows to use {, } and ; instead of indentation. I
wonder why Python doesn't.

Best regards,
Tom

--
..signature: Too many levels of symbolic links

[Tomasz Zielonka]

mi*****@ziplip.com napisa³:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately.

Well, there is Haskell which also offers indentation-based syntax and
one
of its compilers (GHC) recently added the Template Haskell extension.

This is a statically typed, non-strict, purely functional language with
higher order and polymorphic functions, algebraic datatypes,
type-class based overloading, etc. so it's a BIT different than Python,
but it's worth trying IMO :)

PS. Haskell also allows to use {, } and ; instead of indentation. I
wonder why Python doesn't.

Best regards,
Tom

--
..signature: Too many levels of symbolic links

[Jeremy Yallop]

Tomasz Zielonka wrote:

mi*****@ziplip.com napisa³:

I think everyone who used Python will agree that its syntax is
the best thing going for it.

I've used Python rather a lot, and I don't agree with this, FWIW.
PS. Haskell also allows to use {, } and ; instead of indentation. I
wonder why Python doesn't.

http://groups.google.com/groups?as_u....eeel.nist.gov

Jeremy.

[Tomasz Zielonka]

Jeremy Yallop wrote:

PS. Haskell also allows to use {, } and ; instead of indentation. I
wonder why Python doesn't.
http://groups.google.com/groups?as_u....eeel.nist.gov

A state of the art sophisticated parser? :)))

You almost got me. I don't know very much about Python and I had to
check that # is a beginning of a comment.

Do you know the meaning of 'instead of' ?

You still have to use indentation, right? You can't write:

if 1: #{ print 2 #} else: #{ print 3 #}

instead of

if 1: #{
print 2
#}
else: #{
print 3
#}

because that would be read as

if 1:
Jeremy.

Best regards,
Tom

--
..signature: Too many levels of symbolic links

[Mark Brady]

This whole thread is a bad idea. If you like python then use python.
Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps and there seems to be a rebirth in the Scheme
and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp. A
lot of new Scheme and Common Lisp developers I talk to followed the
same route. Python is a great language and I still use it for some
things.

Paul Rubin's comments are just pure fud.

Some great scheme implementations with large modern libraries (not yet
a match for python but growing fast):
http://www.plt-scheme.org/
http://www-sop.inria.fr/mimosa/fp/Bigloo/
http://www.wikipedia.org/wiki/Gauche
http://sisc.sourceforge.net/
http://www.scheme.com/

Common Lisp has a fantastic wiki site (links to implementations and
loads of libraries) with everything you need to get started at:
http://www.cliki.net/index

Also see:
http://www.lisp.org/alu/home
http://common-lisp.net
http://www.cliki.net/YoungLispers

Many of the latest Scheme and Lisp mailing lists can be browsed from:
http://news.gmane.org/index.php?match=gmane.lisp

Develop in the language that suits you but despite the fud you do have
a choice,
Python, Scheme and Common Lisp are all fine languages with good
libraries and FFI capabilities.

Regards,
Mark.

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

mi*****@ziplip.com writes:

If the answer is yes, would many Python programmers switch to Lisp
or Scheme if they were offered identation-based syntax?

I don't think the syntax is that big a deal. But programming in lisp
or scheme has a creaky feeling these days, because the traditional
runtime libraries in those languages have fallen so far behind the
times.

[Matthias]

ka****@lycos.com (Mark Brady) writes:

Paul Rubin's comments are just pure fud. [...] Develop in the language that suits you but despite the fud you do have
a choice,
Python, Scheme and Common Lisp are all fine languages with good
libraries and FFI capabilities.

I think that's incorrect: The Common Lisp language has no FFI (foreign
function call) capabilities. Each CL _implementation_ has one (which
is usually compatible to itself). This is exactly the reason why
there are way more libraries out there for Python, Perl, maybe Ruby
than for any single CL implementation. The same probably holds for
Scheme.

[Toni Nikkanen]

ka****@lycos.com (Mark Brady) writes:

just me, I prefer S-exps and there seems to be a rebirth in the Scheme
and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp.

It's be interesting to know where people got the idea of learning
Scheme/LISP from (apart from compulsory university courses)? I think
that for me, it was the LPC language used in LPmuds. It had a
frightening feature called lambda closures, and useful functions such
as map and filter. Then one day I just decided to bite the bullet and
find out where the heck all that stuff came from (my background was
strongly in C-like languages at that point. LPC is like C with some
object-oriented and some FP features.)

Yes, I know, there's nothing frightening in lambda closures. But the
way they were implemented in LPC (actually just the syntax) was
terrible :)

[Alex Martelli]

mi*****@ziplip.com wrote:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
You can surely hack a "pre-processor" on top of the Python
interpreter. With the Python 2.3 architecture of import
hooks, it might even be quite feasible to experiment with
this idea as a pure Python package and distribute it as such:
just add a hook that scans incoming source files (modules)
for definitions and/or occurrences of the 'macros' you want,
and (respectively) squirrels away the definitions, and/or
expands the macros. As for designing the syntax for macro
definitions and expansions while remaining 'amazing', I'll
pass -- but surely it's not beyond human possibilities;-).

Anyway, see later in this post for a toy-level example.

add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

If you could make all of the existing Python extensions,
libraries, frameworks, etc, instantly available from Lisp or
Scheme, you'd gain a LOT of kudos in the Lisp or Scheme
community, I suspect. That most existing Python coders
would be happy to leave the semantic simplicity of their
chosen language for the richness of Common Lisp, I very,
very strongly doubt, but in any case until the whole array
of existing extensions &c is available it's not an issue;-).
So, anyway, here's the promised toy-level example of using
custom importers with the new Python 2.3 mechanics to get
macros. I'm cutting corners to the bone (just to mix a
couple metaphors...) by using the C preprocessor (!) as my
"macro expander", ignoring packages, _and_ only looking for
"C-macro" definitions AND expansions in files with extension
".pyp" (all others, I'll leave alone...). Oh, also, I do
not worry about saving bytecode for such files -- I'm gonna
preprocess and recompile them on every run of the program
(far too much trouble, when macros exist, to determine
whether a bytecode file is up to date -- one should check
it, not only with respect to the date of ONE source file,
but rather of a hard-to-pin-down collection of macro and
include files... so, in the spirit of cutting corners and
keeping this a VERY toy-level example, I'm punting:-). So,
here's the gist...:
import sys
import os
import imp

prepro = 'cat %s | gcc -E -'

class MacroImporter(object):

def __init__(self, path):
self.path = path

def find_module(self, modname):
look_for_file = os.path.join(self.path, modname+'.pyp')
self.code = os.popen(prepro % look_for_file).read()
if self.code: return self
else: return None

def load_module(self, modname):
mod = imp.new_module(modname)
sys.modules[modname] = mod
mod.__file__ = "<Macro-Expanded %s>" % modname
exec self.code in mod.__dict__
return mod

sys.path_hooks.append(MacroImporter)

example = open('pippo.pyp', 'w')
example.write('''
#define unless(cond) if not(cond)
def pippo(x):
print 'x is', x
unless(x>=2): print ' x is smaller than two'
unless(x<=4): print ' x is bigger than four'
''')
example.close()

import pippo
pippo.pippo(1)
pippo.pippo(7)
Removing the various oversimplifications, and, in particular, designing
a better macro scheme than gcc -E supplies, is left as a trivial exercise
for the reader (I have in fact devised a perfect scheme, of course, but,
unfortunately, the margins of this post are too narrow for me to write it
down...).
Alex

[Paul Foley]

On 03 Oct 2003 14:44:36 +0300, Toni Nikkanen wrote:

ka****@lycos.com (Mark Brady) writes:

just me, I prefer S-exps and there seems to be a rebirth in the Scheme
and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp.

It's be interesting to know where people got the idea of learning
Scheme/LISP from (apart from compulsory university courses)?

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

--
Cogito ergo I'm right and you're wrong. -- Blair Houghton

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

[Kenny Tilton]

Toni Nikkanen wrote:

ka****@lycos.com (Mark Brady) writes:

just me, I prefer S-exps and there seems to be a rebirth in the Scheme
and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp.

It's be interesting to know where people got the idea of learning
Scheme/LISP from (apart from compulsory university courses)?

<g> We wonder alike. That's why I started:

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

That recently got repotted from another cliki and it's a little mangled,
but until after ILC2003 I am a little too swamped to clean it up. But
there is still a lot of good stuff in there. On this page I grouped
folks according to different routes to Lisp (in the broadest sense of
that term): http://alu.cliki.net/The%20RtLS%20by%20Road

You will find some old-timers because I made the survey super-inclusive,
but my real interest was the same as yours: where are the New Lispniks
coming from?

Speaking of which, Mark Brady cited Python as a stepping-stone, and I
have been thinking that might happen, but the survey has yet to confirm.
Here's one: http://alu.cliki.net/Robbie%20Sedgewick's%20Road%20to%20Lisp

So Ping! Mark Brady, please hie ye (and all the others who followed the
same road to Lisp) to the survey and correct the record.

I think that for me, it was the LPC language used in LPmuds. It had a
frightening feature called lambda closures, and useful functions such
as map and filter. Then one day I just decided to bite the bullet and
find out where the heck all that stuff came from (my background was
strongly in C-like languages at that point. LPC is like C with some
object-oriented and some FP features.)

Yes, I know, there's nothing frightening in lambda closures. But the
way they were implemented in LPC (actually just the syntax) was
terrible :)

You could cut and paste that into the survey as well. :)

kenny

[Terry Reedy]

"Mark Brady" <ka****@lycos.com> wrote in message
news:e8**************************@posting.google.c om...

This whole thread is a bad idea.
I could agree that the OP's suggestion is a bad idea but do you
actually think that discussion and more publicity here for Lisp/Scheme
is bad? You make a pretty good pitch below for more Python=>Lisp
converts.
If you like python then use python.
As I plan to do.
Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps and there seems to be a rebirth in the cheme and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp. A
lot of new Scheme and Common Lisp developers I talk to followed the
same route. Python is a great language and I still use it for some
things.

Other Lispers posting here have gone to pains to state that Scheme is
not a dialect of Lisp but a separate Lisp-like language. Could you
give a short listing of the current main differences (S vs. CL)? If I
were to decide to expand my knowledge be exploring the current
versions of one(I've read the original SICP and LISP books), on what
basis might I make a choice?

Terry J. Reedy

[Toni Nikkanen]

Kenny Tilton <kt*****@nyc.rr.com> writes:

Speaking of which, Mark Brady cited Python as a stepping-stone, and I
have been thinking that might happen, but the survey has yet to
confirm.

It usually happens that when I google for some scheme/lisp-isms,
I get lots of Python mailing list messages as results. There's
something going on with that.

[Kenny Tilton]

Kenny Tilton wrote:

Toni Nikkanen wrote:

It's be interesting to know where people got the idea of learning
Scheme/LISP from (apart from compulsory university courses)?

<g> We wonder alike. That's why I started:

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

That recently got repotted from another cliki and it's a little mangled,
but until after ILC2003 I am a little too swamped to clean it up.

Me and my big mouth. Now that I have adevrtised the survey far and wide,
and revisited it and seen up close the storm damage, sh*t, there goes
the morning. :) Well, I needed a break from RoboCells:

http://sourceforge.net/projects/robocells/

I am going to do what I can to fix up at least the road categorization,
and a quick glance revealed some great new entries, two that belong in
my Top Ten (with apologies to those getting bumped).

kenny

[Lothar Scholz]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

mi*****@ziplip.com writes:

If the answer is yes, would many Python programmers switch to Lisp
or Scheme if they were offered identation-based syntax?

I don't think the syntax is that big a deal. But programming in lisp
or scheme has a creaky feeling these days, because the traditional
runtime libraries in those languages have fallen so far behind the
times.

Funny. Yesterday i downloaded the trial version of Franz Lisp (Allegro
CL).
I can'T say if the runtime libraries are out of date because there is
absolute no documentation for the runtime libraries - of course they
also bundle the ANSI-Common Lisp book.

I found that they still want to sell every fucking line of code in an
extra library raising the price to an unexceptable high value.

[Jeremy H. Brown]

"Terry Reedy" <tj*****@udel.edu> writes:

Other Lispers posting here have gone to pains to state that Scheme is
not a dialect of Lisp but a separate Lisp-like language. Could you
give a short listing of the current main differences (S vs. CL)?
According to the "Revised(5) Report on the Algorithmic Language
Scheme", "Scheme is a statically scoped and properly tail-recursive
dialect of the Lisp programming language..." It's certainly not a
dialect of Common Lisp, although it is one of CL's ancestors.

I'm sure if you do some web-groveling, you can find some substantial
comparisons of the two; I personally think they have more in common
than not. Here are a few of the (arguably) notable differences:

Scheme Common Lisp
Philosophy minimalism comprehensiveness
Namespaces one two (functions, variables)
Continuations yes no
Object system no yes
Exceptions no yes
Macro system syntax-rules defmacro
Implementations >10 ~4
Performance "worse" "better"
Standards IEEE ANSI
Reference name R5RS CLTL2
Reference length 50pp 1029pp
Standard libraries "few" "more"
Support Community Academic Applications writers

The Scheme community has the SRFI process for developing additional
almost-standards. I don't know if the CL community has something
equivalent; I don't think they did a year ago.
If I were to decide to expand my knowledge be exploring the current
versions of one(I've read the original SICP and LISP books), on what
basis might I make a choice?

Try them both, see which one works for you in what you're doing.

Jeremy

[Paul Rubin]

Oren Tirosh <or*******@hishome.net> writes:

Implementing Python-like syntax in LISP or even a full Python
implementation in LISP would be a worthwhile goal (LPython?). BTW, this
kind of implementation is one of the relatively few programming tasks
that can benefit greatly from macros. The Python semantics can be mostly
done using macros and a preprocessor would translated Python syntax to
s-expression code that uses those macros.

If done straightforwardly, the language semantics would end up
different from Python's in a few ways. For example, strings in most
Lisp systems are mutable. Also, Python's class system doesn't map
onto Lisp all that well; Python's variable-scoping rules are bizarre,
and so forth. I think the result would still be worth doing but
it would be a further departure from CPython than, say, Jython is.

[Duane Rettig]

jh*****@ai.mit.edu (Jeremy H. Brown) writes:

"Terry Reedy" <tj*****@udel.edu> writes:

Other Lispers posting here have gone to pains to state that Scheme is
not a dialect of Lisp but a separate Lisp-like language. Could you
give a short listing of the current main differences (S vs. CL)?

I'm sure if you do some web-groveling, you can find some substantial
comparisons of the two; I personally think they have more in common
than not. Here are a few of the (arguably) notable differences:
This is actually a pretty good list. I'm not commenting on
completeness, but I do have a couple of corrections:
Scheme Common Lisp
Philosophy minimalism comprehensiveness
Namespaces one two (functions, variables)
Continuations yes no
Object system no yes
Exceptions no yes
Macro system syntax-rules defmacro
Implementations >10 ~4 ===========================================^

See http://alu.cliki.net/Implementation - it lists 9 commercial
implementations, and 7 opensource implementations. There are
probably more.
Performance "worse" "better"
Standards IEEE ANSI
Reference name R5RS CLTL2 ============================================^

No, CLtL2 is definitely _not_ a reference for ANSI Common Lisp.
It was a snapshot taken in the middle of the ANSI process, and
is out of date in several areas. References which are much closer
to the ANSI spec can be found online at

http://www.franz.com/support/documen...icl/ansicl.htm

or

http://www.lispworks.com/reference/H...ront/index.htm
Reference length 50pp 1029pp
Standard libraries "few" "more"
Support Community Academic Applications writers

The Scheme community has the SRFI process for developing additional
almost-standards. I don't know if the CL community has something
equivalent; I don't think they did a year ago.

There are many grassroots defacto standards efforts to extend CL in
several areas. Some of these are listed here:

http://alu.cliki.net/Standard
If I were to decide to expand my knowledge be exploring the current
versions of one(I've read the original SICP and LISP books), on what
basis might I make a choice?

Try them both, see which one works for you in what you're doing.

Agreed, but of course, I'd recommend CL :-)

--
Duane Rettig du***@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: [phone]; Fax: [phone]

[Rayiner Hashem]

> Object system no yes
To be fair, most Scheme implementations come with one, and you can always
download an external one if you want.

Macro system syntax-rules defmacro Again, depends on the implementation. Gambit offers CL-style macros too.
Performance "worse" "better"

Depends on the implementation. Bigloo did a bit better on the Great Computer
Language Shootout than did CMUCL, though, there were complaints that the
CL-code was sub-par. In the few small benchmarks I've tried on my machine,
Bigloo is pretty competitive with CMUCL.

[Jeremy H. Brown]

Duane Rettig <du***@franz.com> writes:

jh*****@ai.mit.edu (Jeremy H. Brown) writes:
This is actually a pretty good list. I'm not commenting on
completeness, but I do have a couple of corrections:

....

Implementations >10 ~4

===========================================^

See http://alu.cliki.net/Implementation - it lists 9 commercial
implementations, and 7 opensource implementations. There are
probably more.

Thanks. I hadn't realized the spread was that large.

Performance "worse" "better"
Standards IEEE ANSI
Reference name R5RS CLTL2

============================================^

No, CLtL2 is definitely _not_ a reference for ANSI Common Lisp.
It was a snapshot taken in the middle of the ANSI process, and
is out of date in several areas. References which are much closer
to the ANSI spec can be found online at

http://www.franz.com/support/documen...icl/ansicl.htm

or

http://www.lispworks.com/reference/H...ront/index.htm

Thanks again.

Try them both, see which one works for you in what you're doing.

Agreed, but of course, I'd recommend CL :-)

I've arrived at the conclusion that it depends both on your task/goal
and your personal inclinations.

Jeremy

[Marco Antoniotti]

mi*****@ziplip.com wrote:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

Why do I feel like crying? :{

Cheers
--
Marco

[Alexander Schmolck]

pr***********@comcast.net writes:

mi*****@ziplip.com writes:

I think everyone who used Python will agree that its syntax is
the best thing going for it.

I've used Python. I don't agree.

I'd be interested to hear your reasons. *If* you take the sharp distinction
that python draws between statements and expressions as a given, then python's
syntax, in particular the choice to use indentation for block structure, seems
to me to be the best choice among what's currently on offer (i.e. I'd claim
that python's syntax is objectively much better than that of the C and Pascal
descendants -- comparisons with smalltalk, prolog or lisp OTOH are an entirely
different matter).

'as

[Kenny Tilton]

Kenny Tilton wrote:

Kenny Tilton wrote:

Toni Nikkanen wrote:

It's be interesting to know where people got the idea of learning
Scheme/LISP from (apart from compulsory university courses)?

<g> We wonder alike. That's why I started:

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

That recently got repotted from another cliki and it's a little
mangled, but until after ILC2003 I am a little too swamped to clean it
up.

Me and my big mouth. Now that I have adevrtised the survey far and wide,
and revisited it and seen up close the storm damage, sh*t, there goes
the morning. :)

OK, I copied over all the twenty-plus pages that got lost in the
repotting, fixed the survey questions, and even took the time to
annotate my Top Ten list:

http://alu.cliki.net/Kenny's%20RtLS%20Top-Ten

Check it out. The Switch Date pages have been restored, but I do not
think the cross-indexing works until pages get edited and resaved. That
is not the most fascinating breakdown in the world, so it may be a while
before I fuss with that. But this breakdown is cool:

http://alu.cliki.net/The%20RtLS%20by%20Road

More responses always welcome.

kenny

[Terry Reedy]

"Jeremy H. Brown" <jh*****@ai.mit.edu> wrote in message
news:uv*************@tenebrae.ai.mit.edu...

"Terry Reedy" <tj*****@udel.edu> writes: .....

give a short listing of the current main differences (S vs. CL)?

.... than not. Here are a few of the (arguably) notable differences: ....
Thank you. This is just the sort of preview I wanted.
Try them both, see which one works for you in what you're doing.

My present interest is intellectual broadening. I think I should
start with parts of the current version of SICP and then read a modern
CL chapter on macros.

Terry J. Reedy

[Joe Marshall]

Alexander Schmolck <a.********@gmx.net> writes:

pr***********@comcast.net writes:

mi*****@ziplip.com writes:

> I think everyone who used Python will agree that its syntax is
> the best thing going for it.

I've used Python. I don't agree.

I'd be interested to hear your reasons. *If* you take the sharp distinction
that python draws between statements and expressions as a given, then python's
syntax, in particular the choice to use indentation for block structure, seems
to me to be the best choice among what's currently on offer (i.e. I'd claim
that python's syntax is objectively much better than that of the C and Pascal
descendants -- comparisons with smalltalk, prolog or lisp OTOH are an entirely
different matter).

(I'm ignoring the followup-to because I don't read comp.lang.python)

Indentation-based grouping introduces a context-sensitive element into
the grammar at a very fundamental level. Although conceptually a
block is indented relative to the containing block, the reality of the
situation is that the lines in the file are indented relative to the
left margin. So every line in a block doesn't encode just its depth
relative to the immediately surrounding context, but its absolute
depth relative to the global context. Additionally, each line encodes
this information independently of the other lines that logically
belong with it, and we all know that when some data is encoded in one
place may be wrong, but it is never inconsistent.

There is yet one more problem. The various levels of indentation
encode different things: the first level might indicate that it is
part of a function definition, the second that it is part of a FOR
loop, etc. So on any line, the leading whitespace may indicate all
sorts of context-relevant information. Yet the visual representation
is not only identical between all of these, it cannot even be
displayed.

Is this worse than C, Pascal, etc.? I don't know.
Worse than Lisp, Forth, or Smalltalk? Yes.

[Mark Brady]

"Terry Reedy" <tj*****@udel.edu> wrote in message news:<7w********************@comcast.com>...

"Mark Brady" <ka****@lycos.com> wrote in message
news:e8**************************@posting.google.c om...

This whole thread is a bad idea.

I could agree that the OP's suggestion is a bad idea but do you
actually think that discussion and more publicity here for Lisp/Scheme
is bad? You make a pretty good pitch below for more Python=>Lisp
converts.

You are right of course, however I dislike cross posting and I also
dislike blatantly arguing with people over language choice. I would
prefer to lead by example. I think one good program is worth a
thousand words. For example people listen to Paul Graham
(http://www.paulgraham.com/avg.html) when he advocates Common Lisp
because he wrote Viaweb using it and made a fortune thanks to Lisp's
features (details in the link).

If you like python then use python.

As I plan to do.

Nothing wrong with that. Most people on these groups would agree that
Python is a very good choice for a wide range of software projects and
it is getting better with every release.

I think that if you can get over S-exps then Scheme and Common Lisp
feel very like python. I would recommend Pythonistas to at least
experiment with Common Lisp or Scheme even if you are perfectly happy
with Python. After all you have nothing to lose. If you don't like it
then fine you always have Python and you've probably learned something
and if you do like it then you have another language or two under your
belt.

Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps and there seems to be a rebirth in the

cheme

and Common Lisp communities at the moment. Ironically this seems to
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp. A
lot of new Scheme and Common Lisp developers I talk to followed the
same route. Python is a great language and I still use it for some
things.

Other Lispers posting here have gone to pains to state that Scheme is
not a dialect of Lisp but a separate Lisp-like language. Could you
give a short listing of the current main differences (S vs. CL)? If I
were to decide to expand my knowledge be exploring the current
versions of one(I've read the original SICP and LISP books), on what
basis might I make a choice?

Terry J. Reedy

This is a difficult question to answer. It's a bit like trying to
explain the differences between Ruby and Python to a Java developer
;-)

*Personally* I find it best to think of Scheme and Common Lisp as two
different but very closely related languages. The actual languages and
communities are quite different.

Common Lisp is a large, very pragmatic, industrial strength language
and its community reflects this. Common Lisp has loads of features
that you would normally only get in add on libraries built right into
the language, it's object
system "CLOS" has to be experienced to be believed and its macro
system is stunning. Some very smart people have already put years of
effort into making it capable of great things such as Nasa's award
winning remote agent software
(http://ic.arc.nasa.gov/projects/remote-agent/).

Scheme is a more functional language and unlike Common Lisp is has a
single namespace for functions and variables (Python is like Scheme in
this regard). Common Lisp can be just as functional but on the whole
the Scheme community seem to embrace functional programming to a
greater extend.

Scheme is like python in that the actual language is quite small and
uses libraries for many of the same tasks Python would use them for,
unlike Common Lisp that has many of these features built into the
language. It also has a great but slightly different macro system
although every implementation I know also has Common Lisp style
Macros.

Scheme doesn't have a standard object system (it's more functional)
but has libraries to provide object systems. This is very hard to
explain to python developers, scheme is kind of like a big python
metaclass engine where different object systems can be used at will.
It's better than I can describe and it is really like a more powerful
version of Pythons metaclass system.

Pythonistas who love functional programming may prefer Scheme to
Common Lisp while Pythonistas who want a standard amazing object
system and loads of built in power in their language may prefer Common
Lisp.

To be honest the these tutorials will do a far better job than I
could:

For Scheme get DrScheme:
http://www.drscheme.org/

and go to

'Teach yourself scheme in fixnum days' :
http://www.ccs.neu.edu/home/dorai/t-...-y-scheme.html
For Common Lisp get the trial version of Lispworks:
http://www.lispworks.com/

and go get Mark Watsons free web book:
http://www.markwatson.com/opencontent/lisp_lic.htm

Regards,
Mark.

Ps. If anyone spots a mistake in this mail please correct me, it will
have been an honest one and not an attempt to slander your favourite
language and I will be glad to be corrected, in other words there is
no need to flame me :)

[Edi Weitz]

On 03 Oct 2003 13:37:32 +0200, Matthias <[e-mail]> wrote:

I think that's incorrect: The Common Lisp language has no FFI
(foreign function call) capabilities. Each CL _implementation_ has
one (which is usually compatible to itself). This is exactly the
reason why there are way more libraries out there for Python, Perl,
maybe Ruby than for any single CL implementation. The same probably
holds for Scheme.

I'd say the Python /language/ also has no FFI capabilities. Either
that, or the Jython people are lying when they say that Jython "is an
implementation of the [...] language Python." (On the same website:
"Many of these modules are not yet implemented. Those coded in C for
CPython must be re-implemented in Java for Jython.")

Common Lisp and Scheme are languages defined by ANSI standards -
that's why you can have different implementations. Python, Perl, and
Ruby are defined by a reference implementation. You're comparing
apples and oranges.

Edi.

[MetalOne]

ka****@lycos.com (Mark Brady) wrote in message news:<e8**************************@posting.google. com>...

Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps ...

I am just barely familiar with Lisp and Scheme. However, I always
find comments like the above interesting. I have seen other people
make this claim also.
However, from an earlier post on comp.lang.python comparing a simple
loop.

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.

The second thing that puzzles me is the usage of the LISP macro
system. This system is touted as one of LISPs major strengths. I
believe the "Do" above is a macro. Is that the best syntax that can
be achieved with a macro for "Do". I would think there would already
be macros to write the Scheme code above in a format similar to the
Python code below, or some more readable syntax. I have looked for
repositories of such macros and I can't find any. This leads me to
think that in practice LISP macros are not used. Couple this with the
fact that LISP programmers seem happier with S-exprs, and I can't see
why a LISP programmer would even want to write a macro.

I have tried on 3 occassions to become a LISP programmer, based upon
the constant touting of LISP as a more powerful language and that
ultimately S-exprs are a better syntax. Each time, I have been
stopped because the S-expr syntax makes we want to vomit.

If a set of macros could be written to improve LISP syntax, then I
think that might be an amazing thing. An interesting question to me
is why hasn't this already been done.

[felix]

On 03 Oct 2003 11:25:31 -0400, Jeremy H. Brown <jh*****@ai.mit.edu> wrote:

I'm sure if you do some web-groveling, you can find some substantial
comparisons of the two; I personally think they have more in common
than not. Here are a few of the (arguably) notable differences:

Scheme Common Lisp Namespaces one two (functions, variables)
Common Lisp has actually more than two namespaces.
Implementations >10 ~4
There are loads more.
Performance "worse" "better"
Nonsense.
Support Community Academic Applications writers
Also nonsense.

Try them both, see which one works for you in what you're doing.

Very good point.
cheers,
felix

[Alex Martelli]

Mark Brady wrote:
...

This is a difficult question to answer. It's a bit like trying to
explain the differences between Ruby and Python to a Java developer
;-)

Been there, done that, it's not all _that_ difficult. The average Java
developer is quite able to understand the differences if you explain them
in terms of similarities and differences from Lisp ("Python has immutable
strings like Java, while Ruby's strings are mutable; Ruby has single
inheritance like Java, plus mix-ins, while Python has multiple inheritance,
with certain limitations", etc) and ability to interoperate ("Python has an
implementation that runs on a JVM, uses any Java class, and can generate
..class and .jar files just as if you had coded in Java, Ruby doesn't").

I think the "cultural" differences are subtler and more interesting (and
also, no doubt, even more debatable:-) -- the distinction between a Python
culture that takes pride in simplicity, uniformity, and avoidance of clever
tricks, versus a Ruby one that's quite different in these regards, IMHO.

Similarly, I suspect (but with even less reason to believe my observations
are correct) that the concept of a language being small and simple may be a
source of pride to the Scheme crowd (as it is, say, to the Python or C
ones), while that of a language being large and comprehensive may appeal to
Common Lispers (as it does, say, to C++ites or Perlmongers).

Such "soft-sciences" considerations may help guide one's choices about what
language to study next, I believe. E.g., a Pythonista who's looking for a
brisk "change of pace" might be more likely to find it in large-language
Common Lisp, while one who's looking for another "small, simple language"
culture might be more likely to find it in Scheme.
Alex

[Peter Seibel]

jc*@iteris.com (MetalOne) writes:

ka****@lycos.com (Mark Brady) wrote in message news:<e8**************************@posting.google. com>...

Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps ...
I am just barely familiar with Lisp and Scheme. However, I always
find comments like the above interesting. I have seen other people
make this claim also. However, from an earlier post on
comp.lang.python comparing a simple loop.

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.

Well, over in comp.lang.lisp (where we speak Common Lisp, more so than
Scheme) we might write that:

(defun vector-fill (v x)
(dotimes (i (length v)) (setf (aref v i) x)))

or

(defun vector-fill (v x)
(loop for i below (length v)
do (setf (aref v i) x))) (defun vector-fill (v x)
which seems pretty similar to the Python version.

(If of course we didn't already have the FILL function that does just
that.)
The second thing that puzzles me is the usage of the LISP macro
system. This system is touted as one of LISPs major strengths. I
believe the "Do" above is a macro. Is that the best syntax that can
be achieved with a macro for "Do".
Nope. Common Lisp includes the standard macros DOTIMES and LOOP as
shown above.
I would think there would already be macros to write the Scheme code
above in a format similar to the Python code below, or some more
readable syntax. I have looked for repositories of such macros and I
can't find any.
I'm sure the Scheme folks will tell you were you can find such
repositories for Scheme. But Common Lisp has them built in.
This leads me to think that in practice LISP macros are not used.
That is decidedly not true of Common Lisp.
Couple this with the fact that LISP programmers seem happier with
S-exprs, and I can't see why a LISP programmer would even want to
write a macro.
Well, macros aren't intended to get you away from s-exps though the
LOOP macro does to a certain extent. They are just intended to get you
to more to-the-point s-exps. You put your finger right on it when you
wondered why there wasn't a better way to write your loop than DO. If
DOTIMES didn't already exist, you'd write it as a macro that expands
into DO. That is: DO is a almost completely general looping construct
which makes it more than you want in a lot of situations. Macros let
you turn what you want to write (DOTIMES) into the right version of
the more general, more powerful construct (DO).
I have tried on 3 occassions to become a LISP programmer, based upon
the constant touting of LISP as a more powerful language and that
ultimately S-exprs are a better syntax. Each time, I have been
stopped because the S-expr syntax makes we want to vomit.
Hmmm. If all three of those times have been with Scheme, you might
want to try Common Lisp for a change of pace.
If a set of macros could be written to improve LISP syntax, then I
think that might be an amazing thing. An interesting question to me
is why hasn't this already been done.

Some (including me) would argue it has. They just don't define
"improve" as "get rid of all sexps".

-Peter

--
Peter Seibel pe***@javamonkey.com

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

[Frode Vatvedt Fjeld]

jc*@iteris.com (MetalOne) writes:

[..] However, from an earlier post on comp.lang.python comparing a
simple loop.

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind. [..]
The scheme example can only have been written by someone who is on the
outset determined to demonstrate that sexp-syntax is complicated. This
is how I'd write it in Common Lisp:

(defun vector-fill (v x)
(dotimes (i (length v))
(setf (aref v i) x)))

As you can see, it matches the python example quite closely.
[..] If a set of macros could be written to improve LISP syntax,
then I think that might be an amazing thing. An interesting
question to me is why hasn't this already been done.

Lisp macros and syntactic abstractions are one of those things whose
power and elegance it is somewhat hard to explain to those who have
not experienced it themselves first hand. Paul Graham's book "On Lisp"
is considered by many to be a good introduction to the subject.

I am quite comforatble with Common Lisp's syntax, and I see no
particular need for some set of macros to improve its syntax. In fact
I have no idea what so ever as to what such a set of macros would look
like.

--
Frode Vatvedt Fjeld

[Paul Rubin]

jc*@iteris.com (MetalOne) writes:

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))
I think you could write the scheme code like this:

(define vector-fill! (v x)
(let ((i 0))
(while (< i (length v))
(vector-set! v i x)
(set! i (1+ i)))))
I have tried on 3 occassions to become a LISP programmer, based upon
the constant touting of LISP as a more powerful language and that
ultimately S-exprs are a better syntax. Each time, I have been
stopped because the S-expr syntax makes we want to vomit.

If you go crazy with macros, lisp gets confusing, that's for sure.

[Daniel Silva]

On Fri, 3 Oct 2003, MetalOne wrote:

I am just barely familiar with Lisp and Scheme. However, I always
find comments like the above interesting. I have seen other people
make this claim also.
However, from an earlier post on comp.lang.python comparing a simple
loop.

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.

I'd prefer one of these two implementations myself:

(define (vector-fill! v x)
(let loop ([i (sub1 (vector-length v))])
(unless (< i 0)
(vector-set! v i x)
(loop (sub1 i)))))

(define (vector-fill-again! v x)
(for-each (lambda (i)
(vector-set! v i x))
(build-list (vector-length v) identity)))
The second one actually does almost exactly what the Python version does,
other than creating a lambda and mapping identity across range(len(v)).

If you want to use macros to make a for-each that does just what your
example asks for:
(define-syntax (for stx)
(syntax-case stx ()
[(_ idx lst exp) #`(for-each (lambda (idx)
exp)
lst)]))

And given a function range that does the same thing:

(define (range r)
(build-list r identity))

Now you have the same for loop:

(define (my-vector-fill! v x)
(for i (range (vector-length v))
(vector-set! v i x)))
- Daniel

[Grzegorz Chrupala]

Rene van Bevern <rv*@rvb.dyndns.org> wrote in message news:<sl****************@negoyl.vb-network>...

I know at least one more person who came to LISP/Scheme over ruby. Maybe
it needs ruby and python to enlighten people without confusing them with
a syntax they are not used to first. ;)

I can't remember how *exactly* I came to use scheme (unfortuantely I
don't keep a diary), but trying to reconstruct it looks something like
this:

I am actually not a programmer, but mostly a linguist. About four
years ago I got interested in computational linguistics and decided to
learn a programming language. The first programming book I picked up
was "The Gentle Introduction..." (Common Lisp). I made sense to me but
I couldn't find a plug'n' play lisp implementation (I was pretty
computer-illiterate at the time: could only manage v. basic stuff on
Windoze). So I put that aside and decided to have a go at Perl (widely
used in NLP). That was much easier, I installed the ActiveState win32
port no problems and picked Perl up from online tutorials and the
multitude of other easily accessible Perl resources. After I've played
with perl for a while I heard about Python and Ruby, which to me
looked like more sophisticated versions of Perl, and I switched to
Ruby for most of my toy and not-so-toy scripts. While reading
ruby-talk and other ruby-stuff I kept coming across references to
Scheme and Lisp, which I was already vaguely familiar with from my
perusal of the "Gentle Introduction". At this point I was already
using Linux and so could easily install Clisp and half a dozen Scheme
implementations. Schemes such as Gauche, Bigloo and PLT seemed like
they were better suited to writing the sort of small programs or CGI
scripts that I was using Perl and Ruby for, so I sort of settled for
Scheme. (Sometime during this time I also learned Prolog in a
university course and it made me aware of the various advantages, as
well as some disadvantages, of using a very high level languages in
comp-ling).
At the moment I am quite happy with Scheme although I do miss the
large lively communities and the amout of libraries associated with
Perl, Python and Ruby. I hope the "revival" of Lisp-like languages
some of you have observed will gain momentum and that CL anb Scheme
will catch up with Python and Ruby in the areas where they are behind.

Cheers,
--
Grzegorz

[Philippe]

mi*****@ziplip.com wrote:

I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience.

Yes. In fact Daniel Silva and I are working on an implementation of
the Python language for the DrScheme development environment. So you
don't get just a pythonistic syntax for Scheme, you directly get
Python in your Scheme environment. It looks like this:
http://www.ccs.neu.edu/home/matthias/Tmp/spy.jpg

Then Scheme programmers can reuse existing Python code and vice-versa.
Python programmers can also use DrScheme's tools with their code.
Here's an example of using DrScheme's Check Syntax tool on Python
code: http://www.ccs.neu.edu/home/matthias/Tmp/spy2.jpg The tool
analyzes the code, colors terms according to their syntactic category,
and draws arrows that show bindings. Note that no modification to the
Check Syntax tool was necessary to get it to work with Python:
everything was handled automatically by DrScheme's underlying syntax
object system. Not all of DrScheme's tools will automatically work
for Python without modifications like Check Syntax does because some
tools, like the Stepper or the analyzer, need to be aware of some
details about the semantics of the language, but the fact that Check
Syntax and DrScheme's test coverage tool already work with Python and
for free is quite encouraging.

Currently most of the Python language has been implemented and the few
remaining things are well within our reach (except for unicode
support). Daniel (who's the main developer actually - my role is just
to criticize everything he does :-)) is now working on the FFI so
Python and Scheme programmers can have access to the C-level Python
modules.

There's still a lot of work that remains to be done so if anyone,
whether Python or Scheme programmer, is interested in helping you're
more than welcome to contact us!

Also, if people are interested in knowing how it all works, Daniel
will have a short presentation of the system at the Scheme Workshop in
Boston next month (the day before the Lightweight Languages 2003 (LL3)
conference).

</shameless plug>

Philippe

[Erann Gat]

In article <92**************************@posting.google.com >,
jc*@iteris.com (MetalOne) wrote:

ka****@lycos.com (Mark Brady) wrote in message news:<e8**************************@posting.google. com>...

Personally I find Scheme and Common Lisp easier to read but that's
just me, I prefer S-exps ...

I am just barely familiar with Lisp and Scheme. However, I always
find comments like the above interesting. I have seen other people
make this claim also.
However, from an earlier post on comp.lang.python comparing a simple
loop.

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.

In Common Lisp you can write:

(defun vector-fill (v x)
(loop for i from 0 below (length v) do
(setf (aref v i) x)))

or

(defun vector-fill (v x)
(dotimes (i (length v))
(setf (aref v i) x)))

But if you focus on examples like this you really miss the point. Imagine
that you wanted to be able to write this in Python:

def vector_fill(v, x):
for i from 0 to len(v)-1:
v[i] = x

You can't do it because Python doesn't support "for i from ... to ...",
only "for i in ...". What's more, you can't as a user change the language
so that it does support "for i from ... to ...". (That's why the xrange
hack was invented.)

In Lisp you can. If Lisp didn't already have LOOP or DOTIMES as part of
the standard you could add them yourself, and the way you do it is by
writing a macro.

That's what macros are mainly good for, adding features to the langauge in
ways that are absolutely impossible in any other language. S-expression
syntax is the feature that enables users to so this quickly and easily.
I can't see
why a LISP programmer would even want to write a macro.

That's because you are approaching this with a fundamentally flawed
assumption. Macros are mainly not used to make the syntax prettier
(though they can be used for that). They are mainly used to add features
to the language that cannot be added as functions.

For example, imagine you want to be able to traverse a binary tree and do
an operation on all of its leaves. In Lisp you can write a macro that
lets you write:

(doleaves (leaf tree) ...)

You can't do that in Python (or any other langauge).

Here's another example of what you can do with macros in Lisp:

(with-collector collect
(do-file-lines (l some-file-name)
(if (some-property l) (collect l))))

This returns a list of all the lines in a file that have some property.
DO-FILE-LINES and WITH-COLLECTOR are macros, and they can't be implemented
any other way because they take variable names and code as arguments.

E.
----

P.S. Here is the code for WITH-COLLECTOR and DO-FILE-LINES:

(defmacro with-collector (var &body body)
(let ( (resultvar (gensym "RESULT")) )
`(let ( (,resultvar '()) )
(flet ( (,var (item) (push item ,resultvar)) )
,@body)
(nreverse ,resultvar))))

(defmacro do-file-lines ((linevar filename &optional streamvar) &body body)
(let ( (streamvar (or streamvar (gensym "S"))) )
`(with-open-file (,streamvar ,filename)
(do ( (,linevar (read-line ,streamvar nil nil)
(read-line ,streamvar nil nil)) )
( (null ,linevar) )
,@body))))

Here's DOLEAVES:

(defmacro doleaves ((var tree) &body body)
`(walkleaves (lambda (,var) ,@body) ,tree))

:-)

(defun walkleaves (fn tree)
(iterate loop1 ( (tree tree) )
(if (atom tree)
(funcall fn tree)
(progn (loop1 (car tree)) (and (cdr tree) (loop1 (cdr tree)))))))

; This is the really cool way to iterate
(defmacro iterate (name args &rest body)
`(labels ((,name ,(mapcar #'car args) ,@body))
(,name ,@(mapcar #'cadr args))))

E.

[Kenny Tilton]

Grzegorz Chrupala wrote:

Rene van Bevern <rv*@rvb.dyndns.org> wrote in message news:<sl****************@negoyl.vb-network>...

I know at least one more person who came to LISP/Scheme over ruby. Maybe
it needs ruby and python to enlighten people without confusing them with
a syntax they are not used to first. ;)

I can't remember how *exactly* I came to use scheme (unfortuantely I
don't keep a diary), but trying to reconstruct it looks something like
this:

It would be valuable to have what you wrote next in:

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

Lisp there is defined as "any member of the Lisp family".

Aside: oh, great. Now the survey is going to get thrown off the ALU
Cliki by the Iki Police. um, could you all find something less
productive to focus on? Cutting and pasting thirty pages is /so/ helpful
to the Lisp community. Not!!!

You can be response #78...oops, #79.

Or e-mail me a go-ahead and I'll do the legwork.

kenny

[Sampo Smolander]

In comp.lang.scheme Paul Rubin <http://ph****@nospam.invalid> wrote:

I think you could write the scheme code like this: (define vector-fill! (v x)

I guess parenthesising like

(define (vector-fill! v x)

would be more schemey.

[Followups set to scheme-group only]

[synthespian]

Jeremy H. Brown wrote:
(snip)

According to the "Revised(5) Report on the Algorithmic Language
Scheme", "Scheme is a statically scoped and properly tail-recursive
dialect of the Lisp programming language..." It's certainly not a
dialect of Common Lisp, although it is one of CL's ancestors.

I'm sure if you do some web-groveling, you can find some substantial
comparisons of the two; I personally think they have more in common
than not. Here are a few of the (arguably) notable differences:

Scheme Common Lisp
Philosophy minimalism comprehensiveness

(etc)
Hello --

I would just like to point out that there's more choice out there in
the Lisp family than Scheme - Common Lisp.
In particular, I would like to mention ISLISP, which is an
ISO-standard Lisp. Apparently, the story goes somewhat like this: when
lispers went for an ANSI standard, they left out the Europeans and the
Japanese - which were the other people heavily using Lisp at the time.
Thus, ANSI Common Lisp was made all-American. So the people left out
went for an ISO-standard Lisp.
I don't know why this happened, I suspect (and I might be *very*
wrong) it had something to do with competition way back when Lisp were
aiming higher expectations market-wise (the French being very proud of
Prolog :-) ).
I have recently bumped into ISLISP. It is pretty good. It has full
documentation and two usable implementations: a GPL TISL, and a free for
non-commercial use OpenLisp (for now, at least, and I can't say for now
if this will change - for the better).
I don't have time to write a comparison table now, but let me just
say that it mentions in its documentation the purpose of merging the
perceived best features of "the family": "It attempts to bridge the gap
between the various incompatible members of the Lisp family of languages
(most notably Common Lisp, Eulisp, LeLisp, and Scheme) by focusing on
standardizing those areas of widespread agreement." (check the URLs
bellow, this quote from KMP's ISLISP site). However, it's not as big as
Common Lisp (but some people mention that Common Lisp is a large as it
is because it ported functionality that was from the Lisp Machines - but
I might be wrong, what do I know about Lisp Machines - I wish...).
ISLISP has objects, generic functions, defmacro and other good
things. One of its stated aims was industry-use, not academia (that's
from the spec).
The TISL implementation is not so much developed as OpenLisp, but
it's functional and GPLed. OpenLisp is lovely, and it beats the hell out
of Scheme and Common Lisp on the *huge* number of platforms it compiles
on. OpenLisp has compiled on over 60 platforms (yes! 16 to 64 bits!),
and is actively ported today to over 20! So, it's pretty amazing, when
you take into consideration that platform differences are an issue,
particularly with Common Lisp implementations (CLISP being the most
portable), when you need to interact with the OS. So, this is a
non-issue solved on OpenLisp, just as it is solved on Python or Perl. It
approaches Perl or Python in portability (or beats them, I dunno).
OpenLisp's author, unfortunately, isn't much of a "marketing" person...
I have tested it under win32 and NetBSD on Alpha.

BTW, I bumped into OpenLisp because of a Lisp-friendly unix shell
account provider,SDF Public Access Unix Network, a non-profit, that
supports OpenLisp for CGI (also having the usual Python/Perl, etc).
I mention ISLISP here because people are unaware of its existence,
and it's quite a jewel, really.
And let's be honest, who needs Python/Perl/Ruby when you have Lisp? ;-)

Well, that's my 2c, get to know and enjoy ISLISP.

Cheers,
Henry
OpenLisp by Eligis
http://christian.jullien.free.fr/
or http://www.eligis.com

TISL GPL'd ISLISP form Tohoku University (Japan) (under active development)
http://www.ito.ecei.tohoku.ac.jp/TISL/index_j.html

ISLISP - Standards http://anubis.dkuug.dk/JTC1/SC22/WG1.../standard.html

More ISLISP documentation http://www.islisp.info/, this site maintained
by Kent Pitman

ISLISP in Java http://cube.misto.cz/lisp/

TBK's links on ISLISP
http://tkb.mpl.com/~tkb/links/tkb-li...3c416bc48.html

[Grzegorz Chrupala]

jc*@iteris.com (MetalOne) wrote in message news:<92**************************@posting.google. com>...

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.
Pick a construct your pet language has specialized support, write an
ugly equivalent in a language that does not specifically support it
and you have proved your pet language to be superior to the other
language. (I myself have never used the "do" macro in Scheme and my
impression is few people do. I prefer "for-each", named "let" or the
CL-like "dotimes" for looping).
The point is if you want you can easily implement something like
"range" in Scheme (as shown by other posters). It would be more
illustrative choose an area where one of the languages is inherently
underpowered. For example I was shocked at how awkward Paul Graham's
"accumulator generator" snippet is in Python:

class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n

If a set of macros could be written to improve LISP syntax, then I
think that might be an amazing thing. An interesting question to me
is why hasn't this already been done.

There are libraries that let you write Scheme in Python-like
indentation syntax (<URL:http://cliki.tunes.org/Scheme>, look for
Alternative Syntaxes). However, they are not widely used.

Cheers,
--
Grzegorz

[synthespian]

Marco Antoniotti wrote:

mi*****@ziplip.com wrote:

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while keeping
its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

Why do I feel like crying? :{

Cheers
--
Marco

Because it makes you wonder: "why?"

Henry

[synthespian]

Mark Brady wrote:

Pythonistas who love functional programming may prefer Scheme to
Common Lisp while Pythonistas who want a standard amazing object
system and loads of built in power in their language may prefer Common
Lisp.
(snip) Regards,
Mark.

Ps. If anyone spots a mistake in this mail please correct me, it will
have been an honest one and not an attempt to slander your favourite
language and I will be glad to be corrected, in other words there is
no need to flame me :)

I would just say that CLOS (Common Lisp Object System) is not "standard"
in the sense people take OOP to be nowadays, but able to encompass and
go beyond the JAVA, C++, Python, etc, paradigm. This fact was
demonstrated briefly on Paul Graham's ANSI Common LISP book, and
elsewhere, and it's basically a satori.

Henry

[Alex Martelli]

Grzegorz Chrupala wrote:
...

class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n

some might prefer:

def foo(n):
tot = [n]
def acc(i):
tot[0] += i
return tot[0]
return acc

which is roughly equivalent. It's true that most Pythonistas prefer to
use class instances, rather than closures, in order to group together
some state and some behavior, and the language favours that; and Python
separates expressions and statements quite firmly, so one just can't
increment-and-return in one stroke, nor define-and-return-function ditto.
But I don't see how these issues spell "awkwardness" in this case.
Alex

[Bengt Richter]

On 4 Oct 2003 00:17:30 -0700, gr******@pithekos.net (Grzegorz Chrupala) wrote:

jc*@iteris.com (MetalOne) wrote in message news:<92**************************@posting.google. com>...

Scheme
(define vector-fill!
(lambda (v x)
(let ((n (vector-length v)))
(do ((i 0 (+ i 1)))
((= i n))
(vector-set! v i x)))))

Python
def vector_fill(v, x):
for i in range(len(v)):
v[i] = x
I guess you could also just write

v[:] = [x]*len(v)

instead of calling a function (though it takes more space), e.g.,

v=range(10)
id(v),v (9442064, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) v[:] = [55]*len(v)
id(v),v (9442064, [55, 55, 55, 55, 55, 55, 55, 55, 55, 55])

using id(v) to show that the same object is mutated.

To me the Python code is easier to read, and I can't possibly fathom
how somebody could think the Scheme code is easier to read. It truly
boggles my mind.
Pick a construct your pet language has specialized support, write an
ugly equivalent in a language that does not specifically support it
and you have proved your pet language to be superior to the other
language. (I myself have never used the "do" macro in Scheme and my
impression is few people do. I prefer "for-each", named "let" or the
CL-like "dotimes" for looping).
The point is if you want you can easily implement something like
"range" in Scheme (as shown by other posters). It would be more
illustrative choose an area where one of the languages is inherently
underpowered. For example I was shocked at how awkward Paul Graham's
"accumulator generator" snippet is in Python:

class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n

Do you like this better?
def foo(n): ... box = [n]
... def foo(i): box[0]+=i; return box[0]
... return foo
... bar = foo(10)
bar(1) 11 bar(2) 13 bar(37) 50 baz = foo(100)
bar(1), baz(23)

(51, 123)

If a set of macros could be written to improve LISP syntax, then I
think that might be an amazing thing. An interesting question to me
is why hasn't this already been done.

There are libraries that let you write Scheme in Python-like
indentation syntax (<URL:http://cliki.tunes.org/Scheme>, look for
Alternative Syntaxes). However, they are not widely used.

Cheers,
--
Grzegorz

Regards,
Bengt Richter