From fe823bdbe0a104d5036612873e10ee4e19a21679 Mon Sep 17 00:00:00 2001 From: dann toliver Date: Sun, 19 Jun 2016 13:08:25 -0400 Subject: [PATCH 1/2] footnote change rewording --- dagoba/dagoba.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/dagoba/dagoba.markdown b/dagoba/dagoba.markdown index 1560a9e25..6d8271fe6 100644 --- a/dagoba/dagoba.markdown +++ b/dagoba/dagoba.markdown @@ -93,11 +93,11 @@ children = function(x) { return E.reduce( function(acc, e) { return ~x.indexOf(e[0]) ? acc.concat(e[1]) : acc }, [] )} ``` -Now we can say something like: +Now we can say something like: ```javascript children(children(children(parents(parents(parents([8])))))) -``` +``` It reads backwards and gets us lost in silly parens, but is otherwise pretty close to what we wanted. Take a minute to look at the code. Can you see any ways to improve it? @@ -508,7 +508,7 @@ produces output in one-to-one correspondence with the grandchildren: ```javascript g.v('Thor').in().in().out().out().unique().run() -``` +``` The pipetype implementation: @@ -924,7 +924,7 @@ There are a couple of tradeoffs with this approach: one is that spatial performa This second point isn't usually an issue, because of the phase separation between when our compiler runs its optimizations and when all the thunking occurs at runtime. In our case we don't have that advantage: because we're using method chaining to implement a fluent interface [^fluentinterface] if we also use thunks to achieve laziness we would thunk each new method as it is called, which means by the time we get to `run()` we have only a thunk as our input, and no way to optimize our query. -[^fluentinterface]: Method chaining lets us write `g.v('Thor').in().out().run()` instead of a series of statements that accomplish the same thing. +[^fluentinterface]: Method chaining lets us write `g.v('Thor').in().out().run()` instead of the six lines of non-fluent JS required accomplish the same thing. Interestingly, our fluent interface hides another difference between our query language and regular programming languages. The query `g.v('Thor').in().out().run()` could be rewritten as `run(out(in(v(g, 'Thor'))))` if we weren't using method chaining. In JS we would first process `g` and `'Thor'`, then `v`, then `in`, `out` and `run`, working from the inside out. In a language with non-strict semantics we would work from the outside in, processing each consecutive nested layer of arguments only as needed. @@ -1331,7 +1331,7 @@ after the query transformers have all run. We could run the `times` transformer ```javascript g.v('Thor').out().all().out().all().out().all().run() -``` +``` Then run the `all` transformer and have it transform each `all` into a uniquely labeled `as`, and put a `merge` after the last `as`. From 8f8f70bece679ae25f59fa1559759dceceb81176 Mon Sep 17 00:00:00 2001 From: dann toliver Date: Sun, 19 Jun 2016 16:42:44 -0400 Subject: [PATCH 2/2] wordo fix --- dagoba/dagoba.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dagoba/dagoba.markdown b/dagoba/dagoba.markdown index 6d8271fe6..8fc1614e0 100644 --- a/dagoba/dagoba.markdown +++ b/dagoba/dagoba.markdown @@ -924,7 +924,7 @@ There are a couple of tradeoffs with this approach: one is that spatial performa This second point isn't usually an issue, because of the phase separation between when our compiler runs its optimizations and when all the thunking occurs at runtime. In our case we don't have that advantage: because we're using method chaining to implement a fluent interface [^fluentinterface] if we also use thunks to achieve laziness we would thunk each new method as it is called, which means by the time we get to `run()` we have only a thunk as our input, and no way to optimize our query. -[^fluentinterface]: Method chaining lets us write `g.v('Thor').in().out().run()` instead of the six lines of non-fluent JS required accomplish the same thing. +[^fluentinterface]: Method chaining lets us write `g.v('Thor').in().out().run()` instead of the six lines of non-fluent JS required to accomplish the same thing. Interestingly, our fluent interface hides another difference between our query language and regular programming languages. The query `g.v('Thor').in().out().run()` could be rewritten as `run(out(in(v(g, 'Thor'))))` if we weren't using method chaining. In JS we would first process `g` and `'Thor'`, then `v`, then `in`, `out` and `run`, working from the inside out. In a language with non-strict semantics we would work from the outside in, processing each consecutive nested layer of arguments only as needed.