On Tue, Dec 28, 2021 at 8:11 PM Luke Peterson <[email protected]> wrote:
> I concluded that the Rust trait system and dyn dispatch mechanism was a bad > fit - at least without quite a bit of additional plumbing and glue. Things > it needs to do in order to perform the compile-time monomorphization prohibit > the kind of fast-and-loose polymorphism that you need. Speaking of polymorphism, I've discovered that OCaML has a similar set of issues. My zeroth impression was that it's a modern typed functional language with high performance. Should be a good fit for the AtomSpace, right? Nope. After fiddling with it for a few weeks, I "discovered" the OCaml type system was static, compile-time typed, and there are no provisions for run-time type-casting/polymorphism. That means, for example, if I define a type "Atom" at the beginning, and then, minutes or hours later add something like ProteinNode, there's no way to pass this to something expecting an Atom; conversely, given an Atom, there's no way to discover it's actually a ProteinNode. (no polymorphic lists, either) Of course, this could be made to work with a lot of extra "plumbing and glue", but adding that plumbing defeats the whole point of having the OCaML type system, which was (*) type safety (*) compile-time optimizations. More about that here: https://github.com/opencog/atomspace/tree/master/opencog/ocaml ----------------- Reading about Rust, I see "traits" as an important language feature. Reading about traits says that both Haskel and OCaml can support them ("easily"??) I don't know OCaml well enough to figure this out, or if this would be a good match for the atomspace type system. I'm utterly lost as to vsbogd's issues, or what alice & quinedot wrote. Which leads to some other off-hand comments: the reason the atomspace keeps getting smaller and simpler is so that .. well, complexity and over-engineering is the enemy. One should always try to keep things as simple as possible. This helps avoid hard-to-debug problems, and it also helps performance. (Those paying attention might have noticed some large parts of the atomspace were nuked to oblivion in the last 6 months. It's gotten smaller and simpler... again.) One humble suggestion for hyperon: instead of trying to reinvent the atomspace, you might have more luck and less expended effort by just ... using the atomspace as-is, and layering what you need on top. Don't create headaches where they don't need to exist. Focus on doing the experiments that you need to do, get them to work right. After they work, after you get good results, then and only then start thinking about what kind of infrastructure you need. Don't put the cart before the horse. Don't over-engineer. Everyone here has observed that I do most of my work in scheme. There's a reason for this: when coding in scheme, one never-ever runs into problems where the language/compiler is trying to stop you from doing "the obvious thing" (as OCAML is doing, and as Rust is doing, apparently.) This flexibility of being able to do anything you want, anything you feel like, without having to stop to ask questions on stackexchange, is one of the huge benefits of scheme/lisp. Socially, though, it is a curse: because everything is so easy, programmers never feel much of an urge to standardize anything, instead working happily with their home-grown solutions. There is a worthwhile essay about this to read and ponder: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html I think the above essay explains vsbogd's problem with Rust. (about 5 paragraphs down.) Since I'm on the topic: perhaps my biggest #1 greatest "discovery" about the atomspace is that it would be really really really nice to have a vector (matrix, tensor) API to it. To be able to say "here's a vector of Atoms". Because, well, vectors are really really useful. I implemented one, its here: https://github.com/opencog/atomspace/tree/master/opencog/matrix Unfortunately, it is in ... scheme, so the pythonistas and rustaceans are out of luck. Someone should recreate this API in C++ (and thus get R and python bindings "for free") ... Why the heck am I talking about this? It's an example of a "discovery". I didn't start with a profound theoretical insight or fundamentalist proclamation. I started with a tiny collection of small-time utilities to make writing code easier. Over time, it evolved and got more sophisticated, as the actual needs became clear. Now that the shape of the thing is clear, and the need for it is fairly obvious, one can go back and "harden" the code, formalize it, rewrite it, tune it, optimize it. Put the horse before the cart: Let experiments and quick-n-dirty attempts be the horse. They'll pull the cart of infrastructure, the code base, in the direction you want to go in. Find what works, first. Make it industrial-strength second. -- Linas -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34VC1a46TUFZ_zzVpOtJUUZgZOM4YebidmaumjcWdzR7w%40mail.gmail.com.
