> [0,1,2,3].permutations;
> When you mess around with the text, you
are messing around with the semantics of the language (as the two examples
above should highlight).
Certainly code text changing could be somewhat disruptive for a programmer so there may be some sort of cognitive issue with text substitution strategies.
Still a cool idea and I can see specific settings where it could have good properties. Charlie uses Rand in his video, and that one actually seems to work. Here are other examples that came to mind reading Andrew's post:
Say something like permutations is used temporally. And it is an operator that rather than explode all possible permutations, iterates through all possible permutations.
For example if at T1 the code text reads [0,1,2,3].permutations; and at T2 it reads [0,3,1,2].permutations; etc . This would actually add clarity to the text (by making the "current" state explicit) while remaining syntactically correct.
If the program is paused and resumed this would actually have the neat advantage of visibly retaining the correct "seeding position" of the "active" permutation. You'd need to reset that seed when the program is run from scratch, but that's not a huge issue.
Reverse in a temporal loop also seems to have these properties. At T1 the code reads [c,d,e,f#,g].reverse; at T2 it reads [g,f#,e,d,c].reverse; at T3 it reads [c,d,e,f#,g].reverse; etc. I.e. it could get the identical advantage of making state explicit and robust through pause/resume.
Of course this does assume a specific temporal realization of .reverse/.permutation/.rand, but seems quite doable.
But it is a specific set of in-place substitutable things (perhaps with some additional invariants attached) where something like this can work out and have some added benefit.
In the big picture, I think the question how we can relate run-time state back into the code representation is really important and interesting. Could be a fun thing to try to actually sketch out a language with the property that all run-time states/consequences induced by code must have a visualizable code-side representation.
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/SB05bOx0znBLOby5zA6US
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Sat Jan 31 2015 - 02:04:57 GMT