• Mark Evans (15/15) May 02 2003 Found via Google search on "compiled language" + "fast as C"; GPL licens...
• Bill Cox (10/30) May 02 2003 Pliant looks pretty cool. IMO, for marketing reasons, it should have
• Mark Evans (8/10) May 02 2003 You can change it:
• Sean L. Palmer (13/28) May 03 2003 Very interesting.
• Bill Cox (21/71) May 03 2003 I've read through a bit more of Pliant's documentation, and installed
• Mark Evans (57/62) May 03 2003 For language extensibility, sure:
• Sean L. Palmer (87/112) May 04 2003 Systems written in these languages tend to drift toward the kernel, then...
• Mark T (7/7) May 03 2003 interesting material for language lovers like me, BUT
• Walter (10/17) May 04 2003 does not

Mark Evans <Mark_member pathlink.com> writes:

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."

Bill Cox <bill viasic.com> writes:

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."
 
 
 

Mark Evans <Mark_member pathlink.com> writes:

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

"Sean L. Palmer" <palmer.sean verizon.net> writes:

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."

Bill Cox <bill viasic.com> writes:

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."
 
 

Mark Evans <Mark_member pathlink.com> writes:

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)."

"Sean L. Palmer" <palmer.sean verizon.net> writes:

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

Mark T <Mark_member pathlink.com> writes:

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 .

"Walter" <walter digitalmars.com> writes:

"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.