Remove `e2function` preprocessing

[AbigailBuccaneer]

Lua is good at domain-specific languages. There's no reason we should preprocess source code.

Instead of:

e2function number operator==(complex lhs, complex rhs)
    if abs(lhs[1] - rhs[1]) > delta then return 0 end
    if abs(lhs[2] - rhs[2]) > delta then return 0 end
    return 1
end

We could get away with:

e2function [[number operator==(complex, complex)]] ..
function(lhs, rhs)
    if abs(lhs[1] - rhs[1]) > delta then return 0 end
    if abs(lhs[2] - rhs[2]) > delta then return 0 end
    return 1
end

And that's valid pure Lua.

It's not quite as nice a syntax, I grant you that, but it would actually work correctly with code editors, and it would get rid of a significant amount of code. We could also use the same syntax for registerType / registerOperator, which currently use pure Lua to define their E2 names and types.

[TomyLobo]

The two editors i have used with lua in the past always highlighted e2function syntax correctly.
In addition to that, extpp is standard lua so you can run extpp in whatever external environment you want to test your code in.

EDIT: btw, is there any particular reason why the bodies of the two functions aren't identical?
EDIT2: btw that's not valid Lua, at least not in 5.1.
And how were you going to get the function out of there anyway? :)

[AbigailBuccaneer]

@TomyLobo, it is valid Lua, and this is how it would work:

function e2function(signature)
  return setmetatable({}, {
    __concat = function(_, func) return registerE2Function(signature, func) end
  })
end

Yes, that's a bit weird, but defining DSLs often is - and it's something that we can explain in one small part of the code.

The bodies aren't identical because the body of the first one wasn't valid pure Lua, and I thought while fixing it up I may as well fix up the awful formatting caused by using an if statement.

Editors which only do basic syntax highlighting via tokenization can handle e2function functions mostly just fine, but others which actually parse the code get very tripped up by it. (The editor I use - the Lua plugin for IntelliJ - does things like highlighting locals, globals and upvalues separately, which has helped me spot a whole class of bugs.)

[TomyLobo]

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> function e2function(signature) return setmetatable({}, { __concat = function(_, func) return registerE2Function(signature, func) }) end
stdin:1: 'end' expected near '}'
> function e2function(signature) return setmetatable({}, { __concat = function(_, func) return registerE2Function(signature, func) end }) end
> e2function [[number operator==(complex, complex)]] .. function(lhs, rhs) local equal = abs(lhs[1]-rhs[1])<=delta and abs(lhs[2]-rhs[2])<=delta return equal and 1 or 0 end
stdin:1: unexpected symbol near '..'

try again?

Btw the body of both of your example function is valid standard Lua.
If you're gonna fix one, fix both. The difference between your examples should be what you want to show, not some random thing you noticed while editing code.

[AbigailBuccaneer]

Btw the body of both of your example function is valid standard Lua.

No, it uses &&, which is Garrys Mod specific.

Urgh, Lua doesn't allow arbitrary expressions as statements. So you have to bind it to a local.

function registerE2Function(signature, func)
  return print("Registering E2 function " .. signature .. " = " .. tostring(func))
end

function e2function(signature)
  print(signature)
  return setmetatable({}, {
    __concat = function(_, func) return registerE2Function(signature, func) end
  })
end

local __eq = e2function([[number operator==(complex, complex)]]) ..
function(lhs, rhs)
end

In that case, can I propose:

e2function([[number operator==(complex, complex)]],
function(lhs, rhs)
end)

Even simpler, with no special DSL magic. Would still remove a lot of preprocessing code.

[TomyLobo]

at least half of extpp.lua has to do with:

• parsing the signature
• figuring out the type abbreviations for each type (including for types in extensions not yet loaded)
• accounting for methods/member functions
• doing special fetching for functions and some operators but not for others
• making sure it's possible to call the functions as local function under a mangled name
• making functions pretty in debug output

You would need all of that in your implementation as well.

[TomyLobo]

I updated your original post with a body that's better than both your example bodies :)

[thegrb93]

For member functions 'this' will need to be added as a parameter.

Also, your examples don't show the function name anywhere. Would it be like this?

E2Functions["myfunctionname"] = e2function([[number operator==(complex, complex)]],
function(lhs, rhs)
end)

[bigdogmat]

That's because it's not a function, it's an operator. And it is defined here

[[number operator==(complex, complex)]]

[TomyLobo]

@bigdogmat if you are talking about "Foo:pos()", that's not an operator.

[thegrb93]

Oh sorry, duh. I'm sleepy. I guess the function name would go where the operator is.

e2function([[vector entity:pos()]],
function(this)
end)

Would probably be abbreviated types instead of this, but yea

[TomyLobo]

yeah, @AbigailBuccaneer picked kinda the most extreme example

[TomyLobo]

@thegrb93 well the point of e2function, or at least one of them, is to make E2 function signatures readable and less boilerplate-y.
So you're supposed to use typenames there, not typeids.

[immibis]

Just make it a straightforward function call - why use weird tricks to get weird syntax that's not even an improvement?

e2function("number operator==(complex, complex)",
    function(lhs, rhs)
        if abs(lhs[1] - rhs[1]) > delta then return 0 end
        if abs(lhs[2] - rhs[2]) > delta then return 0 end
        return 1
    end
)

or (different whitespace):

e2function("number operator==(complex, complex)",
function(lhs, rhs)
    if abs(lhs[1] - rhs[1]) > delta then return 0 end
    if abs(lhs[2] - rhs[2]) > delta then return 0 end
    return 1
end)