Re: [Condor-devel] [classad-users] RFC: an implementation of classads enhanced with macro evaluation

[Erik Erlandson <eje@xxxxxxxxxx>]

On Mon, 2012-03-12 at 10:48 -0500, Alain Roy wrote:
> On Mar 11, 2012, at 2:37 PM, Erik Erlandson wrote:
> > I have been fooling around with an implementation of the ClassAd 2.4
> > language spec, and I came up with a surprisingly clean extension to the
> > language that provides macro evaluation at parse time, with the full
> > ClassAd "evaluation in context" eval() semantics behind it.
> 
> What's the goal? When do you need evaluation at parse time instead of runtime?

Regarding goal:  condor makes heavy use of *two* key-value stores:
classads and the config system.  In theory, it would be simpler to just
use one.

I guess my goal was to demonstrate that it's *possible* to do that, and
even do it cleanly, in the classad language framework.  (obviously,
"possible" does not even begin to address things like backward
compatability, or the difference between condor's classads and the 2.4
language spec)

More about how that relates to macros and parse-time below.


> 
> > An interesting use case for this extension is that it would allow a
> > system to be configured using classads.  For example, in theory condor
> > could be configured using the same classad system that it already uses
> > for all its other data.
> 
> I don't understand why macros allow configuration and lack of macros prohibit it. Can you explain more?

Lack of macros definitely doesn't prohibit configuration, so much as it
prohibits configuration as condor knows it.  This sort of common
configuration idiom:

        DAEMON_LIST = $(DAEMON_LIST), NEGOTIATOR
        
Doesn't work with classads, unless you extend the language with macros.


> 
> I think that one of the challenges in Condor is that--at least for users--it's not obvious when parse time is. Maybe in a configuration system it's obvious. But as ClassAds zip around between daemons, when does the evaluation happen? It has to be very clearly defined so that there isn't confusion. 
> 

In condor, classads are mostly unparsed and parsed as they go over the
wire.  

A macro "disappears" after it is encountered by the parser: it is
replaced by the result of evaluating the macro.  The $/$() operator does
not exist in the internal representation.  So, it is part of the
grammar, but never part of the internal expression tree :D

The main use-case for macros in classads would not be in the internal
classads as condor currently uses them.  The use case would be for
classads residing as files, and probably specifically configuration
files.