Hummus followed by tart?

[ghost]

I was avidly following the Hummus blog to learn about the pure actor model and managed to get a basic framework running on iOS using GCD and blocks.

I have missed the Hummus blog posts and return now and then to see if there have been any updates.

Googling for Dale by name resulted in finding this new set of repos and I am intrigued to find out more.

Is tart a pure actor framework following in the foot steps of Hummus or does it try to address a different set of problems?

Andy

[dalnefre]

Thanks for your interest in our project. I'm glad to hear that you are experimenting with your own implementation. I believe that is one of the best ways to learn. Sorry I haven't had the time to blog. I'm still very interested in developing insights into the Actor Model.

Tart is an experiment used to gain insight. It is an attempt to build a system that is "actors all the way down", at least to the level of the Von Neumann machine. It is one of several iterations on this idea. We're not sure how far we'll take this experiment before deciding if it merits promotion into the core of the Organix operating system.

Some other likely building blocks include mechanisms for implementing a variety of programming language constructs, but based on an asynchronous actor-messaging core. We're likely to implement Humus on this foundation, but also other more well-known languages, demonstrating the versatility of the platform.

Humus (like dirt, not food) is a "simple" pure-actor language that I still use to prototype and communicate ideas. After considerable use, I've decided that I overlooked first-class pattern-matching mechanisms and failed to make the language homoiconic. I'd like to remedy both of these issues in a successor to Humus. However, Tart/Organix will not fill that role, since it is a platform rather than a language.

[tristanls]

Hey Andy,

To speak to some of the experimentation Dale mentioned... One of the experiments was colart, which attempted bootstrapping a minimal object model on top of an actor system. It could support, for example, all sorts of different object paradigms such as multiple inheritance, hierarchical inheritance, prototypical inheritance, etc. It is not fully correct yet, but there is a way forward to make it correct. However, colart development is paused for now.

Also, if you take a look at universe.c or expr.c (check out the test functions at the bottom for usage examples) you can start to see the machinery to support various language constructs required for implementation of a Humus successor and other languages like JavaScript, for example.

The way I think about Tart is a "machinery-first" approach (and as minimal as possible), a sort of "engine" for Organix. I believe that actor languages, without an actor operating system, will ultimately run into synchronous constructs and assumptions that were made that are incompatible with actor ideas. Dale has been doing excellent work providing powerful mechanisms at the lowest level possible in order to create a toolkit to express everything in actors. One of my favorite code examples of this are things like:

extern Actor    req_call_new(Actor ok, Actor fail, Actor selector, Actor parameter);

And by the way, the Actor result of that constructor is a message that is sent to another actor 😄. And it runs.

Cheers!

[ghost]

Dale, Tristan

Thanks for the feedback, I shall follow your progress here with interest, is this the home of the Organix operating system or are there other references or papers I can read?

Dale, apologies with the Humus mixup, thinking with my stomach again!

I am way behind the curve on language design/concepts but your reference to 'homoiconic' is very interesting.

In my project data is represented as RDF triples, data is manipulated using SPARQL language, but I am now starting to store SPARQL queries/constructs using SPIN, which stores SPARQL statements as RDF triples. So SPARQL as a language it is now capable of manipulating itself at runtime by querying and modifying SPARQL stored as RDF triples. This looks like it meets the requirements of 'homoiconicity'?

I am playing with the idea of using SPIN statements as behaviours, they can define guard conditions as queries on RDF triples providing pattern matching, and through rewriting could change actor behaviour. Messages would be RDF triples, representing a graph or dataset.

I have not done much with this yet but it's a long term project I'd like to explore.

[tristanls]

The Organix project is still new-ish, so the GitHub Organix organization is the home for what exists right now. There are other resources scattered, as well as previous experiments that have not made their way into Organix. The focus currently is on getting the fundamental mechanisms to work. I hope to be able to provide more context, content and make the project more accessible once these fundamentals settle.

I'm not familiar enough with RDF/SPARQL/SPIN to comment.