C & C++
DMDScript
|
Archives
D Programming
digitalmars.Ddigitalmars.D.bugs digitalmars.D.dtl digitalmars.D.ide digitalmars.D.dwt digitalmars.D.announce digitalmars.D.learn digitalmars.D.debugger D.gnu D C/C++ Programming
c++c++.announce c++.atl c++.beta c++.chat c++.command-line c++.dos c++.dos.16-bits c++.dos.32-bits c++.idde c++.mfc c++.rtl c++.stl c++.stl.hp c++.stl.port c++.stl.sgi c++.stlsoft c++.windows c++.windows.16-bits c++.windows.32-bits c++.wxwindows digitalmars.empire digitalmars.DMDScript electronics |
D - Pliant Language
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 02 2003
Bill Cox wrote,Pliant looks pretty cool [but] should have used C-like syntax. May 02 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 May 03 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 May 03 2003
Bill Cox says...The language seems to be another ML derived language May 03 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...
May 04 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 03 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 May 04 2003
|
Mark Evans <Mark_member pathlink.com> 