Hmm, it's been quite some time since my last update. I should work on trying my best to resolve that. Well either way, a lot has happened in the life of EleetScript since the days of your (you know, October of last year). As of my writing this the latest version of the EleetScript gem that I've pushed is 0.0.17a, one of many builds that are already live and available for use. Yes, EleetScript is in it's alpha phase with mostly complete features and APIs but still not in a state of working where I'd consider a beat or even an RC. Changes happen too fast and too often.
I Push Small Updates Often
EleetScript is still young but I'm already integrating into a large project that I'm working on (it's a MUD server, remember?). The language was, mostly, built for this exact purpose anyways. This usage allows me to see what's still missing or broken within the language. I've already targeted a major flaw in the way I managed context for objects and a need for more security within the language via method locks/allows (more on these troubles and stuff later).
Once I fix an issue I find or add a feature I need I build and push a new version of the gem, so the language should be evolving fairly quickly. Perhaps too quickly for anyone to reasonably use it aside from myself but I feel that the community, should it be interested, deserves to have access to the lastest updates in gem format.
Evolution of EleetScript
EleetScript has changed slightly from my original concept of it, only slightly. Since the initial format of the language I've introduced regular expressions (backed entirely by Ruby's regular expression engine) with their own syntax for EleetScript. Lambda's exist within the language as a first class function providing Proc like availability. I added an operator I've always wanted to see in a language (
.= such as
some_string .= substr(1, 3)) which was more for "Let's see it done" than any real practical reason.
The language itself was not the only that evovled, I've rewritten the way I manage context/memory, modified that method, added in the ruby bridge and fixed issues linking the two languages together. So, one thing I learned is that managing context is one of the more difficult tasks of building a language. Tokenizing input was almost trivial, I mean it's done almost everyday in any type of program just about without really realizing that you're your doing the majority of the work for lexical analysis. Anyway, parsing was a bit more difficult just becuase learning how the grammar works and building an AST and such, just more complex than lexing but still fairly simple.
Iterpreting proved to be a very time consuming process but overall it was fairly simple. What started proving difficult was managing classes and instances; but even that was resolved fairly quick. Then I added in namespaces and that released a terribly storm of hurt upon contexts and managing the memory overall. The concept seemed simple and for simple cases it really was, but namespaces proved that the simplicity would be short lived. Eventually I worked through those issues, the most notable being the most recent which was that class definitions were tied explicity to the namespace in which they were defined and so therefore were their instances. Simple solution though, just tied the instance to the namespace in which it was created and it will fetch variables defined in that scope first before moving up the context chain.
Implementing basic lambda functionality was simple enough; however, giving the lambda closure like functionality proved slightly more difficult. Lambda's eventually obtained this functionality so it was all good in the end. It was a simple matter of binding lambda's to the scope in which they were defined and then they search through the bound context before the context they're called from.
The ruby bridge was the pinacle of the language production and was, probably, the easiest part to impelment thanks to the very dynamic nature of Ruby. Some simple
method_missings and some
sends and all was well pulling objects in and out of Ruby/EleetScript. The bridge worked out much better than anticipated. Using either object in either language is almost seamless. There are some unseen bugs that I haven't yet encountered I'm sure but for now everything appears to be working just as expected. Here's a simple example:
class Person attr_accessor :fname, :lname def initialize(fname, lname) @fname = fname @lnmae = lname end end engine = ES::SharedEngine.new engine.evaluate <<-ES print_name do |person| fname = person.fname lname = person.lname println("Your name is %fname %lname") end ES me = Person.new("Brandon", "Buck") engine.call(:print_name, me) # => Your name is Brandon Buck
As you can see, it's fairly seamless to push ruby objects into EleetScript and trust me the same is true for the other direction.