ecfe57b · opencog-atomese-simd

Changed files (1) +22 -1

Design-E.md +22 -1

…	…	@@ -100,4 +100,25 @@ the atomese-simd interfaces.
100	100
101	101	Malleability
102	102	------------
103		What's the point of doing this? Its to
	103	What's the point of doing this? It's to explore the malleability of
	104	interfaces. None of these interfaces are ideal, or even very good. it
	105	would be nice to be able to morph and refactor them, but to do this
	106	morphing and refactoring in Atomese, rather than in C++. So the dream
	107	is to have structures, written in Atomese, and morphisms (rewrite rules)
	108	that map between them.
	109
	110	In principle, the combo of `FilterLink` plus `RuleLink` provide
	111	everything needed to define a morphism. In practice, this seems to turn
	112	into a train-wreck of complexity, as the `RuleLink`s promptly get
	113	complicated and unreadable when given some practical task, such as the
	114	two outlined above.
	115
	116	Perhaps careful modular design can avoid issues. But compositionality of
	117	`RuleLink`s then arises as an issue. So, if I have `(Plus a (Times b c))`
	118	then the first rule to run unwraps the outside `Plus` but leaves the
	119	inside `Times` untouched. We'd need a rule chainer at this point: either
	120	chain the `Times` rule next, via recursive descent, till getting to the
	121	bottom (i.e. depth-first), are some multi-pass width-first appreach.
	122	Width-first is a bit more compatible with lazy evaluation. But
	123	width-first algos are notoriously more complicated than
	124	recursive-descent, depth-first algos. Hmmm.