ASM development log 2: Dilly-dallying

Posted on by Idorobots

Despite being absorbed thoroughly by the University and numerous end term tests and projects I still have lot's and lot's of free time on my hands... Let's face it, I'm just faffing about.

There was very little to none activity arround in ASM repo lately due to a single, simple reason - my poor time management skills. I'm an Emacs Org-Mode user and most of my time management happens in accordance to David Allen's GTD but for some reason I thought "Herp derp, Myself, let's not put them projects into them GTD lists! Heck no!" and left delicious, lispy ASM aside to bitrot on my harddrive...

Not going to happen anymore as I've just created a dedicated GTD list, in addition to numerous TODO lists ASM already had, where I'm going to schedule next actions to be performed in ASM codebase aswell as deadlines for the releases. Furthermore, I got myself a laptop so I can code on the go and...

puts sunglasses on

...go on with the code.



So, even though I didn't do much arround in ASM repo I was doing some general testing, thinking and toyplementing stuff. I did some research on Virtual Machine architectures and figured a SECD machine might do the trick but I quickly turned to a modified abstract CESHK machine which I'm going to implement, basing loosely on the mentioned publication, and substitute the current VM with. This will require some time and will break some semantics but hopefully it'll be worth it - ASM will get continuations and error handling out of the box and it'll facilitate a simplified bytecode generation. The new VM won't use OOP so it won't enforce any evaluation semantics meaning that everything will be user-redefineable directly in the language including the GC). It'll also make interfacing with C through FFI possible. Neat!

The obvious con is, however, the decreased generality of different ASM primitives due to the lack of polymorphism - iterating a Tuple won't be as simple as iterating a Vector or a Scope anymore. I'm currently trying to solve this problem using D-like ranges for iterable types and functors for the callable types. The other problem I am having is introducing low-level concurency into the VM.

By the way, here's a CEK machine according to Google image search:

CEK Machine

Google <3

2016-02-16: Adjusted some links & tags.