Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expression for exploding "complex atomics" to maps #23

Open
ghislainfourny opened this issue Dec 18, 2020 · 4 comments
Open

Expression for exploding "complex atomics" to maps #23

ghislainfourny opened this issue Dec 18, 2020 · 4 comments

Comments

@ghislainfourny
Copy link

ghislainfourny commented Dec 18, 2020

This is a counterproposal to the extension of the ? syntax to "complex atomics" such as dates.

The idea is that

Expr 🎆

explodes an atomic (like date, etc...) returned by Expr into a map (with fields year, month, etc).

(the choice of 🎆 is arbitrary and a placeholder for any other reasonable choice of syntax)

It can also work on a sequence of atomics, returning a sequence of maps.

Then one can write

(current-date():fireworks: )?year

where the semantics of ? is completely unchanged.

Parentheses are here for clarity on precedence, but may or may not be needed depending on the relative precedence of 🎆 and ?.

This way, 🎆 could be combined and used with all other functionality applying to maps (functions, obtaining the keys, the values, etc), providing a more general functionality than only for ?-based lookup.

As raised in Slack, it would be clear to anybody seeing 🎆 and getting an error with an XQuery 3.1 query that this is something new, rather than an existing ? with modified semantics

@ChristianGruen
Copy link
Member

Hi Ghislain, a rather explosive proposal ;) So we could decide between 💥 and 🎆…

One (pretty boring) alternative would be a fn:to-map function, which binds the actual value to a value key and provide additional mappings depending on the type:

to-map(current-date())?year

@michaelhkay
Copy link
Member

michaelhkay commented Dec 18, 2020 via email

@michaelhkay
Copy link
Member

michaelhkay commented Dec 19, 2020 via email

@ChristianGruen
Copy link
Member

ChristianGruen commented Dec 19, 2020

I’m in favor of the extra function. It seems better extensible to me as, in principle, the argument of an fn:parts function could also be a sequence, records, or function items (including maps and arrays).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants