Constants, Macros, Variables and Stacks

[erikmartin]

From my perusal of the wikipedia descriptions, I'm very confused about the whole grammar, language, and context thing. I'm pretty certain that at least the first two are suggestions are context-free, but I'm not sure about the second three.

#1: Numerical constants! Globally defined numerical constants would simplify and make more readable a lot of designs -- for example when you have a tree that uses 35 degrees in 10 places (and then when you want to try 25 instead).

#2: String Macros... Actually this could be the same thing as #1. But instead of the constant having to be a self-contained expression, you could have something like

Code: Select all

const shrink size 0.9999 hue 20 a -10

, so that you could just stick "shrink" inside other existing attribute strings, like

Code: Select all

myshape {rotate -10 shrink}

to concatenate the contents.

#3: Variables! Global variables that could be used in expressions for attribute strings would be extremely powerful. For example, they would provide a number of solutions for what seems to be a very common concern, which is recursion-depth-sensitive behavior. If global variables violates "context-free"-ness, what about local variables within a rule? Not as powerful, but you could do a lot with a variable within a loop.

#4: IF statements! IF statements would let you make full use of variables, especially for recusion-depth-sensitive behavior, but even without them, one could probably simulate them by use of the variables within attribute expressions.

#5 A Stack! A stack, or equivalently(?), variables that can be passed to rules as parameters, would allow a more elegant and more powerful recursion-depth-sensitive behavior, and other cool things!.

ETA: #6: This is very minor, as it doesn't affect the actual capabilities, but it would seem cleaner if there were a default startshape rule name, like "start", so that instead of

Code: Select all

startshape start
rule start {CIRCLE{}}

you could just do

Code: Select all

rule start {CIRCLE{}}

, or even better if the things that weren't rules, paths, etc, were just interpreted, so it could be just

Code: Select all

CIRCLE{}

or

Code: Select all

myrule1{} 
myrule2{}
rule myrule1{...
rule myrule2{...

[erikmartin]

I just read your "pre-emptive what not to suggest" which makes me think that my 3,4,&5 suggestions don't count as context free. If that's the case, here's an alternate one:

A "render" attribute, and an "expand" attribute. They would both be additive, default to zero, and real-valued. A shape would only be rendered if 0<="render"<1, and a rule would only continue to be recursed if 0<="expand"<1. So, then one could have:

Code: Select all

...
myshape{render -3}
...
rule myshape { 
   SQUARE{}
   myshape{y 1 r -10 render 1 expand .3 }
   myshape{y 1 r  10 render 1 expand .3 }
}

The expand attribute would then determine that no more than four recursions were evaluated, and the render attribute would determine that the first three recursions would not be rendered.

Or, a little less powerful, they could be combined, so that recursion stops when "render">= 1.

[MtnViewJohn]

Here are some of the things we are thinking of for the next version:

#1: Global constants that can be numbers, a string of adjustments (like your string macro), or a string of shape replacements. Constants can be defined in the cfdg file or provided by the user from the render dialog (or the command line).

#2: Local constants that parameterize rules (numeric, adjustments, or shape replacements).

#3: Accessing the value of a loop index in an expression

#4: Some type of if statement.

#5: Random numbers in expressions

#6: Support more than one color in the shape state

#6: A time axis for use in animation

Your idea of a default startshape is a little dangerous. Rather than pick an actual shape name we could say that if there is no startshape line then the first rule in the file is the startshape. The reason that this is a little dangerous is that included files can contain startshape lines that are for testing the included file but are supposed to be ignored when the file is included. If you include a cfdg file then you better not try to use a default startshape.

[TorfusPolymorphus]

For the time until these features are built into CFDG see this workaround.

[mycelium]

i would appreciate very much numeric constant that - i think- could be implemented as code preprocessing. this is an example (fantasy syntax):

Code: Select all

define #NUMBER_OF_LEAVES = integer_rand(50)
define #ANGLE = 360 / #NUMBER_OF_LEAVES 

rule draw { 
                 #NUMBER_OF_LEAVES *  {  y 1 r #ANGLE} leaf {} 
}

rule leaf { 
 ........
}

also expression and special directives like "rand" would be nice to work inside definitions.

i think this can be useful beacause
- it is very simple to use, understand and implement
- it can be used to randomize design fast
- it makes the code more clean and understandable