do...until wisdom needed...

Andrew Dalke dalke at
Mon May 7 11:53:52 CEST 2001

>> I was under the impression that OO programming grew out of Simula-67.

Douglas Alan wrote:
>It grew out of Simula-67 too.  The first true OO language was
>Smalltalk, which grew out of Lisp and Simula-67, and was invented in
>the '70's.  OO made it's way back into Lisp in about two hours (okay
>slight exaggeration, but not by much) after the invention of
>Smalltalk.  This happened so quickly due, in part, to Lisp's
>extensible syntax.

As you yourself pointed out, its introduction into Lisp at the
time doesn't mean anyone used it.  For example, take a look
at's history page where it mentiones the differences
between emacs event message data structure and xemacs's OO

Umm, actually from :
) I don't think you'll find much anybody involved in the Lisp
) world (apart from those with their tastes set in concrete
) circa 1972) who believe that the ad-hoc mess of "vectors of
) length 259 of lists whose first element is the symbol `indirect'
) and whose tail is an alist of conses whose ..." is any
) substitute for actual structure objects (of varous degrees
) of opacity.)

  That date of 1972 is highly curious, but I think it's
a coincidence.  Emacs Lisp wasn't started until at least 4
years later, according to

So I take that to mean the infusion of OO programming into
Lisp did not make strong headway until years after Smalltalk
came out.

>Just because some people were using OO, doesn't mean it had "caught
>on" in any serious way.  I was doing OO in Lisp in 1980, but finding a
>job doing that would have been something of a challenge.

What does "caught on" mean, then?  I interpreted it as "people
knew that that was the paradigm they had to learn, I had
written some objects (in Pascal), people were graduating from
school to start jobs doing OO programming, and text books were
coming out targeted towards C++."  I bought the 2nd ed. of the
C++ programming language book in 1991 and by 1993 I was working
on OO code that was already several years old.  Perhaps I'm
more cutting edge than I thought.

Sill, that's a much stronger "caught on" compared to your
statement that OO programming caught on in Lisp roughly two
hours after Smalltalk-72 came out.

>> My apologies for using a loaded word there.  I meant something that
>> was the equivalent to "widely used languages" "other than Lisp"
>> (which you include as a widely used language even though it "only
>> really ever caught on in AI circles and for teaching programming").
>> All quotes yours.
>Lisp *is* widely used for AI.  In fact, the vast majority of AI is
>done in Lisp.  And Scheme *is* widely used for teaching Computer

I never denied that.  I just regard AI and teaching languages
as small domains compared compared to everything else which goes
on in the world of programming.

> If you want to see how popular macros are, you need look no
>farther than C.  I don't think many C programmers would want to give
>up the macro mechanism.

Okay, that's a good point.  But doesn't that then reflect more
poorly on C?  I've created some heineous C macros but I've
never felt the need to do the same tricks in Python, because
I can getattr, I can define functions on the fly and I can
even (in rare cases) do an eval of string.  I don't think I've
ever bemoaned the lack of a cpp or m4 for Python.

>These are
>not fundamental limitations of macro mechanisms in general -- just C's
>lame instantiation.

So we agree :)  But I still haven't needed those macro tricks
in Python that I've needed in C.

>> Could you give an example of the Dylan syntax for doing macros?
>> Perhaps this would help with my mental block in understanding how it
>> could/should be applied to Python.
>     define macro unless
>       { unless ?test:expression ?:body }
>         => { if (~?test) ?body }
>     end macro;

Ahh!  Now I know why there was a mental block.  In my programming
languages book ("Principles of Programming Languages" by Bruce
MacLennam, (c) 1987) there's a section called "Return to
Simplicity" where it talks about extensible languages.  (All
typos mine.)

] As a result, PL/I has become the classic example of a "Swiss
] army knife" approach...  The result is inevitably a langauge so
] large as to be unmanageable.
] Many programming language designers believed that it was
] futile to design a language that was all things to all programmers.
] ... Rather, these designers believe that a more effective approach
] was to have a closely knit family of application-oriented
] languages. .. It was necessary to develop ... the extensible
] language approach; the idea that one is given a simple,
] application independent kernel, or base, language and an
] extension mechanism that allows the kernel langauge to be
] extended into various application areas.  Early examples of
] extensible languages are the MAD language and McIlroy's
] "syntax macros".
] For example, if a programmer wanted to use 'x # y' for the
] symmetric difference between two real numbers, a typical
] operator definition would be:
] operator 2 x # y; value x, y; real x, y;
]   begin
]     return abs(x-y)
]   end;
] Other languages went much further by providing syntax macros
] that allowed the programmer to introduce new syntax into the
] programming language.  For example, a summation notation might
] be defined:
]  real syntax sum from i = lb to ub of elem;
]    value lb, ub;
]    integer i, lb, ub; real elem;
]    begin real s; s:=0;
]     for i=lb step 1 until ub do
]       s := s + elem;
]     return s
]    end;
] [...] This defintion allows the programmer to write statements
] such as
]    Total := sum from k = 1 to N of Wages[k];
] instead of the usual
]    Total := sum(k, l, N, Wages[k]);
] The intention was that programmers could use the notation
] common to their application areas.
]  Unfortunately, extensibility usually resulted in very
]  inefficient languages. ... compilers large and unreliable ...
]  minor inefficiencies in the kernsl implementation became
]  magnified at the application language level
] poor diagnostics ... most diagnostics were issued in terms
] of kernel language constructs.  This was, of course, confusing
] for a user working at the application language level.
]   These problems, and others, ultimately defeated extensible
] languages.  Although they were once the most active area of
] programming language research, they are now rarely discussed.
] This does not imply that all of their ideas have been
] abandonded; we will see that the idea of extensible data
] types has been incorporated into Pascal and its successors
] and that a limited form of operator extension is provided
] by Ada.

(Huh, and Lisp not mentioned at all.)

So what I think happened was that this judgement (true or
not) stuck with me enough to make me not think about this
topic.  Indeed, I remember now thinking deeply about this
section when it came up and trying to judge for my self if
I thought it was correct.

It raises some strong points which you need to address - how
complicated is the implementation, how fast is the resulting
code, how easy is it to understand, how easy is it to debug?
Oh, and how well do support tools (editors, debuggers, pretty
printers) integrate with syntax macros?

You assert it's not a problem.  In response I've given my
judgement (that it is) the views of others (that it is) and
references from the literature (that it is).

Proving otherwise then becomes that much more complicated,
which explains at least some of the resistance you've seen
from me and others.

                    dalke at

More information about the Python-list mailing list