Re: 'in' keyword today (was Re: mathlib)

[steve donovan <steve.j.donovan@...>]

<meta> Moonscript is useful sister-language[1] to consider when
evaluating new features.  A lot of Moonscript's features come from the
endless supply of language proposals which are such an entertaining
part of this list's traffic. Nice thing about having an actual
implementation of these features is that they can be tried out in
actual small programs, as opposed to imaginary snippets.  For
instance, if you wondered what Lua would be like with implicit local,
then consider the strategies used in Moonscript programs.

In particular, it has "import x,y,z from t" (Leaf is not worried about
new keywords) as equivalent to proposed "local x,y,z in t".

This one also feels relevant - what happens when a table literal
appears on the LHS?

http://moonscript.org/reference/#destructuring_assignment

thing = {1,2}
{a,b} = thing

obj = {
  hello: "world"
  day: "tuesday"
  length: 20
}

{hello: hello, day: the_day} = obj

It's explicit table unpacking. [2]

You can achieve the same effect as 'import...' but with more
flexibility about possible renaming (':k" is short for "k:k" in these
literals)

{:concat, :insert} = table

(Leaf also doesn't mind having multiple ways to do a thing)

I'm not a total fan - Leaf has chosen the traditional ':' for
key-value pairs in table literals, and ends up having to use \ to mean
: in method calls.  Still feels like an ugly decision.

</meta>

[1] Compiles to straightforward Lua, but is a true compiler, not a
preprocessor (i.e generates AST from source and then generates code).
So, apart from syntax, most of what you already know about Lua and its
ecosystem applies.

[2] Contrast to implicit unpacking, like what you get on the LHS of
Python assignments.  It involves a lot of magic, and wise people avoid
it in performance-critical contexts.  It may look like
multiple-return, but it's more expensive.