Re: Pliant

[Gordon Matzigkeit <gord@trick.fig.org>]

>>>>> Ian Bicking writes:

 IB> I guess I don't see what's more syntax-independent about Pliant
 IB> than Scheme.  The Scheme syntax is almost identicle to a parse
 IB> tree, the lowest common denominator of syntax.

I'm not claiming that it's any more syntax-independent, only that it
has a more advanced compiler/interpreter/type system.  It still lacks
a GC (although a GC may be unnecessary, since Pliant has convenient
refcounting).

 IB> All languages have an internal representation -- a parse tree,
 IB> Java bytecodes, machine code, strings, or in Scheme's case, lists
 IB> and symbols (this may not be the case with every Scheme
 IB> implementation, but they hide that fact).  Why is Pliant's
 IB> internal representation more neutral than Scheme's?

Don't confuse languages with implementations.  Scheme has no `internal
representation' per se.  All I know is that Pliant's implementation is
tight, can be aggressively optimized, and is far more elegant than
SCM.  Pliant has capabilities for multiple levels of internal
representations, rather than just choosing one and making it the
default: one can compile to bytecodes (not yet), assembler, C (in
progress), all without changing the input sources, and any one of
those can be done at runtime.

I don't mean any disrespect to SCM: it was a good base for Guile, and
will continue to be that for a while.  All I'm saying is that if
anybody is considering revamping Guile's base, there's a ready-made
framework that looks extremely mature from my point of view.

 IB> And from what I can see from the website, Pliant seems to
 IB> emphasize efficiency a great deal -- I don't think Guile shares
 IB> this emphasis, it is meant as a compliment to more efficient
 IB> languages (like C).  Pliant seems to have a quite heavy compiling
 IB> phase.

That's why I'm saying that Guile and Pliant can complement one another.

 IB> So, while Pliant looks interesting I don't think it is trying to
 IB> do the same thing as Guile.

I agree.  That's all I'm trying to point out to the Guile folks:
``take a look at Pliant; this is not a competitor, this is a chance
for a fantastic mutual exchange between two GPLed projects.''

Pliant has already got the framework for features that are being
contemplated for Guile (but aren't fully implemented, much less
robust), such as a generic object system, more efficiency, compiling
to native code, etc (I don't know Guile *that* well).

Guile has the user base, and real-world applications.  They both have
the same basic goal: make life easier for programmers, and their
approaches are not in conflict.

As to your comments about debugging, I encourage you to read the
documents on error handling.  Pliant's low-level error mechanisms can
implement all sorts of crazy things like throw and catch.

The only significant shortcoming that I see right now is the absence
of something like call/cc, but I would need to talk with the author to
ask how he would implement it.

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)