[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: Wed, 12 Jan 2005 09:23:07 -0500

On Tue, 2005-01-11 at 19:27, Tim Nelson wrote:
>       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:

We have Cfengine now.  So it is easier.

> -------------------------------------
> 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
> -------------------------------------

Can I get a show of hand of people who know what this means?

> > 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?

I don't know for sure.  There is a cfservd.conf file which must execute
the cfengine parser inside cfservd.  So I guess at that point their
wouldn't be an issue for making it work.  I think the details are quite
hazy though.

>       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.

Don't get me wrong I like the idea of it.  It just sounds like a whole
different project.  I don't think you are going to convince very many
people here to rewrite how Cfengine works unless you make it totally
transparent.  Even then if you introduce the complexity it will make it
more difficult to support.  We are having difficultly so as it is.

It would make for a very hackable project.

>       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:
>       Please be aware that the list above is not cfengine-specific.

Yea the idea isn't mine it has been a topic of discussion for a couple
of years now.  Though I was only introduced to it recently.

>       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 :).

But you claim we can include Python and Ruby as well (granted they need
to buy into parrot, which I think they have for the most part).  It
sounds like what you are suggesting is just rewriting cfengine in perl. 
Is this what you mean to say? 

> > At least this is my understanding of the whole thing.
>       Well, when it finally comes out, we'll see who's right :).

All very interesting stuff.  I would certainly work on a project like
this.  Perl 6 is a ways off right now though isn't it?

Christian Pearce

reply via email to

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