Yet another language comparison: Pliant and Python

[Warren Postma]

Pliant web page: http://pliant.cams.ehess.fr/pliant/

Sorry for possibly kicking off another "Python and $LOOK_MA_A_NEW_LANGUAGE"
discussion,
but Pliant appears quite interesting.

At first Pliant looks like a statically typed LISP-variant, but the subtle
bit is that this is all for show.  In reality it's Syntactic Sugar Gone
Wile. By default it uses an infix syntax, but also fluidly supports
Lisp-like parenthetical syntax.

The syntax of the language itself is modified by a first stage of
compilation. They call it "meta programming". You basically can extend the
grammar of the language during the first compilation phase.  That would make
an interesting set of syntax errors, if you manage to extend the grammar in
a way that breaks some basic language construct, or which breaks a whole
bunch of previously working code.

You can look at the default syntax and see it as LISP with lots of Classic
Infix Operators.  In fact, the syntax presented at the web page, is not
"THE" or "THE ONLY" Pliant syntax. The "PDEE" is the default environment,
not the language itself.

What a sticky web of choices is a language design. Take Pliant's default
literal representation for hexadecimal constants:

08BDh

Nice enough if the first digit is from 0-9, unfortunately it conflicts with
the grammar for variable names, if the Hex literal starts with A-F:

FF8Dh

So, to resolve this, you have to add a leading 0 to hex literals if the
first digit of the hex constant is not a value from 0 to 9:

0FF8Dh

Nice. This is just a trivial example of what I imagine building non-trivial
Pliant systems would involve: Several large subsystems, consisting of
thousands of lines of code, each with varied semantics and different sets of
extensions. How can Pliant be "compact" in the same way that I expect Python
to be?


Interesting and Noble Things:

After the first stage of compilation, I assume that a bytecode byproduct is
created that can be interpreted.  Then the bytecode can be passed through a
second phase allowing it to be compiled to something "faster than C" (a
dubious statement, since that would imply it bypasses C code output
entirely, and goes straight to generating assembly language, a difficult
task given the variety of backends already supported by gcc).

I think it's trying to be LISP meets EIFFEL, with an underlying hint of
Forth-like extensability.

It leads me to believe that surely Guido has seen the future, and it gives
the user the choice of writing dynamic or statically typed (or 'optimization
hinted') code in Python. This would mean any extension that could be written
in C could instead by written in Python, have static typing hints associated
with it later in it's design, and then be automagically compiled into a
binary module that runs without interpretation.  I would think there would
have to be some loss of introspection into the module [black box].  Is this
Python 3000?  That would be cool.

Warren