Existential Operator

[SteveD]

Generally, I've been a happy bunny working with Moonscript - all the usual Lua ecosystem is available, so I haven't had to learn new libraries.

One feature that Leaf discussed was the 'existential operator': e.g. a?.b?.c evaluating as nil if the fields b or c don't exist.  This would be a very useful addition - it was recently discussed (with a patch) on lua-l.

BTW, a suggestion was made that it really should be called a 'safe navigation operator'...

Moonscript is where proposed Lua features go to get implemented ;)

[leaf corcoran]

Yeah I plan on doing this fairly soon. Haven't had time to add many things lately because I've been working on a separate moonscript project and website.

The only thing I am unsure about is implementation. The easiest thing to do would be to chain ands:

x = a?.b -- x = a and a.b

x = a?.b?.c -- x = a and a.b and a.b.c

The only problem is that as the chain gets longer you keep re-fetching things up in the same tables. It's bad for performance and also a table look up can have a side effect.

The alternative approach would be to expand it out into a series of statements, and cache the result of each lookup:

x = a?.b

local _current = a

if _current then

  x = _current.b

end

x = a?.b?.c?.d

local _current = a

if _current then

  _current = _current.b

  if _current then

    _current = _current.c

    if _current then

      x = d

    end

  end

end

The disadvantage of this is that because the original operator is most likely to be used in an expression form, I'll have to convert the statements to an expression using a anonymous function. This is also a pretty significant performance hit.

--
You received this message because you are subscribed to the Google Groups "MoonScript Users" group.
To post to this group, send email to moonscri...@googlegroups.com.
Visit this group at http://groups.google.com/group/moonscript-users?hl=en.
 
 

[Elias Barrionovo]

On Wed, Mar 20, 2013 at 1:30 PM, leaf corcoran <lea...@gmail.com> wrote:
> The alternative approach would be to expand it out into a series of
> statements, and cache the result of each lookup:

> x = a?.b?.c?.d
>
> local _current = a
> if _current then
> _current = _current.b
> if _current then
> _current = _current.c
> if _current then
> x = d
> end
> end
> end
>
> The disadvantage of this is that because the original operator is most
> likely to be used in an expression form, I'll have to convert the statements
> to an expression using a anonymous function. This is also a pretty
> significant performance hit.

Why not use `_current` where the original expression is used?

```moonscript
do_stuff a?.b?.c
```

would compile to

```lua
local _current0 = a
if _current0 then
_current0 = _current0.b
if _current0 then
_current0 = _current0.c
end
end

do_stuff(_current0)
```

--
NI!

[leaf corcoran]

That's another approach, but pretty complicated.

If there are multiple arguments the order they are evaluated matters.

do_stuff print("hello"), has_side_effect!, a?.b?.c

Essentially if I wanted to extract the last argument for the previous line, I would have to extract all the arguments and run them in the correct order. Things become even more complicated when you nest function calls, and include things like table literals.

But I've been considering writing a general system to do this because it would significantly reduce the amount of anonymous functions I would create when coercing a statement into an expression.

[Nils Nordman]

Hi!

On Wed, Mar 20, 2013 at 9:56 AM, SteveD <steve.j...@gmail.com> wrote:
>
> Moonscript is where proposed Lua features go to get implemented ;)

Which can be nice, but provided it's done with constraint so that
Moonscript don't end up being a mixed bag of various convenience
expansions. Please note that I don't necessarily suggest that this is
the case for the safe navigation operator (which I'm personally
cautiously positive about), nor am I suggesting that Steve or Leaf
thinks the opposite :)

It just seems at times that some of the feature suggestions I see are
based more on the sheer convenience of cutting away some repetitive
patterns than useful, easily understandable language features. The
nice thing about Lua to begin with, for me, is that it's small and
clean and easily understandable. Moonscript adds a much nicer syntax
on top of it, which again is great for me since I enjoy typing less
and having a more succinct syntax, and since I easily can map the
constructs over to Lua mentally it's not a big cognitive obstruction
either*. The more features that are added, the bigger the cognitive
load will be however, hence my worry. I guess I just like it fine more
or less the way it is, and don't want it to end up with to many
features :)

Cheers,

* Except for the class stuff of course, that I have to look up when I
need to do funky stuff with it :)
--
Nils Nordman <ni...@nordman.org>