Sebastien Bourdeauducq wrote:
> How will this "per-frame" omission be done?
It's simply that per_frame= and per_vertex= switch the default
assignment target. The new parser doesn't even know where there
are newlines - they are all treated like spaces by the scanner.
> I would prefer to have special statements (that do not appear in MilkDrop),
> such as:
Right now, it's as follows, with indentation to emphasize the
structure:
foo = 1
bar = 2
per_frame=
foo = foo+bar
bar = sin(time)
per_vertex=
foo = expr
bar = whatever
(You could also put whitespace between per_frame and "=", etc.)
> [initial]
I don't like the [...] syntax too much, although it's popular.
But I was thinking of adding a per_frame: variant, that would
just have the same semantics, but looks different from an
assignment.
> This way we retain MilkDrop compatibility (by assuming [initial] mode at the
> beginning of the patch).
Yup, that's how it works today.
> Otherwise, code such as:
> per_frame=eq1
> eq2
> would treat both eq1 and eq2 as per-frame, while MD treats eq1 as per-frame
> and eq2 as initial condition.
That's where the new parser differs from MilkDrop. Since it has
only the vaguest glimpse of where newlines are, it can't switch
back to initial/global if it sees one.
I could try to add this as a compatibility feature, but it
would probably make the scanner and parser messy.
At least with the per_frame: syntax, it may also make sense to
enforce an initial - per_frame - per_vertex sequence, with each
patch being allowed at most one per_frame: and per_vertex:
> (By the way: my parser only allows initial condition 'equations' in
> the simple
> case where the right member is simply a constant. MD allows math expressions
> to be written here. This isn't a priority as most presets use constants, but
> could be a small addition.)
Ah yes, I was wondering about that :-) Compile-time evaluation
of constant subexpressions - anywhere - would definitely make
sense.
Do we have any other good MilkDrop features that are currently
missing ?
>> foo = bar ? sin(time) : 1-cos(time)
>
> I'm for this option.
Great. I'm also considering getting rid of the operator
precedence directives and just express precedence within the
grammar, following the example of K&R 2nd Ed. This needs a
few more rules but tightens the semantics.
- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
