MoonScript is a programming language that compiles to Lua. This guide expects the reader to have basic familiarity with Lua. For each code snippet below, the MoonScript is on the left and the compiled Lua is on right right.
MoonScript is a programming language that compiles to Lua. This guide expects the reader to have basic familiarity with Lua. For each code snippet below, the MoonScript is on the left and the compiled Lua is on right right.
Unlike Lua, there is no local
keyword. All assignments to names that are not
already defined will be declared as local to the scope of that declaration. If
you wish to create a global variable it must be done using the export
keyword.
moonscript | lua |
|
|
+=
, -=
, /=
, *=
, %=
, ..=
operators have been added for updating a value by
a certain amount. They are aliases for their expanded equivalents.
moonscript | lua |
|
|
Like Lua, comments start with --
and continue to the end of the line.
Comments are not written to the output.
moonscript | lua |
|
|
MoonScript supports all the same primitive literals as Lua and uses the same
syntax. This applies to numbers, strings, booleans, and nil
.
MoonScript also supports all the same binary and unary operators. Additionally
!=
is as an alias for ~=
.
All functions are created using a function expression. A simple function is
denoted using the arrow: ->
moonscript | lua |
|
|
The body of the function can either be one statement placed directly after the arrow, or it can be a series of statements indented on the following lines:
moonscript | lua |
|
|
If a function has no arguments, it can be called using the !
operator,
instead of empty parentheses. The !
invocation is the preferred way to call
functions with no arguments.
moonscript | lua |
|
|
Functions with arguments can be created by preceding the arrow with a list of argument names in parentheses:
moonscript | lua |
|
|
Functions can be called by listing the values of the arguments after the name of the variable where the function is stored. When chaining together function calls, the arguments are applied to the closest function to the left.
moonscript | lua |
|
|
In order to avoid ambiguity in when calling functions, parentheses can also be used to surround the arguments. This is required here in order to make sure the right arguments get sent to the right functions.
moonscript | lua |
|
|
Functions will coerce the last statement in their body into a return statement, this is called implicit return:
moonscript | lua |
|
|
And if you need to explicitly return, you can use the return
keyword:
moonscript | lua |
|
|
Just like in Lua, functions can return multiple values. The last statement must be a list of values separated by commas:
moonscript | lua |
|
|
Because it is an idiom in Lua to send an object as the first argument when
calling a method, a special syntax is provided for creating functions which
automatically includes a self
argument.
moonscript | lua |
|
|
It is possible to provide default values for the arguments of a function. An
argument is determined to be empty if it’s value is nil
. Any nil
arguments
that have a default value will be replace before the body of the function is run.
moonscript | lua |
|
|
An argument default value expression is evaluated in the body of the function in the order of the argument declarations. For this reason default values have access to previously declared arguments.
moonscript | lua |
|
|
Because of the expressive parentheses-less way of calling functions, some restrictions must be put in place to avoid parsing ambiguity involving whitespace.
The minus sign plays two roles, a unary negation operator and a binary
subtraction operator. In order to force subtraction a space must be placed
after the -
operator. In order to force a negation, no space must follow
the -
. Consider the examples below.
moonscript | lua |
|
|
The precedence of the first argument of a function call can also be controlled using whitespace if the argument is a literal string.In Lua, it is common to leave off parentheses when calling a function with a single string literal.
When there is no space between a variable and a string literal, the function call takes precedence over any following expressions. No other arguments can be passed to the function when it is called this way.
Where there is a space following a variable and a string literal, the function call acts as show above. The string literal belongs to any following expressions (if they exist), which serves as the argument list.
moonscript | lua |
|
|
When calling functions that take a large number of arguments, it is convenient to split the argument list over multiple lines. Because of the white-space sensitive nature of the language, care must be taken when splitting up the argument list.
If an argument list is to be continued onto the next line, the current line must end in a comma. And the following line must be indented more than the current indentation. Once indented, all other argument lines must be at the same level of indentation to be part of the argument list
moonscript | lua |
|
|
This type of invocation can be nested. The level of indentation is used to determine to which function the arguments belong to.
moonscript | lua |
|
|
Because tables also use the comma as a delimiter, this indentation syntax is helpful for letting values be part of the argument list instead of being part of the table.
moonscript | lua |
|
|
Although uncommon, notice how we can give a deeper indentation for function arguments if we know we will be using a lower indentation futher on.
moonscript | lua |
|
|
The same thing can be done with other block level statements like conditionals. We can use indentation level to determine what statement a value belongs to:
moonscript | lua |
|
|
Like in Lua, tables are delimited in curly braces.
moonscript | lua |
|
|
Unlike Lua, assigning a value to a key in a table is done with :
(instead of
=
).
moonscript | lua |
|
|
The curly braces can be left off if a single table of key value pairs is being assigned.
moonscript | lua |
|
|
Newlines can be used to delimit values instead of a comma (or both):
moonscript | lua |
|
|
When creating a single line table literal, the curly braces can also be left off:
moonscript | lua |
|
|
The keys of a table literal can be language keywords without being escaped:
moonscript | lua |
|
|
If you are constructing a table out of variables and wish the keys to be the
same as the variable names, then the :
prefix operator can be used:
moonscript | lua |
|
|
Compiling provide a convenient syntax for constructing a new table by iterating over some existing object and applying an expression to its values. There are two kinds of comprehensions: list comprehensions and table comprehensions. They both produce Lua tables; list comprehensions accumulate values into an array-like table, and table comprehensions let you set both the key and the value on each iteration.
The following creates a copy of the items
table but with all the values
doubled.
moonscript | lua |
|
|
The items included in the new table can be restricted with a when
clause:
moonscript | lua |
|
|
Because it is common to iterate over the values of a numerically indexed table,
an *
operator is introduced. The doubled example can be rewritten as:
moonscript | lua |
|
|
The for
and when
clauses can be chained as much as desired. The only
requirement is that a comprehension has at least one for
clause.
Using multiple for
clauses is the same as using nested loops:
moonscript | lua |
|
|
The syntax for table comprehensions is very similar, differing by using {
and
}
and taking two values from each iteration.
This example copies the key-value table thing
:
moonscript | lua |
|
|
Table comprehensions, like list comprehensions, also support multiple for
and
when
clauses. In this example we use a where
clause to prevent the value
associated with the color
key from being copied.
moonscript | lua |
|
|
The *
operator is also supported. Here we create a square root look up table
for a few numbers.
moonscript | lua |
|
|
A special syntax is provided to restrict the items that are iterated over when
using the *
operator. This is equivalent to setting the iteration bounds and
a step size in a for
loop.
Here we can set the minimum and maximum bounds, taking all items with indexes between 1 and 5 inclusive:
moonscript | lua |
|
|
Any of the slice arguments can be left off to use a sensible default. In this example, if the max index is left off it defaults to the length of the table. This will take everything but the first element:
moonscript | lua |
|
|
If the minimum bound is left out, it defaults to 1. Here we only provide a step size and leave the other bounds blank. This takes all odd indexed items: (1, 3, 5, …)
moonscript | lua |
|
|
There are two for loop forms, just like in Lua. A numeric one and a generic one:
moonscript | lua |
|
|
The slicing and *
operators can be used, just like with table comprehensions:
moonscript | lua |
|
|
A shorter syntax is also available for all variations when the body is only a single line:
moonscript | lua |
|
|
A for loop can also be used an expression. The last statement in the body of the for loop is coerced into an expression and appended to an accumulating table if the value of that expression is not nil.
Doubling every even number:
moonscript | lua |
|
|
Filtering out odd numbers:
moonscript | lua |
|
|
For loops at the end of a function body are not accumulated into a table for a
return value (Instead the function will return nil
). Either an explicit
return
statement can be used, or the loop can be converted into a list
comprehension.
moonscript | lua |
|
|
This is done to avoid the needless creation of tables for functions that don’t need to return the results of the loop.
The while loop also comes in two variations:
moonscript | lua |
|
|
Like for loops, the while loop can also be used an expression. Additionally, for a function to return the accumulated value of a while loop, the statement must be explicitly returned.
moonscript | lua |
|
|
A short syntax for single statements can also be used:
moonscript | lua |
|
|
Because if statements can be used as expressions, this can able be written as:
moonscript | lua |
|
|
Conditionals can also be used in return statements and assignments:
moonscript | lua |
|
|
For convenience, the for loop and if statement can be applied to single statements at the end of the line:
moonscript | lua |
|
|
And with basic loops:
moonscript | lua |
|
|
The switch statement is shorthand for writing a series of if statements that
check against the same value. Note that the value is only evaluated once. Like
if statements, switches can have an else block to handle no matches. Comparison
is done with the ==
operator.
moonscript | lua |
|
|
Switches can be used as expressions as well, here we can assign the result of the switch to a variable:
moonscript | lua |
|
|
We can use the then
keyword to write a switch’s when
block on a single line.
No extra keyword is needed to write the else block on a single line.
moonscript | lua |
|
|
It is worth noting the order of the case comparison expression. The case’s
expression is on the left hand side. This can be useful if the case’s
expression wants to overwrite how the comparison is done by defining an eq
metamethod.
In these examples, the generated Lua code may appear overwhelming. It is best to focus on the meaning of the MoonScript code at first, then look into the Lua code if you wish to know the implementation details.
A simple class:
moonscript | lua |
|
|
A class is declared with a class
statement followed by a table-like
declaration where all of the methods and properties are listed.
The new
property is special in that it will become the constructor.
Notice how all the methods in the class use the fat arrow function syntax. When
calling methods on a instance, the instance itself is sent in as the first
argument. The fat arrow handles the creation of a self
argument.
The @
prefix on a variable name is shorthand for self.
. @items
becomes
self.items
.
Creating an instance of the class is done by calling the name of the class as a function.
moonscript | lua |
|
|
Because the instance of the class needs to be sent to the methods when they are called, the ‘' operator is used.
All properties of a class are shared among the instances. This is fine for functions, but for other types of objects, undesired results may occur.
Consider the example below, the clothes
property is shared amongst all
instances, so modifications to it in one instance will show up in another:
moonscript | lua |
|
|
The proper way to avoid this problem is to create the mutable state of the object in the constructor:
moonscript | lua |
|
|
The extends
keyword can be used in a class declaration to inherit the
properties and methods from another class.
moonscript | lua |
|
|
Here we extend our Inventory class, and limit the amount of items it can carry.
super
is a special keyword that can be used in two different ways: It can be
treated as an object, or it can be called like a function. It only has special
functionality when inside a class.
When called as a function, it will call the function of the same name in the
parent class. The current self
will automatically be passed as the first
argument. (As seen in the inheritance example above)
When super
is used as a normal value, it is a reference to the parent class
object.
It can be accessed like any of object in order to retrieve values in the parent class that might have been shadowed by the child class.
When the \
calling operator is used with super
, self
is inserted as the
first argument instead of the value of super
itself. When using .
to
retrieve a function, the raw function is returned.
A few examples of using super
in different ways:
moonscript | lua |
|
|
super
can also be used on left side of a Function Stub.
The only major difference is that instead of the resulting function being bound
to the value of super
, it is bound to self
.
Every instance of a class carries its type with it. This is stored in the
special __class
property. This property holds the class object. The class
object is what we call to build a new instance. We can also index the class
object to retrieve class methods and properties.
moonscript | lua |
|
|
Because, by default, all assignments to variables that are not lexically visible will be declared as local, special syntax is required to declare a variable globally.
The export keyword makes it so any following assignments to the specified names will not be assigned locally.
moonscript | lua |
|
|
This is especially useful when declaring what will be externally visible in a module:
moonscript | lua |
|
|
Assignment can be combined with the export keyword to assign to global variables directly:
moonscript | lua |
|
|
Additionally, a class declaration can be prefixed with the export keyword in order to export it.
The export
statement can also take special symbols *
and ^
.
export *
will cause any name declared after the statement to be exported in the
current scope. export ^
will export all proper names, names that begin with a
capital letter.
Often you want to bring some values from a table into the current scope as local variables by their name. The import statement lets us accomplish this:
moonscript | lua |
|
|
The multiple names can be given, each separated by a comma:
moonscript | lua |
|
|
Sometimes a function requires that the table be sent in as the first argument
(when using the \
syntax). As a shortcut, we can prefix the name
with a \
to bind it to that table:
moonscript | lua |
|
|
A common pattern involving the creation of an object is calling a series of functions and setting a series of properties immediately after creating it.
This results in repeating the name of the object multiple times in code, adding unnecessary noise. A common solution to this is to pass a table in as an argument which contains a collection of keys and values to overwrite. The downside to this is that the constructor of this object must support this form.
The with
block helps to alleviate this. Within a with
block we can use a
special statements that begin with either .
or \
which represent
those operations applied to the object we are using with
on.
For example, we work with a newly created object:
moonscript | lua |
|
|
The with
statement can also be used as an expression which returns the value
it has been giving access to.
moonscript | lua |
|
|
Or…
moonscript | lua |
|
|
It is common to pass a function from an object around as a value, for example, passing an instance method into a function as a callback. If the function expects the object it is operating on as the first argument then you must somehow bundle that object with the function so it can be called properly.
The function stub syntax is a shorthand for creating a new closure function that bundles both the object and function. This new function calls the wrapped function in the correct context of the object.
Its syntax is the same as calling an instance method with the \
operator but
with no argument list provided.
moonscript | lua |
|
|
While lexical scoping can be a great help in reducing the complexity of the code we write, things can get unwieldy as the code size increases. Consider the following snippet:
moonscript | lua |
|
|
In my_func
, we've overwritten the value of i
mistakenly. In this example it
is quite obvious, but consider a large, or foreign code base where it isn’t
clear what names have already been declared.
It would be helpful to say which variables from the enclosing scope we intend on change, in order to prevent us from changing others by accident.
The using
keyword lets us do that. using nil
makes sure that no closed
variables are overwritten in assignment. The using
clause is placed after the
argument list in a function, or in place of it if there are no arguments.
moonscript | lua |
|
|
Multiple names can be separated by commas. Closure values can still be accessed, they just cant be modified:
moonscript | lua |
|
|
moonscript
ModuleUpon installing MoonScript, a moonscript
module is made available. The best
use of this module is making your Lua’s require function MoonScript aware.
moonscript | lua |
|
|
After moonscript
is required, Lua’s package loader is updated to search for
.moon
files on any subsequent calls to require
. The search path for .moon
files is based on the current package.path
value in Lua when moonscript
is
required. Any search paths in package.path
ending in .lua
are copied,
rewritten to end in .moon
, and then inserted in package.moonpath
.
The moonloader
is the function that is responsible for searching
package.moonpath
for a file available to be included. It is inserted in the
second position of the package.loaders
table. This means that a matching .moon
file
will be loaded over a matching .lua
file that has the same base name.
For more information on Lua’s package.loaders
see Lua Reference Manual
—
package.loaders
The moonloader
, when finding a valid path to a .moon
file, will parse and
compile the file in memory. The code is then turned into a function using the
built in load
function, which is run as the module.
Runtime errors are given special attention when using the moonloader
.
Because we start off as MoonScript, but run code as Lua, errors that happen
during runtime report their line numbers as they are in the compiled file. This
can make debugging particularly difficult.
Consider the following file with a bug:
moonscript | lua |
|
|
The following error is generated:
moon:err.moon:1: attempt to perform arithmetic on global 'z' (a nil value)
stack traceback:
err.moon:1: in function 'add_numbers'
err.moon:2: in main chunk
Instead of the error being reported on line number 3, where it appears in the Lua file, it is reported on line 1, where the faulty line originated. The entire stack trace is rewritten in addition to the error.
The MoonScript module also contains methods for parsing MoonScript text into an abstract syntax tree, and compiling an instance of a tree into Lua source code.
Knowledge of this API may be useful for creating tools to aid the generation of Lua code from MoonScript code.
Here is a quick example of how you would compile a MoonScript string to a Lua String:
moonscript | lua |
|
|
Two tools are installed with MoonScript, moon
and moonc
.
moonc
is for compiling MoonScript code to Lua.
moon
is for running MoonsScript code directly.
moon
moon
can be used to run MoonsScript files directly from the command line,
without needing a separate compile step. All MoonsScript files are compiled in
memory as they are run.
$ moon my_script.moon
Any MoonScript files that are required will also be compiled and run automatically.
When an error occurs during runtime, the stack trace is rewritten to give line
numbers from the original .moon
file.
If you want to disable error rewriting, you can pass the
-d
flag. A full list of flags can be seen by passing the -h
or --help
flag.
moonc
moonc
is used for transforming MoonsScript files into Lua files.
It takes a list of files, compiles them all, and creates the associated .lua
files in the same directories.
$ moonc my_script1.moon my_script2.moon ...
You can control where the compiled files are put using the -t
flag, followed
by a directory.
moonc
can also take a directory as an argument, and it will recursively scan
for all MoonScript files and compile them.
moonc
can write to standard out by passing the -p
flag.
Combined with linotify
on linux, the -w
flag can be used to watch all files
that match the given search path for changes, and then compile them only when
required.
A full list of flags can be seen by passing the -h
or --help
flag.
Copyright (C) 2011 by Leaf Corcoran
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.