The basic goal behind these suggestions is to retain the uncluttered and non-intimidating feel of version 2, while providing enough syntactic discipline to avoid ambiguity as well as assist visual navigation and discrimination among different parts of code.
Preliminary assumption: An expression is readily seen and parsed as a single token.
This is important for allowing whitespace to delimit tokens without ambiguity.
Expressions:
Non-simple expressions in foreign contexts are always fully enclosed by parens, "( )", which visually represent a single return value.
This includes function calls: the function name and arguments together correspond to a single return value.
- ([color=#0000BF]select[/color] num (2 - 1) 2 -1 (- 1) (1/2) ([color=#0000BF]sqrt[/color] var))
- [size=85]An alternative is just to prohibit space between unenclosed expression elements. "function(args)" style would therefore also fulfil the main requirement, but it looks more cluttered to me, and the habitual connection between neighbouring words - function and variable names - would go the wrong way.[/size]
Tuples:
Explicit tuples are represented by brackets, "[ ]", with space delimited values.
These include adjustment, rule, and path parameters.
Background, size, and tile directives should probably also use tuples given their limited effects.
Adjustment functions always take exactly one tuple as argument.
- [color=#800000]skew[/color] [30 40]
- [color=#800000]size[/color] 2
In contexts where tokens are required to occur in associated pairs, the parser can pair them correctly without additional clues, and all tokens are delimited by whitespace alone.
- Parameter definition pairing: [color=#000080]type[/color] [color=#008000]name[/color]
Adjustment group pairing: [color=#000080]function[/color] [color=#008000]argument[/color]
Transform type values are defined using adjustment group syntax, including braces.
- myShape [3 {x [1 2]}]
In general, I favour using keywords, tuples and code blocks for a consistent feel, avoiding special purpose syntax.
Variable assignment:
- [color=#800000]set[/color] name value_expression
- [color=#800000]loop[/color] name control_tuple {adjustments}
[color=#FFFFFF]........[/color]loop_body
[color=#800000]finally[/color]
[color=#FFFFFF]........[/color]finally_body
- [color=#800000]loop[/color] count {adjustments} [color=#808080]etc.[/color]
1: count
2: count start
3: count start step
Note that these parameters allow the final value to adjust correctly and automatically with other changes.
Loop 1-tuples do not require brackets.
I think it's clear enough how this style could be applied elsewhere, so I won't spell it out.
Possible extensions:
Parameters:
1) Definitions can have default values, bound to the name using "=" without intervening space.
2) Values can be supplied by name, again using "=" as above, for both shape replacements and adjustment functions.
For illustration only, imagine an adjustment function definition analogous to shape definition
- [color=#FF8000]adjustment[/color] size [[color=#000080]number[/color] x [color=#000080]number[/color] y=x [color=#000080]number[/color] z=1]
Transform type values:
Explicit chaining within expressions.
- myShape {tr (trans & {z -1 s 2})}
- myShape1 {tr trans}
...
[color=#FF8000]shape[/color] myShape1 { myShape {z -1 s 2} }
Other:
I have deleted the original section on re-write filters as I did not explain what I was referring to, nor make a definite proposal.
I will cover them again when I have the opportunity to do a better job of it.