help-cfengine
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parrot, cfengine, and embedded languages

From: Tim Nelson
Subject: Re: Parrot, cfengine, and embedded languages
Date: Wed, 12 Jan 2005 11:27:40 +1100 (EST) 
On Tue, 11 Jan 2005, Christian Pearce wrote:


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
Hmm. Well, it's true that you'd need to compile to parrot code. But is this that much harder than what we're doing now? Also, just supposing you *were* to do this in Perl6, you'd have access to the new grammar constructs. Example: 

-------------------------------------
grammar HTML {
        rule file :iw { \Q[<HTML>]  <head>  <body>  \Q[</HTML>] }
        rule head :iw { \Q[<HEAD>]  <head_tag>+  \Q[<HEAD>] }
        # etc.
} # Explicit end of HTML grammar
-------------------------------------
Obviously the above example isn't complete (NB: I took it from http://dev.perl.org/perl6/exegesis/E05.html), it gives you an idea of what's possible. 


would get confusing quick considering cfservd executes cfengine code.
You would need to some how embed the parrot into cfservd.


        I thought that:
1.      cfagent executed cfengine code, and cfservd just picked up on
        certain pieces.
2.      Parrot would be running underneath cfservd.  We run tomcat here,
        which is a server written in java.  How would cfservd on top of
        Parrot be different?


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.
Well, I thought the things I mentioned (cross-embedding; see below for some clarification) and access to a huge function library were pretty compelling, but maybe I'm the only one who sees it that way. As for the configuration VM (which you referred to as a configuration engine), it sounds like a good idea, but since, to my mind at least, its at a higher level than Parrot, I don't see why it shouldn't be built on top of it. Incidentally, discussion on a similar topic was being done in November at: 

http://lists.inf.ed.ac.uk/pipermail/lssconf-discuss/2004-November/000424.html

        Please be aware that the list above is not cfengine-specific.


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.
Ah. But Perl6 will contain a complete perl6 grammar in the format mentioned above. So we could just refer to that (or to a section of it) to embed Perl6 in our cfengine code. Or at least, that's what I'm hoping for :). 


At least this is my understanding of the whole thing.


        Well, when it finally comes out, we'll see who's right :).

        Also, a few links for those who aren't following Parrot/Perl6.

Main Parrot site: http://www.parrotcode.org/
        (Current version: 0.1.1)
Perl6 site: http://dev.perl.org/perl6/

        :)

--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, Vic, 3008 
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/
reply via email to
[Prev in Thread] Current Thread [Next in Thread]