Since NIL has been written in pure Lua, NIL should be able to work properly in Lua. The NIL_Love.lua file has been set up to make sure NIL.Use takes it files from your .love file accordingly. Of course LOVE will always look for the mainscript being in Lua, but if you just make it refer to the rest of the code being in NIL, NIL can take over.

A few notes are in order!

NIL has NOT been tested in LOVE.

It should work, but I cannot be not sure! NIL has been tested in Lua 5.1 and 5.2

LOVE callbacks

Unless you decide to make LOVE call the SDL routines the way SDL was intended (which you just can do, you know), LOVE will work with callbacks. Now "void love.draw()" is not gonna work, and NIL will throw an error even. "love.draw = void()" on the other hand WILL work, and all callback functions will have to be defined that way. (Of course, only use "void" if you don't need to return something, but that should be pretty obvious).

Do not turn "love" into a class

Although NIL supports classes, and these classes should work fine in LOVE, you should not turn the "love" variable itself into a class. The reason I say this, is because some people might be crazy enough to try. NIL uses its own routines to create classes, and although Lua can handle these just fine after the class' creation, LOVE was NEVER set up to work with these (How can it? It's older than NIL!) and thus nothing but trouble could arise from that. And as long as it was only used to receive callbacks you could cope as long as all required callback functions were present, BUT, first of all LOVE deprecates and removes stuff faster than Apple does, which is bound to tie your game to one specific version of love only, and second, "love" also contains the links to all the underlying APIs LOVE provides to make LOVE act as an engine. So it's best not to mess with that. I know it makes you code look cleaner, but best is not to go there. If you really want to use a class for your callbacks perhaps, you should try this:

class MyCallBacks

     void Draw()
     ... code ...
     end

     void Update()
      ... code ...
     end
end

var MCB
MCB = MyCallBacks.NEW()

love.draw=void() MCB.Draw() end
love.update=void() MCB.Update() end

Note, for easiness sake I omitted arguments. This may not be the most satisfying way to work, but I think it works (I never tested this though). I'm not quite sure if this is a very clean way either, though, but hey, it's your call ;)

I can still use modules/libraries in LOVE never meant for NIL?

Yup! But that goes for all engines using Lua. NIL can accept anything written in either pure NIL or Lua code.

#use LibraryInLuaAndNotInNIL

Should do the trick and if it's a module, it'll be stored in the variable "LibraryInLuaAndNotInNIL"

Now I have a .dll/.so file for a library. Can NIL handle that?

Yes, but you'll need a little trick for this.

var MyModule
MyModule = load("return require 'MyModule'")

I believe that the Lua version in LOVE needs the "load" function and that some older versions of Lua use "loadstring", but I'll need to check in LOVE once more, as it's really been awhile since I used either routine in LOVE last.

And this too should work in all engines using Lua.