Inline substitution of named transforms

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: MtnViewJohn, chris, mtnviewmark

Post Reply
User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Inline substitution of named transforms

Post by zol »

Let's say you want to rotate arrows, birds, and lightning at random angles.

The current approach would be to duplicate the entire RandomRotate complex for each subject.

Code: Select all

rule RandomRotate1 { RandomRotate2 { } }
...
rule RandomRotate6 { RandomRotate7 { r 4 } }
rule RandomRotate7 { DrawArrow { } }

rule DrawRandomArrows { 30*{ b -0.05 z 1 } RandomRotate1 { } }
(repeat for birds and lightning)

Or the subjects can be bundled together under one virtual shape leaving the number of each to chance.

Code: Select all

rule RandomRotate1 { RandomRotate2 { } }
...
rule RandomRotate6 { RandomRotate7 { r 4 } }
rule RandomRotate7 { DrawThing { } }

rule DrawRandomThings { 90*{ b -0.05 z 1 } RandomRotate1 { } }
rule DrawThing{DrawArrow { } }
rule DrawThing{DrawBird { } }
rule DrawThing{DrawLightning { } }
Either way, RandomRotate cannot distinguish separate subjects.

The above pass transformations by inheritance, but there is another mechanism in CF allowing transformations to enter the system to begin with - the inline adjustments to the parent space before inheritance by the child.

My suggestion is that named rules could act as adjustments, returning their transformations inline, to perform the same job as adjustments using "{}" syntax.

Code: Select all

rule RandomRotate1 { RandomRotate2 { } }
...
rule RandomRotate6 { RandomRotate7 { r 4 } }
rule RandomRotate7 { RETURN { } }

rule DrawRandomArrows { 30*{ b -0.05 z 1 } DrawArrow RandomRotate1 }
rule DrawRandomBirds { 30*{ b -0.05 z 1 } DrawBird RandomRotate1 }
rule DrawRandomLightning { 30*{ b -0.05 z 1 } DrawLightning RandomRotate1 }
RandomRotate1 can now act as a general purpose library function.

I can think of a few restrictions one might want to simplify implementation, but the most useful aspect could be accommodated fairly elegantly, I expect.

User avatar
mtnviewmark
Site Admin
Posts: 81
Joined: Wed May 04, 2005 12:46 pm
Location: Mountain View, CA
Contact:

Post by mtnviewmark »

For 3.0 John and I have been considering a full generalization of this sort of thing. We'd like one to be able to parameterize a rule invocation with a sort of continuation like thing. This would allow the invoked rule to act in a generic way, like you describe.

Examples of sort of thing are Guigui's recent meta-alphabet gammabet.cfdg, where he has you include his file, and then define a rule CIR to control the look of the resulting letters.

I could imagine meta rules like a tree that takes in continuations for drawing leaves and a segment of a trunk.

As always, the trick will be keeping such a construct context free.
I'm the "m" in "mtree.cfdg"

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Post by zol »

I agree that continuations are the better solution. In fact, it improves the more I think about it.

When I first read your post suggesting continuations, I thought it might be too radical for CF, almost resembling functional language.

But it is actually a more appropriate and accessible idiom, as well as allowing more elegant, exception free, implementation than my suggestion.
Certainly it is context free to pass nothing but a handle to an unreadable callback chain.

Incidentally, there's also an implicit but independent suggestion in your example of allowing anonymous rule definitions.

Code: Select all

rule foo { 
    grid5{ {CIRCLE {} SQUARE {s SQRT(2)/2 b 1} } 
}

//versus

rule foo { 
    grid5{ bar } 
}
rule bar { CIRCLE {} SQUARE {s SQRT(2)/2 b 1} }
My own suggestion was entangled with thoughts about iteration, syntax (snap?), and allowing inline composition, as well as the assumption that any suggestions should be as inconspicuous as possible.
MtnViewMark wrote: Examples of sort of thing are Guigui's recent meta-alphabet gammabet.cfdg, where he has you include his file, and then define a rule CIR to control the look of the resulting letters.
My, that's a big one. This is the second case, above, with the same unfortunate limitation to one subject. I've been using the idea mainly as a sampler gallery for experiments, but this is a much better candidate for things-you-don't-want-to-do-twice. :shock:

[edit]
Continuing discussion at the original continuations thread.
[edit 2] I linked to the wrong thread ... 3 years ago! :oops:
Last edited by zol on Thu Jan 20, 2011 5:16 pm, edited 1 time in total.

User avatar
Nom
Posts: 30
Joined: Tue Jan 30, 2007 6:45 am

Post by Nom »

MtnViewMark wrote:For 3.0 John and I have been considering a full generalization of this sort of thing. We'd like one to be able to parameterize a rule invocation with a sort of continuation like thing. This would allow the invoked rule to act in a generic way, like you describe.
I see an analogy between the continuation idea, and a stack with push/peek functions (but not necessarily pop). Per comparison to traditional programming languages, e.g. c, or java - - equivalent structure would be when a stack is passed locally from the calling method to the called method (as parameter). Now the called method can access the stack's content, but does not know whether the stack was modified by the calling method or by someone else, or even who it was that called it. Furthermore, the stack would always be of size one in continuations. Am I totally wrong in my analogy?

Post Reply