Python syntax in Lisp and Scheme

[Greg Ewing (using news.cis.dfn.de)]

Re: Code block literals

Dave Benjamin wrote:[color=blue]
> In that case, why do we eschew code blocks, yet have no problem with the
> implicit invocation of an iterator,[/color]

I don't think code blocks per se are regarded as a bad thing.
The problem is that so far nobody has come up with an entirely
satisfactory way of fitting them into the Python syntax as
expressions.
[color=blue]
> What if I wrote:
>
> for byte in file('input.dat '):
> do_something_wi th(byte)
>
> That would be a bit misleading, no?[/color]

It certainly would! But I think the implicitness which is
tripping the reader up here lies in the semantics of the
file object when regarded as a sequence, not in the for-loop
construct. There is more than one plausible way that a file
could be iterated over -- it could be a sequence of bytes
or a sequence of lines. An arbitrary choice has been made
that it will (implicitly) be a sequence of lines. If this
example shows anything, it's that this was perhaps a bad
idea, and that it might have been better to make it explicit
by requiring, e.g.

for line in f.iterlines():
...

or

for byte in f.iterbytes():
...

then if you wrote

for byte in f.iterlines():
...

the mistake would stick out just as much as it does in
Ruby.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Pascal Costanza wrote:
[color=blue]
> Many programming languages require you to build a model upfront, on
> paper or at least in your head, and then write it down as source code.
> This is especially one of the downsides of OOP - you need to build a
> class hierarchy very early on without actually knowing if it is going to
> work in the long run.[/color]

Whoa! The MOP and CLOS went to a lot of trouble to create an OOP for
Lisp that lived up to the Lisp heritage of figuring things out as we go.
I am forever refactoring class hierarchies, dragging slots from here to
there, adding some, erasing others, changing initforms and inheritance.
Best of all I can do all this for a couple of hours after landing in a
backtrace and then simply pick an appropriate stack frame from which to
restart and all the existing instances adjust themselves on the fly.

kenny

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

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

[Erann Gat]

Re: Python syntax in Lisp and Scheme


In article <ue0ib.267972$R 32.8718052@news 2.tin.it>, Alex Martelli
<aleaxit@yahoo. com> wrote:
[color=blue]
> Let's start with that WITH-CONDITION-MAINTAINED example of Gat. Remember
> it? OK, now, since you don't appear to think it was an idiotic example,
> then SHOW me how it takes the code for the condition it is to maintain and
> the (obviously very complicated: starting a reactor, operating the reactor,
> stopping the reactor -- these three primitives in this sequence) program
> over which it is to maintain it, and how does it modify that code to ensure
> this purpose. Surely, given its perfectly general name, that macro does not
> contain, in itself, any model of the reactor; so it must somehow infer it
> (guess it?) from the innards of the code it's analyzing and modifying.[/color]

It is not necessary to exhibit a theory of how WITH-CONDITION-MAINTAINED
actually works to understand that if one had such a theory one can package
that theory for use more attractively as a macro than as a function. It
is not impossible to package up this functionality as a function, but it's
very awkward. Control constructs exist in programming languages for a
reason, despite the fact that none of them are really "necessary" . For
example, we can dispense with IF statements and replace them with a purely
functional IF construct that takes closures as arguments. Or we can do
things the Java way and create a new Conditional object or some such
thing. But it's more convenient to write an IF statement.

The claim that macros are useful is nothing more and nothing less than the
claim that the set of useful control constructs is not closed. You can
believe that or not. To me it is self-evidently true, but I don't know
how to convince someone that it's true who doesn't already believe it.
It's rather like arguing over whether the Standard Model of Physics covers
all the useful cases. There's no way to know until someone stumbles
across a useful case that the Standard Model doesn't cover.
[color=blue]
> For example, the fact that Gat himself says that if what I want to write
> are normal applications, macros are not for me: only for those who want
> to push the boundaries of the possible are they worthwhile. Do you think
> THAT is idiotic, or wise? Please explain either the reason of the drastic
> disagreements in your camp, or why most of you do keep trying pushing
> macros (and lisp in general) at those of us who are NOT particularly
> interested in "living on the edge" and running big risks for their own sake,
> accordingly to your answer to the preceding question, thanks.[/color]

I can't speak for anyone but myself of course, but IMO nothing worthwhile
is free of risks. I also think you overstate the magnitude of the risk.
You paint nightmare scenarios of people "changing the language"
willy-nilly in all sorts of divergent ways, but 1) in practice on a large
project people tend not to do that and 2) Lisp provides mechanisms for
isolating changes to the language and limiting the scope of their effect.
So while the possibility exists that someone will change the language in a
radical way, in practice this is not really a large risk. The risk of
memory corruption in C is vastly larger than the risk of "language
corruption" in Lisp, and most people seem to take that in stride.
[color=blue]
> ...and there's another who has just answered in the EXACTLY opposite
> way -- that OF COURSE macros can do more than HOF's. So, collectively
> speaking, you guys don't even KNOW whether those macros you love so
> much are really necessary to do other things than non-macro HOFs allow
> (qualification inserted to try to divert the silly objection, already made
> by others on your side, that macros _are_ functions), or just pretty things
> up a little bit.[/color]

But all any high level language does is "pretty things up a bit". There's
nothing you can do in any language that can't be done in machine
language. "Prettying things up a bit" is the whole point. Denigrating
"prettying things up a bit" is like denigrating cars because you can get
from here to there just as well by walking, and all the car does is "speed
things up a bit".

E.

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <29kib.206536$h E5.6945256@news 1.tin.it>, Alex Martelli
<aleaxit@yahoo. com> wrote:
[color=blue][color=green]
> > What makes you think that macros have farther reaching effects in this
> > regard than functions? If I call a method and pass it a function object,
> > I also don't know what the method will do with it.[/color]
>
> Of course not -- but it *cannot possibly* do what Gat's example of macros,
> WITH-MAINTAINED-CONDITION, is _claimed_ to do... "reason" about the
> condition it's meant to maintain (in his example a constraint on a variable
> named temperature), about the code over which it is to be maintained
> (three functions, or macros, that start, run, and stop the reactor),
> presumably infer from that code a model of how a reactor _works_, and
> rewrite the control code accordingly to ensure the condition _is_ in fact
> being maintained. A callable passed as a parameter is _atomic_ -- you
> call it zero or more times with arguments, and/or you store it somewhere
> for later calling, *THAT'S IT*. This is _trivially simple_ to document and
> reason about, compared to something that has the potential to dissect
> and alter the code it's passed to generate completely new one, most
> particularly when there are also implicit models of the physical world being
> inferred and reasoned about. Given that I've seen nobody say, for days!,
> that Gat's example was idiotic, as I had first I thought it might be, and
> on the contrary I've seen many endorse it, I use it now as the simplest
> way to show why macros are obviously claimed by their proponents to
> be _scarily_ more powerful than functions.[/color]

Why "scarily"?

E.

[Raffael Cavallaro]

Re: Python syntax in Lisp and Scheme

In article <m1d6d9njkr.fsf @tti5.uchicago. edu>,
Matthias Blume <find@my.addres s.elsewhere> wrote:
[color=blue]
> Most of the things that macros can do can be done with HOFs with just
> as little source code duplication as with macros.[/color]

Most, but not all. From <http://okmij.org/ftp/papers/Macros-talk.pdf>

"One sometimes hears that higher-order functions (and
related non-strictness) make macros unnecessary. For
example, In Haskell, 'if' is a regular function. However,
every language with more syntax than lambda-calculus
has phrases that are not expressions. Examples of such
second-class forms are: type, module, fixity and other
declarations; binding forms; statements. Only macros
can expand into a second-class object. The result of a
function is limited to an expression or a value."

[color=blue]
> (And with macros
> only the source code does not get duplicated, the same not being true
> for compiled code. With HOFs even executable code duplication is
> often avoided -- depending on compiler technology.)[/color]

So you're willing here to trade code size for readability. The pro-macro
camp (myself included) find that macros make source code easier to read
and write than the equivalent HOF solution. We're willing to trade that
ease of use for a little compiled code size, especially when this means
you can write your code in what amounts to a domain specific language.

[color=blue][color=green]
> > This can only be accomplished with functions if you're
> > willing to write a set of functions that defer evaluation, by, say
> > parsing input, massaging it appropriately, and then passing it to the
> > compiler. At that point, however, you've just written your own macro
> > system, and invoked Greenspun's 10th Law.[/color]
>
> This is false. Writing your own macro expander is not necessary for
> getting the effect. The only thing that macros give you in this
> regard is the ability to hide the lambda-suspensions.[/color]

But this hiding of the lambda-suspensions is the whole point. Why look
at how the code works unless you have to? Why not work in a syntax, a
domain specific language, that matches the problem? Put the complexity
into one place (the macro) and make the rest of the code easier to
write, and clearer to read.

For me, macros are about making the code one writes match the problem
one is thinking about. HOFs seem to me to be about looking cleverly
functional, not making the code look like the problem domain.

[Greg Ewing (using news.cis.dfn.de)]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:[color=blue]
> Besides,
> "if you want PL/I you know where to find it" has nice precedents (in
> the only other language which was widely successful in the real world
> while adhering to "provide only one way to perform an operation" as
> one of its guiding principles -- not perfectly, but, close enough:-).[/color]

Pardon? Wasn't PL/I the language that had two wildly different
syntaxes for declaring variables, one bearing a close resemblance
to Fortran, and the other looking suspiciously like Cobol?
(All right, two... there are *two* ways to do it...)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Bengt Richter]

Re: Code block literals

On Fri, 10 Oct 2003 16:28:11 GMT, Alex Martelli <aleax@aleax.it > wrote:
[color=blue]
>Bengt Richter wrote:
> ...[color=green]
>> This way lambda would only be needed for backwards compatibility, and
>> since "def(" is a syntax error now, IWT it could be introduced cleanly.[/color]
>
>In theory, yes, I think it could (and wrt my similar idea with 'do' has
>the advantage of not requiring a new keyword). In practice, trying to
>hack the syntax to allow it seems a little nightmare. Wanna try your
>hand at it? I'm thinking of Grammar/Grammar and Modules/parsermodule.c ...
>[/color]
Also tokenizer.c, so as not to ignore indentation when tokenizing a nameless
def inside a bracketed expression where (in|de)dents are otherwise ignored.

The thing is, the current tokenizer doesn't know def from foo, just that they're
names. So either indenting has to be generated all the time, and the job of
ignoring it passed on upwards, or the single keyword 'def' could be recognized
by the parser in a bracketed context, and it would generate a synthetic indent token
in front of the def name token as wide as if all spaces preceded the def, and then
continue doing indent/dedent generation like for a normal def, until the def suite closed,
at which point it would resume ordinary expression processing (if it was within brackets --
otherwise is would just be a discarded expression evaluated in statement context, and
in/de/dent processing would be on anyway. (This is speculative until really getting into it ;-)
Special-casing on a keyword in the tokenizer might be a practical implementation shortcut,
but it wouldn't be very aesthetic ;-/

IWT changes also in the compiler/code generator so it can handle generating code
for an anonymous def which will plug in like lambda in an expression, as
opposed to binding a name in a statement context, hopefully a slight change,
since it would be stacking a code object and calling makefunction either way.
The anonymous def just won't do the store to bind a name. Generating the code
object for the nameless def should be identical to the normal def IWT,
almost by definition ;-)

But the whole thing will be a bit of a chore I'm sure ;-)
Would it have a chance of getting adopted, do you think?

(Recent [cross]postings from the friendly :-)))) people got me to
playing with writing a little toy scheme environment in python, which is sooo
pleasant compared to using MASM on a 16-mhz 386 with 2mb ram (whoo, time flies).

Regards,
Bengt Richter

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue][color=green]
>> What makes you think that macros have farther reaching effects in this
>> regard than functions? If I call a method and pass it a function object,
>> I also don't know what the method will do with it.[/color]
>
> Of course not -- but it *cannot possibly* do what Gat's example of macros,
> WITH-MAINTAINED-CONDITION, is _claimed_ to do... "reason" about the
> condition it's meant to maintain (in his example a constraint on a
> variable named temperature), about the code over which it is to be
> maintained (three functions, or macros, that start, run, and stop the
> reactor), presumably infer from that code a model of how a reactor
> _works_, and rewrite the control code accordingly to ensure the condition
> _is_ in fact
> being maintained. A callable passed as a parameter is _atomic_ -- you
> call it zero or more times with arguments, and/or you store it somewhere
> for later calling, *THAT'S IT*. This is _trivially simple_ to document
> and reason about, compared to something that has the potential to dissect
> and alter the code it's passed to generate completely new one, most
> particularly when there are also implicit models of the physical world
> being
> inferred and reasoned about.[/color]

Don't fear code that rewrites code. Hell, if Psycho didn't exist (or if I
didn't think it did a good enough job), I'd sure like to say:

optimized:
for x in range(2**63):
pass

and let an 'optimized' special form rewrite my code into just "pass".

Or maybe I don't want to manually delete unexported functions in my modules:

clean_module exporting [a, b, d]
and exporting_from {some.module:[fun1,fun2]}:
import some.module
def a(): pass
def b(): pass
def c(): pass
def c(): pass

becomes:

import some.module
def a(): pass
def b(): pass
def c(): pass
def d(): pass
fun1 = some.module.fun 1
fun2 = some.module.fun 2
del c

Or cleanly write code using another module's namespace:

using_module some.module:
print x, some.other.modu le.y
using_module __main__:
print x

In this case using_module inspects the code and rewrites it, leaving all
qualified identifiers untouched but modifying the global references, so the
example becomes:

print some.module.x, some.other.modu le.y
print x

Is that so dangerous?
[color=blue]
> Without macros, when you see you want to design a special-purpose
> language you are motivated to put it OUTSIDE your primary language,
> and design it WITH its intended users, FOR its intended purposes, which
> may well have nothing at all to do with programming. You parse it with a
> parser (trivial these days, trivial a quarter of a century ago), and off
> you
> go.[/color]

Hmm, but isn't every program a language?

http://blogs.gotdotnet.com/emeijer/PermaLink.aspx

ea13a4da-7421-44af-99e8-fc86de84e29c

Guy Steele agrees:

http://java.sun.com/features/2003/05/steele_qa.html

////////////////////
Q: You have written that "a language design can no longer be a thing. It
must be a pattern -- a pattern for growth - a pattern for growing the
pattern for defining the patterns that programmers can use for their real
work and their main goal." You said that a good programmer does not just
write programs, but engages in language design, building on the frame of a
base language. Could you elaborate on this?

A: Sure. Every time you write a new function, a new method, and give it a
name, you have invented a new word. If you write a library for a new
application area, then the methods in that library are a collection of
related words, a new technical jargon for that application domain. Look at
the Collection API: it adds new words (or new meanings for words) such as
"add", "remove", "contains", "Set", "List", and "LinkedHashSet" . With that
API added to Java, you have a bigger vocabulary, a richer set of concepts
to work with.

Some concepts are more powerful, more general, more widely used than others
-- "liberty" and "mortgage" are more widely used than "belly button ring"
or "faucet wrench". But every new word, every new meaning, every new idiom
enriches the language.
////////////////////////


But talk is cheap. Maybe my next project should be a Python preprocessor :)

- Daniel

[Rayiner Hashem]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

> From that point of view, "car" and "cdr" are as good[color=blue]
> as anything![/color]
Well, if you're going to call the thing a 'cons' you might as well go
all the way and use 'car' and 'cdr' as operators. A little flavor is
nice, although I think that "4th" would be easier to read than
"cadddr"...

[Pascal Costanza]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

Rayiner Hashem wrote:[color=blue][color=green]
>> From that point of view, "car" and "cdr" are as good
>>as anything![/color]
>
> Well, if you're going to call the thing a 'cons' you might as well go
> all the way and use 'car' and 'cdr' as operators. A little flavor is
> nice, although I think that "4th" would be easier to read than
> "cadddr"...[/color]

....but cadddr might not be "fourth". It might be some leaf in a tree. Or
something completely different. "fourth" doesn't always make sense.

(And just for the sake of completeness, Common Lisp does have FOURTH and
also (NTH 3 ...).)

Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Kenny Tilton]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)



Pascal Costanza wrote:
[color=blue]
> Rayiner Hashem wrote:
>[color=green][color=darkred]
>>> From that point of view, "car" and "cdr" are as good
>>> as anything![/color]
>>
>>
>> Well, if you're going to call the thing a 'cons' you might as well go
>> all the way and use 'car' and 'cdr' as operators. A little flavor is
>> nice, although I think that "4th" would be easier to read than
>> "cadddr"...[/color]
>
>
> ...but cadddr might not be "fourth". It might be some leaf in a tree. Or
> something completely different. "fourth" doesn't always make sense.
>
> (And just for the sake of completeness, Common Lisp does have FOURTH and
> also (NTH 3 ...).)
>[/color]

And it maxes out at ten:

http://www.lispworks.com/reference/HyperSpec/Body/f_firstc.htm#tenth

Doesn't seem right for a language that goes to eleven.*

:)

kenny

* That's one more, isn't it?

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

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

[John Roth]

Re: Code block literals


"Greg Ewing (using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote in
message news:bmd3cv$lk5 1t$1@ID-169208.news.uni-berlin.de...[color=blue]
> Dave Benjamin wrote:[color=green]
> > In that case, why do we eschew code blocks, yet have no problem with the
> > implicit invocation of an iterator,[/color]
>
> I don't think code blocks per se are regarded as a bad thing.
> The problem is that so far nobody has come up with an entirely
> satisfactory way of fitting them into the Python syntax as
> expressions.[/color]

I know. I played around with the idea a bit after it came up a couple
of weeks ago, and identified a number of issues.

1. One code block, or a code block for any parameter?
This isn't as simple as it seems. Ruby does one code block
that is an implicit parameter to any method call, but in
Smalltalk any method parameter can be a code block.

2. How do you invoke a code block? Does it look just like
a function? I presume so. If you do one code block per
method call, though, it gets a bit sticky. Again, Ruby
uses a special keyword ('yield') to invoke such a code
block, while if code blocks were simply anon functions,
then it's a non-issue.

3. Expression or statement syntax? Ruby avoids the
problem by making its single code block a special
construct that immediately follows the method
call parameter list, and it doesn't have the chasm
between expression and statement syntax that's built
into Python.

4. Do we want it to be smoothly substitutable for
lambda? I presume so, simply based on the principle
of minimum surprise. Then that forces multiple
code blocks in a method, which in turn reduces
a lot of other issues.

5. Is uglyness really an issue? One of the major
discussion points (read: flame war issues) any time
expanding expression syntax comes up is that
expressions that are too long become unreadable
very rapidly.

So what I come up with at this point is twofold:

1. We need to be able to insert a code block in
any parameter, and

2. Code blocks need to have statement syntax.

So let's say I want to use a code block instead of
a lambda or a named function in a map:

foobar = map(def (x, y, z):
astatement
anotherstatemen t
list1, list2, list3)

This doesn't actually look anywhere near as bad
as I thought it might. The indentation, though, is a
bit peculiar. The first point is that the statements
in the code block are indented with respect to the
enclosing statement, NOT with respect to the first
word ('def') that starts the code block.

The second point is that the continuation of the
embedding expression has to dedent to close the
code block without closing the embedding statement,
and this has to be visually identifiable.

A third item is that I don't really care if we use 'def'
or not. Borrowing the vertical bar from Ruby, the map
example becomes:

foobar = map(| x, y, z |
astatement
anotherstatemen t
list1, list2, list3)

I kind of like this better, except for one really unfortunate
issue: it's going to raise havoc with code coloring algorithms
for a while.

John Roth
[color=blue]
>
> --
> Greg Ewing, Computer Science Dept,
> University of Canterbury,
> Christchurch, New Zealand
> http://www.cosc.canterbury.ac.nz/~greg
>[/color]

[Marcin 'Qrczak' Kowalczyk]

Re: Python syntax in Lisp and Scheme

On Mon, 13 Oct 2003 03:19:11 +0000, Raffael Cavallaro wrote:
[color=blue]
> Most, but not all. From <http://okmij.org/ftp/papers/Macros-talk.pdf>
>
> "One sometimes hears that higher-order functions (and
> related non-strictness) make macros unnecessary. For
> example, In Haskell, 'if' is a regular function.[/color]

It's not. It could easily be a regular function which would look like
'if condition branch1 branch2' and behave exactly the same (arguments
would often have to be parenthesized), but it's a keyword with the syntax
'if condition then branch1 else branch2' (condition and branches don't
have to be parenthesized because of 'then' and 'else' delimiters).
OTOH && and || are regular functions.
[color=blue]
> So you're willing here to trade code size for readability. The pro-macro
> camp (myself included) find that macros make source code easier to read
> and write than the equivalent HOF solution. We're willing to trade that
> ease of use for a little compiled code size, especially when this means
> you can write your code in what amounts to a domain specific language.[/color]

Note that Lisp and Scheme have a quite unpleasant anonymous function
syntax, which induces a stronger tension to macros than in e.g. Ruby or
Haskell.

In Haskell one often passes around monadic actions instead of anonymous
nullary functions, so it's not only the lambda syntax. Putting such action
in a function argument doesn't make it run. Laziness also reduces the
number of anonymous functions. Partial application doesn't require lambda,
binary operators can be partially applied on either argument. The 'do'
notation and list comprehensions are another case where other languages
would use anonymous functions. Yes, they are built in the language rather
than library features - but with all these things only few anonymous
functions remain and thus they are not so scary.

I happen to be in the other camp. Macros indeed make it easier to embed a
domain-specific language, OTOH they require the rest of the syntax to be
more regular than pretty (so they can examine code) and they make the
language and its implementations complicated. Just a tradeoff...

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Stephen Horne]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

On Mon, 13 Oct 2003 15:28:57 +1300, "Greg Ewing (using
news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote:
[color=blue]
>Andrew Dalke wrote:[color=green]
>> It has sometimes been said that Lisp should use first and
>> rest instead of car and cdr[/color]
>
>I used to think something like that would be more logical, too.
>Until one day it occurred to me that building lists is only
>one possible, albeit common, use for cons cells. A cons cell
>is actually a completely general-purpose two-element data
>structure, and as such its accessors should have names that
>don't come with any preconceived semantic connotations.
>
> From that point of view, "car" and "cdr" are as good
>as anything![/color]

"left" and "right" - referring to 'subtrees'?


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Pascal Costanza]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

Stephen Horne wrote:[color=blue]
> On Mon, 13 Oct 2003 15:28:57 +1300, "Greg Ewing (using
> news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote:
>
>[color=green]
>>Andrew Dalke wrote:
>>[color=darkred]
>>> It has sometimes been said that Lisp should use first and
>>> rest instead of car and cdr[/color]
>>
>>I used to think something like that would be more logical, too.
>>Until one day it occurred to me that building lists is only
>>one possible, albeit common, use for cons cells. A cons cell
>>is actually a completely general-purpose two-element data
>>structure, and as such its accessors should have names that
>>don't come with any preconceived semantic connotations.
>>
>>From that point of view, "car" and "cdr" are as good
>>as anything![/color]
>
>
> "left" and "right" - referring to 'subtrees'?[/color]

Sure, why not?

(defun left (tree)
(car tree))

(defun right (tree)
(cdr tree))


;-)

Note: Why break anyone else's code just because you prefer a different
vocabulary?

(Yes, this is different from the Python mindset. What I have learnt from
this thread is that the languages might seem similar on the technical
level, but the "social" goals of the languages are vastly different.)


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)