Newbie questions about Pliant

Newbie questions about Pliant


is this a language with a future?
Message posted by maybe frank on 2002/09/14 15:45:14
i think it can be
Message posted by maybe Hubert Tonneau on 2002/09/14 16:06:05
It depends what you call a 'futur' !

If you think about continue to be polished at implementation level and design
details, then the answer is definetly yes because it's my life project,
and I'm only 33 years old, so I have time. Patrice is not much older, so if
I get under a bus, the answer still remains true.

If you think about getting a significant user base, then the answer is no,
at least for the next fiew years: the short term problem with Pliant is the
lack of computing culture among humans. Most standard people, and even most in
the computing cannot see if an application is better designed than another one
on their own. So, we have to first spread Pliant in universities, then wait
for a new user generation to grow. Also spreading in universities is not at
all granted because I'm not good at providing university required goodies, so
it depends mainly on how Marcus and his helpers will succeed to fill the gap.
Message posted by maybe Hubert Tonneau on 2002/09/14 16:14:36
If you prefer the history point of view, here it is:

Pliant is a new generation compared to GNU Unix clone.
At the moment, GNU is the king and Pliant is the prince.
So the question could be: how long will the old king stay ?
Message posted by maybe Patrice on 2002/09/15 07:03:26
If the question, as it seems to be, only delas with the "language" aspect of the
project, the answer will definetely be yes.

The reasons are threefold. First, this is a conceptual breakthrough (what makes it
a bit difficult to explain), as could appear Lisp in front or Fortran.
Second, it is efficient (this used to be the main goal of the project), what will
make it practible for real life problems (in constrast with Prolog, or even
Lisp family language). Last, it is extendable as no part of its implementation
is out of reach of the language. This opens the language and allows further evolutions, thus ensuring a non-zero adaptability, as encountered in most of
the programing languages (reason of C->C++, Lisp->ML, etc.)
Message posted by maybe Pixel on 2002/09/23 10:30:12

# The reasons are threefold. First, this is a conceptual breakthrough (what makes it a bit difficult to explain), as could appear Lisp in front or Fortran. Second, it is efficient (this used to be the main goal of the project), what will make it practible for real life problems (in constrast with Prolog, or even Lisp family language).
well mercury (prolog), ocaml, mlton (MLs), cmucl, bigloo (Lisps) achieves very good performance

# Last, it is extendable as no part of its implementation is out of reach of the language.
could type inference be added? ;p AFAIK there's always a limitation!

# This opens the language and allows further evolutions, thus ensuring a non-zero adaptability, as encountered in most of the programing languages
but many languages don't relinquish on changing their behaviour by changing the compiler/interpreter. For example, python has many new features (closure, nested functions, iterators). Haskell also has many extensions (eg: hugs).

-- Pixel programming languages addict

Message posted by maybe Hubert Tonneau on 2002/09/23 11:14:07
> well mercury (prolog), ocaml, mlton (MLs), cmucl, bigloo (Lisps) achieves very good performance 

This is the kind of comparison that I feel unfair: efficient logical or
functional programming language are efficient in some areas only, not all,
and that's the key difference.

So people that want to promote these will select applications where they are
efficient (basically applications where you don't need to randomly 'peek' and
'poke' the memory, and where you don't need to go as low as assembly).

Just try to write a database server in one of these, or a semaphore handler,
or a compression library, or a bitmap graphic library, and you will understand
what I mean.

> could type inference be added?

As far as I can understand what type inference is, we are targetting something
much more powerfull in Pliant which is proofing. Basically, the idea is to
have some properties of the program forwarded so that we can deduce some
properties, so perform extra optimisations, remove some tests, and provide
feedback to the programmer.
See Mr Couso works for extra details.
Adding types inference is, still as far as I understand it, no more than
adding a type property to each expression, so it's no problem.

> but many languages don't relinquish on changing their behaviour by changing the compiler/interpreter.

Once again, all depends if you considere details or not. If one say a car
is a car, so all cars are equal, they one may get to your conclusion.
Now, if one drives a car everyday, he will see the difference between high
end and low end ones, between sport cars and berlines.
Same with a programming languages.
Staying always on the paper is dangerous: one has to write big applications
in order to get real feedback.

I would go as far as saying beeing abble to change the language is no value
in itself. There are two kind of languages: the 'one peticular field dedicated
ones', and the 'general purpose' ones. Pliant is a general purpose one.
For a general purpose language (you select it because you want all your
developments to append in a single consistent environment in order to minimize
the interfacing problems) the question is not how well does it solve this or
that peticuler problem but rather how does is solve any random problem.
So beeing abble to change the language is a good way to avoid beeing completely
locked on some problems, just as beeing efficient is.
Message posted by maybe Pixel on 2002/09/23 13:45:24
> Just try to write a database server in one of these, or a semaphore handler,
> or a compression library, or a bitmap graphic library, and you will understand
> what I mean.

many languages have C backend and can use known efficient C libraries
(zlib, libpng, libssl...)

> > could type inference be added?

> As far as I can understand what type inference is, we are targetting something
> much more powerfull in Pliant which is proofing. Basically, the idea is to
> have some properties of the program forwarded so that we can deduce some
> properties, so perform extra optimisations, remove some tests, and provide
> feedback to the programmer.
> See Mr Couso works for extra details.

any link? google didn't help me.

> Adding types inference is, still as far as I understand it, no more than
> adding a type property to each expression, so it's no problem.

wow. I wonder why there is so much research in that area. Achieving
haskell or ocaml type system doesn't seem "no problem" for me.
Message posted by maybe Hubert Tonneau on 2002/09/23 13:53:22
> any link? google didn't help me.

> Achieving haskell or ocaml type system doesn't seem "no problem" for me.

By no problem I mean there is probably no problem to use any type properties
algorithm on Pliant.
I don't mean that the algorithms for propagating types properties are trivial.

It is exactly the same with Cousot works: Pliant is ready for propagating
properties. Also designing algorithms that propagate interesting properties
might be many many years researches.
I could say it another way: Pliant is a good support for such researches.
Cousot tend to use Pascal, others tend to use CAML. One could use Pliant.
Message posted by maybe Marcus on 2002/09/23 13:57:55
I think what Mr. Pixel mean by 'type inference' is that in those languages the 
defining the type of objects is optional. Then, during compiling time, the com-
piler infers which is the more approapriate type for the objects, based on the 
operations and object definitions involved.

In Pliant, as far as my limited knowledge is concerned, one *has* to define all
object types before compilation. Then, I guess, some rudimentary type 'checking'
takes place.

You should take what I say with a grain of salt, though.

Message posted by maybe Hubert Tonneau on 2002/09/23 14:07:15
> In Pliant, as far as my limited knowledge is concerned, one *has* to define all
> object types before compilation.

Not necessary at high level programming. Only at low level programming.
This is the lambda calculus issue.
One could define very easily in Pliant a type that contains an expression which
is not low level compiled because some types are not defined in it, then keep
it as is until it gets completely define and truely compile it then. All this
is no problem because Pliant is a dynamic compiler.