$sequence-of-maps ? info()

[michaelhkay]

We're increasingly using the design pattern where maps contain entries that are function items. If $map is a map and it has an entry info that is a zero-arity function, then $map ? info() invokes the function. This looks appealingly as if it's a method application applying the method info() on the object $map, but that's not actually what's really going on underneath. What is really happening is that we evaluate ($map ? info) which yields a function item, and then we dynamically call this function.

Now what if $maps is a sequence of maps each of which has an info field? This parses as ($maps ? info)(). $maps ? info returns a sequence of function items, and a dynamic function call can't be applied to a sequence of functions items. Instead you have to write ($maps ? info)!.() which feels fairly bizarre.

Should we allow the LHS of a dynamic function call to be a sequence? On the whole, I don't tend to like operations to do implicit mapping over one of the arguments, but I feel like this might warrant an exception. The justification is that a dynamic function call is a postfix expression, and all the other postfix expressions accept a sequence on the LHS. Thoughts please.

[ChristianGruen]

Should we allow the LHS of a dynamic function call to be a sequence?

While I’m generally in favor of sequence processing, I feel this could be over the top. It would make ()()()()()()() legal, and it’s already difficult for non-HOF-people to swallow that ()() is correctly parsed – and that the pairs of parentheses have a different meaning.

[michaelhkay]

This doesn't feel to me like a very strong argument. ***** and ++++++1 and ------1 all parse and execute just fine, and no-one complains. And if we want to avoid strange-looking expressions, then forcing people to write ($maps?info)!.() is surely a worse offence.

[ChristianGruen]

This doesn't feel to me like a very strong argument. ***** and ++++++1 and ------1 all parse and execute just fine, and no-one complains. And if we want to avoid strange-looking expressions, then forcing people to write ($maps?info)!.() is surely a worse offence.

I’d like to add that the new proposal reminds me of another one that got rejected a while ago… #707 (comment)

Personally, I would certainly use the new syntax (let’s see what others say).

When I occassionally present the new features to potential future users, my impression is that 4.0 evolves more and more into an expert language, and we won’t deter this target group anyway. As far as I can judge, the most popular features of 4.0 will be the map constructor without the map keyword ;) Admittedly, a feature that makes expressions shorter.

[michaelhkay]

I'm getting more into the habit of using expressions like $json??entry::item?parent() and the fact that this fails because $json??entry::item?parent selects more than one function is a constant gotcha: it definitely needs to be fixed. At the moment I'm typically getting around it with for $e in $json??entry::item return $e?parent() which feels clumsy (but a lot more readable than the equivalent using !, namely $json??entry::item!.?parent()

It's tempting to try $json??entry::item =!> parent() but that fails hopelessly because parent isn't a function in the static context. And $json??entry::item =?> parent() fares no better; though it would work if we defined parent() to be an arity-1 function rather than arity-0.

I'm also starting to realise that such expressions lead to a requirement for deduplication if two items have the same parent. I'll park that issue for the moment until I understand it better.