Reece H. Dunn

@michaelhkay I'm happy to keep this constrained, such that your `$actual-predicate` example would not be able to use named parameters without the dynamic proposal from @ChristianGruen. -- This goes along...

I'm happy to treat 1-3 and 4 as two separate proposals.

My XQuery plugin has support for an older keyword syntax. It does not currently handle placeholders well (with or without keywords). -- I'm doing this for things like providing inlay...

For the bound variables, I'm constructing them as follows: 1. variable name -- the parameter's variable name; 2. variable type -- the parameter's variable type; 3. variable expression -- the...

It looks like it should be straightforward to implement that logic as opposed to fully dynamic parameter resolution. That is, given a partial function application, any argument placeholders assigned via...

Regarding function types, I've always wondered why you cannot assign parameter names e.g. to document the parameters. With that, the parameter names could come from the earliest/nearest/closest function signature. I.e.:...

Why do the parameter names need to be considered for instance matching, subtyping, and function coercion? -- I would advocate that they don't affect those. Thus, they are a purely...

Yes, that's in line with what I'm thinking. There are two aspects to this: 1. a static context only feature that does not affect the runtime; 2. a dynamic context...

I would like the named parameters in function types to work as keywords. -- I suggested that to help with the static analysis of names for the case when implementing...

I made parse-html support binary as the HTML spec has rules for detecting the encoding and decoding a binary data stream. It therefore makes sense to support that in the...