Lexically-scoped variables, shameless plug

[futrelle]

Apologies for suggesting something that may be a non-starter, and double apologies for a shameless plug:

Suggestion:

Adding lexically-scoped variables would not make the resulting grammars context-sensitive, since a variable set in a rule would only affect the expansion of that rule (and therefore all the ones it invokes, but not any of its siblings or ancestors in the result tree). The "current coordinate system" is already an implicit set of lexically-scoped variables that parameterize every rule; why not add user-specifiable variables of that sort? e.g.,

rule foo { bar { baz 2 } }
rule foo { bar { baz 0.5 } }

rule bar {
SQUARE { x baz s baz }
foo { }
}
rule bar {
SQUARE { x 1 s baz }
foo { }
}

This saves me from having to exhaustively enumerate every combination of parameters I want to compute for the square, given that sometimes I want s and x to be the same, and sometimes I don't.

Now, adding dynamically-scoped variables changes everything; I should know.

Shameless plug:

http://www.schneertz.com/rmutt

rmutt is a freeware random text-generation engine based on user-specifiable context-sensitive grammars.

[robo git]

Hmm... thinking about this further, stemming from the discussion here, the ideal way to handle this would be to be able to pass parameters and set defaults for parameters, and/or to inherit parameters....

pass params example:

Code: Select all

startshape paramDemo

include i_pix_brush.cfdg
// A variation of i_pix that allows definable brushes
include i_brush.cfdg
// A series of pre-defined brushes &/or brush templates

rule paramDemo {
   writeText {} //normal 5by5 font
   writeText { brush block_5by5_ds } //drop-shadow variant
   writeText { brush circle_5by5 } //some other brush being used
}

rule writeText $brush=block_5by5 {
   F_5by5 {x 0 brush $brush }
   O_5by5 {x 1.2 brush block_5by5_ds } //Will always be brush-rule "block_5by5_ds"
   R_5by5 {x 2.4 brush $brush }
   T_5by5 {x 4.0 brush $brush }
   H_5by5 {x 5.2 brush $brush }
   E_5by5 x 6.4 brush $brush }
   W_5by5 {x 8.0 brush $brush }
   I_5by5 {x 9.2 brush $brush }
   N_5by5 {x 10.6 brush $brush }
   Exclaim_5by5 {x 11.8 brush $brush }
   Exclaim_5by5 {x 12.2 brush $brush }
   Exclaim_5by5 {x 12.6 brush $brush }
} 

If variable called $brush (or pretty much anything else) is passed to a rule, but the rule does not have a definition for that parameter, this would need to either result in one of three actions: 1) a parse error, 2) be ignored/dropped or 3) define the parameter for the child rule (useful for interitance control - see below).

Likewise if the rule DOES have a parameter with no default, but no parameter is passed, it would either need to ignore (and just substitute blank - a useful feature in and of itself, but would need something like another $ on the end to define the scope of the variable name, eg W_$fontheight$by$fontwidth$ {} could resolve to W_5by5 {} or W_6by3 {} or W_by {} ), cause a parse error, or if parameter of the same name is defined in the parent rule, inherit from parent rule.

If a variable of the same name is present in the parent rule, but not passed into the child rule, this could be inherited from the parent rule, and would override any default value (which would also obliviate the need for the "brush $brush" statements above and provide backwards-compatibility with existing CFDG), but if not defined, I'm not sure: If it doesn't use it, why inherit it? - only makes sense if a rule lower down on the inheritance hierachy uses it, but then it's a trade-off of possible child use against system memory clutter.

Usage example 2:

Code: Select all

startshape paramDemo2

rule paramDemo2 {
   writeText {}
   writeText { $brush$ block_5by5_ds } 
//Could probably do a format that does not require $ surrounding the name within the parameter-space
}

rule writeText {  
//brush is either defaulted or defined in call, no explicit references though.
   F_5by5 {x 0 }
   //...
}

//--------------------------------
//in i_pix.cfdg

//...
rule F_5by5 $brush$ { 
   //no default, will inherit any defined $brush$  or brush passed as explicit parameter though. 
   //again, as long as the first-character of the name cannot be numeric or the name be a reserved name, then possible to not need the $ here
   pix_5by5_00 {} 
   //...
}

rule pix_5by5_00 $brush$=block_5by5 { $brush$ {size 0.20 x -0.4 y 0.4} } 
   //Yet again, possible to not need the $ in the rule-opening, though $ are needed 
   //inside the rule as we want a substitution to occur, rather then call out to a rule called "brush".

//...

My reasoning around this suggested model is that it gives greatly increased flexibility for minimum cfdg retrofitting effort, while still being able to write code that is backwardly compatible (for running older CFDG files)... As normal, I've got no idea what would actually be involved to implement this...

Thoughts?

Cheers!
-Trav