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: Thu, 13 Jan 2005 10:10:26 +1100 (EST) 
On Wed, 12 Jan 2005, Christian Pearce wrote:


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.


        This is true :).  I'll happily agree with that.


-------------------------------------
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?
Hmm. Well, I never expect to understand a new language without at least a little explanation. So here's a few key points: 
1.      Rules are essentially regexes, just with a slightly different
        syntax.  So the first rule is a rule named "file" which could've
        been written in perl5 as
        m/\Q<HTML>\E\s*$head\s*$body\s*\Q<\/HTML>/E/iw
2.      The \Q[...] sections (\Q...\E in perl5) are literals, embedded in
        the regex.
3.      The <head>, et. al., are references to other rules; this is why
        the next rule is called "head".
4.      No, I don't know what the w option (as in :iw) does either; I'd
        guess whitespace expansion ...[looks in doco]... yes, it means
        that any whitespace is equivalent to \s* in perl5.
The reason I included part of an HTML grammar is that I assumed everyone would know HTML. But I should've explained about the regexes :). And no, we might not have to use the perl; I guess I'm just saying this is a possible alternative to the lex/yacc stuff. Hmm. Now I wonder if lex and yacc will get ported to Parrot :). 


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.
I guess I was under the impression that cfservd had a completely different parser to the one cfagent uses. But there's only one lex/yacc file pair in the source (as of version 2.1.10, which is what I had lying around), and it looks like I'm wrong (unless the separation is done somewhere later on). 


        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.
:). That's one of the reasons for perl6; they were having trouble maintaining perl5, and figured the perl6/parrot split would make things more maintainable. And I'm not suggesting that we do it before cfengine 3 (since Parrot/Perl6 aren't ready yet). 


It would make for a very hackable project.
Am I right in assuming that you mean that we would have a lot more flexibility in our cfengine scripts? 


        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.


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.
I thought of it independently by myself, although only in a vague general sort of way :). 


        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?


        Ok, try this quote:
----------------------------------------------

From http://dev.perl.org/perl6/list-summaries/2004/p6summary.2004-11-22.html
Patrick R. Michaud (for ever after known as Patrick) released a first version of the Perl 6 Grammar Engine (P6GE). Some time later, he renamed it to the Parrot Grammar Engine, as it will by standard in Parrot and PGE sounds better. ----------------------------------------------
Now, I'm not sure what possible syntaxes there will be for the PGE, but I suppose it's possible that Lex and Yacc could be frontended onto it (although I haven't heard this talked about). Or various others. Here's my assumption as to how things work: 

perl6, lex/yacc, whatever  ---> PGE ---> execution
My assumption is that the PGE can refer to PGE structures taken from other languages. So if Python and Ruby have parsers written in something that turns into PGE, they also could be included. But I'm not certain of these assumptions, and my level of "following perl6" is just reading the summaries every once in a while; I'm not actually on the mailing lists (any more, anyway). 


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?


        That's correct.
------------------------
When will Perl 6 be released?
The current plan is to have a working 6.0.0 compiler ready in the 3rd quarter of 2005, based on a snapshot of the language design taken in late 2004. 
------------------------
So that gives you a basic idea of how long it will take. So by January 1 next year, Parrot/Perl6 ought to be around. It might even be out before Longhorn/Enlightenment 1.0. Are we expecting to look at cfengine version 3 before then? I'd expect that we'd be no further than the discussion stages by that point. After all, Mark and I still need to have the editfiles discussion; IIRC, the last suggestion was having multiple "layers" of editfiles, all with different levels of intelligence. But we still didn't agree on various other things.
To refresh the memory of anyone who cares (not just this link, but also the rest of the thread): 
http://lists.gnu.org/archive/html/help-cfengine/2004-01/msg00086.html

        :)

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

"Your Business, Your Web, Your Control"
reply via email to
[Prev in Thread] Current Thread [Next in Thread]