Re: reducing patch complexity and conflicts

[HyperHacker <hyperhacker@...>]

On Thu, Nov 25, 2010 at 22:12, David Manura <dm.lua@math2.org> wrote:
> Some changes might be made in the Lua source to reduce the complexity
> of patches and the likelihood of conflicts between patches.
>
> Consider the "continue" patch [1], which extends the lexer like this:
>
> -------------------------
>  const char *const luaX_tokens [] = {
> -    "and", "break", "do", "else", "elseif",
> +    "and", "break", "continue", "do", "else", "elseif",
>     "end", "false", "for", "function", "if",
> ---
> #define FIRST_RESERVED  257
> ---
>  enum RESERVED {
>   /* terminal symbols denoted by reserved words */
> -  TK_AND = FIRST_RESERVED, TK_BREAK,
> +  TK_AND = FIRST_RESERVED, TK_BREAK, TK_CONTINUE,
>   TK_DO, TK_ELSE, TK_ELSEIF, TK_END, TK_FALSE, TK_FOR, TK_FUNCTION,
> -------------------------
>
> That will conflict with other patches that extend the lexer with
> nearby keywords.  I'd suggest the lexer being written like this:
>
> ----------------------------
> static const char *const luaX_tokens [] = {
>    /* terminal symbols denoted by reserved words */
>    "and",
>    "break",
>    "do",
>    "else",
>    .....
> ---------------------------
> enum RESERVED {
>  /* terminal symbols denoted by reserved words */
>  TK_RESERVED_BEFORE = FIRST_RESERVED - 1,
>  TK_AND,
>  TK_BREAK,
>  TK_DO,
>  .....
>  TK_WHILE,
>  TK_RESERVED_AFTER,
>  /* other terminal symbols */
>  TK_OTHER_BEFORE = TK_RESERVED_AFTER - 1,
>  TK_CONCAT
>  .....
> /* number of reserved words */
> #define NUM_RESERVED    (cast(int, TK_RESERVED_AFTER - TK_RESERVED_BEFORE - 1))
> ---------------------------
>
> Similar things might be done elsewhere, such as adding a placeholder
> after VINDEXED in expkind to avoid the hardcoded comparison here,
> which will break if another variable kind is added after VINDEXED:
>
>  #define vkisvar(k)    (VLOCAL <= (k) && (k) <= VINDEXED)
>
> One may also write a Lua script that validates constraints like
> "ORDERED RESERVED" on patched Lua sources.
>
> [1] http://lua-users.org/wiki/LuaPowerPatches
>
>

The hextype patch has a similar problem. It adds a new variable type
(64-bit unsigned integer) and some new operators for binary
operations. It deals with this problem basically like:
#ifdef LUA_HEX
...modified line...
#else
...original line...
#endif
which does get a bit messy. Adding that new type also breaks all
binary compatibility with existing libraries; I tried to correct this
by moving the new type to the end of the type list, but found this
didn't work because Lua makes some assumptions about the ordering of
types (IIRC something like all types in a certain range represent
objects that need garbage collection) and I couldn't figure out how to
change all such assumptions to accommodate it.

tl;dr: Agreed, while Lua is a fantastic language, the source code is
very messy, difficult to understand, and not very patch-friendly.

-- 
Sent from my toaster.