Following up from RacketCon, based on some feedback (esp. from Jesse Alama and William Hatch) I've created a tutorial for Qi that includes lots of illustrative examples.
At RacketCon, in the Q&A, Jay pointed out that the SICP eval example I used in my slides only converted the expression to be evaluated into a flow, while leaving the environment alone even though it had a lot of redundant mentions in the body of the function. He posed a challenge to incorporate the environment into the flow too in an elegant way.
Well, I'm pleased to report that I've added an implementation using flows exclusively, incorporating both the expression as well as the environment. Doing this in "an elegant way" required adding a new, intuitive, feature to the switch conditional form. See for yourself at the tutorial linked above whether you think this fully fluid implementation is the best one or not -- it's one of the examples used.
Very interesting, thank you for the announcement! When I was a Haskeller in my previous life, I enjoyed the point-free style, which consists precisely in chaining transformations and avoiding explicit mentions of the argument. The Qi package seems to do this, and way more. Exciting!
As a former Haskeller, I can't help but ask the following question: Is there Typed Qi? Is there a project to make Typed Qi?
Typed Qi sounds like a very fun / interesting project. I don't have a lot of experience with type systems so I don't have much insight to add here, but at arm's length, I think the same considerations would apply to Typed Qi as typed anything - viz. we'd trade flexibility for robustness. E.g. right now flows always accept any number of arguments and fail at runtime if the arity doesn't match what the flow expects. And also, using flows in place of lambdas is a common pattern, like (map (☯ (~> sqr add1)) (range 10)). These would be less convenient if we had to type them, although of course there is a huge upside as well.
But yeah, there isn't already a project underway @scolobb . I'm happy to start something up here if there is community interest!
@jeapostrophe yeah, initially I tried implementing it with switch where both conditions and consequents receive all inputs. In this solution I had to use 1> in all of the predicates, which is essentially car in the (expr x env) case. The third solution in the tutorial is strictly prettier than this one, since it retains the same consequent expressions and also loses the car references in the predicate expressions. Thank you for inspiring it
@Dexter thanks for the heads up! I merged a PR to do a big change in the package structure of the project (to using the lib/test/doc structure that many other projects use), and the package server didn't like it. I reverted the changes last night so it should be back to normal now. Let me know if you continue to encounter issues. I'll probably make another attempt at merging the changes soon, so just a heads up that there might be more hiccups, but hopefully not.
