Python syntax in Lisp and Scheme

[Ed Avis]

Re: Python syntax in Lisp and Scheme

mike420@ziplip. com writes:
[color=blue]
>I'd like to know if it may be possible to add a powerful macro system
>to Python, while keeping its amazing syntax,[/color]

I fear it would not be. I can't say for certain but I found that the
syntax rules out nesting statements inside expressions (without adding
some kind of explicit bracketing, which rather defeats the point of
Python syntax) and you might run into similar difficulties if adding
macros. It's a very clean syntax (well, with a few anomalies) but
this is at the price of a rigid separation between statements and
expressions, which doesn't fit well with the Lisp-like way of doing
things.

Myself I rather like the option chosen by Haskell, to define an
indentation-based syntax which is equivalent to one with bracketing,
and let you choose either. You might do better to add a new syntax to
Lisp than to add macro capabilities to Python. Dylan is one Lisp
derivative with a slightly more Algol-like syntax, heh, Logo is
another; GNU proposed some thing called 'CTAX' which was a C-like
syntax for Guile Scheme, I don't know if it is usable.

If the indentation thing appeals, maybe you could preprocess Lisp
adding a new kind of bracket - say (: - which closes at the next line
of code on the same indentation level. Eg

(: hello
there
(goodbye)

would be equivalent to

(hello
there)
(goodbye)

I dunno, this has probably already been done.

--
Ed Avis <ed@membled.com >

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck wrote:
[color=blue]
> [comp.lang.funct ional removed]
> Peter Seibel <peter@javamonk ey.com> writes:
>[color=green]
>> which seems pretty similar to the Python version.
>>
>> (If of course we didn't already have the FILL function that does just
>> that.)[/color]
>
> Just for the record, in python all you'd write is: v[:] = a
>
> 'as[/color]

I suspect you may intend "v[:] = [a]*len(v)", although a good alternative
may also be "v[:] = itertools.repea t(a, len(v))".


Alex

[Frode Vatvedt Fjeld]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Sure, but aren't these the examples that are being presented? Isn't
> "with-collector" a general purpose iteration construct, etc? Maybe
> only _special_ purpose ones should be built with macros (if you are
> right that _general_ purpose ones should not be), but the subtleness
> of the distinction leaves me wondering about the practice.[/color]

It is a subtle distinction, just like a lot of other issues in
programming are quite subtle. And I think this particular issue
deserves more attention than it has been getting (so far as I know).

As for the current practice, I know that I quite dislike code that
uses things like with-collector, and I especially dislike it when I
have to look at the macro's expansion to see what is going on, and I
know there are perfectly fine alternatives in the standard syntax. On
the other hand, I do like it when I see a macro call that reduces tens
or even hundreds of lines of code to just a few lines that make it
immediately apparent what's happening. And I know I'd never want to
use a language with anything less than lisp's macros.

--
Frode Vatvedt Fjeld

[David Golden]

Re: Python syntax in Lisp and Scheme

Sugar exists. http://redhog.org/Projects/Programming/Current/Sugar/


let
group
foo
+ 1 2
bar
+ 3 4
+ foo bar

[Sander Vesik]

Re: Python syntax in Lisp and Scheme

In comp.lang.schem e Grzegorz Chrupala <grzegorz@pithe kos.net> wrote:[color=blue]
> jcb@iteris.com (MetalOne) wrote in message news:<92c59a2c. 0310031345.57d2 0631@posting.go ogle.com>...[color=green]
>> 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.[/color]
>
> 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).[/color]

Whiile true, if solving a problem requires you to use a lot of constructs
that one language provides and for which youave to do lots of extra work
in teh other, one might aswell take the pragmatic approach that the other
language is better for the given problem at hand.
[color=blue]
>
> Cheers,
> --
> Grzegorz[/color]

--
Sander

+++ Out of cheese error +++

[Christoph]

Re: Python syntax in Lisp and Scheme

"Alex Martelli" wrote:
....[color=blue]
> def outer(a) proc do |b| a+=b end end
>
> x = outer(23)
> puts x.call(100) # emits 123
> puts x.call(100) # emits 223
>
> [i.e., I can't think of any way you could just use x(100)
> at the end of such a snippet in Ruby -- perhaps somebody
> more expert of Ruby than I am can confirm or correct...?][/color]

Guy is probably thinking about something like this

---
def outer(sym,a)
Object.instance _eval {
private # define a private method
define_method(s ym) {|b| a+=b }
}
end

outer(:x,24)

p x(100) # 124
p x(100) # 224
---


but there is no way to write a ``method returning
method ::outer in Ruby that could be used in the form

----
x = outer(24)
x(100)
----

On the other hand, using []-calling convention
and your original definition, you get - at least
visually - fairly close.

---
def outer(a) proc do |b| a+=b end end

x = outer(23)
puts x[100] # emits 123
puts x[100] # emits 223
---


/Christoph

[Sander Vesik]

Re: Python syntax in Lisp and Scheme

In comp.lang.schem e David Rush <drush@aol.ne t> wrote:[color=blue]
> On 03 Oct 2003 14:44:36 +0300, Toni Nikkanen <toni@tuug.fi > wrote:[color=green]
>> It's be interesting to know where people got the idea of learning
>> Scheme/LISP from (apart from compulsory university courses)?[/color]
>
> Emacs. I've noticed over the years that people don't really get Emacs
> religion until they've started hacking elisp. I know that the frustration
> of having almost-but-not-quite the behavior I wanted on top of having all
> that source code was a powerful incentive for me to learn Lisp. Of course
> my apreciation of Emacs only increased as I went...[/color]

I have at times almost gnawed off my hand to avoid going down that path.
I'd rather write cobol than elisp...
[color=blue]
>
> The thing that sealed it for me was re-programming SCWM's behavior so that
> I could use X w/no mouse &cet. That got me hooked on Scheme (I had been
> hacking SML at roughly the same time while looking for the foundations of
> OOP), which was really just about perfect semantically.
>
> david rush[/color]

--
Sander

+++ Out of cheese error +++

[Grzegorz Chrupała]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
>
> Tut-tut. You are claiming, for example, that I mentioned the lack
> of distinction between expressions and statements as "too complex for
> Python to support": I assert your claim is demonstrably false, and
> that I NEVER said that it would be COMPLEX for Python to support such
> a lack. What I *DID* say on the subject, and I quote, was:[/color]

Sorry if I inadvertantly distorted your words. What I meant by my admittedly
rhetorical statement wa something like: "these features either introduce
too much complexity, or are messy, or otherwise incompatible with Python's
philosophy and for this reason the language refuses to support them." Not
necessarily too complex to *implement*. I do realize that
no-statements-just-expressions is not a particularly challenging design
issue.
[color=blue]
> It makes the _learner_'s job simple (the rule he must learn is simple),[/color]

That is plausible.
[color=blue]
> and it makes the _programmer_'s job simple (the rule he must apply to
> understand what will happens if he codes in way X is simple)[/color]

This makes less sense. The rule may be simple but it also limits the
expressiveness of the language and forces the programmer to work around the
limitations in a contorted and far from "simple" way.

[color=blue]
> I thought the total inability to nest method definitions (while in Python
> you get perfectly normal lexical closures, except that you can't _rebind_
> outer-scope names -- hey, in functional programming languages you can't
> rebind ANY name, yet nobody every claimed that this means they "don't have
> true lexical closures"...!-), and more generally the deep split between
> the space of objects and that of methods (a split that's simply not there
> in Python), would have been show-stoppers for a Schemer, but it's always
> nice to learn otherwise.[/color]

I don't really feel quite qualified discuss Ruby's design decisions wrt the
relation between methods, procedures and objects, but I don't think the
split between methods and objects is as deep as you claim:

irb(main):011:0 > meth="f-o-o".method(:spli t)
=> #<Method: String#split>
irb(main):012:0 > meth.class
=> Method
irb(main):013:0 > meth.kind_of?(O bject)
=> true
irb(main):014:0 > meth.call('-')
=> ["f", "o", "o"]
irb(main):015:0 >

I do tend to think that Ruby would be better off with a more unified
treatment of blocks, procedures and methods, but my understanding of the
issues involved is very incomplete. Perhaps Smalltalk experts would be more
qualified to comment on this.

--
Grzegorz

http://pithekos.net

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Sander Vesik wrote:[color=blue]
> I have at times almost gnawed off my hand to avoid going down that path.
> I'd rather write cobol than elisp...[/color]

Mileage does vary :): http://alu.cliki.net/RtL%20Emacs%20Elisp

That page lists people who actually cite Elisp as at least one way they
got turned on to Lisp. I started the survey when newbies started showing
up on the c.l.l. door in still small but (for Lisp) significantly larger
numbers. Pail Graham holds a commanding lead, btw.

kenny

[Andrew Dalke]

Re: Flat-schmat! [was Re: Python syntax in Lisp and Scheme]

Still have only made slight headway into learning Lisp since the
last discussion, so I've been staying out of this one. But

Kenny Tilton:[color=blue]
> Take a look at the quadratic formula. Is that flat? Not. Of course
> Python allows nested math (hey, how come!), but non-mathematical
> computations are usually trees, too.[/color]

Since the quadratic formula yields two results, I expect most
people write it more like

droot = sqrt(b*b-4*a*c) # square root of the discriminate
x_plus = (-b + droot) / (4*a*c)
x_minus = (-b - droot) / (4*a*c)

possibly using a temp variable for the 4*a*c term, for a
slight bit better performance.
[color=blue]
> It occurred to me that, if the computation
> is indeed the moral equivalent of the quadratic formula, calling various
> lower-level functions instead of arithmetic operators, then it is
> /worse/ to be reading a flattened version in which subexpression results
> are pulled into local variable, because then one has to mentally
> decipher the actual hierarchical computation from the bogus flat sequence.[/color]

But isn't that flattening *exactly* what occurs in math. Let me pull
out my absolute favorite math textbook - Bartle's "The Elements
of Real Analysis", 2nd ed.

I opened to page 213, which is in the middle of the book.

29.1 Definition. If P is a partition of J, then a Riemann-Stieltjes sum
of f with respect to g and corresponding to P = (x_0, x_1, ..., x_n) is a
real
number S(P; f, g) of the form

n
S(P; f, g) = SIGMA f(eta_k){g(x_k) - g(x_{k-1})}
k = 1

Here we have selected number eta_k satisying

x_{k-1} <= eta_k <= x_k for k = 1, 2, ..., n

There's quite a bit going on here behind the scenes which are
the same flattening you talk about. For examples: the definiton
of "partition" is given elsewhere, the notations of what f and g
mean, and the nomenclature "SIGMA"


Let's try mathematical physics, so I pulled out Arfken's
"Mathematic al Methods for Physicists", 3rd ed.

About 1/3rd of the way through the book this time, p 399

Exercise 7.1.1 The function f(z) expanded in a Laurent series exhibits
a pole of order m at z = z_0. Show that the coefficient of (z-z_0)**-1,
a_{-1}, is given by
1 d[m-1]
a_{-1} = ------- * ------------- * ( (z-z_0)**m * f(z)) evalutated as )
(m-1)! d z [m-1]
x -> x_0

This requires going back to get the definition of a Laurent series,
and of a pole, knowing how to evaluate a function at a limit point,
and remembering the bits of notation which are so hard to express
in 2D ASCII. (the d[m-1]/dz[m-1] is meant to be the d/dz operator
taken m-1 times).

In both cases, the equations are flattened. They aren't pure trees
nor are they absolutely flat. Instead, names are used to represent
certain ideas -- that is, flatten them. Yes, it requires people to
figure out what these names mean, but on the other hand, that's part
of training.

And part of that training is knowing which terms are important
enough to name, and the balance between using using old
names and symbols and creating new ones.
[color=blue]
> So if we have:
>
> (defun some-vital-result (x y z)
> (finally-decide
> (if (serious-concern x)
> (just-worry-about x z)
> (whole-nine-yards x
> (composite-concern y z)))))
>
> ...well, /that/ visually conveys the structure of the algorithm, almost
> as well as a flowchart (as well if one is accustomed to reading Lisp).
> Unwinding that into an artificial flattening /hides/ the structure.[/color]

"Flat is better than nested." does not mean nested is always and
forever wrong. "Better" means there's a balance.

"Readabilit y counts." is another guideline.
[color=blue]
> I do not know what Zen is, but I do now that is not Zen.[/color]

The foreigner came to the monestary, to learn more of the
ways of Zen. He listened to the monks then sat cross-legged
for a day, in the manner of initiates. Afterwards he complained
to the master saying that it would be impossible for him to reach
Nirvana because of the pains in his legs and back. Replied the
master, "try using a comfy chair," but the foreigner returned
home to his bed.

The Zen of Python outlines a set of guidelines. They are not
orthogonal and there are tensions between them. You can
take one to an extreme but the others suffer. That balance
is different for different languages. You judge the Zen of Python
using the Zen of Lisp.

Andrew
dalke@dalkescie ntific.com

[Paul Rubin]

Re: Python syntax in Lisp and Scheme

Kenny Tilton <ktilton@nyc.rr .com> writes:[color=blue]
> That page lists people who actually cite Elisp as at least one way
> they got turned on to Lisp. I started the survey when newbies started
> showing up on the c.l.l. door in still small but (for Lisp)
> significantly larger numbers. Pail Graham holds a commanding lead, btw.[/color]

I'd fooled around with other lisp systems before using GNU Emacs, but
reading the Emacs source code was how I first got to really understand
how Lisp works.

[Robin Becker]

Re: Flat-schmat! [was Re: Python syntax in Lisp and Scheme]

In article <PsIfb.2222$gA1 .1619@newsread3 .news.pas.earth link.net>,
Andrew Dalke <adalke@mindspr ing.com> writes
.......[color=blue]
>Since the quadratic formula yields two results, I expect most
>people write it more like
>
>droot = sqrt(b*b-4*a*c) # square root of the discriminate
>x_plus = (-b + droot) / (4*a*c)
>x_minus = (-b - droot) / (4*a*c)
>
>possibly using a temp variable for the 4*a*c term, for a
>slight bit better performance.[/color]

perhaps we should be using computer algebra as suggested in this paper
http://www.mmrc.iss.ac.cn/~ascm/ascm03/sample.pdf on computing the
solutions of quadratics.
--
Robin Becker

[David Eppstein]

Re: Python syntax in Lisp and Scheme

In article <crIfb.14315$pv 6.1105@twister. nyc.rr.com>,
Kenny Tilton <ktilton@nyc.rr .com> wrote:
[color=blue][color=green]
> > I have at times almost gnawed off my hand to avoid going down that path.
> > I'd rather write cobol than elisp...[/color]
>
> Mileage does vary :): http://alu.cliki.net/RtL%20Emacs%20Elisp
>
> That page lists people who actually cite Elisp as at least one way they
> got turned on to Lisp. I started the survey when newbies started showing
> up on the c.l.l. door in still small but (for Lisp) significantly larger
> numbers. Pail Graham holds a commanding lead, btw.[/color]

Heh. Does that mean former TECO programmers will get turned on to Perl?
Hasn't had that effect for me yet...

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

[Sander Vesik]

Re: Python syntax in Lisp and Scheme

In comp.lang.schem e David Rush <drush@aol.ne t> wrote:[color=blue]
>[color=green]
>> Exceptions no yes[/color]
> yes, via continuations which reify the
> fundamental control operators in all languages[/color]

the exceptions SRFI and saying it is there as an extension would imho be a
better answer.
[color=blue]
>[color=green]
>> Implementations >10 ~4[/color]
> too many to count. The FAQ lists over twenty. IMO
> there are about 9 'major' implementations which
> have
> relatively complete compliance to R5RS and/or
> significant extension libraries
>[/color]

And the number is likely to continue increase over the years. Scheme is
very easy to implement, including as an extensions language inside the
runtime of something else. The same doesn't really hold for common lisp.
[color=blue]
>
> david rush[/color]

--
Sander

+++ Out of cheese error +++

[Hans Nowak]

Re: Python syntax in Lisp and Scheme

Lulu of the Lotus-Eaters wrote:[color=blue]
> grzegorz@pithek os.net (Grzegorz Chrupala) wrote previously:
> |shocked at how awkward Paul Graham's "accumulato r generator" snippet is
> |in Python:
> |class foo:
> | def __init__(self, n):
> | self.n = n
> | def __call__(self, i):
> | self.n += i
> | return self.n
>
> Me too. The way I'd do it is probably a lot closer to the way Schemers
> would do it:
>[color=green][color=darkred]
> >>> def foo(i, accum=[0]):[/color][/color]
> ... accum[0]+=i
> ... return accum[0]
> ...[color=green][color=darkred]
> >>> foo(1)[/color][/color]
> 1[color=green][color=darkred]
> >>> foo(3)[/color][/color]
> 4
>
> Shorter, and without an awkward class.[/color]

Yah, but instead it abuses a relatively obscure Python feature... the fact that
default arguments are created when the function is created (rather than when it
is called). I'd rather have the class, which is, IMHO, a better way to
preserve state than closures. (Explicit being better than implicit and all
that... :-)

--
Hans (hans@zephyrfal con.org)

http://zephyrfalcon.org/