Some ideas for Context Free 3.0

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

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

Post by zol » Thu Apr 24, 2008 2:23 am

Invertible z
One application is 3-D, e.g. some objects have inside/outside relationships to some centre, and you want to show this in profile, with outwards extending both directions along z.
More generally though, (CF is not about representational depiction) I suspect there are some cunning and attractive effects to made with reversible stacking.

Useable iterator values
I believe that cumulative adjustments are always ignored on the first pass, so zero-indexing has a natural sense to it.
The kind of variable reference I'd go for is like "$1" for the innermost, "$2" for the one outside that. This has the advantage of keeping inner loop code independent of whether it appears inside another loop, and being naturally extensible to deeper nesting, should that ever be considered.
(I don't know about "$0". I feel that it should be reserved for something special, but I don't know what)

Also going back a bit, I don't see why named constants should have anything to do with parameterization.
The main impetus behind constants is reliable code maintainence and modification. All that is needed is string substitution during parsing; it has no effect on rule interpretation.

Script arguments can be handled the same way, without rule parameterization.

The reason I mention this is that I have reservations about rule parameterization. I'm still not sure that I have an objection worth making, but I feel that I should make my ambivalence known.

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

Post by MtnViewJohn » Thu Apr 24, 2008 11:36 am

zol wrote:Invertible z
One application is 3-D, e.g. some objects have inside/outside relationships to some centre, and you want to show this in profile, with outwards extending both directions along z.
More generally though, (CF is not about representational depiction) I suspect there are some cunning and attractive effects to made with reversible stacking.
If I understand you correctly then I think you can do that now by inverting the z scale: size 1 1 -1 All down-stream z changes would go in the opposite direction, until you reversed the z scale again.
zol wrote: Useable iterator values
I believe that cumulative adjustments are always ignored on the first pass, so zero-indexing has a natural sense to it.
The kind of variable reference I'd go for is like "$1" for the innermost, "$2" for the one outside that. This has the advantage of keeping inner loop code independent of whether it appears inside another loop, and being naturally extensible to deeper nesting, should that ever be considered.
(I don't know about "$0". I feel that it should be reserved for something special, but I don't know what)
Exactly, only I would start with $0. I would rather that cfdg files remain simple and straight-forward. Not full of special variables like Perl.
zol wrote: Also going back a bit, I don't see why named constants should have anything to do with parameterization.
The main impetus behind constants is reliable code maintainence and modification. All that is needed is string substitution during parsing; it has no effect on rule interpretation.

Script arguments can be handled the same way, without rule parameterization.

The reason I mention this is that I have reservations about rule parameterization. I'm still not sure that I have an objection worth making, but I feel that I should make my ambivalence known.
Yes, global parameters could have been done in version 2.2 using string substitution in the lexer. In fact that is probably how it will be done in version 3.0. The only similarity between global parameters and rule parameters is that they would be invoked using the same syntax (I think).

Mark and I are also unsure whether rule parameters violate the spirit of Context Free. One argument is that rule parameters are just syntactic sugar for specifying and using an infinitely large family of rules. It would be like adding C++ templates to cfdg files.

But template parameters are always compile-time constants. Would rule parameters be OK if they were constant and could not depend on incoming parameters or loop iterator values? That seems too restrictive to me. Certainly a parameterized rule should be able to invoke itself using the same parameters (and invoke itself main times, not just tail recursion).

Maybe that would be sufficient: rule parameters are compile-time constants and there is some syntax for a rule to invoke itself with the same parameters (maybe by leaving the parameter list empty). Each time a parameterized rule is invoked the parameters would get folded into the rule name using some sort of name mangling scheme and if that particular instance of the rule has not previously been used then the rule template gets recompiled with the new parameters, using the same string substitution techniques used for global parameters.

Actually, we would still be able to use incoming parameters when invoking other parameterized rules as long as they are unchanged. The name mangling and string substitution technique still works because the parameters are know at compile time. So a parameter can either be an unchanged incoming parameter or a constant expression (no use of parameters, loop iterator values, or random functions). Paths could have parameters too under this scheme.

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

Post by zol » Thu Apr 24, 2008 3:08 pm

Silly me. I got so into the mindset that z isn't like the xy-space that I missed or forgot the option to scale it - which of course is even better than merely flipping it.

"$0" is fine by me. I was only thinking 'just in case'.

I'm glad you're aware that parameterization, although it is only syntactic sugar from one perspective, does have practical consequences on the spirit in which things are done.
I think that your suggestions might hold the key to that middle way. I'll reflect on them and see how many qualms I can put to rest.

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

Re: Some ideas for Context Free 3.0

Post by zol » Thu Jan 20, 2011 9:20 pm

I have just been preparing to get into CF again after a long hiatus, and thinking about what I might do inevitably reminds me of the issues that must be overcome.
I originally posted this idea in 2008, but as far as I know it wasn't noticed and hasn't been considered yet.

Invertible colour dimensions
Colour adjustments follow absolute orientation. Unlike spatial adjustments, they always know which way is "up."
And bounded dimensions in particular require duplicate rules to allow alternation, or even maintain variation without stalling at the limits.

I propose a set of adjustments that do nothing but reverse orientation; the output remains the same, but subsequent adjustments effectively have the opposite sign.

This detachment of relative from absolute values simplifies at least one basic idiom.

Code: Select all

rule concentric{ CIRCLE{} concentric{s .9 b 1 ~b} }
This makes more rewarding and revealing results available within a single rule, and frees experimentation from maintaining consistency between intended duplicates.
I expect this would greatly encourage beginners, and in conjunction with target colours, allows more sophisticated palette control.

As a minor illustration, one could apply a trick like that in The Visible Hilbert, used to specify alternating hues, in Folded Squares, to specify alternating brightness and saturation values with less code. (Excuse the pimping. I just know my own code best)

If implemented, I suggest that it would be most intuitive for inversions to be applied after other adjustments in the default order, since people are likely to prefer making those adjustments based on current orientation.

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

Re: Some ideas for Context Free 3.0

Post by MtnViewJohn » Fri Jan 21, 2011 11:08 am

Yes, that feature idea did get lost in the mix. But you can get that effect using rule parameters, and I think the code would reflect your intent more clearly.

Code: Select all

rule concentric<b1, b2>
{ 
    CIRCLE{b b1} 
    concentric<b2, b1> {s .9} 
}
Or you could cycle between three colors:

Code: Select all

rule concentric<b1, b2, b3>
{ 
    CIRCLE{b b1} 
    concentric<b2, b3, b1> {s .9} 
}
So there is a certain pleasing symmetry in allowing color to manipulated the way that space can be manipulated. I would even suggest generalizing it from an inversion flag to a color scale that could be anything between -1 and 1 (even zero). But this can all be done with rule parameters and I think it is easier to understand if it is done with rule parameters, instead of with more syntax and hidden state. The color target feature has the same issue. I will probably deprecate color targets in CF3 and provide a more CF3-like way to implement the same effect

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

Re: Some ideas for Context Free 3.0

Post by zol » Fri Jan 21, 2011 4:44 pm

Yes, of course. I was still thinking about it from a hidden state cumulative transformation perspective.

Somehow, in spite of frequently searching 'All Pages' in the wiki, I have only just found the 'Version 3 External Reference Spec.' So, I can finally stop trying to guess what's on the cards from everyone's wishlists, and update my thinking.

User avatar
minimaleye
Posts: 14
Joined: Sat Jan 22, 2011 1:03 am

Re: Some ideas for Context Free 3.0

Post by minimaleye » Mon Jan 24, 2011 12:49 am

Hi there!)

I'm playing around with CFA for few days and YES it's really addictive!D

I don't know if anybody already suggested such thing but the first feature that can make the game easier for me will be something like:

Inspecting Element
    when you click on certain element in the render window it simply marks /selects the part/s of code that it coming from...
there is no end...
...therefore there isn't now and here

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

Re: Some ideas for Context Free 3.0

Post by zol » Tue Jan 25, 2011 3:06 pm

Yikes! That is not at all simple.
Apart from the technical issues, I am sure that it would be much, much less helpful than you imagine.

The only "elements" are primitive shapes. Anything more complex is just a pile of independent primitives, very often resulting from different parts and arrangements of code, quite possibly all of it.

The best way to identify which parts of the code are having a particular effect is to comment parts out and rerun it. This gives a general idea of where different effects are coming from.

Once the amount of code is manageable, you can focus on understanding or recreating whichever aspect you are interested in.

Ideas for the interpreter
Not really important, but worth noting down for after the hard stuff is done.
  • block comments
  • explicit code breaks
    • an end of code keyword, so unused code can reside on page with normal highlighting
    • a switch for choosing among different chunks of code
    • I do not suggest generalised conditional compilation however

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

Re: Some ideas for Context Free 3.0

Post by MtnViewJohn » Tue Jan 25, 2011 5:36 pm

It wouldn't actually be that hard. But it would slow down drawing and I agree that it wouldn't be as useful as you might think. And for non-opaque shapes it would be undeniably useless. The easy way to do it would be to maintain a bitmap of shape indices in parallel with the bitmap of pixels. As primitive shapes are drawn in the pixel bitmap their index would be drawn into the index bitmap. I would create a custom pixel blender that overwrites a destination index if the source index has greater than 50% opacity. Then when you click on the pixel bitmap the corresponding index would be looked up and highlighted in the code.

There are block comments already.

I could create a break command that can break out of loops or all the way out of a rule.

There are if statements and switch statements in CF3.

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

Re: Some ideas for Context Free 3.0

Post by zol » Tue Jan 25, 2011 7:23 pm

I was thinking a trace of the entire expansion history was wanted. Maybe that's what you mean and I have overestimated the cost.
MtnViewJohn wrote:There are block comments already.
Guh. So there are. I am an idiot.
I meant top-level compiler directives, sorry. I didn't express it clearly. E.g.

Code: Select all

...
shape VERSION        //active
...
endcode                 //ignore everything after this

shape VERSION        //inactive
...
MtnViewJohn wrote:There are if statements and switch statements in CF3.
Yes, okay. The same effect can be produced using master controller shapes. And it probably isn't such a good idea, I was just taking the above an extra step.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest