From: "Grzegorz Chrupała" <grzegorz@...>
Date: 2003-10-05T08:16:39+09:00
Subject: Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:

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

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.
 
> It makes the _learner_'s job simple (the rule he must learn is simple),

That is plausible.

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

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.

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

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(:split)
=> #<Method: String#split>
irb(main):012:0> meth.class
=> Method
irb(main):013:0> meth.kind_of?(Object)
=> 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