dot operator as function doesn't seem to work

[suimong]

let a = {foo=1} in
(.) "foo" a

# or
let a = {foo=1} in
(.)  a "foo"

In nickel repl, either of the above code results in "error: unexpected token" pointing at the ".". Since in the documentation "." is described as an operator, and "all infix operators can be turned into functsion by putting them inside parentheses", I wonder if this is a bug or does "." gets special treatment?

[yannham]

I don't think this is on purpose. . is a treated differently from, say, + (because it has special precedence in the grammar, for example the head of an application can be foo.bar.baz as in std.array.map f array, which isn't the case of any other operator), but so is &, for example, and the latter is correctly curried, even if it requires a special rule to do so.

So, at first sight, I would say it's an overlook because . isn't part of the general grammar rule InfixOp, and I don't see a good reason why it couldn't be curried as well.

[suimong]

Thanks for explaining! While I'm a total newbie to Rust and haven't write any parser before, I'm tinkering with the grammar file and come up with something that compiles (here), alas the expression (.) some_record some_field is always looking for the field "x2" in the record.

I'm still trying to find a way to match the term and pass the term to StaticAccess (similar to the definition at RecordOperationChain) without ambiguity. As far as I can tell, the ambiguity might stem from that any hand written pattern (e.g. <t: AsTerm<Atom>> "." <id: Ident>) will also match RecordOperationChain. Could you may be give some extra hint?

[jneem]

I think one issue is that we encode StaticAccess as a unary op with a fixed field name, not as a binary op. That is, x.foo gets encoded as the unary op (.foo) applied to x. Probably the easiest solution would be to interpret (.) as DynAccess instead.

[suimong]

Thanks! I opened a PR for your perusal.