Preemptive - what not to suggest for expanding CFDG!

[Nom]

The program works so well that these ideas are rather superficial.

However...

1) a little syntactical change for doing multiple subsequent rules in an easier way

letters etc. would be simpler if one could "pipe" rules in the following way:

** { x 1 } TT HH EE MM EE SS SS AA GG EE { } **

It is almost like 5* { } RULE { } but more flexible, and still preprocessor (stage 1)

The ending asterisks (or similar) would be optional



2) inheritance...

It could still be preprocessor. And sometimes it would decrease code size quite nicely. The include directive would be more useful then, too.

I mean the following way

metarule AB { b .1 }
metarule ASAT { sat .1 }
rule DRAW { SQUARE { } DRAW { s .9 } }

rule CHILDTHING inherits AB ASAT DRAW { }

This is of course a stupid example, because writing the rules takes more characters. But suppose we would use the same kinds of modulations in, say, 10 drawing rules? Or building libraries of personal artistic ideas?

[MtnViewJohn]

Ideas like that have been kicked around before to make outputting text easier. It wouldn't be that hard to do. But it does lock you into fixed width fonts when most high quality text output uses proportional fonts. If we are going to go to the trouble to make text output easier then I think we should figure out a way to support proportional fonts.

Maybe a pre-processor could read a string and some font metadata and spit out cfdg code. Or perhaps rules could "return" a translation transform that is only used in a context-free manner. This would be context free if a rule had only one return value even if it has multiple versions; i.e., a "compile-time" return and not a "run-time" return.

We already have a way of expressing inheritance:

Code: Select all

rule DRAW { SQUARE { } DRAW { s .9 } } 

rule CHILDTHING { DRAW { b .1 sat .1 } }

What would another inheritance syntax do for us? Maybe we should use the existing inheritance method but add C-style #define support.

[Nom]

Regarding text output. I'm aware about the complexities of doing good looking writing is horribly difficult in context free (I think proportional fonts would be a big thing in work hours, would they?). I was thinking of other applications, too, for this kind of chaining. If you put one line like this "inside" another, you can easily get definitions for different shape matts...

I might be a bit mixed about the other thing.

With inheritance I was primarily pointing to C-style multiple inheritance. (I've forgotten most of my C, so I don't remember what #DEFINE enables).

Code: Select all

rule DRAW { SQUARE { } DRAW { s .9 } }

rule CHILDTHING { DRAW { b .1 sat .1 } }

is not interesting, but

Code: Select all

rule DRAW { SQUARE { } DRAW { s .9 } }
rule DRAW2 { CIRCLE { } DRAW { s .9 } }

rule CHILDTHING { DRAW { b .1 sat .1 }  DRAW2 { b .1 sat .1} }

Now note that the attributes

Code: Select all

 b .1 sat .1

need to be written twice, and the "turtle" does not know, doing DRAW2, what changes passed, doing DRAW. But this might be nearly non-context free (?)

[jeremydouglass]

If we are going to go to the trouble to make text output easier then I think we should figure out a way to support proportional fonts.

Given that proportional fonts are inherently context-ful, collision-detecty, or what have you, I suspect that any in-Context Free support is going to help fixed distance fonts or nothing. Not that I wouldn't love proportional fonts, mind you... I just seems like they won't happen except as a pre-pre-stage. The advantage of Nom's syntax above is that it supports a bunch of interesting things in addition to fixed fonts. It really looks to me like two different syntaxes, so I'm going to re-propose the same thing with a small difference.

One distributes a shared pre-transform across an unspecified number of shapes:

** { x 1 } TT{} HH {}II{} SS{} -> TT{x1} HH{x2} II{x3} SS{x4}.

...and one lets many rules share a transform definition:

TT HH II SS {h 10} ** -> TT{h 10}HH{h 10}II{h 10}SS{h 10}

Each would be useful on its own in a bunch of general situations - although if handled separately they might interact weirdly - the second could cause all kinds of problems. My suggestion would be to handle them something like this:

First: words inside <> are always rules - {} not allowed. They expand to share the subsequent {}, e.g.

<TT HH II SS>{b 1} -> TT{b 1}HH{b 1}II{b 1}SS{b 1}

Second: ** {} iterates the transform across as many functions as follow on the same line, e.g.

** {x 1} SQUARE{} CIRCLE{} -> SQUARE{x 1} CIRCLE {x 2}

These two can pre-parse independently, but together you get

** {x 1}<TT HH II SS>{b 1} ->
TT{x 1 b 1}HH{x 2 b 1}II{x 3 b 1}SS{x 4 b 1}

... which could be useful for a lot of stuff other than fonts. You could also combine the shared transform syntax with the other expansion rule:

10 * [s .8 y -1.1]<AA BB CC DD EE FF GG>{b 1 h 120}

Cool.