LambdaCube 3D

Questions & Answers

These questions were asked by the audience during our tour.



What is the LambdaCube 3D project licence?

The whole project is licensed under BSD3.


Where can I bounce ideas and advice around?

Join to the lambdacube3d-discuss google group.

Project goals

What are your long-term goals with the project?

We plan to use LambdaCube 3D for application development.

What kind of applications would you like to develop with LambdaCube 3D?

It could be a mobile game or a data visualisation tool.

Is LambdaCube 3D only for graphics programming?

Currently yes, it is. General purpose GPU programming is planned.

Development plan

When will be the language stable?

We consider the following phases of completeness (ordered list):

After completing these phases, we plan to write more and more applications and validate the language against real world use cases until LambdaCube 3D will be announced stable.

What’s the next big feature to add?

Planned features

Will the compiler be independent?

The compiler is already in a separate GitHub repository. We intend to make the compiler as general purpose as possible, given the constraint that its main purpose is to compile a graphics DSL for CPU+GPU. This means for example that the type family reductions wired into the compiler will be moved into the libraries. Also we would like to experiment with a language extension which would specialise error messages for the problem domain and make this machinery independent from the actual problem domain.


Who sponsors you?

Two of us work on the project full time, living on spared money. One of us work on the project in his spare time.



Where can I find the documentation for the language?

There is only a rough language specification at the moment. The documentation pages are exposed in the homepage: We plan to improve the documentation gradually and a tutorial planned also. Get back to the development history to see the progress.

Development with LambdaCube 3D

How is the time input treated in the demos?

The time variable is a Float-typed input value which is supposed to be updated by the user application. Input values are constants during the rendering of a frame.

Conceptually this means that we treat the screen frames as a set of individual images and there is no way to express connection between the images with the type system at the moment. We plan to add some kind of FRP system to LambdaCube 3D which will be reflected in the type of time too.

Is it possible to see the generated shader code?

The generated shader code is part of the IR (Intermediate Representation) which is the output of the LambdaCube compiler. In the online editor IR is shown on a separate tab next to the canvas.

How do you support debugging?

Currently we use native debugging tools on different platforms. It is possible to add a debugger for the intermediate representation of LambdaCube 3D. It is also possible to add a debugger for the LambdaCube 3D language.


Would it be possible to guarantee execution time limits with the type system?

Probably it is possible, it would be a nice area to explore later. Now we focus on simpler features.

I expect usability errors with structural records plus type classes. Does they play well together?

We don’t have enough experience yet to answer this question. We plan to use structural records more and more in our Prelude and see the consequences.

Does LambdaCube support scene graph?

How does this language compare to Elm?

Elm focuses on FRP and web programming. LambdaCube 3D targets computer graphics on multiple platforms.

Elm has a different philosophy regarding language features: be newcomer friendly and avoid advanced type system constructs like type classes and GADTs. On the contrary, LambdaCube 3D aims to use these powerful constructs.

LambdaCube3D try to reuse syntax and type system constructs from Haskell. Elm explores new areas instead.

Why are you developing a separate DSL instead of a Haskell EDSL?

Csaba spent several years experimenting with EDSLs, as the previous versions of LambdaCube 3D were implemented as DSLs embedded in GHC Haskell. Based on this experience, we decided to make the next iteration of the language an independent DSL for several reasons:

To sum it up, in many ways going the Haskell EDSL way would either make the result suboptimal compared to our vision, or it would be at least an order of magnitude more work to achieve what we want. For instance, several of the above mentioned issues could be solved by improving GHC. However, that’s suddenly a lot bigger undertaking than working on our tiny isolated project, and it would also be a distraction from our own goals that would slow us down considerably. Besides, the option is always there to backport the DSL’s innovations to the EDSL implementation if there’s demand to do so.



Is the generated byte code Turing-complete?

It is probably not Turing-complete hence the system generates static pipeline structure at the moment. We haven’t proved it though.

If the pipeline has infinite loop, will the compiler stuck?

In the current system the yes. That will be fixed in a later version.

Does the compiler decide what to run on the CPU and on the GPU? How?

The language has builtin primitives to mimic the GPU functionality. The parameters of these builtin functions (e.g. vertex and fragment shader function) are executed in the GPU hardware.


Are the shaders generated for every frame?

No, shaders are generated compile time. This means that all shaders should be known at compile time, i.e. only static pipelines are supported. We plan to support dynamic pipelines (pipeline which depend on user input) later.

If you use LambdaCube from a JavaScript or C++ application, then the application has to load the pipeline through a LambdaCube backend. The backend allocates every necessary OpenGL resources for pipeline execution, then it can be used to render several frames.

Do you have performance comparisons against C++ and native OpenGL?

We know that performance is crucial for 3D graphics programming. Currently the focus is on language design, later it will shift to compiler optimizations with performance benchmarks.

Is it OK to deal with performance later?

Csaba has experience with doing computer graphics in C++. We keep performance in mind during making design decisions.

Is it possible to get good performance for a high-level language like LambdaCube 3D?

We believe that modern compilers should automate as much boring programming tasks as possible while keeping good performance. You can see LambdaCube 3D as an experiment achieving this goal.

Source code

What is the code-base size?

Figures as of 5th June, 2015

Component Sources
Compiler 4.6 kLOC Haskell
Prelude modules 0.7 kLOC LambdaCube 3D
OpenGL 3.3 backend 2.7 kLOC Haskell
WebGL backend 1.9 kLOC PureScript

Why do you use PureScript instead of Elm?

Why don’t you use GHCJS?

GHCJS can be used in the following cases:

We would like to keep the WebGL interpreter as lightweight as possible, the code generated by GHCJS is too big for this.

We tried GHCJS to run the compiler in the browser. It was running, but it was 13x slower than the native code. We will experiment with it later again.

Is any code reused from GHC?

In short, no. The compiler is written from scratch. As the benefit of this decision we can use the latest technology and theory advancements.

Which editor do you use in the browser?

It is Ace editor, an open-source editor written in JavaScript. PureScript has an Ace interface.