Constants, Macros, Variables and Stacks

Let the developers know what you think of the software and what can be done to either improve the CFDG language or the Context Free program.

Moderators: chris, MtnViewMark, MtnViewJohn

Post Reply
erikmartin
Posts: 2
Joined: Fri Jul 18, 2008 7:52 am
Location: USA
Contact:

Constants, Macros, Variables and Stacks

Post by erikmartin » Mon Jul 21, 2008 8:36 am

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
Posts: 2
Joined: Fri Jul 18, 2008 7:52 am
Location: USA
Contact:

Post by erikmartin » Mon Jul 21, 2008 9:12 am

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.

User avatar
MtnViewJohn
Site Admin
Posts: 844
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn » Fri Aug 08, 2008 4:34 pm

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.

User avatar
TorfusPolymorphus
Posts: 27
Joined: Sun Dec 28, 2008 2:16 pm
Contact:

Post by TorfusPolymorphus » Mon Jan 12, 2009 4:23 pm

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

User avatar
mycelium
Posts: 22
Joined: Tue Aug 28, 2007 4:21 am
Location: Italy
Contact:

numeric constant

Post by mycelium » Sat May 09, 2009 12:05 am

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

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests