Python not a Very High-Level Language?

[Tim Peters]

[Tim]
> In any case, it's quite rare for any given language to evolve
> in really significant ways ... Fortran is ... an exception

[Neel Krishnaswami]
> As possible counterexamples, what about Lisp and C++?

No single version of Lisp ever had enough users for anyone to care, and to
this day 98% of Scheme users do nothing with the language except implement
compilers for their own Scheme variants <wink>.

C++ has certainly been a wild ride, although "the real C" continues to
evolve in conservative ways.

> Common Lisp is quite a different Lisp from basically all of
> the Lisps that preceded it (eg, it's lexically scoped rather
> than dynamically scoped). And on top of that it grew CLOS,
> which is (again) a pretty major change -- it was an backward-
> incompatible unification of the Common Loops and Flavors
< object systems.

Seriously, the Lisp family is unique in many respects.  IIRC, the addition
of CLOS to CL made it the first OO language with an ANSI std!  Lisp rarely
gets the credit it deserves.  Guido honored it by throwing away its syntax
<wink>.

>> Languages ... that should also be mined for inspiration are
>> Prolog, Dylan and SETL

> I know (and quite like) both Prolog and Dylan, but now you've
> given me another language to learn. Thanks!

The first validated Ada compiler was written in SETL -- and that's about all
anyone seems to remember it for these days.  I'm not sure you can even get a
viable implementation anymore.  amazon.com lists the primary book (which is
a good one!) as out of print:

    Programming With Sets: An Introduction to SETL
    (Texts and Monographs in Computer Science)
    Schwartz, Dewar, Dubinsky, Schonberg
    Spring-Verlag

The primary gimmick was, well, sets <wink>. "Even functions" were viewed as
sets of pairs, and high-level mathematical set notation (like construction
via abstraction, and nested existential & universal quantifiers) got
executed directly.  That integers "should be" unbounded was thought so
obvious that the book never even mentions that they are.  The Haskell folk
credit SETL for list comprehensions, and it even had built-in support for
non-deterministic programming (of the flavor Scheme would later model via
"arb").  Way ahead of its time -- heck, likely still ahead!  The Courant
Institute (SETL's home) did much pioneering work in high-level algorithm
transformation, motivated in part by the challenge of making 6 lines of SETL
run to completion before you died <wink>.

> And now a favor for you: have you heard of Mercury? It's kind
> of like a purely declarative Prolog with a higher-order type
> system designed along the lines of Haskell or ML.

I've never used it, but my time for learning new languages now is close to
zero.  It struck me as being Prolog on industrial-strength static
declarations, aiming more at "big system" integration, type safety and speed
than at raising the level of expressiveness.  Someone should tell them that
the "Hello, World!" of the tutorial does not leave a compellingly inviting
first impression <0.5 wink>:

<SNIP>

:- module hello_world.

:- interface.

:- import_module io.

:- pred main(io__state, io__state).
:- mode main(di, uo) is det.

:- implementation.

main -->
	io__write_string("Hello, World!\n").

</SNIP>

That's enough for me <wink>.

If you've got the time, investigate Oz/Mozart for us!

    http://www.mozart-oz.org/

If I had the time, that's the one I'd check out next, because it's the one
I'm most prejudiced against <no wink>:  it seeks to combine all of logic,
constraint-based, functional, and OO approaches on a highly concurrent
substrate.  When I picture those all together, I can only conjure up visions
of extreme pain; but browsing thru the intro material didn't hurt at all,
and someone here last year (Boris?) spoke highly of it.  If not truly
innovative, it's at least bold <wink>.

> Hm. Would a real metaobject protocol (as the offspring of
> type/class unification) count as major change [for Python]?

It would be a big change for the implementation, but not really to the
conceptual bases of the language.  The type/class split today is much more
an artifact of the initial implementation than a design choice.  Indeed,
part of the hangup in healing this split has been that there are so *many*
ways to do it that all "feel Pythonic" (and JPython has already healed it,
in a Java-like way, with some unfortunate hacks to make it behave more like
CPython).

> ...
> Yes. Smalltalk and Common Lisp are two of the most fun
> languages to program in, in large part due to the power
> of their interactive environments.

Almost as good as Model 100 BASIC!

missing-"power off, resume"-ly y'rs  - tim