mtl77 · HackerTrans

Main reasons at the time: * strictness was preferred for consistency 1) with the C++ execution model (a lot of our code base is written in C++ by quants, and a typical Mu program will make extensive use of these external calls; they can even be higher-order, calling back into C++); and 2) because we have a lot of end-users who are not Haskell experts and are much more confortable with a strict execution model * code mobility is essential to what we do, and was not directly available in Haskell: we often capture computations on our users' desktops running Windows, and stream them to a Unix compute farm. * GHC was not openly available as an API years ago; this is different now which is why we have started a new implementation that is GHC-based.

mtl77

3년 전discuss

The reason is that we don't have a general solution for tail-call optimisation for computations made of a mixture of Mu code and C++ primitives. We have higher order functions defined in C++ that can be called from Mu, and can call back Mu functions passed to them. This back and forth between languages has occurred naturally in recursive definitions, and we don't have a way of reusing stack frames between the Mu interpreter and the native C++ code for these higher-order functions. We decided a long time ago to disable recursion by default, encouraging programmers to use recursion operators. We do however have a Mu language extension that enables recursion, which is used when the recursion depth is known to be bounded.

mtl77

3년 전discuss

Gergo and I are working on a new implementation of the Mu compiler that uses GHC up to Core; from which we translate to the legacy Mu bytecode format.

The original Mu compiler is not designed for separate compilation, our new version is, based on GHC's binary representation of compiled interfaces with unfoldings.

comments