[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parrot, cfengine, and embedded languages

From: Christian Pearce
Subject: Re: Parrot, cfengine, and embedded languages
Date: Tue, 11 Jan 2005 13:38:37 -0500


I have been following both Cfengine and Parrot for quite some time.  I
never really considered having Cfengine target Parrot.  I guess it is
possible.I don't know how perl handles all the system calls that it

Would it be worth it?  It could really complicate the development of
Cfegine.  You would need to write something in C or in perl to parse the
Cfengine language and then generate the p-code to parrot.  I think this
would get confusing quick considering cfservd executes cfengine code. 
You would need to some how embed the parrot into cfservd.

One of the benefits of Parrot for Perl, Python and Ruby is that the can
benefit from all the existing optimizations of the registered based
virtual machine.  This also separates the compiler geeks from the
language geeks.  And lets each group focus on what they are good and and
enjoy.  I don't see how we as a community gain the benefit.  If anything
we should be thinking about our out parrot.  A configuration engine that
lets multiple configuration tools target it.

Lastly it would be interesting to have the embedded language support of
a large array of languages.  But I don't think it would work out or
function the way you might thing.  The nice thing about Cfengine is that
is all I need.  Okay maybe you call perl scripts from it.  But we would
have to write into the cfengine parse a method for each language we
wanted to embed.  Parrot only knows parrot code.

At least this is my understanding of the whole thing.

On Tue, 2005-01-11 at 10:38, David Douthitt wrote:
> On Mon, 2005-01-10 at 19:55, Tim Nelson wrote:
> >     Incidentally, before I forget, is there any possibility that 
> > cfengine will ever be rewritten to run on Parrot?  For those who haven't 
> > been following Parrot, it's the common platform (think JVM or .Net) which 
> > is going to be the backend for Perl6, Perl5, and probably also the other 
> > scripting languages (Python, Ruby, and a bunch of others; Haskell and 
> > Prolog have been talked about).

Christian Pearce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]