Stephan Renatus f8286be64e ast, topdown: add 'in' operator via internal builtins and future imports ...

There are four variants to this: with or without 'some', and with
only one or two lhs arguments:

 a) x in xs
 b) k, v in xs
 c) some x in xs
 d) some k, v in xs

(a) and (b) are handled in the parser, and end up in the AST as
calls to `internal.member_2` and `internal.member_3`:

 a) internal.member_2(x, xs)
 b) internal.member_4(k, v, xs)

The backing builtin functions iterate over their last arguments,
trying to find a match. If they do, they will return `true`.
In all other cases -- no match, or a type in the last argument that
can't be iterated over (not an array, object or set), it will
return `false`.

As such, they can be used with `not` without any restrictions.

(c) and (d) are rewritten in the compiler, where x', v', and k' are
fresh local vars:

 c) x' = xs[_]
 d) v' = xs[k']

Since `in` is a new keyword, it's enabled gradually: for now, a new
mechanism of future keyword imports is added. There are new option
arguments in the parser methods, and there's a hook in the parser
code updating its set of enabled future keywords whenever it
encounters an import statement like

    import future.keywords.in # enables only "in"
    import future.keywords    # enables all future keywords

Functionally, these are identical right now: there is only one
future keyword, "in".

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>

2021-10-14 19:21:52 +02:00

..

filter_imports.go

ast, topdown: add 'in' operator via internal builtins and future imports

2021-10-14 19:21:52 +02:00

parser_opts.go

ast, topdown: add 'in' operator via internal builtins and future imports

2021-10-14 19:21:52 +02:00