| … | … | @@ -74,6 +74,8 @@ which would return the desired initial embedding. This works. Some |
| 74 | 74 | problems: |
| 75 | 75 | * Requires actually creating the Link. But this link is not really |
| 76 | 76 | needed for any kind of long-term use/re-use. |
| 77 | * But this is not really a problem, after all. Just use `ValueOf` or |
| 78 | `PureExec` to pipe Atoms into this. See hand-wringing agonizing below. |
| 77 | 79 | |
| 78 | 80 | A new-style OO API could be |
| 79 | 81 | ``` |
| … | … | @@ -98,3 +100,56 @@ But this is terrible, because the URL is ugly. |
| 98 | 100 | |
| 99 | 101 | Overall: the OO API seems pointless and useless. |
| 100 | 102 | |
| 103 | ### Stateless Executation |
| 104 | A meta-problem might be that we needs something in between `cog-execute!` |
| 105 | and `cog-set-value!`. The problem with `cog-execute!` is it takes just |
| 106 | one argument: the Atom to execute. Thus, a Link must be created to wrap |
| 107 | arguments (e.g. `ExecutionOutputLink` as the prototypical, canonical |
| 108 | example.) The `cog-set-value!` avoids this, as it specifies keys and |
| 109 | arguments. The problem with it is that it is completely async: it has no |
| 110 | return value; useing `cog-value` to read the result forces it to be |
| 111 | stateful. Thus, a completely stateless intermediate form between |
| 112 | `cog-execute!` and `cog-set-value!` is desirable. Or so it would seem. |
| 113 | |
| 114 | The backwards compat solution would be to change `Atom::setValue()` to |
| 115 | not return void, and so on down the line. So `(cog-exeucte! (SetValue...))` |
| 116 | would then return not VoidValue, but something meaningful... |
| 117 | |
| 118 | It seems like having this might make it easier to specify flows. For |
| 119 | example, this would allow us to ditch things like `ExecutionOutputLink`. |
| 120 | But is anything really gained, here? Analysis of the flow of control |
| 121 | seems to get ... more complicated. Hmm. All this is very unclear. |
| 122 | |
| 123 | Conclusion: This is some kind og agony hand-wringing. We already have |
| 124 | everything needed with things like `ValueOf` link, and the executable |
| 125 | atoms that return `QueueValue` and whatnot. We can just pipe things. |
| 126 | So the answer is: don't change anything. What we have already is just |
| 127 | fine... |
| 128 | |
| 129 | ### Embedding Flow. |
| 130 | |
| 131 | Another "fix" for the flow situation is to write |
| 132 | ``` |
| 133 | (cog-execute! |
| 134 | (VectorEmbedLink |
| 135 | (ValueOf (Anchor "somewhere") (Predicate "some key")) |
| 136 | (NumberNode 768) |
| 137 | (TypeNode 'Float32Value))) |
| 138 | ``` |
| 139 | and so the generation of the initial embeddings becomes a flow. |
| 140 | If its a query, then |
| 141 | ``` |
| 142 | (cog-execute! |
| 143 | (VectorEmbedLink |
| 144 | (PureExec (QueryLink ...)) |
| 145 | (NumberNode 768) |
| 146 | (TypeNode 'Float32Value))) |
| 147 | ``` |
| 148 | |
| 149 | Then write to where the embedding will be stored: |
| 150 | ``` |
| 151 | (cog-execute! |
| 152 | (SetValueLink |
| 153 | (Anchor "some place") (Predicate "some embedding key") |
| 154 | (VectorEmbedLink ...))) |
| 155 | ``` |