Calling other languages from love2d?

[Skeletonxf]

Say I wanted to mix Lua with another language such as Haskell, I've found https://wiki.haskell.org/HsLua and to me it looks like using two languages each with a C FFI would probably not be quite so hard as mixing other sorts.

Can I / how would I go about setting something like this up from within a love2d program, and would such an implementation be easily cross compatible? Ideally I'd like to write my code once and be able to get it to easily it run on desktops and mobile.

[raidho36]

And just why would you do that? Lua is already the single best language for this type of job. It's the fastest, most flexible, and easiest to integrate into parent program, which in context of the LOVE framework have already been done for you. Some functionality may be available as a dynamic link library (aka shared object) and LuaJIT had the FFI to load those.

[dixita]

Hei, i also want to know that, why would you do that?

[MasterLee]

Lua is already the single best language for this type of job.

Source please

It's the fastest, most flexible, and easiest to integrate into parent program, which in context of the LOVE framework have already been done for you. Some functionality may be available as a dynamic link library (aka shared object) and LuaJIT had the FFI to load those.

There are many shortcomings in Lua http://nekovm.org/lua

BY the way hsLua is an Lua Interpreter written in Haskell. So you can use Lua in Haskell as an scripting language.
For other language for example Red the is no sense in embedding Red in any other language or embedding any other languages in Red. Because you can do both sides in Red.

[Tjakka5]

The link you provided only lists differences, not shortcomings.

[MasterLee]

The link you provided only lists differences, not shortcomings.

Ok lats make it short Lua has no native integer support.
And the Arrays starting with one are a little bit painful sometimes.
For example when you have an canvas of width 800 i goes from 0 to 799 in löve2d but arrays goes from 1 to 800 by default.
Next when you wrap arround you could write

Code: Select all

pos=(pos+delta)%size

in cpp
but in Lua it becomes

Code: Select all

pos=((pos+delta-1)%size)+1

when using 1 based Arrays

[zorg]

Ok, let's make it short; lua has no native integer support.
The arrays starting with one are a little bit painful sometimes;
For example, when you have an canvas of width 800, i goes from 0 to 799 in löve2d, but arrays go from 1 to 800, by default.
Next, when you wrap around, you could write

Code: Select all

pos=(pos+delta)%size

in cpp, but in lua, it becomes

Code: Select all

pos=((pos+delta-1)%size)+1

when using 1-based arrays.

Löve comes with luaJIT; luaJIT comes with an FFI interface; The FFI interface allows you to define C types on the lua side; now you have integers, arrays, structs, unions, etc...

Nothing is forcing you to use 1-based indexing, just forget about ipairs and #; for loops will work with whatever limits you give it. (And yes, the 1-based modular arithmetic does tend to get on my nerves as well, but again, you can use 0-based indexing if you wish, it won't incur any performance penalties or anything.)

(And yes, i'm assuming that the discussion was about Löve (or at the very least, luaJIT), not just plain lua. )

Also, that nekoVM site's claims about lua are interesting, and in some places either a bit counterintuitive, or (at least to me, seemingly) wrong.

bool in Lua (true and false) is similar to the Neko bool except that in Neko only one instance of true and one instance of false are allocated and shared by all the code.

Not sure what is being implied here; i'm pretty sure lua doesn't "instance" booleans either. Maybe it's just talking about how neko's runtime representation mentioned below is somehow more optimal with them? (It would still need to refer to them, so i believe a pointer may have a larger (or equal) footprint than just storing a representation of the boolean true or false... i could be wrong though.)

One large difference is that Neko's strings are mutable, that is, they can be modified at runtime. This makes an operation like reading a file to a string byte by byte a fast, efficient, linear operation. By contrast, if you were to try and do this in Lua (which has immutable strings), the operation would be quadratic and become prohibitively slow for even files of a few kilobytes. Lua offers a facility, table.concat, to alleviate this problem; but it still bites programmers on occasion.

I mean, sure, if you're reading a file in one byte at a time, even C tends to choke on it... reading n bytes at once with io or Löve's own filesystem stuff is fine as it is; also, immutable strings are a problem with concatenation, reading in n bytes from a file at once won't concatenate the input byte-by-byte. No need to use tables either, if you want to preserve memory, and are fine with one string.

[airstruck]

Can I / how would I go about setting something like this up from within a love2d program, and would such an implementation be easily cross compatible? Ideally I'd like to write my code once and be able to get it to easily it run on desktops and mobile.

I think the most straightforward way would be to write some "foreign export" declarations, compile your Haskell code as a shared library (.dll/.so) and then use it though LuaJIT's FFI. Cross-compilation might be a bit of a pain to get set up, but I don't see any way around it (unless you actually want to compile on every architecture you target).

Lua and Haskell are so fundamentally different that it almost doesn't make any sense to compare them. You don't need to find flaws in Lua for Haskell to make sense. If you already use Haskell or just want some experience with an FP language, I see nothing wrong with using it for some of the heavy lifting.

[raidho36]

Not that you cannot do heavy lifting with Lua, all thanks to LuaJIT's FFI. In good case scenarios, which is almost always, it provides comparable performance to C.

Source please

You mean other than it's the language of choice of many major games and studios and vast multitude of smaller projects*, who are all citing speed, flexibility and ease of use as the reasons? Please.

Also yes the arguments in the links are not shortcomings, they're just the list of things some people personally don't like but that don't really make any difference.

*if you don't count the special snowflake ones that go out of their way to be different

[airstruck]

Not that you cannot do heavy lifting with Lua, all thanks to LuaJIT's FFI. In good case scenarios, which is almost always, it provides comparable performance to C.

I assume you mean LuaJIT's JIT? Outside of simple things like one-off C structs, the whole point of LuaJIT's FFI is calling native code that was written in compiled languages like C or Haskell.

Not everything is about performance. Sure, LuaJIT performs quite nicely thanks to JIT compilation (usually, if you know which things will compile and which won't). The point of using something like Haskell isn't just performance characteristics. It gives you type safety though implicit static typing, lazy evaluation, immutable everything, everything is a function, every function is pure, etc. It's basically impossible to get lost in state transformations or side effects in a purely FP language the way you can in imperative languages. You'll find simple and elegant solutions to many problems that really have no analogy in imperative languages. Consider something like `factorial n = product [1..n]`, for example.

Yes, you can do something similar in Python, but I don't consider it to be "strictly" imperative like Lua; you have things like list comprehensions, operators-as-functions, and things like "reduce" built in. At any rate, you can't do it in Lua.

@Skeletonxf, go on, learn you a Haskell, you won't regret it.