path: root/starts/meaning-vm/habit-starts/learning-parts.cpp

#include "learning-parts.hpp"

/*
# "How do you think we could show better understanding of the things we are disregarding?"
# "If we do understand these, can you help us?  Do you know who can?"
*/

// idea of learning to keep well having more process time and
// priority than risky behaviors

/*
idea of a secret group attacking a present group, and the attackers being
the only channel to deal with it.
        if we talk, we need nobody to _ever_ know this.  the walls all have ears;
        I was one of them. [from eastern half of continent where a targeted
        activist was living alone]
*/

using namespace habitstarts;
using namespace intellect::level2;

// Propose:
// 	everything that happens is passed to a set of common habits.
// 	these habits categorize, summarize, and pass to relevent habits.
//	high level triggers are thus efficient, because they respond only
//	to the group that applies to them.
//	these habits must be learned.
//	when providing a trigger at a high level, provide a way to get examples
//	of what it should and should not trigger for.  this provides for learning
//	how to do this.
// the above looks like relevence to me.  propose learning it.
//	to learn most effectively, apply to process of learning.
//	how do we adjust from success or from failure?  need some attribute
//	of scenario to store for next time, to respond to differently.
//	so when we do something, we'll want to be able to store all information
//	needed to learn to improve.
// we can include in this the meaning of a concept, and add language translation.
// is this 'apple'?  is this? yes, no.  then pattern recognition could engage
// triggers.  later we'll want to propagate wrongness from failures.
// likely we'll grow better if we use this on things before they have words.
// 	// propose using random or exhaustive trial to find successes until habits develop
// 	// and then using the same on possible structure matches of the data
// 		// it may not work, we'll need to creatively grow data; reaonable start though

static int __init = ([]()->int{

	decls(link, source, type, target);
	ahabit(link, ((source, s), (type, t), (target, dst)),
	{
		s.link(t, dst);
	});

	// we want the habits expressive enough to code efficiently in.

	// constructors are tentatively abolished in the low-level habit language. (new-thing modifies, not creates)
	// we have one constructor of concepts, and knowledge attachment to concepts.
	
	decl(make, know, concept, is, group, already, in);
	ahabit(make-concept, (),
	{
		result = a(concept);
	}); 
	ahabit(know-is, ((concept, c), (group, g)),
	{
		if (c.linked(is, group)) {
			throw an(already-in-group).link
				(habit, self,
				 context, ctx,
				 concept, c,
				 group, g);
		}
		c.link(is, group);
		result = c;
	});

	// separate habits and behaviors.
	// behaviors are modifiableb data run hy immutable habits.
	// they use translation maps to move concepts between
	// subhabits.
	// 	translation map is just list of equivalent pairs
	
	// note: lisp can self modify; would need wrapper
	// constructors to make functions and lists into
	// concepts.
	// 	remember can google how to debug lisp
	// opencog does concepts in lisp already, is heavyweight
	// with few habita.  just want goertzel's effort honored,
	// he came up with it before I did.
	// 	opencog has functions for pattern matching etc
	// 	they arent self-modifiable, may not matter
	
	
	decls(ordered, behavior);
	// need args and result for sequence
	//ahabit(habit-sequence, ((
	
	decls(list, nothing, next, previous);
	decls(make, add, to, until, each, item, in, remove, from, somewhere);

	// these below comments were written during recovery of this document
	// hmm work was also lost.
	// 	we got to the point of separating habits from behaviors.
	// 	behaviors are modifiable.  habits have code.
	// 	so, habit-sequence is a behavior.
	// 	we also made behaviors that describe/mirror habits, and were
	// 	confused over how to handle rewriting them before we knew how
	// 	to rewrite habits.  should be solved by impact management.
	// is also nice to have habits and behaviors be same thing
	// could pick one or the other to use depending on presence of triggers
	// or temporary change or something. dunno.
	// 
	// 	hey in the notepad, you can call habits from outside.  is that ok?
	// 	only meaningful if you pass to them more code to run?
	// 		note: habits never recurse
	// 	habits might make decision based on you.  they will track it.
	// 	seems okay.  need to specify that all parameters are from output.
	// 		that could make exponential slowness, quickly
	// 		only if decision is made. make decisions inside notepad.
	// 	we'll figure it out.

	ahabit(make-list, ((list, l)),
	{
		result = a(list, l);
		link(result, first-item, nothing);
		link(result, last-item, nothing);
	});
	ahabit(add-to-list, ((item, i), (list, l)),
	{
		ref prev = l.get(last-item);
		ref li = a(list-item);
		li.link(item, i);
		li.link(next, nothing);
		li.link(previous, prev);

		if (l.linked(first-item, nothing)) {
			l.set(first-item, li);
			l.set(last-item, li);
		} else {
			ref prev = l.get(last-item);
			l.set(last-item, li);
			prev.set(next, li);
		}
	});
	// TODO: this is a useful function with way too much verbosity
	// please make it simple, later.
	ahabit(until-each-list-item-context-in-list, ((action, a), (context, c), (list, l)),
	{
		ref cur = l.get(first-item);
		while (cur != nothing && result == nothing) {
			result = a(cur, context);
			cur = cur.get(next);
		}
	});
	ahabit(remove-from-somewhere-in-list, ((item, i), (list, l)),
	{
		result = (until-each-list-item-context-in-list)(
			ahabit(self-iter, ((list-item, i2), (remove-item, i)),
			{
				if (i2.get(item) == i) {
					result = true
					ref prev = i2.get(previous);
					ref n = i2.get(next);
					if (prev != nothing) {
						prev.set(next, n);
					}
					if (n != nothing) {
						n.set(previous, prev);
					}
					i2.unlink(previous);
					i2.unlink(next);
					i2.unlink(item);
					dealloc(i2); // hmm.  we do have an active goal of making memory allocation be habit based.  this might work here, though.
				}
			}),
			i, l);
	});

	ahabit(happened-habit, ((happened, ev)),
	{
		// TODO: perform each event associated with happened

		if (!happened.linked(whenever-list)) { return; }

		(until-each-list-item-context-in-list)(action-whenever-happened, ctx, happened.get(whenever-list));
	});

	ahabit(action-whenever-happened, ((list-item, li), (happened-context, hapctx)),
	{
		// here: when we trigger a behavior, we want information associated with producing the trigger,
		// as well as the event that triggered.  that's two contexts.

		// list-item has item
		// item has action and context
		ref i = li.get(item);
		// i think below we are proposing that handlers
		// take one context, which is the one prepared
		// in the list, then we inject our context
		// into that, inside a "happened" property.

		i.get(action)(hapctx, i.get(action-context));
	});

	ahabit(whenever-habit, ((happens, ev), (action, act), (action-context, actctx)),
	{
		if ((action-context).linked(happened)) {
			throw std::logic_error("happened on action-context");
		}
		if (!ev.linked(whenever-list)) {
			ev.set(whenever-list, (make-list)(nothing));
		}
		ref list = ev.get(whenever-list);
		// happens gets the list
		ref item = a(whenever-action);
		item.set(action, act);
		item.set(action-context, actctx);

		(add-to-list)(item, list);
		// store ctx[action] on ctx[happens] as behavior to do
		// store ctx[action-context] as context for behavior
		// PROPOSE: automatically place [happened] inside [action-context] as a stub
		// for call event objects, and then place [context] inside [happened].
		// PROPOSE: report error if [action-context] contains [happened]
		// 		as a stub for error patterns, it would be pretty nice to throw
		// 		a unique concept ref for each error type.  plan to add to level-0.
	});

	ahabit(stop-when-habit, ((action, act), (happens, ev)),
	{
		// remove doing ctx[action] for ctx[happens]
	});

	ahabit(once-habit, ((happens, ev), (action, act), (action-context, actctx)),
	{
		// takes ctx[action] and ctx[happens] and ctx[action-context]
		// uses above habits to do the action only once, probably by using
		// a trigger on the habit-happening habit to check if a label is set,
		// and remove the habit if it is.
	});

	return 0;
})();
diff --git a/starts/meaning-vm/habit-starts/learning-parts.cpp b/starts/meaning-vm/habit-starts/learning-parts.cpp
index ee55b04..09c7b64 100644
@@ -1127,10 +94,13 @@ static int __init = ([]()->int{
 
 		if (!happened.linked(whenever-list)) { return; }
 
-		(until-each-list-item-context-in-list)(action-whenever-happened, ctx, happened.get(whenever-list));
+		ref stub = a(event);
+		stub.set(event, ev);
+
+		(until-each-list-item-context-in-list)(action-whenever-happened, stub, happened.get(whenever-list));
 	});
 
-	ahabit(action-whenever-happened, ((list-item, li), (happened-context, hapctx)),
+	ahabit(action-whenever-happened, ((list-item, li), (event, h)),
 	{
 		// here: when we trigger a behavior, we want information associated with producing the trigger,
 		// as well as the event that triggered.  that's two contexts.
@@ -1142,8 +112,11 @@ static int __init = ([]()->int{
 		// take one context, which is the one prepared
 		// in the list, then we inject our context
 		// into that, inside a "happened" property.
+		ref actctx = i.get(action-context);
+
+		actctx.set(happened, h);
 
-		i.get(action)(hapctx, i.get(action-context));
+		i.get(action).fun<ref>()(i.get(actctx));
 	});
 
 	ahabit(whenever-habit, ((happens, ev), (action, act), (action-context, actctx)),