Python syntax in Lisp and Scheme

[Daniel Silva]

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

My mistake in choosing stx_id(stmt).  Maybe foo{'bar', baz()} would be
better, or
    foo bar:
      baz()

> >> the details.  Consensus is culturally important, even though in the end
> >> Guido decides: we are keen to ensure we all keep using the same language,
> >> rather than ever fragmenting it into incompatible dialects.
> >
> > The point is that the language spec itself is changed (along with the
> > interpreter in C!) to add that statement.  I would be happier if I could
> > write syntax extensions myself, in Python, and if those extensions worked
> > on CPython, Jython, Python.Net, Spy, etc.
>
> So, I hope the cultural difference is sharply clear.  To us, consensus
> is culturally important, we are keen to ensure we all keep using the
> same language; *you* would be happier if you could use a language that
> is different from those of others, thanks to syntax extensions you
> write yourself.  Since I consider programming to be mainly a group
> activity, and the ability to flow smoothly between several groups to
> be quite an important one, I'm hardly likely to appreciate the divergence
> in dialects encouraged by such possibilities, am I?

Yes, we disagree about how we use a language.  It's too bad the choice
isn't left to the programmer, though.

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

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

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

- Daniel