Posts Tagged 'gypsum'
Lambdas in Gypsum
I've finally added a feature to Gypsum that I've wanted for a long time: lambdas. They're useful for defining short, compact functions that can be passed to other functions as callbacks. They're especially important for functional programming (map, filter, reduce, and friends).
Migrating to Bazel: Part 2
Previously, I focused mostly on getting Python and C++ code to build. This time, I'll talk about adding support for building Gypsum packages. I'll also give a bit more background on the Skylark language and how Bazel deals with extensions.
Migrating to Bazel: Part 1
Bazel is the open source version of Google's internal build system. Gypsum is a cross-language project, and wanted something that could easily be extended to work with Gypsum itself. Bazel was a natural choice.
Traits in Gypsum
I'm happy to announce the launch of a major new language feature in Gypsum: traits. Traits are like interfaces in Java. They provide a form of multiple inheritance. When you define a trait, you create a new type and a set of methods that go with it, some of which may be abstract. Classes and other traits that inherit from a trait will inherit those methods.
Static and dynamic types in pattern matching
Gypsum now supports pattern matching using both static and dynamic type information. In general, pattern matching involves checking at run-time whether a value has a given type. By incorporating static type information about the value being matched, we can perform some checks that wouldn't normally be safe to perform at run-time.
CodeSwitch API: native functions
I've added the capability for CodeSwitch to call native functions written in C++. This means that when you write a package, part of it can be written in Gypsum, and part of it in C++. This is useful for implementing new low-level primitives, such as files and sockets.
CodeSwitch API improvements
CodeSwitch is designed to be a library that can be embedded in any application. A good API is crucial. While I can't say that CodeSwitch's C++ API is completely stable yet, I think it's gotten to a pretty usable state.
Existential types in Gypsum
Existential types allow you to express that you have an object with a known class, but you don't know what's inside it. For example, instead of having a list of strings, you have a list of "something". In technical terms, you have an instance of some paraterized class, but you don't know the type arguments. Existential types are similar to wildcard types in Java.
Arrays in Gypsum
In most languages (like C or Java), arrays are a primitive that stand on their own. You can build other data structures like array lists and hash maps out of them. In Gypsum, array elements can be integrated into any class. The normal class members come first in memory, then the array elements follow immediately.
Pattern matching in Gypsum
You might think of pattern matching as a switch statement on steroids. You examine a value using several patterns, then execute one an expression based on which of the patterns successfully matched.
Importing symbols in Gypsum
The import statement is one of several new language features I added to Gypsum this summer. Just like the import statement in Java, it makes definitions from another package available in the scope containing the import statement. Unlike Java, multiple definitions can be imported in the same statement. Definitions can also be renamed.
Memory management in CodeSwitch
CodeSwitch has its own garbage collected heap, which is used not only for objects allocated by interpreted code, but also for most internal data structures. In this article, I'll describe how the heap is built, how the garbage collector works, and how it tracks pointers to the heap from C++ code.
CodeSwitch bytecode and interpretation
The interpreter is essentially a loop with a big switch-statement. In each iteration, it reads one instruction, switches on the opcode, branches to the appropriate case, then executes some code for that instruction.
Packages in Gypsum and CodeSwitch
Packages are named bundles of related code. They make code easier to understand and distribute. Each package is compiled into a single file, and has a unique name, a version, and a list of dependencies.
Type parameter bounds and variance
Type parameter bounds and variance provide a huge amount of flexibility and precision in the Gypsum type system. They let you handle many cases where you would normally have to fall back to casting and run-time type checking.
A weird problem in the Scala type system
I've been trying to formalize the type system in Gypsum. There are two operations in particular that I want to put on a sound theoretical foundation.
Gypsum now has type parameters!
Type parameters are also known as generics in other languages. They enable parametric polymorphism, providing abstraction over types for functions and classes.
Structure of the Gypsum compiler (part 3)
In this article, I discuss closure conversion, class flattening, CodeSwitch bytecode, semantic analysis, and serialization.
Structure of the Gypsum compiler (part 2)
In this article, I discuss the Gypsum intermediate representation, declaration analysis, inheritance analysis, and type analysis.
Structure of the Gypsum compiler (part 1)
Gypsum is an experimental language, so the compiler is designed to be very flexible, easy to change and extend. The nice thing about side projects is that you can spend some extra time making sure the code is clean and elegant. You don't have to take on any technical debt to meet deadlines.
Gypsum is a new compiled, statically-typed, object-oriented programming language. When the compiler is more complete, it will be functional as well. Its syntax is inspired by Python and Scala.