Praxis – A live coding environment based on Lua, Lisp and Forth
1–10 of 22 posts
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#2Is a language environment really live if it does not support interaction or encapsulated state (inside rather than outside of the render loop)? Is it really live if you have to manually refresh your code?
Well, I guess it does fit the requirements of live coding.
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#3If you're interested in this then you should definitely checkout extempore:
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#4Is a language environment really live if it does not support interaction or encapsulated state (inside rather than outside of the render loop)? Is it really live if you have to manually refresh your code? Well, I guess it does fit the requirements of live coding.
> supporting interaction or encapsulated state
I don't know what you mean. Could you give an example of this? What would you like to be able to do?
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#5Is a language environment really live if it does not support interaction or encapsulated state (inside rather than outside of the render loop)? Is it really live if you have to manually refresh your code? Well, I guess it does fit the requirements of live coding.
> supporting interaction or encapsulated state I don't know what you mean. Could you give an example of this? What would you like to be able to do?
Your render loop looks like:
while true:
renderP()
var state = initValue
while true:
renderP(ref state)
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#6Also see:
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#7Earlier quoted context omitted.
> supporting interaction or encapsulated state I don't know what you mean. Could you give an example of this? What would you like to be able to do?
Your render loop looks like: while true: renderP() Now, renderP will get executed afresh each time. Assuming no static data, if you want any state at all it must be global to the loop; e.g. var state = initValue while true: renderP(ref state) Immediate-mode UIs suffer from the same constraint, and really, the author is getting most of their liveness by being immediate.
What about the old let-over-lambda?
do
var state = init
fn renderP()
...
end
end
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#8So far all of the live coding demos were about graphics. I wonder if it's possible to do something similar with something of a much less interactive nature - say, number crunching, compilers, linkers, etc.
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#9So far all of the live coding demos were about graphics. I wonder if it's possible to do something similar with something of a much less interactive nature - say, number crunching, compilers, linkers, etc.
The whole thing is a repl with a graphical and audio engine at your disposal to use as you see fit. As well as writing your program iteratively in the "socratic" repl style, you are free to fluidly create whatever visualizations you wish along the way to help you. As well as this, if you split the process you have implemented into frames (a simple way is with coroutines or closures) you can make whatever visualization you prefer of your number crunching. For example, throw in some yield() calls in your program and every update() do a coroutine.resume(). In render() visualize the state of your program how you wish. The great thing about this is, as you change your program, the effect of your change will be reflected in what is rendered.
Re: Praxis – A live coding environment based on Lua, Lisp and Forth
#10Earlier quoted context omitted.
Your render loop looks like: while true: renderP() Now, renderP will get executed afresh each time. Assuming no static data, if you want any state at all it must be global to the loop; e.g. var state = initValue while true: renderP(ref state) Immediate-mode UIs suffer from the same constraint, and really, the author is getting most of their liveness by being immediate.
What about the old let-over-lambda? do var state = init fn renderP() ... end end Depending on what you wanted the state for, I think it satisfies most of the properties you'd be missing with a persistent, not-in loop state. It wipes itself on refresh, it has a distinct owner, it can be individually refreshed just by re-evaluating everything inside the do-block, etc.
Thank you for that succinct and immediately useful example of let-over-lambda!