About the 'import' statement

I've always felt that the import statement was pretty much useless, because the table unpacking syntax does the same job. These are equivalent:

import sub, len, rep from string
{:sub, :len, :rep} = string

Although the syntax is somewhat cleaner, functionally, it's pointless. Maybe instead of unpacking a module, import could act as a helper for requires. In Lua, it's good practice to localize modules in creation and requiring, but this can easily become verbose and tedious:

local module1 = require 'module1'
local module2 = require 'module2'
local module3 = require 'module3'

module1.hello_world()

What I propose is for the import statement to work similarly to that in Python. You would specify a variable name, and the compiler would render a require statement with a string as the variable name.

import module1
import module2
import module3

module1.hello_world!

-- when importing from paths, uses the base of the path
import lib.stuff.morestuff
morestuff.do_things!

In the case that you have a file named differently to what you want to require it as a different name:

-- a player class with lowercase filename
import player as Player

And if you want behavior similar to the old require statement:

import C, Ct, Cmt from lpeg

Which would compile to:

local C, Ct, Cmt
do
  local _req = require 'lpeg'
  C, Ct, Cmt = _req.C, _req.Ct, _req.Cmt
end

The only thing is that it would break compatibility with the current import statement, so at this stage, it might be better to just use a different keyword, such as "requires" or something silly like "needs", "get" or "obtain".

[ludamad]

I agree completely with this assessment. I always use 'import' with 'import ... from require "foo"' and would like it to be 'import ... from foo' for readability. If 'require' is not being used, there is always table destructuring as you said.

[leafo]

I agree, table destructuring was added way after import was added. They actually use the same code to generate Lua, a import is internally converted to a destructure.

Sadly import is very pervasive in all the moonscript code I've written so far so I've been hesitant to change it. If I did make changes I'd probably learn towards something that's backwards compatible.

I do like the idea of import hello.world being shorthand for world = require "hello.world", I could add that on top of the current syntax without breaking anything but it would make import .. from .. non symmetrical because the from clause is an expression and not a module name.

[ludamad]

Alternatively, it shouldn't be too hard to write a tool that rewrites existing import statements (either detecting 'require' usage or converting to table destructuring). I think its OK to make breaking changes that don't require human labour to fix, although it needs to be carefully versioned.

[ludamad]

It occurred to me there is another alternative. I frequently mistype and write:

import X from 'foo'

Additionally, I frequently extend 'require' to have special characters at the start, eg '@foo' which is in the same 'package'. So perhaps import 'foo' and import X from 'foo' can be supported. This should be backwards-compatible.

[Idyllei]

I also mistype and put quotes around my module names.

As a suggestion, why not make

import X from foo

remain as it is, but with quotes around foo it is interpreted as a require statement instead of a table?

import X,Y from require 'foo'

which would compile to:

local X
local Y
do
    local _req = require 'foo'
    X,Y = _req.X, _req.Y
end

So, all-in-all, if the statement after from is a quoted literal, treat it as a required module. That would save me the extra characters in my never-ending projects.

[Idyllei]

Alternatively, destructuring assignment would be useful here, too.
For example:

import {:mwait, :nwait, timer_wait: twait} from 'waits'

would be compiled as:

local mwait
local nwait
local timer_wait
do
    local _req = require 'waits'
    mwait, nwait, timer_wait = _req.mwait, _req.nwait, _req.twait
end

This would make Moonscript more flexible and also aid it insticking to the paradigm of allowing destructuring wherever a statement is allowed.

[RyanSquared]

I like the concept of using quotes turning into require(). 👍

I do too. That's the way ES6 does it, so I'd be totally cool with that. It also plays nicely with non-identifier characters in filenames.

import HelloWorld from 'hello-world'

But I feel as though I'm not the only one who doesn't always import just parts of the library as opposed to the entire library itself. Correct me if I'm wrong, but isn't requiring the entire library the much more common case? In that case, wouldn't we be better off having the import statement support that case instead?

Even if it breaks compatibility, I'm still in favor of the import keyword being reworked, for reasons discussed before. Here's what I now have in mind with a few considerations from this thread.

-- basic syntax
import 'module' --> local module = require 'module'
import 'module.part' --> local part = require 'module.part'

-- internally, it'd be converted to an assignment, which makes this possible
export import 'module' --> module = require 'module'

-- which also makes this possible
export *
import 'module1' --> module1 = require 'module1'
import 'module2' --> module2 = require 'module2'

-- convert non identifier characters to underscores?
import 'd-a-s-h-e-s' --> local d_a_s_h_e_s = require 'd-a-s-h-e-s'

-- named imports
import 'player' as Player --> local Player = require 'player'

-- destructuring
import 'lpeg' as {:C, :Ct, :Cmt}

-- no assignment
import 'something' as nil --> require 'something'

The only thing is that export import 'module' reads a little funny, but overall, I think I'd really like a system like this. Thoughts?

[RyanSquared]

Since libraries (should be|are) cached in the package table, we wouldn't have to worry about a few more import 'module' instead of using export import 'module', right?

Require libraries are cached in package.loaded, but that's not relevant. I included that for cases like this, where some (or all) libraries aren't localized when required, just to save on typing. It's not uncommon. Plus, just considering the fact that it's just a shorthand variable assignment, that it should work with other parts of the language in the same way.

In short, import b as a would translate to the moonscript syntax a = require b. a is the string content of b by default (with nonID characters translated as noted)