Syntax for inlining of function calls

[rumblesan]

Currently we support inlining in two forms.

rotate 1, 2 fill red box
rotate 1, 2 >> fill red >> box

Could we standardise on the latter of these? It still gives us a useful inlining short cut, but it's (imho) a bit easier to see what's an argument and what's a function.

Also it's a damn site easier to parse, and would mean that I'll be able to extend it to work with arbitrary functions more easily.

[davidedc]

That separation is not a difficult part to do - I do that separation part in 134 badly-written lines in two functions called in sequence (findQualifiers and fleshOutQualifiers) here https://github.com/davidedc/livecodelab/blob/master/coffee/languages/livelangv1/code-preprocessor.coffee#L1080-L1214

before those two functions the input is rotate 1, 2 fill red box and after those two functions becomes rotate 1, 2, -> fill red, -> box;;

(I then need more transformations, but that's where all the "chevrons" positioning is done).

And I made no attempt to be short about it and I'm sure that there is redundant code in there, it's probably just 1 screen of clean code rather than my 3... and I have no clever tokenisation in place which I think you have in place, so really the matching/transformation in your situation would be shorter and cleaner...

It's just unnecessary symbols, and it's so much easier not to use the chevrons, in fact I never used them, so no I don't think is good to mandate them.

[rumblesan]

heh fair enough if you want to keep it working without the >> operator. was asking incase I could make my life easier :)

I'm realising that I'm going to have to have a more extensive rewriter/preprocessor anyway. I'm adding in support for using closures as arbitrary expressions, so we can more easily pass them into functions without having to assign them to variables before hand. turns out that because we don't have a prefix for closures, it's really difficult to parse.

Ah well :p