Thread overview
Pliant Language
May 02, 2003
Mark Evans
May 02, 2003
Bill Cox
May 03, 2003
Mark Evans
May 03, 2003
Sean L. Palmer
OT: Re: Pliant Language
May 04, 2003
Bill Cox
May 04, 2003
Mark Evans
Re: Pliant Language
May 05, 2003
Sean L. Palmer
May 03, 2003
Mark T
May 04, 2003
Walter
May 02, 2003
Found via Google search on "compiled language" + "fast as C"; GPL license. http://pliant.cx/pliant/welcome/design.html http://www.advogato.org/person/pliant/

Compare to Lush from Bell Labs of roughly similar age. http://lush.sourceforge.net/credits.html

Author's claim (spelling-corrected):
http://www.advogato.org/article/258.html
"Pliant is just as fast as C, so you won't have to switch to another language,
with the extra inferfacing problems, to get full speed in speed critical areas.
With Pliant, you can adjust the programming level in each function, with
infinite set of potential levels. It's not only a rough binary matter of writing
in the high level language or switching to the dirty low level language. They
are plenty of things in the middle that better match most cases, but since with
Pliant you can get all these within a single syntax, and a single programming
language, you can truly select the right level for each part of your code."



May 02, 2003
Pliant looks pretty cool.  IMO, for marketing reasons, it should have used C-like syntax.  The code looks pretty ugly to my C-trained eye.  It also seems to come with much more than a language.  There's a Pliant OS.  That seems like a lot for a new language effort to take on.

One of the main points behind Pliant seems to be extendability.  Users are encouraged to write meta programs that add application specific features to the language.  As they say, if C were extendable, then C++ would be a library.  I think I'll check it out a bit further.

Bill

Mark Evans wrote:
> Found via Google search on "compiled language" + "fast as C"; GPL license.
> http://pliant.cx/pliant/welcome/design.html
> http://www.advogato.org/person/pliant/
> 
> Compare to Lush from Bell Labs of roughly similar age.
> http://lush.sourceforge.net/credits.html
> 
> Author's claim (spelling-corrected):
> http://www.advogato.org/article/258.html
> "Pliant is just as fast as C, so you won't have to switch to another language,
> with the extra inferfacing problems, to get full speed in speed critical areas.
> With Pliant, you can adjust the programming level in each function, with
> infinite set of potential levels. It's not only a rough binary matter of writing
> in the high level language or switching to the dirty low level language. They
> are plenty of things in the middle that better match most cases, but since with
> Pliant you can get all these within a single syntax, and a single programming
> language, you can truly select the right level for each part of your code."
> 
> 
> 

May 03, 2003
Bill Cox wrote,
>Pliant looks pretty cool [but] should have used C-like syntax.

You can change it: http://pliant.cx/pliant/language/parser/default_syntax.html


>if C were extendable, then C++ would be a library.

Which I guess is your "HackC" project on Sourceforge, something I had not heard of before.  For those interested, http://pliant.cx/pliant/browse/forum/pliant.question/0369K74/ http://hackc.sourceforge.net/

Mark


May 03, 2003
Very interesting.

It's closer to what I envision as a good language than most others I've seen recently.

Sean


"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b8ua7t$2cdc$1@digitaldaemon.com...
>
> Found via Google search on "compiled language" + "fast as C"; GPL license. http://pliant.cx/pliant/welcome/design.html http://www.advogato.org/person/pliant/
>
> Compare to Lush from Bell Labs of roughly similar age. http://lush.sourceforge.net/credits.html
>
> Author's claim (spelling-corrected):
> http://www.advogato.org/article/258.html
> "Pliant is just as fast as C, so you won't have to switch to another
language,
> with the extra inferfacing problems, to get full speed in speed critical
areas.
> With Pliant, you can adjust the programming level in each function, with infinite set of potential levels. It's not only a rough binary matter of
writing
> in the high level language or switching to the dirty low level language.
They
> are plenty of things in the middle that better match most cases, but since
with
> Pliant you can get all these within a single syntax, and a single
programming
> language, you can truly select the right level for each part of your
code."


May 03, 2003
interesting material for language lovers like me, BUT
you should prefix your post subject with OT (off topic) since this post does not
request/discuss a new feature or discuss anything else directly related to the D
language.
Obviously, Walter has chosen a C like syntax and that is probably not going to
change anytime soon. The language is becoming quite mature and it would be nice
to focus on D in this forum.  These would be great posts in comp.lang.misc .


May 04, 2003
I've read through a bit more of Pliant's documentation, and installed the tools.

On the positive side, the tools worked as advertised.  I can bring up an HTML server, and compile Pliant applications.  Applications are compiled on my machine at run-time, or pre-compiled if I ask for it.

The language seems to be another ML derived language, such as Ocaml. The closest thing I've read about would have to be XL.  The primary developers seem to be French.  They clearly need a native English speaker translating their web pages.  The English documentation is almost as error-prone as something I would write.

On the whole, it looks promising.  I find their syntax extension mechanism crude, but I'm somewhat biased towards Lex and Yacc based parsers.  They parse a line at a time, and provide hooks for matching tokens along the way.  They've really opened up the compiler for hacking in new features.  That seems to be inevitable in langauges designed to be highly extendable.  Forth was such a system.

I wish we could figure out a way to get this kind of power without exposing so much compiler dependent detail.  It seems to be a Catch-22 kind of problem.

Bill

Sean L. Palmer wrote:
> Very interesting.
> 
> It's closer to what I envision as a good language than most others I've seen
> recently.
> 
> Sean
> 
> 
> "Mark Evans" <Mark_member@pathlink.com> wrote in message
> news:b8ua7t$2cdc$1@digitaldaemon.com...
> 
>>Found via Google search on "compiled language" + "fast as C"; GPL license.
>>http://pliant.cx/pliant/welcome/design.html
>>http://www.advogato.org/person/pliant/
>>
>>Compare to Lush from Bell Labs of roughly similar age.
>>http://lush.sourceforge.net/credits.html
>>
>>Author's claim (spelling-corrected):
>>http://www.advogato.org/article/258.html
>>"Pliant is just as fast as C, so you won't have to switch to another
> 
> language,
> 
>>with the extra inferfacing problems, to get full speed in speed critical
> 
> areas.
> 
>>With Pliant, you can adjust the programming level in each function, with
>>infinite set of potential levels. It's not only a rough binary matter of
> 
> writing
> 
>>in the high level language or switching to the dirty low level language.
> 
> They
> 
>>are plenty of things in the middle that better match most cases, but since
> 
> with
> 
>>Pliant you can get all these within a single syntax, and a single
> 
> programming
> 
>>language, you can truly select the right level for each part of your
> 
> code."
> 
> 

May 04, 2003
Bill Cox says...
>The language seems to be another ML derived language
No, Lisp.


>The closest thing I've read about would have to be XL.
For language extensibility, sure:
http://mozart-dev.sourceforge.net/cp-vs-lisp.html
"Of all existing programming languages, Lisp might be one of the closest to the
ideal."

Stratego also comes to mind:
http://www.stratego-language.org/twiki/bin/view/Stratego/StrategoLanguage
Compare statements 1 and 2:
(1) Pliant:  "The key to the reflective system is in symbolic rewriting of
expressions as semantic graphs (as in LISP) rather than as character strings."
http://fare.tunes.org/tmp/Pliant/aspic2000report.html
(2) Stratego:  "A program is a structured object with semantics. The structure
allows us to transform a program. The semantics gives us the means to compare
programs and to reason about the validity of transformations."
http://www.program-transformation.org/twiki/bin/view/Transform/ProgramTransformation



>I find their syntax extension mechanism crude
It would be hard to ask for a more.  For instance, "if you like the C++ template
notion, go on, write a pliant 'template' function that does the same."
http://pliant.cx/pliant/language/compiler/tutorial/samples.html
I suppose if you have improvements to offer then you should let them know.



> I'm somewhat biased towards Lex and Yacc based parsers
Well, Stratego uses them. http://www.stratego-language.org/twiki/bin/view/Stratego/StrategoCompiler


>I wish we could figure out a way to get this kind of power
Ah but we're in the off-topic area. To get back inside, maybe we should talk about something relevant like software management. ;-)


Some language concepts floated on D news have been tarred as maximalist.  In this instance I think Bill is going maximalist.  I favor only limited and controlled introspection.  If I needed "this kind of power" with D, then I would use Stratego to create or modify D programs.

What intrigues me about Pliant is not code generation (Bill's focus), but the attempt at wide expressivity without performance loss. "The key idea about Pliant design is that is an attempt to bring as much as possible extra expression power (high level programming) without impacting low level efficiency."  At the low end, "the inline assembly is standard, and you can even define new assembly instructions." http://pliant.cx/pliantdocs/babel/universal/pliant/welcome/whatisit.html

Pliant takes an extreme approach.  For D I don't think transparent symbol tables, fully customizable syntax, or runtime code generation is necessary or desirable; just more attention to expressiveness.  For instance dismissing functional style as 'weird,' or equating expressiveness with sluggishness, is mistaken.  Pliant may at least refute the zero-sum fallacy.  Note that XL and Lush also claim C speeds.

The idea of posting languages to D is that each one represents a particular design point with a banquet of features.  Unlike hypothetical discussions, languages come with implementations one can actually test drive.  That's a huge difference.  Languages are not off topic at all.

Regards
Mark

P.S. Bill, talk to this guy?
http://fare.tunes.org/tmp/Pliant/aspic2000report.html
"POM explained that the CAMS was planning to use Pliant as the language for
reimplementing their graph manipulation tools. A true object implementation of
these tools would lead to a huge horror of C++ mess that grew exponentially in
complexity with the number of independent graph properties studied and hence,
the actual C++ version is loosely object oriented and has to check properties at
run-time, whereas reflection would allow an efficient true object programmation
in Pliant (of complexity linear in terms of the number of independent
properties)."


May 04, 2003
"Mark T" <Mark_member@pathlink.com> wrote in message news:b905rk$195q$1@digitaldaemon.com...
> interesting material for language lovers like me, BUT
> you should prefix your post subject with OT (off topic) since this post
does not
> request/discuss a new feature or discuss anything else directly related to
the D
> language.
> Obviously, Walter has chosen a C like syntax and that is probably not
going to
> change anytime soon. The language is becoming quite mature and it would be
nice
> to focus on D in this forum.  These would be great posts in comp.lang.misc
.

I enjoy the discussions of other languages here. Since D is young, it will inevitably be compared with other languages rather than with itself. So I think such discussions are on topic.


May 05, 2003
Systems written in these languages tend to drift toward the kernel, then up to high-level land;  there is no hard distinction between library code and user code.  And now that can go all the way back past declaring your own intrinsics or assembly blocks all the way to deciding how the parser parses, how the optimizer works.  It's nice to be able to monkey around back there, to tweak things under the hood without having to leave the drivers' seat, so to speak.  But every time you mess around with the engine layer you introduce system incompatibilities.  So long as you're prepared to deal with that, what's the problem.

I also looked at the core extension mechanism and said "yuck".  Some of the "default" syntax seems yucky as well.  It smacks of ML, but I'd place it more in the LISPy design space.

I love that method of definining lists:

(a b c)

or

(a, b, c)

stuff like:

(a, b; c, d) // defines list ((a,b), (c,d))

it'd be nice to be able to use square or curly brackets too, to help them stand out visually when they are needed.  Usually comma and semicolon would be enough to prevent needing too much parenthesis.

Used this way, you could make a hierarchy of separator tokens:

,  highest precedence
;  medium precedence
:  lowest precedence

And parenthesis would not be necessary except when these aren't enough.

You could also make all brackets work the same way, with precedence determined by nesting:

() [] {}

We could gain alot more different kinds of brackets if we could build them
ourselves using two of the same bracket next to each other
(()) [[]] {{}} ((())) [[[]]] {{{}}}

Can we do that even if the compiler doesn't go out of its way to support it?

But then if all brackets work the same way, how would you tell the difference between tuples, arrays, parameter lists, initializer lists, a group of expressions or values;  The compiler would usually be able to figure out the structure at compile time unless the lists contained other lists or arrays of unknown size.

This is a purely syntactical improvement.  But for it to work you'd have to restructure the rest of the grammar.  And I'm not sure that it's possible to rectify it with keeping any sort of C compatibility.

One of the things that has been annoying me most about D lately is the inability to create arrays at any time.  You can't initialize them as locals, even.  Let alone just declare an array literal, in-place, anywhere you wish.  An array literal is essentially a list literal as well.  With literals, linked lists or trees are a better structural model, but at runtime arrays are better (in some cases).

print(1,2,3,4); // does this print the list (1,2,3,4), or print 1, then
print 2, then print 3, then print 4?
print((1,2),(3,4)); // this prints the list of the list (1,2) concatenated
with the list (3,4)
print({1,2,3,4}); // this prints the literal array 4 int literals, pretty
much the same thing, no?
print([1,2,3,4]); // what would this be?

comma operator would be good for use when outputting to streams.  But if lists are precipitous in the language design, streams would end up being an almost trivial sets of operations that work on a list of one of many possible kinds of values, and dispatch to some functionality when one is encountered in the list.

With proper optimization, one could unwind the list processing model to a linear one (a big loop containing a switch comes to mind) and you could do standard optimizations (unrolling etc) once you have it in loop form.

Are there any plans in D for lists at all?  Is this something you want relegated to second-class citizen, in the library?  It seems that it'd be way better if lists were in the D core.

Lacking that, we could always do iostreams style output in D:

static struct print {} cout;

print splice(print p, string s)
{
    OutputDebugString((char*)s);
}

print splice(print p, float f)
{
    return p ~ (string)f;
}

static struct newline {} endl;

print splice(print p, newline endl)
{
    return p ~ "\n";
}

float x=1,y=2;
cout ~ "hi " ~ x ~ y ~ endl;

I doubt that's valid D, at all.

Sean

"Bill Cox" <bill@viasic.com> wrote in message news:3EB46F98.7060208@viasic.com...
> I've read through a bit more of Pliant's documentation, and installed the tools.
>
> On the positive side, the tools worked as advertised.  I can bring up an HTML server, and compile Pliant applications.  Applications are compiled on my machine at run-time, or pre-compiled if I ask for it.
>
> The language seems to be another ML derived language, such as Ocaml. The closest thing I've read about would have to be XL.  The primary developers seem to be French.  They clearly need a native English speaker translating their web pages.  The English documentation is almost as error-prone as something I would write.
>
> On the whole, it looks promising.  I find their syntax extension mechanism crude, but I'm somewhat biased towards Lex and Yacc based parsers.  They parse a line at a time, and provide hooks for matching tokens along the way.  They've really opened up the compiler for hacking in new features.  That seems to be inevitable in langauges designed to be highly extendable.  Forth was such a system.
>
> I wish we could figure out a way to get this kind of power without exposing so much compiler dependent detail.  It seems to be a Catch-22 kind of problem.
>
> Bill

> > "Mark Evans" <Mark_member@pathlink.com> wrote in message news:b8ua7t$2cdc$1@digitaldaemon.com...
> >
> >Found via Google search on "compiled language" + "fast as C"; GPL
license.
> >http://pliant.cx/pliant/welcome/design.html