-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PutLink specification of executable parts #577
Comments
Well, there are several issues. One is that, right now, As to what should happen, that is unclear. In the common case, it is desirable to execute everything, all the way down -- all the nesting and wrapping and etc. I suppose that, in some cases, maybe one wants to do only one layer, and no more. I don't know who would want to do that or why. I'm not sure what the gig is with Again, its not entirely clear what should happen. If one is nesting these arbitrarily deep, one will typically want to execute everything (lazily) all the way down, but if one is searching for things that are executable, then maybe not. I currently do not have any clear answers for "what should happen", since the most-common use case seems to contradict the more narrow ones. What does haskell do? |
lazy execution issue tracker here: #583 |
Indeed the problem with BindLink is that it executes the searched results, just like PutLink would if you hand it the searched results. I also don't know if that has to be feature or a bug. Haskell is lazy by default but uses https://prime.haskell.org/wiki/BangPatterns when you want a variable to be eagerly evaluated. Basically just put ! in front of it. -- lazy
let y = map foo x -- eager
let !y = map foo x I guess for now we could have execute functions, cog-execute! that is lazy, and cog-eager-execute! that is eager (or maybe remove the ! at the end of cog-execute! for the lazy version, but I don't know if that's good scheme practice). |
well, the problem is with nesting: you can have gets inside puts inside gets inside puts, ad infinituum, with other functions (plus, times. etc.) intervening. Which suggests that we should invent BangLink and LazyLink and use those to wrap things appropriately. Ugh. I would rather not invent yet more link types unless they are really really needed. I feel like I've opened some pandora's box with all these link types, and now the lid won't close. |
The very very last example in https://github.com/linas/atomspace/blob/master/examples/guile/map.scm fails, due to eager evaluation. Hmm.. Although I guess I could work around that in other ways... |
There is a new atom, called DontExecLink http://wiki.opencog.org/w/DontExecLink It was added in pull req #714 to fix issue #704 Maybe this will serve your purposes? |
Yes, |
I just want to be sure I understand PutLink specification correctly. On the wiki http://wiki.opencog.org/wikihome/index.php/PutLink it says
"The PutLink consists of a graph, with a set of variables in it. It is followed by a list of values. When the PutLink is executed, with the cog-execute! function, the variables are replaced by the values, to create a new graph. That is, cog-execute! function performs beta reduction on the PutLink. "
It's not clear from that comment whether it is supposed to perform just a single step of beta-reduction or more.
I noticed that it executes as well the substituted parts that are executable, see the following
The result is
that is plus and times are executed. I'd to know if that is considered a bug or a feature. If that's a feature I'll update the wiki accordingly (cause it's nowhere mentioned).
There's perhaps a disadvantage with that, as far as I'm currently concerned anyway, I cannot use a BindLink to query and build patterns involving executable parts. For instance the following
is gonna return
there seems to be no way of creating my pattern of Plus and Times. I tried using Quote/Unquote, but no way. The only way I found is to manually reconstruct them with Atom constructors after querying them with GetLink only. See the following
Here of course the example is trivial, but my use case involves more complex things (embedded ExecutionOutputLink in patterns, I just tried to build a really simple example here).
The text was updated successfully, but these errors were encountered: