Re: What order should Lua be ported in?

[Steven Degutis <sbdegutis@...>]

On Thu, Dec 18, 2014 at 7:34 PM, quoth Luiz Henrique de Figueiredo wrote:
> What language do you have in mind? And why?

I am considering porting Lua to Swift.

My plan is to first transliterate it, since Lua is written in such
vanilla C that it should produce nearly equivalent Swift code. Once
that's done and I've verified that it actually works, I plan to
experiment with changing up the design so that it uses idiomatic Swift
constructs (classes, enums, etc).

The reason is mostly for fun and as an opportunity to learn Swift and
practice designing idiomatic Swift APIs. But it would also be
practical, since it has the opportunity to make it much easier for me
to port my OS X window manager from ObjC to Swift.

I've been working on a Swift wrapper around Lua's C API [1] but this
already feels quite a bit hacky.

A main reason for that is because you can't actually create C
functions from within Swift, so you have to drop down to C or
Objective-C and create some functions that you can use as a
lua_CFunction. My hacky solution was to use
imp_implementationWithBlock(), provided by Apple, which creates a C
function of type id(objc_object*, char*, ...) and cast it to
int(lua_State*) which then matches lua_CFunction. This only works on
some platforms, but so is Swift.

A secondary reason is because lua_newuserdata() was designed to be
compatible with malloc and return void*, whereas in Swift we have
different ways of representing objects and allocating space. So it's a
bit clunky to wrap this in Swift.

A pure-Swift Lua would be a lot of work up-front, but it would be a
lot less hacky and much easier to integrate into Swift projects
(custom functions, custom userdata, etc). And admittedly it would only
be usable in Swift projects, but in the future that may very well be
nearly all apps written for OS X.

[1]: https://github.com/sdegutis/DIY-Window-Manager/blob/master/DIY%20Window%20Manager/Lua.swift