The require("foo").setup() idiom seems hard to translate to fennel
mitchellwrosen opened this issue ยท 8 comments
Hi there,
I've seen the require("myplugin").setup()
idiom quite often in neovim plugin documentation. It seems rather difficult to translate to fennel for some reason.
Attempt 1
Since (foo.setup)
compiles to foo.setup()
, it seems to stand to reason that the table with the setup
function could instead be returned from a function. That doesn't work at all.
Fennel:
((require "foo").setup)
Lua:
require("foo")(__fnl_global___2esetup)
Attempt 2
Ok, maybe I can't use foo.bar
syntax, but will (. foo bar)
, work? (Aren't they the same?) No, no it will not.
Fennel:
((. (require "foo") setup))
Lua:
do end (require("foo"))[setup]()
Attempt 3
Does quoting the "setup" help? The documentation for the table accessor operator only mentions things like (. foo bar)
, never (. foo "bar")
. I guess I wouldn't expect any difference to attempt 2, yet this one generates the code we want.
Fennel:
((. (require "foo") "setup"))
Lua:
do end (require("foo")).setup()
Attempt 4
Even though attempt 3 works, the Fennel code still looks weird, and is hard to remember. Also, the Lua's strange to my eye, too. Why do end
? I'll just do this in two steps with an explicit variable binding.
Fennel:
(local foo (require "foo"))
(foo.setup)
Lua:
local foo = require("foo")
return foo.setup()
Ok, that looks great.
So, maybe there isn't a bug here, but this has been my experience trying to translate a common snippet of Lua code to Fennel. Any advice or commentary about to what's happening above would be much appreciated.
The third attempt is the correct one if you want to do it in a one-liner, though you can use colon strings:
((. (require :foo) :setup))
the do end
in the beginning is needed because if you had an identifier before the (require("foo")).setup()
it will be interpreted by Lua as a function call. E.g.:
foo
(require("foo")).setup()
Lua sees it as foo(require("foo")).setup()
not as foo; (require("foo")).setup()
. So do end
is like a ;
but more portable between all Lua implementations and is compiled away in bytecode.
The reason the documentation mentions .
only with symbols is that you can always use .field
when you statically know the key, and .
is used when you don't know the key statically or the table is not lexically bound and is produced by a function call.
@technomancy I think the Fennel compiler should report this ((require "foo").setup)
as an error though.
unknown:2:16 Compile error: unknown identifier: .setup
((require "foo").setup)
* Try looking to see if there's a typo.
* Try using the _G table instead, eg. _G..setup if you really want a global.
* Try moving this code to somewhere that .setup is in scope.
* Try binding .setup as a local in the scope of this code.
Right now it is an unknown identifier error, but it looks like it should be a syntax error instead.
And it's also weird that the ((. (require "foo") setup))
didn't trigger the unknown global error, but this may be Nvim thing, as they can disable strict global checking
Right now it is an unknown identifier error, but it looks like it should be a syntax error instead.
I thought we already did treat this as a parse error; apparently not. I agree it should be one, but I'm concerned about the backwards-compatibility implications of making it invalid now.
Probably my preferred way would be this:
(let [{: setup} (require :foo)] (setup))
Admittedly slightly more verbose. Frequently in Lua the idiom is to call this as a method instead, which lets you do this:
(doto (require :foo) (: :setup))
which is much nicer. I might be tempted to do this anyway even if the self arg is ignored.
Cool, thank you for the info!
One point:
And it's also weird that the ((. (require "foo") setup)) didn't trigger the unknown global error, but this may be Nvim thing, as they can disable strict global checking
There's no nvim in-between here. The examples I provided are just running fennel
directly on Lua snippets.
The examples I provided are just running fennel directly
It's mentioned elsewhere but one thing that might not be obvious is that AOT compilation (fennel --compile foo.fnl
) does not perform strict global checking unless you ask for it with --globals
:
~/src/fennel $ ./fennel --compile scratch.fnl
return require("foo")(__fnl_global___2esetup)
~/src/fennel $ ./fennel --globals _G --compile scratch.fnl
scratch.fnl:1:16 Compile error: unknown identifier: .setup
((require "foo").setup)
* Try looking to see if there's a typo.
* Try using the _G table instead, eg. _G..setup if you really want a global.
* Try moving this code to somewhere that .setup is in scope.
* Try binding .setup as a local in the scope of this code.
This was originally because we assumed you might be compiling under (for instance) PUC Lua code which was meant to run under LuaJIT; nowadays I think it was a mistake, but it's too late to change unfortunately.
Tip: you can use antifennel
to see how a piece of Lua code would look like in Fennel, i.e.:
$ echo 'require("myplugin").setup()'|antifennel -
((. (require :myplugin) :setup))
Hope it helps, cheers!
We can reopen this if there are still questions or if there's something actionable but I think this is answered?