Newbie questions about Pliant

Newbie questions about Pliant

On extending Pliant

Since Pliant is a "compiling engine", how to extend it
so that it accepts (i.e., compiles) another language?

Message posted by maybe Marcus on 2002/07/05 13:34:04
In the complex numbers howto, David Ge proposed another example where he defines
a datatype for storing 2D coordinates. His proposed syntax to represent 2D 
coordinates is the following:  
      (x, y)
where x and y are floating point numbers.

Patrice's reply was:" Actually, this solution is not so good, as it breaks a bit 
the semantic of "("."

However, suppose one wants to create a module which defines a another front end
to the Pliant compiler. In this new front end, the source language is a dialect
of Lisp (lets not worry, for now, about garbage collection). Since parenthesis 
abound in such a language, how to define such module, using Pliant's compiling
engine tools, such as the parser filters and operators, but without breaking 
Pliant's semantics?
Message posted by maybe Hubert Tonneau on 2002/07/05 13:38:19
Either the module provides a full new parser, or it provides a new '(' filter
recorded with a higher priority than the existing '(' filter and that is
awared about the new rules.
Message posted by maybe Marcus on 2002/07/05 15:20:50
> Either the module provides a full new parser, or it provides a new '(' filter
> recorded with a higher priority than the existing '(' filter and that is
> awared about the new rules.

Assuming that one wants to use Pliant's compiler back end, it seems to me that 
it would be easier to plug in this new front end if one chooses the second
option. However, in this case one would have to work within the confines of the
available parser sections and their priorities, and this may get a bit ad hoc
and messy, if we consider the particularities of the syntax any given 
programming language.

Patrice mentions that it is possible to add new parser sections to the 
'pliant parser sections' untyped list, but it is a more tricky. I wonder how
'tricky' this might be. Moreover, would this be a good solution?

Message posted by maybe Hubert Tonneau on 2002/07/05 15:41:19
> Assuming that one wants to use Pliant's compiler back end, it seems to me that 
> it would be easier to plug in this new front end if one chooses the second
> option.

A full new parse can reside within Pliant, the only difference is that it
ignores all existing filters. It is probably the good idea for parsing another
language within Pliant.

> Patrice mentions that it is possible to add new parser sections to the 
> 'pliant parser sections' untyped list, but it is a more tricky. I wonder how
> 'tricky' this might be. Moreover, would this be a good solution?

Sections are just a way to order parser filters. Adding a new section is just
adding another word in the parser sections list.
Message posted by maybe Marcus on 2002/07/05 16:54:34
> A full new parser can exist within Pliant. The only difference is that it
> ignores all existing filters.

By "full new parser" you mean a brand new set of parser sections and filters? 
Message posted by maybe Hubert Tonneau on 2002/07/05 17:02:57
> By "full new parser" you mean a brand new set of parser sections and filters?

Yes, let's image that you want to enable Pliant to load on the fly some C
source files containing some advanced algorithms written in C:

then you could either write a brand new C parser as a brand new set of Pliant
parser filters,

or if the general Pliant parser machinery (set of ordered filters and operators
handling mechanism) is no good for parsing C, you can write a brand new C parser
as a single Pliant filter that does everything at once using it's own machinery
(parse some C code, handle operators, build Pliant expression, then call Pliant
expression compile engine)

in all case, Pliant will not care and it will integrate seamlessly with other
modules using Pliant native syntax.

Basically, a Pliant parser filter can do what ever it wants, provided it moves
the parsing cursor forward, Pliant will know that it succeeded to parse some
code, and will not care how it did it.