More useful +diff and +sigh in gall apps #1179
Conversation
|
Am I correct in interpreting this as a shift from |
|
No, from gall's perspective it's a shift from |
|
!>(mark) part surely not that useful...
…Sent from my iPhone
On May 28, 2019, at 4:42 PM, Ted Blackman ***@***.***> wrote:
Am I correct in interpreting this as a shift from [mark vase] to !>([mark data])? That was a change I was pushing for in Ford-Fiesta, and I suspect there are several places we should make that transformation.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
There was a problem hiding this comment.
No, from gall's perspective it's a shift from
!>([mark !>(data)])to!>([mark data]). From the app's perspective, you take off the outer!>, so it's a shift from[mark !>(data)]to[mark data].
It actually took me a little bit of time to see this, but seems clear now.
Also, interesting: I hadn't realised that nothing has been using +diff in its intended fallback mode of sorts.
Suppose
my-markhas typemy-type.In gall apps,
+diff-my-markhandles all%diffcards with markmy-markand takes an argument of type[wire my-type].However,
+diffhandles all%diffcards not otherwise handled, and takes an argument of type[wire cage]. Acageincludesvase, which is very unhelpful (so it was never used).This is obviously wrong. This PR makes it so
+difftakes an argument of type[wire %my-mark my-type]. This gives us a well-typed value, so we can actually do something with this.The same applies to
+sigh, so I changed that too.The motivation for this is in the
philip/tradbranch, where I would like to be able to handle all subscription results in a single arm because the library that creates this arm doesn't know until compile time what are the possible subscription results (it gets the types via|* moldparameterization). Seearvo/lib/tapp.hoon
Lines 149 to 159 in 40c4ea4
in-peer-dataarvo/lib/tapp.hoon
Lines 3 to 8 in 40c4ea4