25 Feb 2012 07:13

Back to list of posts

Type and memory safety are very important. They are handled well in go, so we will steal that design, but throw in some C++ like layered complexity for good measure.

Go's model of having complete type and memory safety, unless you explicty use unsafe is very nice. How can this be generalized in badlang style?

The Goal: Opt-in danger

Rather than opt-in safety, we want opt-in danger. This means that type and memory safe code is identifiable, the default, and can be required simply by disabling the ability to opt in to danger. This comes in 2 flavors: danger provided by the language itself, and danger provided by other modules. Since a goal of badlang it to be simple, the danger thats provided by the language itself can actually be provided via some special core modules, and access to them can be controlled the same as all other modules. That means to opt-ion to dangers, you simply need to import a module that provides those dangers (again, like the unsafe package in Go).

It is important to note that dangers to not get inherited by using dangers. You can use something that lacks memory safety to implement something that is (claims to be) memory safe. Otherwise nothing safe using the lower level tools!


Now we got the safety system down to which modules you can/do import. There are several types of "dangers", so modules can simply register themselves with a list of danger types their public APIs expose. When importing a module, the compiler is provided with a set of modules the module (and any sub-modules it causes to get imported) can access. To restrict access to various types of dangers, the set of modules can simply be filtered.

Some use cases:

  • generally keeping most code free of memory/type errors (and free from having to check for them when debugging!)
  • ability to sandbox code (prevent direct memory access, file system access, syscalls etc)
  • Allowing, but discouraging widespread use of some low level basics which are needed to implement basic language features in standard lib.
  • enforcing clean plugin and other API boundaries inside a project
  • allowing explicit (and easy to find) safety violations where required, such as interfacing with other languages, and some optimizations.
  • enforcing arbitrary project level usage decisions (like preventing some part of the project from using threading, synchronous IO, exceptions, or other random things like that)

Source of Safety

So how exactly can a type and memory safe language be implemented in this system? The basic idea it to stick with the same design as Go, but allocation can be done by functions provided by libraries which internally use operations that are not memory and type safe. Basically a clone of Go in this respect, but new and make come from module in standard lib, not the language itself. Like Go, direct memory access would come through some unsafe types provided by another module. It works for Go, so theres no reason not to steal/copy it.

Comments: 0

Add a New Comment

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License