https://newkrok.github.io/nape-js/examples.html?open=soft-body&mode=3d&outline=0 #gummybears #simulation #TypeScript #HackerNews #ngated
The Task implementation I have is basically the I/O Monad with an Error type, except it doesn't assume that there's infinite recursion depth in whatever interpreter is running the code.
Something like a lazy stream, perhaps.
It should allow me to write a trampoline based interpreter, which makes the most of single threaded situations with minimal overhead, as well as handle asynchronous effects.
There's an aphorism from way back that monads are promiscuous and arrows are meticulous.
If you can have the inputs' structural type figured out by the compiler, like you can in Haxe, arrows are a lot less meticulous because *most* what you're doing then is an I/O monad with the output of the arrow and the meticulous only when you need the extra power you get with ArrowApply.
I'm using Task to build an Arrowlet for the Eff monad.
It'll have a lot better runtime characteristics than the current Fletcher runtime, as there's only one or two extra calls for pure functions when running function Tasks.
In this setup, nothing really is asynchronous except the interpreter, so it can crunch on task processing on a single thread without interruption unless or until a Task reports WAITING, no hoisting by default, which was the case with Fletcher.
It's basically a lot of squinting at type definitions and cranking through logic, but it's all there.
So, I've been thinking of expanding my game dev vocabulary. I'm pretty good at Javascript and Lua and know a bit of C (but don't like it much). But I'm looking for a language/system that will run on/compile to web, desktop, and preferably #Playdate as well. What do you recommend?
(Recommendations and advice in the comments are highly appreciated.)
The Virtual Type `I` acts as a key for the input context you need to run the effects.
Haxe doesn't know what type it is, but it'll structurally accept anything that fits, which is a valid type system key.
flat_map in this instance produces an effect that requires both input requirements to run.
#Haxe #DevLog
Going back to dealing with recursion around types.
I had a smudge around it, but it's become clear that for my purposes, parametrised types are identical, and it's the parameters that differ between declaration and application.
That gives me two forms. a couple of the parametrised type and it's parameters, and a couple of it's Ident and the parameters where there has been recursion further up the datastructure.
This should allow for printing and rehydration of the underlying types.
Doing this knocked out the other part of the smudge which is classtype recursion and maybe classfield recursion.
I need to dream up a bunch of weird classes to figure that out.
Again, it needs to be leafy rather than loopy for i/o and general sanity.
The leafs of TASL schemas are URIs, say `https://schema.org/Person`.
You might have a Product (as in product/coproduct), and one of the fields is person : Person.
To rehydrate the schema, you have a construction, which is a bunch of slots, each with a key and through some expression it's unfolded value.
In this case the slot would have an expression mapping perhaps to the id of a person, if that's what you were using, or perhaps to a partial representation, or so on.
I suppose to get further and more complete representations of object trees, you can add another slot to a particular construction with a longer expression.
Here's the expression language in TASL, I think I've captured it, I need to write an interpreter.