Options parameters as record types

[michaelhkay]

Options parameters as record types

[dnovatchev]

I strongly support this suggestion.

So far providing options in a map seemed completely confusing to me - how would the customer know what keys / entries any such map might have (added or removed) and how to maintain consistency between different implementations...

Having such options represented as a record answers at least 50% of these concerns.

Thank you!

[michaelhkay]

Now that we've introduced constructor functions for record types, the names of the record types (and perhaps the order of fields) becomes rather more important. For example, people would be able to write

serialize($input, opt:serialization-params(method:="xml"))

in preference to writing

serialize($input, map{"method":"xml"})

But since the record type names are global, this doesn't feel much like an improvement.

So we need to think about this in conjunction with issue #162. We get a real usability improvement if we allow:

serialize($input, method:="xml")

But of course that's not easy or we would have done it by now: the main obstacle is that we use the number of supplied arguments as part of the algorithm for deciding which function is being called.

One option would be to use a syntactic marker for these "pseudo-arguments":

serialize($input, %method:="xml")

[ChristianGruen]

One option would be to use a syntactic marker for these "pseudo-arguments":

serialize($input, %method:="xml")

As % ressembles the annotation syntax, we could simulate the map syntax:

(: old :)
serialize($input, map{"method":"xml"})
local:whatever($data, map { '': 'empty', 'hi there': 'phrase' })

(: new :)
serialize($input, 'method':'xml')
local:whatever($data, '': 'empty', 'hi there': 'phrase')

Another challenge could be how to treat (used-defined, or possible future built-in) functions with multiple option parameters.

[Arithmeticus]

Since we're daydreaming about an easier syntax, what about serialize($input, (.method = "xml", .indent = true())). Takes advantage of familiar dot notation for properties, which is exactly what the user is fiddling with. I left off the colon in hopes that the walrus sign could be swapped for simple equality.

[michaelhkay]

serialize($input, (.method = "xml", .indent = true()))

I like it, and I think the grammar works. But it's very confusing for users to know when to use =, when to use :=, and when to use :.

I wonder if we could make this a proper expression usable in contexts other than function calls? That is,

(.method = "xml", .indent = true())

can be used anywhere you could write

map{"method": "xml", "indent":true()}

[ChristianGruen]

serialize($input, (.method = "xml", .indent = true()))

While I’m not particularly fond of the walrus syntax, it feels confusing to me to use =, which is used for comparisons. We already use : for map options and we use := for assignments, so I would prefer to stick with one of those variants.

[Arithmeticus]

walrus makes sense for binding -- sorry to detract from the main thing, which was suggesting dot syntax.

I wonder if initial-dot syntax could be leveraged other places to populate, query, and filter maps, records, or arrays.

[ChristianGruen]

walrus makes sense for binding -- sorry to detract from the main thing, which was suggesting dot syntax.

I like the dot syntax, too… preferrably without additional parentheses.

Instead of introducing more potentially idiosyncratic syntactical sugar, a bolder step could be (if it’s not too late) to question the map keyword: Now that JSON is all around, and now that maps can also be “records”, wouldn’t it be nice if you could simply do this?

serialize($input, { "method": "html" })

let $input := <html/>
let $options := { "method": "html" }
return serialize($input, $options)

[michaelhkay]

Yes, my thinking too. We reserved the bare-brace syntax for use with scripting extensions, but I can't see us wanting to go in that direction, and using it for maps makes sense now, I think.