Re:Fancy a self-hosted programming language for the Rubinius VM
by cygwin98 on Friday April 22, 2011 @11:37AM
(#2474382)
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.
Re:Fancy a self-hosted programming language for the Rubinius VM
by stcredzero on Friday April 22, 2011 @05:49PM
(#2475547)
Lex, Yacc, the RBParser, and SmaCC, and perhaps some others.
Re:Fancy a self-hosted programming language for the Rubinius VM
by cygwin98 on Friday April 22, 2011 @07:39PM
(#2475794)
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
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!