Introducing Cairntaker, a garbage collector

I’ve been using JavaScript for a while now, and I’m finally getting fed up with it in ways that I just can’t deal with. Or can I? Now that I’m fed up with its memory model, I’ve built a garbage collector. In JS.

I call it Cairntaker. It’s for programmers who want well-tended heaps.

Continue reading

Advertisements

Some Programming Evolution

I’ve come an awful long way since the last time I posted to this blog. To catch you up a bit, I’ve become enamored with David Barbour’s RDP programming model, I’ve ported my Arc libraries over to JavaScript (and added to them), I’ve even ported Conan Dalton’s Rainbow (an implementation of Arc in Java) to JavaScript, and generally I’ve just been hacking away in JavaScript. I like JavaScript’s non-broken lexical scope, and I like the fact that it has a real language standard rather than a reference implementation, but most of all, as I mentioned last time, I like how everything I do in JavaScript can run in the browser. Even my static site generator runs in the browser now (but sorry, there aren’t any good examples of how to use it).

Type wild

During this time, the potential value of static type systems has become quite clear to me. For the most part I still really don’t care about protecting programmers from their own mistakes. Instead what I value is the ability to make promises about program behavior that untrusting parties can verify on their own (for non-hackish metaprogramming and secure code distribution), the ability to write expressive abstractions that don’t sacrifice any run-time performance, and the ability to infer a program’s implementation from its interface. I still like the dynamic programming ideal of putting lots of power in the programmer’s hands… but whence else comes this power? Rather than stubbornly reinventing the existing static type research under some other name, I embrace it.

Introducing Chops

Recently I’ve been doing a lot of my exploratory programming in JavaScript, thanks to the fact that I know it’ll run on crazy platforms like the 3DS. -_^ I’ve programmed in JavaScript off and on since high school, and boi has my JavaScript style changed…. @_@

JavaScript’s lack of macros is a bit troubling for me, especially given the recent tendency for JavaScript programmers to deal in lots of nested asynchronous callbacks: “Unindented functions to clean callback mess.” “Asynchronous callbacks in JavaScript”

I haven’t felt the pain of the asynchronous callback nesting problem firsthand, but I know a horror close to that one: Monadic programming in Groovy. Observe the indentation.

In fact, that indentation-heavy part of the Blade code is what originally got me fed up with using Groovy and interested in making Penknife as an intermediate project on the way to Blade. Well, my work on Penknife has been so focused on modularity and hygiene that it’s slack on what really matters: Syntax. Oh, syntax, how you really really matter so! :-p

Continue reading

Lathe’s Arc-to-Implementation-Language FFI

$ cd /path/to/jarc

$ java -server -cp \
>   "jarc.jar;$GROOVY_HOME/embeddable/groovy-all-1.7.2.jar" jarc.Jarc

Jarc> (= lathe-dir* "path/to/lathe/arc/")
"path/to/lathe/arc/"
Jarc> (load:+ lathe-dir* "loadfirst.arc")
nil
Jarc> (use-rels-as jv (+ lathe-dir* "imp/jvm.arc"))
#3(tagged mac #<procedure>)
Jarc> (jv.jvm!groovy-util-Eval-me "2 + 2")
4

It’s on now.

After about a month of me submitting bugs to the Arc forum and Jarc’s creator, JD Brennan, fixing them, Jarc is now compatible enough with Arc 3.1 that my Lathe (the library I introduced last time) now wholeheartedly supports the Jarc implementation of Arc. This means it works on four Arc setups: Jarc, official Arc 3.1 (which itself needs a Windows fix), Anarki (which needs the same fix), and Rainbow. Most of you reading this are probably from the Arc forum, in which case you knew all that already. :-p

Those are all the setups I want Lathe to support for now, but I might consider arc3f, arc2c, or another Arc implementation if I realize it’s actually active. Another complication is that quite a lot of Arc users modify one of the PLT Scheme versions of Arc (Arc or Anarki) to suit their needs. In those cases, I figure the burden of Lathe compatibility is on them if they need it.

Still, there is a bit of a need to add new features to Arc. To this end, Anarki, Jarc, and Rainbow have provided ways to call from Arc into the host platform (PLT Scheme, the JVM, and the JVM respectively).

Continue reading

Modules, Multimethods (Kinda), and More for Arc

I’ve been doing things here or there in Arc without really having a specific plan in mind for sharing them. Most notably, I had the fundamentals of an untested Arc multimethod system laying around, which were made in an effort to collect my thoughts about Blade, a potential idea for an everything-is-a-multimethod language. And that’s what I expect a large part of my projects to be: Approximations of a language I’d rather program in. So finally, last week I started up a GitHub repo, Lathe, where I could submit miscellaneous utilities that smoothed out non-Blade languages according to my own aesthetic.

Continue reading