Re: [ANN] Clue experimental release

[David Manura <dm.lua@...>]

David Given writes:
> ...I've been working on a C compiler for Lua...It generates Lua 5.1.3
> bytecode...Clue is based on the Sparse C compiler frontend....It's all
> currently deeply experimental, ... and potentially useless, but I hope
> it's at least interesting...

It is interesting.  Was the initial motivation more than academic exercise? or
are there other perceived uses?

Would it be preferable to use Sparse to convert C to some type of intermediate
representation X and then implement interpreters for X in various languages
(Lua, Python, etc., or even C itself[1])?  In an extreme case, X could be real
CPU instructions, in which case one may replace Sparse with gcc or
whatever--other choices may be preferable depending on goals.

Mozilla Dehydra[2] exposes semantic information about C++ code to JavaScript to
permit custom types of static analysis, and maybe something similar can be
adapted here.  If semantic information about C code is made available to Lua, or
if user-written Lua scripts could plug into the various phases of the Sparse
pipeline (e.g. metaprogramming C in Lua rather than in C++ templates), that
might be useful.

The reverse direction of this would be to take Lua code and compile it into C. 
There are a few approaches: one can implement a robust VM for the source
language in the target language (which is already done), one can generate very
source-readable output in the target language but that only works for a very
restricted set of cases due to the mismatch between the languages (e.g. bottom
of[3]), or one can do something in-between. I think something in-between like
Python Pyrex[4] may offer a useful approach, with replacing Python with Lua and
Python API with LUA C API.

As an example, this Python code

  x = 2 + f(3)

is translated to a series of Python API calls:

  __pyx_2 = PyInt_FromLong(2); if (!__pyx_2) {__pyx_filename = __pyx_f[0];
__pyx_lineno = 7; goto __pyx_L1;}
  __pyx_1 = __Pyx_GetName(__pyx_m, __pyx_n_f); if (!__pyx_1) {__pyx_filename =
__pyx_f[0]; __pyx_lineno = 7; goto __pyx_L1;}
  __pyx_4 = PyInt_FromLong(3); if (!__pyx_4) {__pyx_filename = __pyx_f[0];
__pyx_lineno = 7; goto __pyx_L1;}
  __pyx_3 = PyTuple_New(1); if (!__pyx_3) {__pyx_filename = __pyx_f[0];
__pyx_lineno = 7; goto __pyx_L1;}
  PyTuple_SET_ITEM(__pyx_3, 0, __pyx_4);
  __pyx_4 = 0;
  __pyx_4 = PyObject_CallObject(__pyx_1, __pyx_3); if (!__pyx_4) {__pyx_filename
= __pyx_f[0]; __pyx_lineno = 7; goto __pyx_L1;}
  Py_DECREF(__pyx_1); __pyx_1 = 0;
  Py_DECREF(__pyx_3); __pyx_3 = 0;
  __pyx_1 = PyNumber_Add(__pyx_2, __pyx_4); if (!__pyx_1) {__pyx_filename =
__pyx_f[0]; __pyx_lineno = 7; goto __pyx_L1;}
  Py_DECREF(__pyx_2); __pyx_2 = 0;
  Py_DECREF(__pyx_4); __pyx_4 = 0;
  if (PyObject_SetAttr(__pyx_m, __pyx_n_x, __pyx_1) < 0) {__pyx_filename =
__pyx_f[0]; __pyx_lineno = 7; goto __pyx_L1;}
  Py_DECREF(__pyx_1); __pyx_1 = 0;

The point is not speeding up the scripting code itself but rather lowering the
boundary between C and the scripting language.

[1] http://www.softintegration.com/
[2] http://developer.mozilla.org/en/docs/Dehydra
[3] http://lua-users.org/wiki/LuaFish
[4] http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/