What order should Lua be ported in?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

What order should Lua be ported in?

Steven Degutis
If someone were to port Lua (i.e. src/*.{c,h}) to another language
besides C, in a piecemeal way and by porting minimally sized chunks of
code at a time, so that at every step the incomplete port would be
able to at least compile, in what order should such a person port the
source files? Any advice on this would be over-enthusiastically
appreciated.

-Steven

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

Tim Channon
On 18/12/2014 23:59, Steven Degutis wrote:
> If someone were to port Lua (i.e. src/*.{c,h}) to another language
> besides C, in a piecemeal way and by porting minimally sized chunks of
> code at a time, so that at every step the incomplete port would be
> able to at least compile, in what order should such a person port the
> source files? Any advice on this would be over-enthusiastically
> appreciated.
>
> -Steven


I would choose a mixed mode compiler so that common linkage and debug
etc. is easier, even if this is not the final choice.

Mirroring data structures will need to be done early.


Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

Luiz Henrique de Figueiredo
In reply to this post by Steven Degutis
> If someone were to port Lua (i.e. src/*.{c,h}) to another language

What language do you have in mind? And why?

Anyway, the compiler (lexer+parser+code generator) is one large portion
of the code that is completely separate from the other modules, except
for the data structures it builds. So you may want to keep those in C
at first, if possible.

However, the code implementing Lua is tightly knit and I don't see how
you can port it to a different language without doing it all at once.

I'd like to hear your experience trying to do that.

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

Steven Degutis
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

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

steve donovan
On Fri, Dec 19, 2014 at 4:45 AM, Steven Degutis <[hidden email]> wrote:
> My plan is to first transliterate it, since Lua is written in such
> vanilla C that it should produce nearly equivalent Swift code.

Would not an ObjC port make more sense? It provides the special
interop sauce you need, and already is a C superset. Besides, I get
the feeling that Swift is not really living up to its name yet ;)

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

Steven Degutis
On Fri, Dec 19, 2014 at 4:42 AM, quoth steve donovan:
> On Fri, Dec 19, 2014 at 4:45 AM, Steven Degutis <[hidden email]> wrote:
>> My plan is to first transliterate it, since Lua is written in such
>> vanilla C that it should produce nearly equivalent Swift code.
>
> Would not an ObjC port make more sense? It provides the special
> interop sauce you need, and already is a C superset. Besides, I get
> the feeling that Swift is not really living up to its name yet ;)

Since ObjC is already a superset of C, Lua is already valid ObjC code.
So that port has technically already been done by PUC-Rio ;)

But I assume you mean port it to use ObjC features such as classes,
and Foundation classes such as NSArray, NSDictionary, NSNumber, and
NSString. These classes are not nearly as good as Swift's equivalents.
Plus ObjC's interop with C data types is awful, whereas Swift can have
an Array of Ints. Not to mention ObjC lacks generics and a plethora of
other useful features that Swift brings.

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

steve donovan
On Fri, Dec 19, 2014 at 5:37 PM, Steven Degutis <[hidden email]> wrote:
> But I assume you mean port it to use ObjC features such as classes,
> and Foundation classes such as NSArray, NSDictionary, NSNumber, and
> NSString.

Exactly. Not as exciting a language as Swift, but you should rather be
thinking of working in a lower-level language that remains aware of
the particular needs of the runtime like reference counting and so
forth - the equivalent of assembly for that platform.

For instance, there are a few ports of Lua to C#, which are very
straightforward and C-like (their weakness IHMO is not the language
implementation but the second-rate emulations of the C runtime).  Now
Boo (the second-greatest language from Brazil) is much more
interesting and compact than C#, but it isn't necessarily a good
choice for a low-level language implementation.

steve d

Reply | Threaded
Open this post in threaded view
|

Re: What order should Lua be ported in?

Steven Degutis
>> But I assume you mean port it to use ObjC features such as classes,
>> and Foundation classes such as NSArray, NSDictionary, NSNumber, and
>> NSString.
>
> Exactly. Not as exciting a language as Swift, but you should rather be
> thinking of working in a lower-level language that remains aware of
> the particular needs of the runtime like reference counting and so
> forth - the equivalent of assembly for that platform.

Swift is actually lower-level than Objective-C, and Swift's standard
library types (Array, Dictionary) are lower-level than their
Foundation.framework counterparts. Swift is much closer to C than
Objective-C. That's a big reason why I think a port of Lua in Swift
might be useful. Especially in a few years when Swift has many
performance improvements.