First release of Goblins, an E-like actor model library for Racket

[Christopher Lemmer Webber]

Hello all,

I've mentioned here before that I'd be working on an E-like actor model
library for Racket named Goblins. The first release is out, and most
importantly, so are the docs:

https://docs.racket-lang.org/goblins/

Stuff that may remind you of E:
- It's an actor model implementation
- E-on-java, it's built on top of another language so we can easily
make use of the goodies available on that language
- The <- "eventual send" operator which promises
- Promise pipelining works
- There are vats, but I have called vats "hives". More on that below.

Things that will be like E, are not supported yet, but are on the
roadmap:
- Inter-vat communication / distributed actors
- Module-level ocap containment. Actually this will be a separate
library, probably named "dungeon" (each secured/contained module
will be a "room")

Other stuff that is different from E:
- By far the most interesting thing, and the most original thing
Goblins is maybe bringing to the table, is the <<- "splitchronous
send" operator. This looks like normal straight-ahead code, but
returns its values to its continuation / raises exceptions on errors
*without* being synchronous, and making no assumption that it is
synchronous. Instead, <<- "splits the turn". I'd be very curious
what people think of this.
- It isn't a full new language but a library; in fact Racket supports
and advertises how good it is at being a language platform, but I
decided not to do that so Goblins can be more easily mixed with other
Racket code, even in multiple racket #langs
- Takes a procedure-first approach rather than method-first approach,
though objects with methods are supported
- Though classes/objects are supported, only Racket style
classes/objects are supported, which work fairly close but are
different in some ways such as its inheritence stuff (Racket's
classes can be composed at runtime though, so it's not so bad). I
might add support for more E-like objects later.
- The naming choice of what the ocap community calls "vats" as "hives".
This is because I discovered this concept independently before
discovering E. When I realized it was the same thing as an E vat, I
renamed hives to vats to be consistent with the ocap community. But
then found out that several people told me they couldn't figure out
what a vat was (in fact, it took me a long time to be sure that
they were the same thing as hives, though I had suspected as such)
but that "hive" was obvious sounding... one person said, "I don't
understand vat, but hive is clear, it's where my fellow bees hang
out". So I switched the name back.
- You can't do synchronous calls on actors directly, but since it's
immersed in Racket's synchronous execution, an actor can always
provide a local-only synchronous version of itself to other actors
in the same vat/hive.

Note that the current release has some known (but should be fixable)
bugs and the semantics might change, so it should not be used for
production code. Nonetheless, I think it's at an interesting enough
point where I'd love to hear feedback.

All the best,
- Chris