Python syntax in Lisp and Scheme

[Erann Gat]

In article <Snhgb.235745$R32.7621170 at news2.tin.it>, aleax at aleax.it wrote:

> Erann Gat wrote:
> 
> > In article <uEwfb.222927$R32.7155971 at news2.tin.it>, aleax at aleax.it wrote:
> > 
> >> Erann Gat wrote:
> >>    ...
> >> > (That's why the xrange hack was invented.)
> >> 
> >> Almost right, except that xrange is a hack.
> > 
> > I presume you meant to say that xrange is *not* a hack.  Well, hackiness
> 
> Please don't put words in my mouth, thanks.  xrange _IS_ a hack,

Perhaps English is not your first langauge?  When one says "Almost right,
except..." the implication is that you are disagreeing with something. 
But you didn't disagree, you parroted back exactly what I said, making it
not unreasonable to assume that you inadvertantly left out the word "not".

> it was introduced in Python back in the dark ages before Python had the
> iterator protocol.

But it's always the dark ages.  Any non-extensible langauge is going to be
missing some features, but that is usually not apparent until later.  The
difference between Python and Lisp is that when a user identifies a
missing feature in Lisp all they have to do is write a macro to implement
it, whereas in Python they have no choice but to wait for the next version
to come along.

> Now, clearly, _uniformity_ in the code will be to the advantage
> of the team and of the project it develops.

Yes.  But non-extensible languages like Python only enforce the appearance
of uniformity, they do not and cannot enforce true stylistic uniformity. 
As a result there are two kinds of code, the kind that fits naturally into
the style of the language, and the kind that doesn't and has to be
shoehorned in.  Of course, superficially both kinds of code sort of look
the same.  But underneath code of the second sort becomes a horrible mess.

> Here is the crux of our disagreement.  If you believe everybody can
> become a good language designer, I think the onus is on you to explain
> why most languages are not designed well.

Because most langauges are designed by people who have had very little
practice designing langauges.  And they've had very little practice
designing langauges because designing languages is perceived as a hard
thing to do.  And if you try to do it without the right tools it is in
fact a hard thing to do.  If you try to do it with the right tool (Lisp)
then it's very easy, you can do lots of iterations in a short period of
time, and gain a lot more experience about what works and what doesn't. 
That's why people who use Lisp tend to be good language designers, and
people who don't tend not to be.  It's also why every language feature
ever invented what invented in Lisp first.

> If I thought Python's design was badly done, and a bad fit for my
> problem domain, then, obviously, I would not have chosen Python (I
> hardly lack vast experience in many other programming languages,
> after all).  Isn't this totally obvious?

No, it's not.  You have taken a strong position against macros, which
means that if you ever encounter a problem domain that is not a good fit
for any language that you know then you have a problem.  I don't know how
you'd go about solving that problem, but I think that a likely outcome is
that you'd try to shoehorn it in to some language that you know (and maybe
not even realize that that is what you are doing).

> Therefore, clearly, your assertion that
> (to adopt Python) one has "to give up all hope" of such goals is not
> at all well-founded.  There is nothing intrinsic to Python that can
> justify it.

Actually, there is.  Python's dynamicism is so extreme that efficient
native code compilation is impossible unless you change the semantics of
the language.

> nuclear warheads

An inappropriate metaphor.

> >> while in Python, where iterators are "the other way around" (they
> >> get relevant items out rather than taking a code block in), it would be:
> >> 
> >>     for leaf in doleaves(tree):
> >>         ...
> > 
> > Forcing you to either waste a lot of memory or write some very awkward
> > code.
> 
> I _BEG_ your pardon...?

Oh, right, I forgot they added the "yield" thingy.  But Python didn't
always have yield, and before it had yield you were stuck.

I could come up with another example that can't be done with yield, but
your response will undoubtedly be, "Oh, that can be handled by feature FOO
which is going to be in Python 3.0" or some such thing.  The point is, a
Python programmer is dependent on Guido for these features.  Lisp
programmer's aren't dependent on anyone.

>>> class criticalsection(object):

All this does is demonstrate how destructors can be used to emulate
unwind-protect.  If you use this to implement crtical-section in the
obvious way you will find that your critical sections do not nest
properly.

> I have no idea of how with-maintained-condition would find and
> examine each of the steps in the body in this example; isn't
> the general issue quite equivalent to the halting problem, and
> thus presumably insoluble?

Only if the conditions you write are unconstrained.  But there is no
reason for them to be unconstrained.  The WITH-MAINTAINED-CONDITION macro
would presumably generate a compile-time error if you asked it to maintain
a condition that it didn't know how to handle.

> If your claim is that macros are only worthwhile for "artificial
> intelligence" code that is able, by perusing other code, to infer
> (and perhaps critique?) the physical world model it is trying to
> control, and modify the other code accordingly, I will not dispute
> that claim.

s/only/also/

> Ah, must be a mutation of the whitespace-eating nanovirus

No, auto-indent in emacs Python mode will generate indentation bugs.

> Whoa there.  I detect in this tirade a crucial unspoken assumption: that
> One Language is necessarily going to be all I ever learn, all I ever use,
> for "any programming domain I might ever choose to explore".

No, the issue is general.  If you concede that for any non-extensible
langauge there are things for which that language is not well suited, then
for any finite number of such languages there will be things for which
none of those languages are well suited.  At that point you only have two
choices: use an inappropriate language, or roll your own.  And if you
choose to roll your own the easiest way to do that is to start with Lisp.

Of course, the same reasoning that leads you to conclude that Lisp is good
for *something* also leads you inexorably to the conclusion that Lisp is
good for *anything*, since its extensibility extends (pardon the pun) to
everything, not just features that happen not to exist in other languages
at the time.

> There being no open-source, generally useful operating system kernels in
> any language but C

That is indeed unfortunate.  Perhaps some day the Lisp world will produce
its own Linus Torvalds.

> I think I have a reasonably deep understanding of "what programming is"

My last remarks weren't addressed to you in particular, but to anyone who
might be reading this dialog.  If you want (meaning if one wants) to gain
a deep understanding of how computers work, Lisp provides a better path
IMO.  (And Eric Raymond thinks so too.)

> I think macros (Lisp ones in particular) are a huge win in situations
> in which the ability to enrich / improve / change the language has more
> advantages than disadvantages.  So, I think they would be a great fit
> for languages which target just such situations, such as, definitely,
> Perl, and perhaps also Ruby; and a net loss for languages which rely on
> simplicity and uniformity, such as, definitely, Python.

That's not an unreasonable position.

E.