What was

When I started working on GoLisp I decided to write tests of the runtime/internals in Go using GoCheck, and tests of Lisp level behavior in Lisp. To that end I wrote a very simple testing framework with one function: describe, which wrapped a sequence of predicate expressions, evaluated them and reported errors if they evaluated to something falsy. Generally, this took the form of a series of equality checks; it worked, but didn’t communicate very well.

With the impending version 1.0 release, I decided it was time to improve this.

Read full post

Coming of age

GoLisp is maturing nicely, and I’ve recently made it a lot more like standard Scheme. This includes some breaking changes where I played fast and loose with the language earlier on. Now I’m bringing some of the more core things into line with how standard Scheme works. Because of that, I’ve decided that it’s time to slap a label on it. v1.0 is now what’s on the master branch, and the previous master branch has been renamed legacy.

So what’s new?

There are several improvements to the runtime, and the standard set of primitives has been expanded.

Read full post

SteelSeries is happy to announce Dota 2 GameSense support in SteelSeries Engine!

We’ve worked with the team over at Valve to bring you another incredible experience.

Read full post

We recently released Engine 3.4.1 with support for some new hardware and various improvements. Let’s look at what’s new.

Read full post

For V1.0, I revisited the way primitive functions are handled to make them work more like regular functions (i.e. defined in Lisp using define/lambda). The visible change if you are writing primitives is that they now recieve evaluated arguments. I.e. they use applicative order of evaluation now. This is as it should be.

Read full post

We recently released Engine 3.4 with GameSense™. Let’s look at what 3.4 includes.

Read full post

You’ve been able to use your SteelSeries hardware to provide input to your games since, well, forever. That is what SteelSeries products are for, afterall. But now, with the beta release of GameSense™, you can use your SteelSeries hardware to display game state information.

Why is this interesting? Well, it’s pretty cool to start with. But it can be quite useful as well. Imagine watching an event where each player has their health level dsplayed as the color of their headset lighting. Imagine playing Minecraft and seeing your hunger level, breath, direction you are facing, and even what tool you are holding and it’s durability all displayed on your keyboard. How about getting notified when spells and abilities are available again after their cooldown expires? Now make that all user customizable.

That’s just the start of what GameSense™ can do.

Read full post

We recently released Engine 3.3.7, with support for new and old devices. Let’s look at what 3.3.7 includes.

Read full post

Scheme (and thus GoLisp) is lexically scoped. This is implemented by the creation of a lexical environment (aka symbol table) for each lexical scope:

• function/lambda/macro invocations, which holds parameters and any local definitions
• let structures, which hold the let bindings
• do structures, which hold the do bindings

Functions and lambdas capture a reference to the environment in which they were defined, so they always have access to its bindings (that’s a closure, btw).

Each environment has a connection to its containing environment, and can override/hide bindings in outer scopes. When a symbol is evaluated, the most local environment is searched first. If a binding for the system isn’t found there, the containing environment is searched. This continues until a binding for the sybol is found or we go all the way to the global environment and still can’t find a binding.

Section 3.2 of [1] does a great job of explaining environments in Scheme, which is the basis for environments in GoLisp.

In Scheme, some environments are more important than others, mainly as they tend to be larger, long lived, and serve as the root of many other environments as a program runs. These are known as top level environments. Specifially, these are the global environment (the only environment that is contained by nothing), and any environments directly below it in the environment tree. The REPL runs in one such environment, which effectively sandboxes it, protecting the bindings in the global environment from corruption.

In standard Scheme, environments are first class objects. That is, they can be passed around, returned, manipulated, etc. I’ve recently added this ability to GoLisp, along with the majority of the environment manipulation functions from Scheme. These are described below.

Read full post

We recently released Engine 3.3.6.1, with new features and new devices. Let’s look at what 3.3.6.1 includes.

Read full post