This is an anonymous function shorthand suggestion & discussion for pico8.
sum=function(a,b)return a+b end
Right now, anonymous function definitions look like this.
This is way too long for such a simple function!
I know that Lua doesn't have its own short function; although efforts were made(as seen here), none stood out to be practical.
But as there is already a ton of shorts in pico8, why not add one more?
Of course, then we have to decide the syntaxes for this short.
Below I list three function shorts from other languages:
As implemented in Python and Java.
lambda p1=default,p2:expression sum=lambda a,b:a+b
(example from Python)
Allows default values, which makes the assignment of local values very concise.
From my experience of size-optimization in pico8, one pattern troubles me: nobody uses local variables.
Of course, size-optimized code is supposed to be purely procedural and I get that; still, they can be better with such a shorthand.
Nice and short. (Don't need 2 characters for the arrow tho, one will do the trick)
Just like the Lambda method, it also allows default values.
> Personally, I think the Elixir
fn(p1)-> expression end fits the Lua syntax better.
> But why arrow again when there are already parentheses to separate the parameters and the expression??
> Also, the additional
end fails to capture the expression-like nature of anonymous functions. It's not a control structure(although it can be used as one).
Overall, I think this is the best choice.
The & shorthand
sum = &(&1 + &2)
(example from https://elixirschool.com/en/lessons/basics/functions/)
This is the shortest so far.
Instead of naming the parameters, why not just number them?
This shorthand has several problems tho:
doesn't align with the De Bruijn index.
- no default values.
- if I do
&(&2), does this just evaluate to
function(x)return function(y)return y end end? As you can see in this example, I just skipped
&1entirely. I do not think this is great at all for intuitive and readable code. It's confusing and not as elegant as shorthands should be. (Just an opinion, feel free to tell me how wrong I am.)
So I guess I won't consider this as an option.
A functional shorthand would make the pico8 experience even better.
I am not sure if this has been requested before, but it might shape how we code in pico8 by a lot.
Feel free to comment below on your favorite shorthand. I am sure there are even better syntaxes than the ones I have listed above.
Self Criticism: Such a shorthand might turn out to be disruptive to the Lua syntax. For now, most shorts in pico8 are alternative functions(the
time). These are pretty harmless because one can always assign something else to the variable. However, a function short is different and might not interact well with the rest of the Lua syntax.
(Self Rebuttal?: tbh, Lua function definitions are already very different in syntax than other structures... For the loops(except for repeat) one needs to append a "do" keyword to begin a block(of code). For
if there's at least
then. But for
function, there is nothing. Hmmm...)
PICO-8 has quite a few shorts that are more sophisticated syntactic replacements. I think simple versions of this idea, especially if syntactically limited to a single line like most PICO-8 preprocessor transforms, could replace to
function(...) ... end easily enough.
Could people explain what these shorthands bring?
Lua already gives us inline anonymous functions, which are convenient to pass to another function call like
foreach or custom sort functions. We can also define functions directly in tables. We don’t have a problem with
this and that is one of the motivations for arrow functions. So what would this add? Saving a few characters?
I do use function shorthand/lambdas pretty frequently in other languages but I'm not sure it necessarily adds anything for pico-8/Lua.
Although a shorthand will save you some characters it's still just building a function underneath so it's not likely to actually save you any tokens and I feel like tokens are generally more precious than characters. That said, if you're using them a lot then the savings in characters might be substantial.
I do think a good shorthand could make code more readable, especially in the built-in editor where line length is severely limited. The shorter the definition the better chance the whole thing can fit onscreen at once. On the flip-side, overuse of lambdas can make code harder to follow but that's true whether the definition is short or not. And you can get the same readability benefits by defining a named function and passing it as a parameter rather than defining it inline. But, again, at the cost of characters and tokens.
If it were to be adopted I would probably go with some variation of the elixir example you gave (
fn(p1)-> expression end) because this is basically already Lua syntax and seems like it would be a fairly easy thing to add. Essentially
fn just needs to be translated to
-> (or whatever other symbol you prefer) translates to
return. Then the whole thing becomes
function(p1) return expression end under the hood.
I don't think this would be a game changer or anything; more of a convenience than a whole new feature. But hey, convenient things are convenient so maybe worthwhile?
True, I don't think a shorthand would be able to save any tokens. I would still like something like this to happen though. I guess I'm just the kind of person who abuses lambda expressions whenever I get the chance to do so; so personally, this will be pretty game-changing for me. I guess the impact of such a shorthand mainly relies on the community - their coding style and their subjective preferences. I guess I am changing the post name to a convenience request rather than a feature request.
I agree with @freds72.
Wow. That was unexpected. Somebody shoot me. :) But yeah, clarity has always been important to me in coding, especially when you don't need to compress code. Like for instance I don't even use
a+=3 in my normal coding any more and always write it out as
a=a+3 for ease of viewing.
On the other end of the stick though this suggested method might open up new TWEET CART methods. Just - don't lose sight of what we already have in current readability.
[Please log in to post a comment]