Back when I was looking at hosting Ruby on Smalltalk VMs, I was playing around with parsers and compiler-compilers.

From what I saw, the Ruby language has about 108 terminals+nonterminals in its grammar.

Python has something like 29 term+nonterm.

Smalltalk (an advanced dialect with namespaces and syntactically distinct class bindings) has 8 term+nonterm.

The Ruby syntax is about 3X bigger than Python's, which in turn is about 3X bigger than Smalltalk's.

I'd like to peruse the syntax of Fancy. If it's significantly smaller than Ruby's, then programming tools will appear in the Fancy community at a much faster rate than they did in Ruby. If large swathes of it are homomorphic to Ruby, then lots of Ruby library code could appear in Fancy at a high rate.

EDIT: Yes, size of the syntax is a real consideration. Just two guys wrote the widely used Refactoring Browser for Smalltalk, which includes a recursive meta-syntax parser engine. I have hand written a top-down parser for Smalltalk, and I completed it in just one afternoon. Contrast this with the situation several years ago, of multiple teams of Ruby syntax "study groups" that each labored many months to produce parsers outside of the Matz Ruby VM. (Yes, an "interpreter" is still a VM! The distinction is nonsense at this point.) Smaller syntaxes mean faster language/tool innovation!

Out of curiosity, by parsers and compiler-compilers did you mean Lex and Yacc? It is always a significant undertaking to implement a dynamic language in that way.

Lex, Yacc, the RBParser, and SmaCC, and perhaps some others.

Thanks for the info. Surprisingly, when I was googling RBParser, I got two different results: one being the RBParser class from Smalltalk (I guess that's the one you meant), the other is a new project with the same name hosted on github [1] -- a Ruby code parser written in OCaml. Both make perfect sense in my search.

[1] "Pure and fast Ruby source code parser for OCaml" https://github.com/m2ym/rbparser

When I saw that this was inspired by Erlang, I expected to see light-weight processes and built-in language constructs to support Actor style message passing between processes. I don't see that or anything else Erlang like.

I'm pretty tired of languages that claim 'erlang-style' concurrency without any of the erlang features that actually make it useful (process isolation, link/monitor, supervisors etc).

EDIT: Personally, I would also add to the above list: algebraic data types, optional static typing with a (mostly) sane type system, no inheritance / minimal indirection, immutable by default, (reasonably) good introspection, support for live code replacement.

Yes, thank you for reminding me how awesome Erlang is!

Hi, I'm the author of Fancy. The erlang-style actor message passing hasn't been implemented yet. I'm workin on that though. Rubinius has a built-in Channel type, (similar to go) and an Actor library built on top of it. Once I get some of the other language features I'm currently working on done, I'll focus on that part of the language. It just takes some time to get all these things finished, but it was always a goal to have this in the language. Rubinius also has inter-vm communication which I will expose in Fancy as part of the language as well. Another feature I'm currently working on is first-class pattern matching that preserves encapsulation (basically you have patterns as first-class values and matching an object against a pattern involves asking the object if it matches a given pattern - that way you don't break encapsulation). Hope that explains some of your concerns.

apparently it's not documented but there is some code in the examples lib in github. It looks more like Io than erlang to me.

https://github.com/bakkdoor/fancy/blob/master/examples/async... https://github.com/bakkdoor/fancy/blob/master/examples/futur... https://github.com/bakkdoor/fancy/blob/master/examples/futur...

So, it looks like @@ is how you send a message to an actor. But there are still a lot of questions I have about what the implementation of that actor is: a lightweight process, a unit of computation to be scheduled, or is it essentially the same as calling any other function?

It will be interesting to see how Fancy evolves its Actor features in comparison to other languages with built-in Actors.

The current implementation of futures uses a thread pool. I'm planning on changing this a bit to behave more like Io's actor model.

Is it on the roadmap?

Yes.