Pliant talk forum

Pliant talk forum


Message posted by maybe Eleanor on 2007/03/07 11:47:39
Professor Tonneau,
Is Pliant a writeable or readable language and is it easily translated?
Thank you for your time.
Message posted by maybe Hubert Tonneau on 2007/03/07 12:02:52
What do you mean by writeable or readable ?
Message posted by maybe Eleanor on 2007/03/08 14:58:31
Professor Tonneau,
Could you perhaps explain how Pliant performs the lexical analysis? Iam doing 
a research project on your language. As for the question about the readability and
writeability, I mean, how easy is it to read a written program in Pliant? I would seem
that it would be not very readable because of the flexibilty and customizability of
the program but that it would be more writeable because of this. Is this true?
And I also think that pliant is not an orthogonal language from what I've read. Is this true?
Thank you again for your time,
Message posted by maybe Hubert Tonneau on 2007/03/08 23:53:01
> Could you perhaps explain how Pliant performs the lexical analysis ?

Please start through reading this:

Also please remind to forget everything you know about grammars and automatons
before starting to read because Pliant parser is not based on these, even
if it's very unusual.

> As for the question about the readability and
> writeability, I mean, how easy is it to read a written program in Pliant? I would seem
> that it would be not very readable because of the flexibilty and customizability of
> the program but that it would be more writeable because of this. Is this true?

Well, the more the programming language is powerfull, the ugliest the final
program might be if the programmer does not use it resonably.
It's not at all specific to Pliant. It's just a general fact of technology.

Pliant customisability is not intended to change everything, but to enable
to write full libraries.
What I mean by full libraries in not just new data types and functions (or new
classes if you prefer object programming wording) but alsoso
. tiny extensions to the parser that make using the library easier
. new checking and rewriting rules that also make using the librarie
  easier, safer and more efficient

> And I also think that pliant is not an orthogonal language from what I've read. Is this true?

Please elaborate on what makes you think it's not orthogonal.
I might not understand properly what you mean by orthogonal.

If I remember well the general meaning of orthogonal in programming languages
theories, that I would say Pliant is very orthogonal because at compiler level,
everything is an expression.

PS: I'm not a professor. I earn my living through a job in the industry.
    Pliant is my personnal project, and I just have very good relations with
    the CAMS research laboratry.
Message posted by maybe Eleanor on 2007/03/13 10:51:45
Thank you for the lengthy answer. It was very helpful!
About the lexical analysis, I read the information on the link you gave me but I 
still have not been able to understand what process Pliant goes through to break 
up the source code into tokens. Thank you so much for your time and I'm sorry
for the repetative questions.
Message posted by maybe Hubert Tonneau on 2007/03/13 11:01:13
We just call an ordered set of filters.
A filter either fails, or pushes a parsed token and moves the cursor forward.

See 'parse_float' function in /pliant/language/type/number/float.pli as an
Message posted by maybe Eleanor on 2007/03/13 11:32:21
Since you asked what I meant by orthogonality here are a few guidelines I have 
learned about that make a programming language orthogonal: 
Cleanly integrated features: 
All features must be cleanly and elegantly integrated into the language.
Composability of features: 
It must be possible to use combination of features to achieve solutions that would
otherwise have required extra separate features. 
Avoid special purpose features: There should be as few spurious and "special 
purpose" features as possible. 
Performance independence: A feature should be such that its implementation does 
not impose significant overheads on programs that do not require it. 
Understatement independence: A user need only know about the subset of the 
language explicitly used to write the program. That is, new features should not 
have their semantics influence that of  old features.

Also, is Pliant easily translatable where the key of easy translation is 
regularity of syntactic structure?

Thank you!

Message posted by maybe Eleanor on 2007/03/18 12:25:31
Mr. Tonneau,
Have you had the opportunity to see my message? 
I'd appreciate an answer when you have the chance!
Thank you!
Message posted by maybe Hubert Tonneau on 2007/03/18 17:02:37
Your criterians are very general, so a full answer would require much more than
I intend to write here.

Here are three remarks:

I tend to think that a language value is more than anything else in the width of
the usage field it's not too bad for. Having many good properties does not worth
much if for your application just one bad one makes it a nightmare.

About your 'performance independence' criterian: Having all memory models
available in a single language is fairly hard from the technical point of view.
High level languages tend to favor garbadge collector (automatic free handling)
but it's not without performances impact on programs that don't really need it.
On the other hand, manual freeing (C++) or manual + references count (Pliant)
does not bring performances constrain, but will make somme applications much
harder to write. So, there is no definitive answer to the memory allocation

The last remark is about translating Pliant.
Pliant key feature from the very high level point of view is that it states that
compiling is binding a set of instructions (procedural low level programming)
to an expression (high level declarative programming) and that any library
or application must be abble to decide how to do that in it's peticular field
(meta programming).
Since the hardware is always procedural, previously to Pliant, languages
where either low level procedural oriented (Pascal, C, C++) so had a straight
and efficient translation to executable code but where inexpressive, or where
higher level (LISP, CAML, Prolog) and had a long and complex fixed built in
transition mechanism and as a result where inefficient in all but the very
fiew fields where the built in transition engine was optimal.
So, the problem when translating from Pliant to another language is not at all
the orthogonality or something like that, but first the memory model because
as previously stated translating from one memory to another cannot be done
automatically, and second the lack of the Pliant 'meta' programming notion
in other languages.