$sequence-of-maps ? info()

[michaelhkay]

$sequence-of-maps ? info()

[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.