- get the sources
- cd metalua/src
- set these variables or modify them in make.sh:
- * BUILD: a directory in which metalua should be built. Must be writable by the user.
+ * BUILD: a directory in which metalua should be built.
+ Must be writable by the user.
* INSTALL_BIN: where metalua will be copied
- * INSTALL_LIB: where (meta)lua libs will be copied. Should be referenced in your LUA_PATH.
+ * INSTALL_LIB: where (meta)lua libs will be copied. Should be
+ referenced in your LUA_PATH.
- run ./make.sh, under your UID
-- a ./make-install.sh script should have been generated, run it. If you want to isntall it
- in a directory that doesn't belong to you, you might want to run it as root.
+- a ./make-install.sh script should have been generated, run it. If you
+ want to install it in a directory that doesn't belong to you, you
+ might want to run it as root.
+- if you don't want to edit make.sh, this will do:
+ DESTDIR=/opt/metalua/git-1 \
+ INSTALL_BIN=/usr/local/bin \
+ INSTALL_LIB=/usr/local/lib/lua/5.1 \
+ ./make.sh
+ If this run is successful, do:
+ DESTDIR=/opt/metalua/git-1 \
+ INSTALL_BIN=/usr/local/bin \
+ INSTALL_LIB=/usr/local/lib/lua/5.1 \
+ ./make-install.sh
+ if no packaging is required, just leave out the "DESTDIR=... \" line.
+ If you want metalua to reside in the same space as distribution
+ supplied files in "/usr" instead of "/usr/local", you propably want to
+ leave out "local/" in the paths above.
Test drive
----------
Metalua is a static metaprogramming system for Lua: a set of tools
that let you alter the compilation process in arbitrary, powerful and
maintainable ways. For the potential first-time users of such a
-system, a descripition of these tools, as implemented by Metalua,
+system, a description of these tools, as implemented by Metalua,
follows.
Dynamic Parsers
---------------
One of the tools is the dynamic parser, which allows a source file to
-change the grammar recognized by the parser, while it's being
+change the grammar recognized by the parser while it's being
parsed. Taken alone, this feature lets you make superficial syntax
tweaks on the language. The parser is based on a parser combinator
library called 'gg'; you should know the half dozen functions in gg
So if your parser won't natively let you specify infix operator
precedence and associativity easily, tough luck for you and your
code maintainers. With combinators OTOH, most of such useful
- functions already exist, and you can write your owns without
+ functions already exist, and you can write your own without
rewriting the parser itself. For instance, adding an infix operator
would just look like:
- To easily let users see sources as trees, as sources, or as
combination thereof, and switch representations seamlessly.
-- To offer the proper libraries, that won't force you to reinvent a
- square wheel, will take care of the most common pitfalls, won't
+- To offer the proper libraries that won't force you to reinvent a
+ square wheel will take care of the most common pitfalls and won't
force you to resort to brittle hacks.
On the former point, Lisps are at a huge advantage, their user syntax
error statements", "rename all local variables and their instances
into unique fresh names", "list the variables which escape this
chunk's scope", "insert a type-checking instruction into every
- assignments to variable X", etc. Most of non-trivial macros will
+ assignment to variable X", etc. Most of non-trivial macros will
require some of those global code transformations, if you really want
them to behave correctly.
Simplification of the install and structure:
-- This release is included in Lua for Windows, so it now couldn't get simpler
+- This release is included in Lua for Windows, so now it couldn't get simpler
for MS-Windows users!
- Metalua is written in pure Lua again, thus making it platform-independant.
- some new extensions: xloop, xmatch, improved match.
-- ASTs now keep track of the source extract that generated them (API is not
+- ASTs now keep track of the source that generated them (API is not
mature though, it will be changed and broken).
- improved table printer: support of a plain-Lua mode, alternative indentation
- Update to Pluto 2.2 and Lua 5.1.3
- Build for Visual Studio .NET
-Notworthy changes from 0.3 to 0.4
+Noteworthy changes from 0.3 to 0.4
=================================
- A significantly bigger code base, mostly due to more libraries:
friendly than the mlc from the previous version.
-- Metalua source libraries are looked for in environmemt variable
+- Metalua source libraries are searched for in environmemt variable
LUA_MPATH, distinct from LUA_PATH. This way, in an application
that's part Lua part Metalua, you keep a natural access to the
native Lua compiler.
x = { f(), f(), f() }
\end{verbatim}
-The extension offers a way to expand intermediate response: they ahve
+The extension offers a way to expand intermediate response: they have
to be followed by {\tt...}. In the example above, {\tt y = \{f()...,
f()..., f()...\}} would expand as {\tt\{1, 2, 3, 1, 2, 3, 1, 2,
3\}}.
y} would have been {\tt y = \{i for i=1,3; i for i=1,3; i for
i=1,3\}} (notice however that we had to separate elements with
semicolons rather than commas: if we didn't, the {\tt i} of the second
-loop would have been tekane as a third parameter to the first for loop
+loop would have been taken as a third parameter to the first for loop
header).
Sub-sampling is done with indexes, by using the comma to separate
interpreted as number {\tt 1.} followed by operator {\tt..}: put a
space between literal numbers and operators starting with a dot.
-Notice taht there are now two substancially different operators with
+Notice that there are now two substancially different operators with
very similar syntaxes: the original index operator, which returns a
single element, and the sub-sampling operators, which returns a list
of elements. If you want to returna single element list, you can
y=x[i...i]}).
FIXME: there should be \verb|x[...i]| and \verb|x[i...]| sub-sampling
-notations, but they aren't currently implemented.
\ No newline at end of file
+notations, but they aren't currently implemented.
\section{{\tt clopts}: command line options parsing}
This library allows to parse command line options in a generic, standard and
reasonably powerful way. Using it for your programs helps ensure that they
-behave in an unsurprizing way to users. the {\tt metalua} compiler parses its
+behave in an unsurprising way to users. the {\tt metalua} compiler parses its
parameters with clopts.
FIXME: Rest of the doc to be written
(ADT is also the usual accronym for Abstract DataType. However, I'll
never talk about abstract datatypes in this manual, so there's no
reason to get confused about it. ADT always refers to algebraic
-datatypes).
+datatypes).
Metalua's distinctive feature is its ability to easily work on program
source codes as trees, and this include a proper syntax for tree
(1, 2, 3) will be represented as:
\begin{verbatim}
-{ tag="Cons", 1,
- { tag="Cons", 2,
- { tag="Cons", 3,
+{ tag="Cons", 1,
+ { tag="Cons", 2,
+ { tag="Cons", 3,
{ tag="Nil" } } } }
\end{verbatim}
Here is a more programming language oriented example: imagine that we
are working on a symbolic calculator. We will have to work this:
\begin{itemize}
-\item litteral numbers, represented as integers;
+\item literal numbers, represented as integers;
\item symbolic variables, represented by the string of their
symbol;
\item formulae, i.e. numbers, variables an/or sub-formulae
\verb+Number+, \verb+Var+ or \verb+Formula+. The formula $e^{i\pi}+1$
would be encoded as:
\begin{verbatim}
-{ tag="Formula", "Addition",
- { tag="Formula", "Exponent",
+{ tag="Formula", "Addition",
+ { tag="Formula", "Exponent",
{ tag="Variable", "e" },
- { tag="Formula", "Multiplication",
+ { tag="Formula", "Multiplication",
{ tag="Variable", "i" },
{ tag="Variable", "pi" } } },
{ tag="Number", 1 } }
With this syntax sugar, the $e^{i\pi}+1$ example above would read:
\begin{verbatim}
-`Formula{ "Addition",
- `Formula"{ "Exponent",
+`Formula{ "Addition",
+ `Formula"{ "Exponent",
`Variable "e",
- `Formula{ "Multiplication",
+ `Formula{ "Multiplication",
`Variable "i",
`Variable "pi" } },
`Number 1 }
is:
\begin{verbatim}
`Op{ "add", `Number 1,
- `Op{ "pow", `Id "e",
+ `Op{ "pow", `Id "e",
`Op{ "mul", `Id "i", `Id "pi" } } }
\end{verbatim}
needed. Metaprogrammers should know their general form, but it is
reasonnable to rely on a cheat-sheet to remember the exact details of
AST structures. Such a summary is provided
-in appendix of this tutorial, as a reference when dealing with them.
+in an appendix of this tutorial, as a reference when dealing with them.
In the rest of this section, we will present the translation from Lua
source to their corresponding AST.
4, but \verb|four=2+2| is a statement, which sets the value of
variable \verb|four| but has no value itself.
-\paragraph{Number constants}
+\paragraph{Number constants}
A number is represented by an AST with tag \verb+Number+ and the
number value as its sole child. For instance, \verb+6+ is represented
by \verb+`Number 6+\footnote{As explained in the section about ADT,
\begin{center}
\begin{tabular}{|c|c||c|c||c|c||c|c|}
\hline
- \bf Op. & \bf AST &
- \bf Op. & \bf AST &
- \bf Op. & \bf AST &
+ \bf Op. & \bf AST &
+ \bf Op. & \bf AST &
+ \bf Op. & \bf AST &
\bf Op. & \bf AST \\
-
+
\hline\hline %%%%%%%%%%%%%%%%%
- \verb|+| & \verb+"add"+ &
- \verb+-+ & \verb+"sub"+ &
- \verb+*+ & \verb+"mul"+ &
+ \verb|+| & \verb+"add"+ &
+ \verb+-+ & \verb+"sub"+ &
+ \verb+*+ & \verb+"mul"+ &
\verb+/+ & \verb+"div"+ \\
\hline %%%%%%%%%%%%%%%%%%%%%%%
- \verb+%+ & \verb+"mod"+ &
- \verb+^+ & \verb+"pow"+ &
- \verb+..+ & \verb+"concat"+ &
+ \verb+%+ & \verb+"mod"+ &
+ \verb+^+ & \verb+"pow"+ &
+ \verb+..+ & \verb+"concat"+ &
\verb+==+ & \verb+"eq"+ \\
\hline %%%%%%%%%%%%%%%%%%%%%%%
\verb+<+ & \verb+"lt"+ &
- \verb+<=+ & \verb+"le"+ &
- \verb+and+ & \verb+"and"+ &
+ \verb+<=+ & \verb+"le"+ &
+ \verb+and+ & \verb+"and"+ &
\verb+or+ & \verb+"or"+ \\
\hline %%%%%%%%%%%%%%%%%%%%%%%
\end{tabular}
\end{center}
-Operator names are the sames as the corresponding Lua metatable entry,
-without the prefix {\tt"\_\,\_"}. There are no operator for operators
+Operator names are the same as the corresponding Lua metatable entry,
+without the prefix {\tt"\_\,\_"}. There are no operators for
\verb+~=+, \verb+>=+ and \verb+>+: they can be simulated by swapping
the arguments of \verb+<=+ and \verb+<+, or adding a \verb+not+ to
operator \verb+==+.
\verb|`Op{ 'add', `Number 2, `Number 2 }|;
\item \verb|1+2*3| is represented as:\\[-2em]
\begin{verbatim}
-`Op{ 'add', `Number 1,
+`Op{ 'add', `Number 1,
`Op{ 'mul', `Number 2, `Number 3 } }
\end{verbatim}
\item \verb|(1+2)*3| is represented as:\\[-2em]
\begin{center}
\begin{tabular}{|c|c||c|c||c|c|}
\hline
- \bf Op. & \bf AST &
- \bf Op. & \bf AST &
+ \bf Op. & \bf AST &
+ \bf Op. & \bf AST &
\bf Op. & \bf AST \\
-
+
\hline\hline %%%%%%%%%%%%%%
- \verb+-+ & \verb+"unm"+ &
- \verb+#+ & \verb+"len"+ &
+ \verb+-+ & \verb+"unm"+ &
+ \verb+#+ & \verb+"len"+ &
\verb+not+ & \verb+"not"+ \\
\hline %%%%%%%%%%%%%%%%%%%%
\end{tabular}
\verb|`Op{ 'len', `Id "x" }|
\end{itemize}
-\paragraph{Indexed access}
+\paragraph{Indexed accesses}
They are represented by an AST with tag \verb+Index+, the table's AST
as first child, and the key's AST as second child.
\verb+`Index{ `Id "x", `String "y" }+
\end{itemize}
-Notice that index AST can also appear as left-hand side of
-assignments, as shall be shown in the subsection dedicated to
+Notice that an index AST can also appear as the left-hand side of
+an assignment, as shall be shown in the subsection dedicated to
statements.
-\paragraph{Function call}
-Function call AST have the tag \verb+Call+, the called function's AST
-as first child, and its arguments as remaining children.
+\paragraph{Function calls}
+A function call AST has the tag \verb+Call+, the called function's AST
+as the first child, and its arguments as the remaining children.
\subparagraph{Examples}
\begin{itemize}
\verb+`Call{ `Id "f", `Id "x", `Dots }+.
\end{itemize}
-Notice that function calls can be used as expressions, but also as statements.
+Notice that function calls can be used as expressions, but also as statements.
-\paragraph{Method invocation}
-Method invocation AST have the tag \verb+Invoke+, the object's AST as
-first child, the string name of the method as a second child, and
+\paragraph{Method invocations}
+A method invocation AST has the tag \verb+Invoke+, the object's AST as
+the first child, the string name of the method as the second child, and
the arguments as remaining children.
\subparagraph{Examples}
Notice that method invocations can be used as expressions, but also as
statements. Notice also that ``{\tt function o:m (x) return x end}'' is
-not a method invocation, but syntax sugar for statement
-``{\tt o["f"] = function (self, x) return x end}''. See the paragraph
-about assignment in statements subsection for its AST representation.
+not a method invocation, but syntax sugar for the statement ``{\tt
+o["f"] = function (self, x) return x end}''. See the paragraph about
+assignment in the statements subsection for its AST representation.
-\paragraph{Function definition}
+\paragraph{Function definitions}
A function definition consists of a list of parameters and a block of
statements. The parameter list, which can be empty, contains only
variable names, represented by their \verb+`Id{...}+ AST, except for
the last element of the list, which can also be a dots AST \verb+`Dots+
(to indicate that the function is a vararg function).
-The block is a list of statement AST, optionnaly terminated with a
+The block is a list of statement AST, optionally terminated with a
\verb+`Return{...}+ or \verb+`Break+ pseudo-statement. These
pseudo-statements will be described in the statements subsection.
\item \verb+function (x, y) foo(x); bar(y) end+ is represented as:
\begin{verbatim}
-`Function{ { `Id x, `Id y }
+`Function{ { `Id x, `Id y }
{ `Call{ `Id "foo", `Id "x" },
`Call{ `Id "bar", `Id "y" } } }
\end{verbatim}
-
+
\item \verb+function (fmt, ...) print (string.format (fmt, ...)) end+
is represented as:
\begin{verbatim}
-`Function{ { `Id "fmt", `Dots }
+`Function{ { `Id "fmt", `Dots }
{ `Call{ `Id "print",
`Call{ `Index{ `Id "string",
- `String "format" },
- `Id "fmt",
+ `String "format" },
+ `Id "fmt",
`Dots } } } }
\end{verbatim}
statement: it is actually syntax sugar for the assignment {\tt f =
function (x) return x end}, and as such, is represented as:
\begin{verbatim}
-`Let{ { `Id "f" },
+`Let{ { `Id "f" },
{ `Function{ {`Id 'x'} {`Return{`Id 'x'} } } } }
\end{verbatim}
(see assignment in the statements subsection for more details);
In Lua, parentheses are sometimes semantically meaningful: when the
parenthesised expression returns multiple values, putting it between
-parentheses foreces it to return only one value. For instance, ``{\tt
+parentheses forces it to return only one value. For instance, ``{\tt
local function f() return 1, 2, 3 end; return \{ f() \}}'' will
return ``{\tt\{1, 2, 3\}}'', whereas ``{\tt local function f() return
1, 2, 3 end; return \{ (f()) \}}'' will return ``{\tt\{ 1 \}}''
\}}''. The second example above has the following AST:
\begin{verbatim}
-{ `Localrec{ { `Id "f" },
+{ `Localrec{ { `Id "f" },
{ `Function{ { },
`Return{ `Number 1,
`Number 2,
\subsubsection{Statements}
Statements are instructions which modify the state of the
-computer. There are simple statement, such as variable assignment,
-local variable declaration, function calls and method invocation;
+computer. There are simple statements, such as variable assignments,
+local variable declarations, function calls and method invocations;
there are also control structure statements, which take simpler
-statement and modify their action: these are if/then/else,
+statements and modify their action: these are if/then/else,
repeat/until, while/do/end, for/do/end and do/end statements.
-\paragraph{Assignment}
-Variable assignment \verb+a, b, c = foo, bar+ is represetned by AST
-\verb+`Set{ lhs, rhs }+, with {\tt lhs} being a list of variables or
+\paragraph{Assignments}
+A variable assignment \verb+a, b, c = foo, bar+ is represented by the
+AST \verb+`Set{ lhs, rhs }+, with {\tt lhs} being a list of variables or
table indexes, and {\tt rhs} the list of values assigned to them.
\subparagraph{Examples}
\item \verb+a = 1, 2, 3+ is represented as:\\
\verb+`Set{ { `Id "a" }, { `Number 1, `Number 2, `Number 3 } }+;
-\item \verb+function f(x) return x end+ is syntax sugar for:\\
- \verb+f = function (x) return x end+. As such, is represented as:\\[-2em]
+\item \verb+function f(x) return x end+ is syntactic sugar for:\\
+ \verb+f = function (x) return x end+. As such, it is represented as:\\[-2em]
\begin{verbatim}
-`Set{ { `Id "f" },
+`Set{ { `Id "f" },
{ `Function{ {`Id 'x'} {`Return{ `Id "x" } } } } }
\end{verbatim}
-\item \verb+function o:m(x) return x end+ is syntax sugar for:\\
+\item \verb+function o:m(x) return x end+ is syntactic sugar for:\\
\verb+o["f"] = function (self, x) return x end+, and as such, is
represented as:\\[-2em]
\begin{verbatim}
-`Set{ { `Index{ `Id "o", `String "f" } },
- { `Function{ { `Id "self, "`Id x }
+`Set{ { `Index{ `Id "o", `String "f" } },
+ { `Function{ { `Id "self, "`Id x }
{ `Return{ `Id "x" } } } } }
\end{verbatim}
\end{itemize}
-\paragraph{Local declaration}
-Local declaration \verb+local a, b, c = foo, bar+ works just as
+\paragraph{Local declarations}
+A local declaration \verb+local a, b, c = foo, bar+ works just as an
assignment, except that the tag is \verb+Local+, and it is allowed to
have an empty list as values.
\end{itemize}
-\paragraph{Recursive local declaration}
+\paragraph{Recursive local declarations}
In a local declaration, the scope of local variables starts {\em
after} the statement. Therefore, it is not possible to refer to a
variable inside the value it receives, and
``{\tt local f = function (x) f(x) end}'': in the latter, the \verb|f|
call inside the function definition probably refers to some global
variable, whereas in the former, it refers to the local variable
-currently being defined (f this therefore a forever looping function).
+currently being defined (f is therefore a function looping forever).
To handle this, the AST syntax defines a special \verb|`Localrec|
-local declaration statement, in which the variables enter in scope
+local declaration statement, in which the variables enter into scope
{\em before} their content is evaluated. Therefore, the AST
corresponding to {\tt local function f(x) f(x) end} is:
\begin{verbatim}
-`Localrec{ { `Id "f" },
- { `Function{ { `Id x }
+`Localrec{ { `Id "f" },
+ { `Function{ { `Id x }
{ `Call{ `Id "f", `Id "x" } } } } }
\end{verbatim}
-\caveat{In the current implementation, both variable names list and
- values list have to be of lenght 1. This is enough to represent
+\caveat{In the current implementation, both variable name lists and
+ value lists have to be of lenght 1. This is enough to represent
{\tt local function ... end}, but should be generalized in the
final version of Metalua.}
`Return{ `Id "x", `Id "y" } }
\end{verbatim}
-\paragraph{Do statement}
-These represent \verb|do ... end| statements, which limit local
-variables scope. They are represented as
-blocks with a \verb|Do| tag.
+\paragraph{Do statements}
+These represent \verb|do ... end| statements, which limit the scope of
+local variables. They are represented as blocks with a \verb|Do| tag.
\subparagraph{Example}
\verb|do foo(x); bar(y); return x,y end| is represented as:
`Return{ `Id "x", `Id "y" } }
\end{verbatim}
-\paragraph{While statement}
+\paragraph{While statements}
\verb|while <foo> do <bar1>; <bar2>; ... end| is represented as \\
\verb|`While{ <foo>, { <bar1>, <bar2>, ... } }|.
-\paragraph{Repeat statement}
+\paragraph{Repeat statements}
\verb|repeat <bar1>; <bar2>; ... until <foo>| is represented as \\
\verb|`Repeat{ { <bar1>, <bar2>, ... }, <foo> }|.
represented as {\tt `Fornum\{ `Id "x", <first>, <last>, <step>, \{
<foo>, <bar>, ... \} \}}.
-The \verb|step| parameter can be omitted if equal to 1.
+The \verb|step| parameter can be omitted if it is equal to 1.
\begin{verbatim}
for x1, x2... in e1, e2... do
...
end
\end{verbatim}
-isrepresented as:\\
+is represented as:\\
{\tt `Forin\{ \{`Id "x1",`Id "x2",...\}, \{ <e1>, <e2>,... \} \{
<foo>, <bar>, ... \} \}}.
\paragraph{If statements}
``If'' statements are composed of a series of (condition, block)
-pairs, and optionnaly of a last default ``else'' block. The conditions
+pairs, and optionally of a last default ``else'' block. The conditions
and blocks are simply listed in an \verb|`If{ ... }| ADT. Notice that
an ``if'' statement without a final ``else'' block will have an even
number of children, whereas a statement with a final ``else'' block
\item
\begin{verbatim}
-if <foo1> then <bar1>; <baz1>
-elseif <foo2> then <bar2>; <baz2>
-else <bar3>; <baz3> end+
+if <foo1> then <bar1>; <baz1>
+elseif <foo2> then <bar2>; <baz2>
+else <bar3>; <baz3> end+
\end{verbatim}
is represented as:
\begin{verbatim}
-`If{ <foo1>, { <bar1>, <baz1> },
+`If{ <foo1>, { <bar1>, <baz1> },
<foo2>, { <bar2>, <baz2> },
{ <bar3>, <baz3> } }
\end{verbatim}
\end{itemize}
-\paragraph{Breaks and returns}
+\paragraph{Breaks and returns}
Breaks are represented by the childless \verb|`Break| AST. Returns are
retpresented by the (possibly empty) list of returned values.
\subparagraph{Example}
-{\tt return 1, 2, 3} is represented as:\\
+{\tt return 1, 2, 3} is represented as:\\
{\tt`Return\{ `Number 1, `Number 2, `Number 3 \}}.
\subsubsection{Extensions with no syntax}
local x = mlp.gensym(); ... `Label\{ x \} }''. You just jump to that
label with ``{\tt `Goto\{ x \} }''.
-Identifiers, string AST or plain strings are equivalent:
+Identifiers, string AST or plain strings are equivalent:
``{\tt`Label\{ `Id "foo"\}}'' is synonymous for ``{\tt`Label\{ `String
"foo"\}}'' and ``{\tt`Label "foo"}''. The same equivalences apply
-for gotos, of course.
+to gotos, of course.
Labels are local to a function; you can safely jump out of a block,
-but if you jump {\em inside} a block, you're likely to get into unspecified
+but if you jump {\em into} a block, you're likely to get into unspecified
trouble, as local variables will be in a random state.
\paragraph{Statements in expressions}
There is a {\tt strict} library in Lua, also provided by metalua, which
complains when one tries to access a global variable which hasn't been
initialized, and when a global variable is initialized anywhere but at the
-program's top-level. This catches many errors, especially typos on variable
+program's top-level. This catches many errors, especially typos in variable
names.
However, with a macro-enabled language, we can do slightly better: we add a {\tt
When you write a short-lived macro which takes reasonably short arguments, you
generally don't want to write a supporting syntax for it. The dollar library
allows you to call it in a generic way: if you store your macro in the table
-{\tt mlp.macros}, say as function {\tt mlp.macros.foobar}, then you can call it
+{\tt mlp.macros}, say as a function {\tt mlp.macros.foobar}, then you can call it
in your code as {\tt\$foobar(arg1, arg2...)}: it will receive as parameters the
ASTs of the pseudo-call's arguments.
\section{{\tt gg}, the grammar generator}
-\verb|gg| is the grammar generator, the library with which Metalua
+\verb|gg| is the grammar generator, the library with which the Metalua
parser is built. Knowing it allows you to easily write your own
parsers, and to plug them into mlp, the existing Metalua source
parser. It defines a couple of generators, which take parsers as
\subsection{Sequences}
A sequence parser combines sub-parsers together, calling them one after
-the other. A lot of these sub-parsers will simply read a keyword, and
-do nothing of it except making sure that it is indeed here: these can
+the other. A lot of these sub-parsers will simply read a keyword and
+do nothing with it except making sure that it is indeed there: these can
be specified by a simple string. For instance, the following
declarations create parsers that read function declarations, thanks
to some subparsers:
\begin{itemize}
\item \verb|func_stat_name| reads a function name (a list of
- identifiers separated by dots, plus optionally a semicolon and a
+ identifiers separated by dots, plus optionally a colon and a
method name);
\item \verb|func_params_content| reads a possibly empty list of
identifiers separated with commas, plus an optional ``\verb|...|'';
\subsubsection{Constructor {\tt gg.sequence (config\_table) }}
This function returns a sequence parser. \verb|config_table| contains,
-in its array part, a sequence of string representing keyword parsers,
+in its array part, a sequence of strings representing keyword parsers,
and arbitrary sub-parsers. Moreover, the following fields are allowed
in the hash part of the table:
elements: the results of \verb|func_stat_name|,
\verb|func_params_content| and \verb|mlp.block|.
-It can also be directly called as simply \verb|x(lexstream)| instead of
+It can also be called directly as simply \verb|x(lexstream)| instead of
\verb|x:parse(lexstream)|.
\subsubsection{Method {\tt .transformers:add(f)}}
This function returns a sequence set parser. The array part of
\verb|config_table| contains a list of parsers. It also accepts tables
instead of sequence parsers: in this case, these tables are supposed
-to be config tables for \verb|gg.sequence| constructor, and are
+to be config tables for \verb|gg.sequence| constructors, and are
converted into sequence parsers on-the-fly by calling
\verb|gg.sequence| on them. Each of these sequence parsers has to
start with a keyword, distinct from all other initial keywords,
result is either returned directly, or passed through \verb|builder|
if this field is non-nil.
-It can also be directly called as simply \verb|x(lexstream)| instead of
+It can also be called directly as simply \verb|x(lexstream)| instead of
\verb|x:parse(lexstream)|.
\subsubsection{Method {\tt :add(sequence\_parser)}}
Beware that separators are consumed from the lexstream stream, but
terminators are not.
-%\caveat{FIXME: check that it works as advertized (for list parserd
+%\caveat{FIXME: check that it works as advertised (for list parsers
% with separators AND terminators; it's related to the trailing
% separator issue in block and table\_content parsers). There still is
% a design issue to settle here.}
\begin{itemize}
\item\verb|primary = <parser>| (mandatory): the parser used to read
- elemetns of the list;
+ elements of the list;
\item\verb|separators = <list> |: list of strings representing the
keywords accepted as element separators. If only one separator is
as read by the primary parser, or the result of that list passed
through \verb|builder| if it is specified.
-It can also be directly called as simply \verb|x(lexstream)| instead of
+It can also be called directly as simply \verb|x(lexstream)| instead of
\verb|x:parse(lexstream)|.
\subsubsection{Method {\tt .transformers:add}}
instance, two infix sequences starting with keyword ``\$'').
Most of the time, the sequences representing operators will have a
-single keyword, and no subparser. For instance, the addition is
+single keyword, and no subparsers. For instance, the addition is
represented as:\\
\verb~{ "+", prec=60, assoc="left", builder= |a, _, b| `Op{ `Add, a, b } }~
\begin{itemize}
\item\verb|prec = <number>| its precedence. The higher the precedence,
- the tighter the operator bind with respect to other operators. For
+ the tighter the operator binds with respect to other operators. For
instance, in Metalua, addition precedence is 60, whereas
multiplication precedence is 70.
\item\verb|builder = <function>| the usual result transformer. The
function takes as parameters the left operand, the result of the
sequence parser (i.e. \verb|{ }| if the sequence contains no
- subparser), and the right operand; it must return the resulting AST.
+ subparser) and the right operand; it must return the resulting AST.
\end{itemize}
\begin{itemize}
\item\verb|primary| (mandatory): the primary parser, which reads the
- primary elements linked by operators. In Metalua expression parsers,
- that would be numbers, strings, identifiers\ldots It is often a
+ primary elements linked by operators. In Metalua expression parsers
+ these would be numbers, strings, identifiers\ldots It is often a
multisequence parser, although that's not mandatory.
\item\verb|prefix|: a list of tables representing prefix operator
sequences, as described above. It supports a {\tt default} parser:
\subsubsection{Method {\tt :parse (lexstream)}}
Read a list from the lexstream. The result is built by \verb|builder1| calls.
-It can also be directly called as simply \verb|x(lexstream)| instead of
+It can also be called directly as simply \verb|x(lexstream)| instead of
\verb|x:parse(lexstream)|.
\subsubsection{Method {\tt :tostring()}}
\verb|false| if the next token in the lexstream wasn't one of the
specified keywords.
-It can also be directly called as simply \verb|x(lexstream)| instead of
+It can also be called directly as simply \verb|x(lexstream)| instead of
\verb|x:parse(lexstream)|.
\subsection{{\tt optkeyword} parser}
Watch for optional keywords: an \verb|optkeyword| parser has a list of
keyword strings as a configuration. If such a keyword is found as the
-nex lexstream element upon parsing, the keyword is consumed and that
+next lexstream element upon parsing, the keyword is consumed and that
string is returned. If not, \verb|false| is returned.
\subsubsection{Constructor {\tt gg.optkeyword (keyword1, keyword2, ...)}}
\begin{itemize}
\item Nothing taboo under the hood: the underlying mechanisms of the
language must remain simple enough to be intelligible to their
- intended users. Black magic should be banned from the desing. This
+ intended users. Black magic should be banned from the design. This
rules out hygienic macros as a primitive: these either rely on very
advanced and hard to predict mechanisms, or severely limit the
manipulation tools available to the macro authors.
\item Simple by default: advanced users should know what happens under
the hood, but more casual users should be able to simply turn the
- ignition and drive. It should be possible to use H, for regular
+ ignition and drive. It should be possible to use H for regular
macros, without much understanding of its advanced principles and
implementation.
\item Everything's a regular program: again, most macro systems
\paragraph{Inside captures}
There are two kind of captures, inside a macro and outside a
-macro. People often think about inside captures, in parts because the
+macro. People often think about inside captures, in part because the
C preprocessor is subject to it. It happens when a macro inserts user
code in a quote, and the quote declares a local variable that shadows
a user one:
}, +{result} } }
\end{Verbatim}
-This is fixed by renaming automatically all local variables in the
+This is fixed by automatically renaming all local variables in the
macro with fresh names. H provides an AST walker which does
that. However, it needs to rename only macro code, not user-provided
code; therefore the macro writer has to somehow mark the user
(-{`Id '.2.X.table'}.tostring(table)))
\end{Verbatim}
-To make this work, we need to introduce, somewhere where no variable
+To make this work, we need to introduce, someplace where no variable
is captured, the following local statement:
\begin{Verbatim}
local -{`Id '.1.X.printf'}, -{`Id '.2.X.table'} = printf, table
\section{Concepts}
\paragraph{Lua}
-Lua\footnote{\url{http://www.lua.org}} is an very clean and powerful
-language, with everything the discrimiating hacker will love: advanced
+Lua\footnote{\url{http://www.lua.org}} is a very clean and powerful
+language, with everything the discriminating hacker will love: advanced
data structures, true function closures, coroutines (a.k.a collaborative
multithreading), powerful runtime introspection and metaprogramming
abilities, ultra-easy integration with C.
the kind of more advanced and baroque things that only CLOS users
could dream of...
-Basically, Lua could be though of as Scheme, with:
+Basically, Lua could be thought of as Scheme, with:
\begin{itemize}
\item a conventional syntax (similar to Pascal's or Ruby's);
-\item the associative table as basic datatype instead of the list;
+\item the associative table as the basic datatype instead of the list;
\item no full continuations (although coroutines are actually one-shot
semi-continuations);
\item no macro system.
\paragraph{Metalua}
Metalua is an extension of Lua, which essentially addresses the lack
of a macro system, by providing compile-time metaprogramming (CTMP)
-and the ability for user to extend the syntax from within Lua.
+and the ability for users to extend the syntax from within Lua.
Runtime metaprogramming (RTMP) allows a program to inspect itself
while running: an object can thus enumerate its fields and methods,
\paragraph{Metaprogramming}
A compiler is essentially a system which takes sources (generally as
-a set of ASCII files), turn them into a practical-to-play-with data
+a set of ASCII files), turns them into a practical-to-play-with data
structure, does stuff on it, then feeds it to a bytecode or machine
code producer. The source and byte-code stages are bad abstraction
levels to do anything practical: the sensible way to represent code,
ISBN 85-903798-2-5 Paperback, 328 pages\\
Distributed by Ingram and Baker \& Taylor.},
a.k.a. ``the blue PiL'', probably one of the best programming books
-since K\&R's ``The C Language''. Suffice to say that a seasonned
+since K\&R's ``The C Language''. Suffice it to say that a seasoned
programmer will be able to program in Lua in a couple of hours,
although some advanced features (coroutines, function environments,
function closures, metatables, runtime introspection) might take
\item Languages built from scratch, such as
converge\footnote{\url{http://convergepl.org}} or
Logix\footnote{\url{http://http://www.livelogix.net/logix/index.html}}, have
- to bear with the very long (often decade) maturing time required by a
+ to bear with the very long (often decades) maturing time required by a
programming language. Moreover, they lack the existing libraries and
developpers that come with an already succesful language.
approach of giving powerful generic tools rather than ready-made
closed features to its users.
\item Its excellent supports for runtime metaprogramming.
-\item Its syntax, despite (or due to its) being very readable and easy
+\item Its syntax, despite (or due to) being very readable and easy
to learn, is also extremely simple to parse. This means no extra
technology gets in the way of handling syntax (no BNF-like
specialized language, no byzantine rules and exceptions). Even more
\end{itemize}
Finally, it's difficult to talk about a macro-enabled language without making
-Lisp comparisons. Metalua borrows a lot to Scheme's love for empowering
+Lisp comparisons. Metalua borrows a lot of Scheme's love for empowering
minimalism, through Lua. However, in many other respects, it's closer to Common
Lisp: where Scheme insists on doing The Right Thing, CL and metalua assume that
the programmer knows better than the compiler. Therefore, when a powerful but
{\tt"mismatch"} is raised. However, we'll see it's easy to add a catch-all
pattern at the end of the match, when we want it to be failproof.
-\subsection{Patterns definition}
+\subsection{Pattern definitions}
-\paragraph{Atomic litterals}
+\paragraph{Atomic literals}
Syntactically, a pattern is mostly identical to the values it matches: numbers,
booleans and strings, when used as patterns, match identical values.
\end{verbatim}
When a variable appears several times in a single pattern, all the elements they
-match must be equal, in the sense of the "==" operator. Fore instance, pattern \{
+match must be equal, in the sense of the "==" operator. For instance, pattern \{
x, x \} will match value \{ 1, 1 \}, but not \{ 1, 2 \}. Both values would be
matched by pattern \{ x, y \}, though. A special identifier is "\_", which doesn't
-bind its content. Even if it appears more than once in the pattern, metched
+bind its content. Even if it appears more than once in the pattern, matched
value parts aren't required to be equal. The pattern "\_" is therefore the
simplest catch-all one, and a match statement with a "{\tt| \_ ->}" final
statement will never throw a "mismatch" error.
\section{Splicing and quoting}
As the previous section shows, AST are not extremely readable, and as
-promized, Metalua offer a way to avoid dealing with them
-directly. Well, rarely dealing with them anyway.
+promised, Metalua offer a way to avoid dealing with them
+directly. Well, rarely dealing with them, anyway.
In this section, we will deal a lot with \verb|+{...}| and
\verb|-{...}|; the only (but real) difficulty is not to get lost
surrounding quote won't be an AST).
But what happens when a splice is put outside of any quote? There is
-no explicit quotation to cancel, but actually, there is an hidden AST
+no explicit quotation to cancel, but actually, there is a hidden AST
generation. The process of compiling a Metalua source file consists in
the following steps:
\hrule~\\
Thanks to the print statement in the splice, we see that the code
-it contains is actually executed during evaluation. More in details,
-what happens is that:
+it contains is actually executed during evaluation. More in detail,
+what happens is this:
\begin{itemize}
\item The code inside the splice is parsed and compiled separately;
\item it is executed: the call to \verb|print "META HELLO"| is
\paragraph{ternary choice operator}
Let's build something more useful. As an example, we will build here a
ternary choice operator, equivalent to the \verb|_ ? _ : _| from
-C. Here, we will not deal yet with syntax sugar: our operator will
+C. Here, we will not deal with syntax sugar yet: our operator will
have to be put inside splices. Extending the syntax will be dealt with
in the next section, and then, we will coat it with a sweet syntax.
quasi-quotes, just to show that we can. Another operator that C
developpers might be missing with Lua is the \verb|++| operator. As
with the ternary operator, we won't show yet how to put the syntax
-sugar coating around it, just how to build the backend functionnality.
+sugar coating around it, just how to build the backend functionality.
Here, the transformation is really trivial: we want to encode
\verb|x++| as \verb|x=x+1|. We will only deal with \verb|++| as
implement \verb|mlp|, the Metalua parser, which turns Metalua sources
into AST.
-Therefore, the informations useful to extend Metalua syntax are:
+Therefore, the information useful to extend Metalua syntax is:
\begin{itemize}
\item What are the relevant entry points in mlp, the methods which
allow syntax extension.
-\item How to use these methods: this consists into knowing the classes
- defined into gg, which offer dynamic extension possibilities.
+\item How to use these methods: this consists of knowing the classes
+ defined in gg, which offer dynamic extension possibilities.
\end{itemize}
\section{{\tt mlp}, the metalua parser}
-Metalua parser is built on top of \verb|gg|, and cannot be understood
+The metalua parser is built on top of \verb|gg|, and cannot be understood
without some knowledge of it. Basically, \verb|gg| allows not only to
build parsers, but to build {\em extensible} parsers. Depending on a
parser's type (sequence, sequence set, list, expression\ldots),
extension point for Metalua expression. Supports all of the methods
defined by {\tt gg.expr}.}
-\entry{mlp.func\_val}{gg.sequence}{Read a function definition,
- from the arguments' openning parenthesis to the final {\tt end}, but
+\entry{mlp.func\_val}{gg.sequence}{Read a function definition
+ from the arguments' opening parenthesis to the final {\tt end}, but
excluding the initial {\tt function} keyword, so that it can be used
both for anonymous functions, for {\tt function some\_name(...) end}
and for {\tt local function some\_name(...) end}.}
% \entry{mlp.func\_params\_content}{gg.list}{Read a potentially empty
% (``{\tt)}''- or ``{\tt|}''-terminated) list of function definition
% parameters, i.e. identifiers or ``{\tt ...}'' varargs. Surrounding
-% parentheses are excluded. Don't get confused between parameters and
+% parentheses are excluded. Don't get confused by parameters versus
% arguments: parameters are the variable names used in a function
% definition; arguments are the values passed in a function call.}
% of function call arguments. Surrounding parentheses are excluded.}
% \entry{mlp.func\_args}{gg.sequence\_set}{Read function arguments: a
-% list of expressions between parenthses, or a litteral table, or a
-% litteral string.}
+% list of expressions between parenthses, or a literal table, or a
+% literal string.}
%\entry{mlp.func\_params}{}{}
\entry{mlp.expr\_list}{}{}
\entry{mlp.table\_content}{gg.list}{Read the content of a table,
excluding the surrounding braces}
-\entry{mlp.table}{gg.sequence}{Read a litteral table,
+\entry{mlp.table}{gg.sequence}{Read a literal table,
including the surrounding braces}
\entry{mlp.table\_field}{\rm custom function}{Read a table entry: {\tt
\tableFooter
Actually, {\tt mlp.stat} is an extended version of a multisequence: it
-supports easy addition of new assignment operator. It has a field {\tt
+supports easy addition of new assignment operators. It has a field {\tt
assignments}, whose keys are assignment keywords, and values are
assignment builders taking left-hand-side and right-hand-side as
parameters. for instance, C's ``+='' operator could be added as:
are macros which take care not to use names that might interfere
with user-provided names. The typical non-hygienic macro in C
is {\tt \#define SWAP( a, b) \{ int c=a; a=b; b=c; \}}: this macro
- will misearbly fail if you ever call it with a parameter named
+ will misearbly fail if you ever call it with an argument named
{\tt c}. There are well-known techniques to automatically make a
macro hygienic. Without them, you'd have to generate a unique name
for the temporary variable, if you had a {\tt gensym()} operator
\item{\bf Meta-programming in metalua:} this chapter exposes the generic principles
of static meta-programming: meta-levels in sources, AST representation of
code, meta-operators. You need to read this carefully if you plan to write any
- non-trivial meta-programming code and you've never used languages like, Common
+ non-trivial meta-programming code and you've never used languages like Common
Lisp, camlp4 or Converge. If you're familiar with one of these, a cursory look
over this chapter might be enough for you.
\item{\bf Standard meta-programming libraries:} these are the tools that will allow
- you to manipulate code effectively; the more advanced an extension you want to
+ you to effectively manipulate code; the more advanced an extension you want to
write the more of these you'll want to know.
\begin{itemize}
\item{\bf mlp} is the dynamically extensible metalua parser. You need to know it
\item{\bf match} is an extension supporting structural pattern matching (which has
almost nothing to do with regular expressions on strings). It's a construct
taken from the ML language familly, which lets you manipulate advanced data
- structures in vrey powerful ways. It's extremely helpful, among others, when
+ structures in very powerful ways. It's extremely helpful, among others, when
working with AST, i.e. for most interesting meta-programs.
- \item{\bf walk} is a code walker generator: smomething akin to a visitor pattern,
+ \item{\bf walk} is a code walker generator: something akin to a visitor pattern,
which will help you to write code analysers or transformers. Whenever you
want to find and transform all return statements in an AST, rename some
conflicting local variables, check for the presence of nested for loops
faster.
\item{\bf hygiene} offers hygienic macros, i.e. protects you from accidental
variable captures. As opposed to e.g. Scheme, macro writing is not limited
- to a term rewriting system in metalua, which lets more power to the
- programmer, but prevents from completely automating macro hygienization. If
- you wrote an extension and you want to raise it to production-quality,
- you'll need among others to protect its users from variable captures, and
- you'll need to hygienize it. If you don't feel like cluttering your code
+ to a term rewriting system in metalua, which gives more power to the
+ programmer, but prohibits completely automating macro hygienization. If
+ you wrote an extension and you wanted to raise it to production-quality,
+ you'd need among others to protect its users from variable captures, and
+ you'd need to hygienize it. If you don't feel like cluttering your code
with dozens of {\tt gensym} calls, you'll want to use the macro hygienizer.
\item{\bf dollar:} if you wrote a macro, but don't feel the need to give it a
- dedicated syntax extension, this library will let you call this macro as a
+ dedicated syntax extension, this library will let you call the macro as a
regular function call, except that it will be prefixed with a ``{\tt\$}''.
\end{itemize}
\item{\bf General purpose libraries:} Lua strives at staying minimalist, and does
needs quite some support to run, and relies on a number of imported and
custom-built libraries. Most of them can be reused for many other purposes
including yours.\\
- A whole category of metalua users, who want to use third party libraries
- rather than reinventing their own wheels, will be primarily interested by
+ A whole category of metalua users who want to use third party libraries,
+ rather than reinventing their own wheels, will be primarily interested in
these.
\begin{itemize}
\item{\bf metalua.runtime:} extensions to Lua core libraries: base, table,
for metalua programs.
\item{\bf springs} brings together Lua Ring's handling of separate Lua universes
with Pluto's communication capabilities.
- \item{\bf clist} offers an extended tables-as-list interface: lists by
+ \item{\bf clist} offers an extended tables-as-lists interface: lists by
comprehension {\em \`a la} Haskell or Python, list chunks etc.
\item{\bf xglobal} makes global variables declaration mandatory, for safer
- programming, with almost no runtime overhead, and a syntax consistant qith
+ programming, with almost no runtime overhead, and a syntax consistant with
local variables declaration.
\item{\bf anaphoric} introduces anaphoric control structures, akin to Common
- Lisp's {\tt aif}-familly macros.
+ Lisp's {\tt aif}-family macros.
\item{\bf trycatch} provides a proper exception system, with reliable finally
blocks and exception catching by structural pattern matching.
\item{\bf log} eases the terminal logging of variables, mainly for those from
\subsection{Exceptions}
-As a first non-trivial example of extension, we'll pick exception:
+As a first non-trivial example of an extension, we'll pick exception:
there is a mechanism in Lua, {\tt pcall()}, which essentially provides
the raw functionality to catch errors when some code is run, so
enhancing it to get full exceptions is not very difficult. We will aim
\item being able to attach additional data to exception (e.g. an error
message);
\item not interfere with the usual error mechanism;
-\item support the ``finally'' feature, which guaranties that a piece
- of code (most often about resource liberation) will be executed.
+\item support the ``finally'' feature, which guarantees that a piece
+ of code (most often about resource release) will be executed.
\end{itemize}
\subsubsection{Syntax}
lets us read an undetermined series of exception cases, separated by
keyword ``{\tt|}'', until we find the terminator ``{\tt end}''
keyword. The parser delegates the building of the resulting statement
-to {\tt trywith\_builder}, which will be detailled later. Finally, we
+to {\tt trywith\_builder}, which will be detailed later. Finally, we
have to declare a couple of mundane things:
\begin{itemize}
\item that {\tt try}, {\tt with} and {\tt->} are keywords. If we don't
- do this, the two firsts will be returned by the lexer as identifiers
- instead of keywords; the later will be read as two separate keywords
- ``{\tt-}'' and ``{\tt>}''. We don't have to declare explicitly
- ``{\tt|}'', as single-character symbols are automatically considered to
- be keywords.
+ do this, the first two will be returned by the lexer as identifiers
+ instead of keywords; the last one will be read as two separate
+ keywords ``{\tt-}'' and ``{\tt>}''. We don't have to declare
+ ``{\tt|}'' explicitly, as single-character symbols are automatically
+ considered to be keywords.
\item that ``{\tt|}'' and ``{\tt with}'' can terminate a block of
statements. Indeed, metalua needs to know when it reached the end of
a block, and introducing new constructions which embed blocks often
\subsubsection{Exception objects}
We want to be able to classify exceptions hierarchically: each
-exception will inherit form a more generic exception, the most generic
+exception will inherit from a more generic exception, the most generic
one being simply called ``{\tt exception}''. We'll therefore design a
system which allows to specialize an exception into a sub-exception,
and to compare two exceptions, to know whether one is a special case
of another. Comparison will be handled by the usual {\tt< > <= >=}
operators, which we'll overload through metatables. Here is an
implementation of the base exception {\tt exception}, with working
-comparisons, and a {\tt new()} method which allow to specialize an
+comparisons, and a {\tt new()} method which allows to specialize an
exception. Three exceptions are derived as an example, so that
{\tt exception > exn\_invalid > exn\_nullarg} and {\tt exception >
exn\_nomorecoffee}:
that fits. If none is found (either it's an uncaught exception, or a
genuine error which is not an exception at all), it must be rethrown.
-Notice that throwing an exception simply consists into sending it as
+Notice that throwing an exception simply consists of sending it as
an error:
\begin{Verbatim}[fontsize=\scriptsize]
end
---------------------------------------------------------
- -- Finally, put an [else] block to rethrow uncought errors:
+ -- Finally, put an [else] block to rethrow uncaught errors:
---------------------------------------------------------
table.insert (catchers, +{error (exn)})
\begin{itemize}
\item Variables {\tt exn} and {\tt status} are subject to capture;
\item There is no way to put personalized data in an exception. Or,
- more accurately, there's no practiccal way to retrieve it in the
+ more accurately, there's no practical way to retrieve it in the
exception handler.
-\item What happens if there's a {\tt return} statement in the guraded
+\item What happens if there's a {\tt return} statement in the guarded
block?
\item There's no {\tt finally} block in the construction.
\item Coroutines can't yield across a {\tt pcall()}. Therefore, a
-yield in the guarded code will cause an error.
+ yield in the guarded code will cause an error.
\end{itemize}
Refining the example to address these shortcomings is left as an
-exercice to the reader, we'll just give a couple of design
+exercise to the reader, we'll just give a couple of design
hints. However, a more comprehensive implementation of this exception
system is provided in metalua's standard libraries; you can consider
its sources as a solution to this exercice!
The simplest way to detect user-caused returns is to create a unique
object (typically an empty table), and return it at the end of the
-block. when no exception has been thrown, test whether that object was
-returned: if anything else than it was returned, then propagate it (by
+block. When no exception is thrown, test whether that object was
+returned: if anything else was returned, then propagate it (by
{\tt return}ing it again). If not, do nothing. Think about the case
-when multiple values have been returned.
+when multiple values are returned.
The {\tt finally} block poses no special problem: just go through it,
whether an exception occured or not. Think also about going through it
returning true;
\item if it's a yield, propagate it to the upper level; when resumed,
propagate the resume to the guarded code which yielded.
-\end{itemize}
\ No newline at end of file
+\end{itemize}
pattern;
\end{itemize}
\item variables are valid patterns, and match everything. Moreover,
- the term matched by the variable captures it, i.e. in the
+ the term matched by a variable captures it, i.e. in the
corresponding block, that variable is set to the
matched term.
\end{itemize}
~\\~\\
Notice that the relative order of tests and assignments is meaningful:
-we cannot put all assignments on one side, and all tests on an
+we cannot put all assignments on one side, and all tests on the
other, e.g. \verb|v2 = v1.tag| on line 3 doesn't make sense if
\verb|type(v1) == table| on line 2 fails.
\begin{Verbatim}[fontsize=\scriptsize]
-------------------------------------------------------------------
- -- Turn a pattern into a list of conditions and assignations,
+ -- Turn a pattern into a list of conditions and assignments,
-- stored into [acc]. [n] is the depth of the subpattern into the
-- toplevel pattern; [tested_term] is the AST of the term to be
-- tested; [pattern] is the AST of a pattern, or a subtree of that
\item {\tt var($n$)} generates the variable name ``\verb|v|$n$'', which
is used to store the tested term at depth level $n$. Indeed,
sub-patterns in table fields are matched against sub-terms of the
- tested term. It also remembers of the biggest $n$ it ever received,
+ tested term. It also remembers the biggest $n$ ever received,
and stores it into \verb|max_n| (this will be used to know which
local vars have to be generated, see below);
\item {\tt accumulate()} just stores an additional code snippet in a
As written above, our collapsing function will be kept as simple
as possible, and will not try to minimize the amount of generated
code. It takes as parameters {\tt n}, the index of the quote currently
-collapsed in the accumulator, and {\tt inner\_term} the statement
+collapsed in the accumulator, and {\tt inner\_term}, the statement
block to put inside the innermost part of the test. It calls itself
recursively, so that the collapsed term is built inside out (generally
speaking, working with trees, including AST, involves a lot of
\begin{Verbatim}[fontsize=\scriptsize]
-------------------------------------------------------------------
- -- Turn a list of tests and assignations into [acc] into a
+ -- Turn a list of tests and assignments into [acc] into a
-- single term of nested conditionals and assignments.
-- [inner_term] is the AST of a term to be put into the innermost
- -- conditionnal, after all assignments. [n] is the index in [acc]
+ -- conditional, after all assignments. [n] is the index in [acc]
-- of the term currently parsed.
--
-- This is a recursive function, which builds the inner part of
\end{Verbatim}
There is one point to notice in this quote: \verb|body| is used where
-a statement is expected, although it contains a {\em list} if
+a statement is expected, although it contains a {\em list} of
statements rather than a single statement. Metalua is designed to
accept this, i.e. if {\tt a, b, c, d} are statements, AST {\tt
`Do\{ a, b, c, d \}} and {\tt`Do\{ a, \{ b, c \}, d\} } are
\subsubsection{Syntax extension}
To use this, we provide a syntax inspired by OCaml\footnote{It is
- actually the same syntax as OCaml's, except that we introduced an
+ actually the same syntax as OCaml's, except that we introduce an
explicit {\tt end} terminator, to stay homogeneous with Lua.}:
\begin{Verbatim}[fontsize=\scriptsize]
\noindent Now, if you try this\ldots\ it won't work! Indeed, Metalua
needs to know what keywords might terminate a block of statements. In
-this case, it doesn't know that ``\verb+|+'' can terminate a block. We
-need therefore to add the following statement:
+this case, it doesn't know that ``\verb+|+'' can terminate a block.
+Therefore we need to add the following statement:
\begin{Verbatim}[fontsize=\scriptsize]
mlp.block.terminators:add "|"
\end{Verbatim}
-\noindent Finally that's it, we have implemented a working pattern
+\noindent That's it, we have implemented a working pattern
matching system in 75 lines of code!
\subsubsection{Possible improvements}
Here are a couple of suggestions to further improve the pattern
matching system presented above. Some of these proposals can be
-implemented very quickly, some others more complex; all of them
+implemented very quickly, others are more complex; all of them
present some practical interest.
The code of the basic version, as presented here, is available at
hand-written programs, but they're a bliss for machine-generated
code. They would slightly simplify the code of pattern matching as
presented above; but for many extension proposals listed below, they
-will make reasonnably easy some things which would otherwise be
-awfully contrived. Exercice: simplify the implementation above as much
+will make some things reasonably easy, which would otherwise be
+awfully contrived. Exercise: simplify the implementation above as much
as possible by using gotos.
Labels and gotos in metalua ASTs are represented as {\tt`Label\{ id
\}} and {\tt`Goto\{ id \}} respectively, with {\tt id} an
identifier, typically generated by {\tt mlp.gensym()}. It is always
-safe to jump out of a block; jumping into a block is not guaranteed
-against weird interactions with local variables and upvalues.
+safe to jump out of a block; jumping into a block is not safe
+regarding weird interactions with local variables and upvalues.
\paragraph{{\tt collapse()} optimization} Instead of nesting if
statements systematically, two nested {\tt if}s without {\tt else}
branches can be simplified in a single branch with an {\tt and}
operator. Not sure it would change the bytecode's efficiency, but
-that's a good exercice of AST manipulation.
+that's a good exercise of AST manipulation.
\paragraph{Superfluous assignments} When parsing a table entry, we
assign it to a variable, then recursively call {\tt parse\_pattern()}
\paragraph{Adding guards}
It is sometimes desirable to add arbitrary conditions for a pattern to
-match, conditions which might no be expressed by a pattern. OCaml
+match, conditions which might not be expressable by a pattern. OCaml
allows to add them with a ``\verb|when|'' keyword:
\begin{Verbatim}[fontsize=\scriptsize]
\paragraph{More bindings}
The way pattern matching is currently implemented, one can either bind
-a subterm to a variable, or check its structure against a sub-pattern,
-not both simultaneously. OCaml provides an ``\verb|as|'' operator,
+a subterm to a variable or check its structure against a sub-pattern,
+but not both simultaneously. OCaml provides an ``\verb|as|'' operator,
which allows to do both (Haskell calls it ``\verb|@|''). For instance,
in the following example, any ADT whose tag is \verb|"RepeatMe"| will
be replaced by two occurrences of itself, while others will remain
convert your code generator to gotos and labels first.
\paragraph{Linear bindings}
-We should check, when compiling a pattern, that it is left-linear,
+When compiling a pattern we should check that it is left-linear,
i.e. that variables don't appear more than once in the pattern. People
might be tempted to write things like this to check whether a tree is
symmetric:
scoping issue: the variables assigned belong to the scope of the
surrounding block.
-\paragraph{Pattern matchings as expressions}
-Pattern matching are currently statements, and take statements as
-right-hand sides of cases. We could allow pattern matchings where
+\paragraph{Pattern matching as expressions}
+Pattern matches are currently statements, and take statements as
+right-hand sides of cases. We could allow pattern matches where
expressions are expected: these would take expressions instead of
statements as right-hand sides. Two ways to implement this: the dirty
one (hack with functions to change match statements into expressions),
reasons: writing a language's compiler in the language itself. Here,
the idea is to re-implement the pattern matching extension by using
pattern matching, and compile it with the older version. Comparing the
-firsrt and second versions of the code will give you an idea of how
+first and second versions of the code will give you an idea of how
much code clarification is brought to you by the pattern matching
extension.
\paragraph{Pattern conjunction} Another feature to take from OCaml is
multiple patterns for a single block. Instead of associating one
block with one pattern, cases associate a block with a (non-empty)
-list of patterns. All of these patterns have to bond the same
+list of patterns. All of these patterns have to bind the same
variables, except for {\tt\_}. The first pattern in the list to match
the tested term does the binding. Patterns are separated by
``\verb+|+''. Example:
\begin{itemize}
\item Realize, if you didn't already, that Metalua's ADT are
isomorphic to XML, if you identify string-keys in tables with
- attributes, and limit there content to strings and number. For
+ attributes, and limit their content to strings and number. For
instance, ``{\tt <foo bar=3><baz/>eek</foo>}'' easily maps to ``{\tt
`foo\{ bar=3, `baz, "eek" \}}'';
-\item compare what ML-style pattern matching does with what XSLT
- does (and with what you'd like it to do);
+\item compare what ML-style pattern matching does with XSLT
+ (and what you'd like it to do);
\item design, implement, publish. You might want to google
``CDuce''\footnote{\url{http://www.cduce.org}} for neat ideas.
\end{itemize}
-If you do this, I'd be really interested to put back your contribution
+If you do this, I'd really be interested to put back your contribution
in the next version of Metalua!
\subsubsection{Correction}
\subsection{Origins and purpose}
Springs (Serialization through Pluto for RINGS) is an extension of Lua Rings and
-Pluto: Lua Rings allow to create new Lua states from within Lua, but offers
+Pluto: Lua Rings allow to create new Lua states from within Lua, but offer
limited communication between them: a master universe can only send instruction
to a slave universe through a ``{\tt dostring}'', and the slave universe can
only send back strings, integers and booleans as results. Since Pluto allows to
\item \verb|<http://www.keplerproject.org/rings/>|
\item \verb|<http://luaforge.net/projects/pluto/>|
\end{itemize}
-Notice however that the Pluto version used in metalua has significantly patched
+Notice however that the Pluto version used in metalua is significantly patched
and debugged by Ivko Stanilov.
\subsection{API}
easily. For instance:\\
\verb|r:pcall('table.concat', {'a', 'b', 'c'}, ',')|
\item {\tt :call()} is similar to :pcall(), except that in case of error, it
- actually throws the error in the sender universe's context. Therefore, it
+ actually throws the error in the senders universe's context. Therefore, it
doesn't return a success status as does pcall(). For instance: \\
\verb|assert('xxx' == r:call('string.rep', 'x', 3))|
\end{itemize}
this non-determinism by choosing the interpretation which allows the
combined parser to yield a result.
-Gg intentionnaly doesn't support backtracking: not only would it be
+Gg intentionally doesn't support backtracking: not only would it be
slightly harder to read in a non-lazy language such as Lua, but it
isn't required to parse Lua. More importantly, built-in backtracking
would encourage people to create ambiguous syntax extensions, which is
cohabitate as smoothly as possible, and two extensions with ambiguous
grammars generally cause a lot of chaos when mixed together. Finally,
a lot of Lua's essence is about friendly, unsurprizing, clear
-syntax. We want to encourage people into respecting this spirit as
+syntax. We want to encourage people to respect this spirit as
much as possible, so if they want to introduce chaotic syntax, Metalua
won't actively prevent them to do so, but it certainly won't help by
providing the tools.
-Gg offers no atomic parser, besides keyword parser generators; it's up
-to the programmer to provide these. Parsers are simply functions which
+Gg offers no atomic parsers besides keyword parser generators; it's up
+to the programmer to provide them. Parsers are simply functions which
take a lexer as a parameter, and return an AST. Such function examples
are provided for mlp in mlp\_expr.lua. Lexers are objects with a
couple of mandatory methods: peek, next and is\_keyword. Lexer API
shall be discussed in the part about mll.
\paragraph{State}
-gg.lua is correctly refactored and commented, and should be readable
+Gg.lua is correctly refactored and commented, and should be readable
by anyone with some notions of Lua and functional programming. Having
dealt with parsec might help a bit, but is definitely not required.
gg. Mlp is cut into several parts:
\begin{itemize}
-\item {\bf mlp\_expr.lua} parses expressions, except literal tables
+\item {\bf mlp\_expr.lua} parses expressions except literal tables
and quotes. It includes other constants (booleans, strings,
numbers), the compound expressions built by combining them with
operators, and function bodies. Most of its complexity is handled by
the expression parser generator gg.expr.
\item {\bf mlp\_table.lua} parses tables. Not much to say about this,
this is probably the simplest subpart of mlp.
-\item {\bf mlp\_stat.lua} parses statements. Except for assignements,
+\item {\bf mlp\_stat.lua} parses statements. Except for assignments,
every different statement is introduced by a distinct initial
keyword, and it should remain that way.
\item {\bf mlp\_ext.lua} gathers the parts of the metalua syntax that
- aren't regulat Lua: customizable assignments, short lambda syntax
+ aren't regular Lua: customizable assignments, short lambda syntax
etc.
-\item {\bf mlp\_meta.lua} handles the meta-operation, splicing and
+\item {\bf mlp\_meta.lua} handles the meta-operations splicing and
quoting.
\item {\bf mlp\_misc.lua} contains various little bits that wouldn't
fit anywhere else. In other words, it's sort of a mess.
\begin{itemize}
\item it helps to understand the original compiler in C;
\item it's easy to backport extensions from the C version to Yueliang
- (I had to do it, since Yueliang was 5.0 and I neede 5.1)
+ (I had to do it, since Yueliang was 5.0 and I needed 5.1)
\item it's rather easy to get bitwise-identical compilations, between
what Yueliang produces and what the C version does. And that's good,
because testing a compiler is a non-trivial problem.
\end{itemize}
The big drawback is that the code is very much structured like C, and
-is therefore, big, memory and time hungry, harder than necessary to
+is therefore big, memory and time hungry, harder than necessary to
understand and maintain, not suitable for clean and easy
extensions. Two possible evolutions could be considered for metalua:
\subsection{The bootstrapping process}
-FIXME
\ No newline at end of file
+FIXME
Many of the extensions of {\tt table} are dedicated to a more
functional style programming. When compared to the functions in
Haskell or ML's standard libs, these one are slightly more general,
-taking advantage from Lua's dynamic typing.
+taking advantage of Lua's dynamic typing.
\function{table.iforeach(f, ...)}
{\tt table.iforeach(f, t)} will evaluate f with every array-part
elements of t in order.
-If more than one table are passed as parameters, f will receive an
+If more than one table is passed as arguments, f will receive an
element of each table at each iteration. For instance, {\tt
table.iforeach (print, \{1, 2, 3\}, \{4, 5, 6\}, \{7, 8, 9\})} will
print:
\end{verbatim}
If the second and/or third parameters are numbers, they indicate the
-first and last indexes to use in the tables. First index defaults to
-1, last index default to the length of the longest table. If only one
-number is passed, it's considered to be the first index. For instance,
+first and last indices to use in the tables. The first index defaults
+to 1, the last index defaults to the length of the longest table. If
+only one number is passed, it's considered to be the first index. For
+instance,
{\tt table.iforeach (print, 2, \{1, 2, 3\}, \{4, 5, 6\}, \{7, 8, 9\})}
will only print:
\begin{verbatim}
the sum of {\tt list}'s elements can be computed by {\tt table.ifold(
(|x,y| x+y), 0, list)}.
-This function also accepts first and last indexes after {\tt acc}, and
-more than one table argument: if there are more than one table, then
+This function also accepts first and last indices after {\tt acc}, and
+more than one table argument: if there is more than one table, then
more than two parameters are passed to {\tt f()}. For instance, this
function returns $\sum_{i\le2} \max(x[i], y[i])$: {\tt
table.ifold( (|acc, xi, yi| acc + max (xi, yi)), 0, 2, x, y)}.
\function{table.izip(...)}
-Take a sequence of lists, and return the
+Takes a sequence of lists, and returns the
list of their first elements, then their second elements, etc. For
instance, {\tt table.izip (\{1,2,3\}, \{4,5,6\})} will return
{\tt\{\{1,4\}, \{2,5\} , \{3,6\}\}}.
Does a deep copy of {\tt t}, i.e. all keys and values are recursively
copied. Handles tables with shared and circular references correctly;
-also set the copy's metatable to the original's one.
+also sets the copy's metatable to the original's one.
\function{table.range(a, b, c)}
\subsection{Library {\tt mlc}}
-FIXME: move in metalua.compiler.
+FIXME: move into metalua.compiler.
-This library offer conversion between the different possible
+This library offers conversions between the different possible
representations of metalua programs:
\begin{itemize}
\item as source files
\item FIXME
\end{itemize}
-Hopefully, the function names are self-explanatory. Some of them are
+The function names are hopefully self-explanatory. Some of them are
simply aliases to other standard functions such as {\tt loadstring()}
or {\tt string.dump()}; many others are compositions of other
functions. The point is that every sensible transformation from
\function{walk\_stat (cfg)}
FIXME
-%don't get confused between the AST it applies on, the the AST being
+%don't get confused between the AST it applies on and the AST being
%currently inspected.
%function calls and method invocations in a statement context are not
Metalua is essentially Lua + code generation at compile time +
extensible syntax. However, there are a couple of additional
constructs, considered of general interest, which have been added to
-Lua's original syntax. These are presented in this section
+Lua's original syntax. These are presented in this section.
\subsection{Anonymous functions}
Lua lets you use anonymous functions. However, when programming in a
functional style, where there are a lot of short anonymous functions
simply returning an expression, the default syntax becomes
-cumbersome. Metalua being functional-styel friendly, it offers a
+cumbersome. Metalua being functional-style friendly, it offers a
terser idiom: ``{\tt function(arg1, arg2, argn) return some\_expr
end}'' can be written:\\
``{\tt|arg1,arg2,argn| some\_exp}''.
\subsection{Metalevel shifters}
-These to dual notations are the core of metaprogramming: one
-transforms code into a manipulaeble representation, and the other
+These two dual notations are the core of metaprogramming: one
+transforms code into a manipulable representation, and the other
transforms the representation back into code. They are noted
{\tt+\{...\}} and {\tt-\{...\}}, and due to their central role in
metalua, their use can't be summed up adequately here: they are fully
\item the protected code is executed
\item if its execution causes an error, the error message is matched
against all exception patterns, until one matches or the last one is
- reached (see the \verb+match+ extension for patterns
+ reached (see the \verb+match+ extension for pattern
semantics). Patterns can include guard clauses. The block
corresponding to the first matching pattern is executed. If no
pattern matches, the error will be rethrown.
programming pattern in which an object's lifetime is strictly
associated with a given lexical scope. For instance, if a file is
opened in a given scope, it must be closed as soon as this scope is
- leaved, even if it's leaved due to a {\tt return} or an error. The
+ left, even if it's left due to a {\tt return} or an error. The
``finally'' block allows this, but since it's a very common use case,
there is a dedicated extension ``with/do'': you initialize some resource
- behind the ``with'' keyword, and it will be closed after the ``do''
+ after the ``with'' keyword, and it will be closed after the ``do''
block is left. The only constraint is that the resources must have a
{\tt:close()} method which releases them. Here is a usage example:
When you write advanced macros, or when you're analyzing some code to check for
some property, you often need to design a function that walks through an
arbitrary piece of code, and does complex stuff on it. Such a function is called
-a code walker. Code walkers can be used for some punctual adjustments, e.g.
+a code walker. Code walkers can be used for selective adjustments, e.g.
changing a function's {\tt return} statements into something else, or checking
that a loop performs no {\tt break}, up to pretty advanced transformations, such
-as CPS transformation (a way to encode full continuations into a language taht
+as CPS transformation (a way to encode full continuations into a language that
doesn't support them natively; see Paul Graham's On Lisp for an accessible
description of how it works), lazy semantics...
and are generally brittle. To ease things as much as possible, Metalua comes
with a walk library, which intends to accelerate code walker implementation.
Since code walking is intrinsically tricky, the lib won't magically make it
-trivial, but at least it will save you a lot of time and code, when compared to
-writing all walkers from scratch. Moreover, other people who took the time to
+trivial, but at least it will save you a lot of time and code when compared to
+writing walkers from scratch. Moreover, other people who took the time to
learn the walker generator's API will enter into your code much faster.
\subsection{Principles}
Code walking is about traversing a tree, first from root to leaves, then from
leaves back to the root. This tree is not uniform: some nodes are expressions,
-some others statements, some others blocks; and each of these node kinds is
+some are statements, some are blocks; and each of these node kinds is
subdivided in several sub-cases (addition, numeric for loop...). The basic code
walker just goes from root to leaves and back to root without doing anything.
-Then it's up to you to plug some action callbacks in that walker, so that it
+Then it's up to you to plug some action callbacks into that walker, so that it
does interesting things for you.
Without entering into the details of AST structure, here is a simplified version
\end{itemize}
\subsection{API}
-There are 3 main tree walkers: {\tt walk.expr()}, {\tt walk.stat()} and {\tt
+There are three main tree walkers: {\tt walk.expr()}, {\tt walk.stat()} and {\tt
walk.block()}, to walk through the corresponding kinds of ASTs. Each of these
-walker take as parameters a table {\tt cfg} containing the various visitor
-functions, and the AST to walk throuhg. the configuration table {\tt cfg} can
+walkers takes as parameters a table {\tt cfg} containing the various visitor
+functions, and the AST to walk through. The configuration table {\tt cfg} can
contain fields:
\begin{itemize}
\item {\tt cfg.stat.down(node, parent, grandparent...)}, which applies when
- traversing a statement down, i.e. before its children nodes are parsed, and
- can modify the tree, and return {\tt nil} or {\tt'break'}. The way children
+ traversing a statement down, i.e. before its children nodes are parsed,
+ can modify the tree and return {\tt nil} or {\tt'break'}. The way children
are traversed is decided {\em after} the {\tt down()} visitor has been run:
this point matters when the visitor modifies its children nodes.
-\item {\tt cfg.stat.up(node, parent, grandparent...)}, which is applies on the
+\item {\tt cfg.stat.up(node, parent, grandparent...)}, which applies on the
way back up. It is applied even if {\tt cfg.stat.down()} returned
{\tt'break'}, but in that case, the children have not been (and will not be)
traversed.
\item {\tt cfg.expr.down()} and {\tt cfg.expr.up()}, which work just as their
{\tt stat} equivalent, but apply to expression nodes.\\
Notice that in Lua, function calls and method invocations can be used as
- statements as well as as espressions: in such cases, they are visited only by
+ statements as well as expressions: in such cases, they are visited only by
the statement visitor, not by the expression visitor.
-\item {\tt cfg.block.down()} and {\tt cfg.block.up()} do the same for statements
+\item {\tt cfg.block.down()} and {\tt cfg.block.up()} do the same for statement
blocks: loops, conditional and function bodies.
\item {\tt cfg.binder(identifier, id\_parent, id\_grandparent...)}: this
- is run on identifiers which create a new local variable, jsut before that
+ is run on identifiers which create a new local variable, just before that
variable's scope begins.
\end{itemize}
Now, let's say we want to catch and remove all statement calls to function
assert(). This can be done by removing its tag and content: an empty list is
-simply ignored in an AST. So we're only interested by `Call nodes, and within
+simply ignored in an AST. So we're only interested in `Call nodes, and within
these nodes, we want the function to be `Id 'assert'. All of this is only
relevant to stat nodes:
function cfg.stat.down (x)
match x with
| `Call{ `Id 'assert', ... } -> x.tag=nil; x <- { }
- | _ -> -- not interested by this node, do nothing
+ | _ -> -- not interested in this node, do nothing
end
end
\end{verbatim}
The imperative table overrider ({\tt x <- y} a.k.a. {\tt table.override(x, y)}
also often comes handy to modify an AST.
-We'll now remove {\tt assert()} calls in non-statement; we cannot replace an
-expression by nothing, so we'll replace these nodes by these will simply be
-replaced by {\tt nil}:
+We'll now remove {\tt assert()} calls in non-statements; we cannot
+replace an expression with nothing, so we'll simply replace them with
+{\tt nil}:
\begin{verbatim}
function cfg.expr.down (x)
match x with
| `Call{ `Id 'assert', ... } -> x <- `Nil
- | _ -> -- not interested by this node, do nothing
+ | _ -> -- not interested in this node, do nothing
end
end
\end{verbatim}
\paragraph{Cuts}
By making down() return 'break', you can prevent the traversal to go further
-down. This might be either because you're not interested by the subtrees, or
+down. This might be either because you're not interested in the subtrees, or
because you want to traverse them in a special way. In that later case, just do
the traversal by yourself in the down() function, and cut the walking by
returning 'break', so that nodes aren't re-traversed by the default walking
-algorithm. We'll see that in the next, more complex example, listing of free
+algorithm. We'll see that in the next, more complex example of listing free
variables.
-This example is exclusively there for demonstration purposes. For actual work on
-identifiers that require awareness of an identifier's binder of freedom, there
+This example is exclusively there for demonstration purposes. For actual
+work on identifiers that require awareness of their binding state, there
is a dedicated {\tt walk.id} library.
-We'll progressively build a walker that gathers all global variables used in a
-given AST. This involves keeping, at all times, a set of the identifiers
-currently bound by a "local" declaration, by function parameters, as for loop
-variables etc. Then, every time an identifier is found in the AST, its presence
-is checked in the current set of bound variables. If it isn't in it, then it's a
-free (global) identifier.
+We'll progressively build a walker that gathers all global variables
+used in a given AST. This involves keeping, at all times, a set of
+the identifiers currently bound by a "local" declaration, by function
+parameters, by for loop variables etc. Then, every time an identifier is
+found in the AST, its presence is checked in the current set of bound
+variables. If it isn't in it, then that's a free (global) identifier.
The first thing we'll need is a scope handling system: something that keeps
track of what identifiers are currently in scope. It must also allow to save the
its documentation for details).
Now let's start designing the walker. We'll keep a scope object up to date, as
-well as a set of found free identifiers, gathered every time we find an `Id{ }
-node. To slightly simplify matter, we'll consider that the AST represent a
+well as a set of free identifiers found, gathered every time we find an `Id{ }
+node. To slightly simplify matter, we'll consider that the AST represents a
block.
\begin{Verbatim}[fontsize=\scriptsize]
\end{Verbatim}
This starts to be useful. We can also easily add the case for `Localrec{ } nodes
-(the ones generated by {\tt "local function foo() ... end"}), where the variable
+(the ones generated by {\tt "local function foo() ... end"}), where a variable
is already bound in the {\tt`Localrec} statement's right-hand side; so we do the
same as for {\tt`Local}, but we do it in the {\tt down()} function rather than
in the up() one.
\subsection{Library {\tt walk.id}, the scope-aware walker}
This library walks AST to gather information about the identifiers in it. It
-call distinct visitor functions depending on whether an identifier is bound or
+calls distinct visitor functions depending on whether an identifier is bound or
free; moreover, when an identifier is bound, the visitor also receives its
binder node as a parameter. For instance, in {\tt +\{function(x) print(x)
end\}}, the bound identifier walker will be called on the \verb|+{x}| in the
\item {\tt walk\_id.guess()}.
\end{itemize}
-They take the same config tables as regular walkers, except that they also
+They take the same config tables as regular walkers, except they also
recognize the following entries:
\begin{itemize}
\item {\tt cfg.id.free(identifier, parent, grandparent...)}, which is run on
projects / metalua.git / commitdiff