15:20 <discocaml_> <regularspatula> Does anyone know the rationale behind not including the name in the element end tags in the xmlm library (pull based XML library)? Perhaps for increased performance?

15:22 <discocaml_> <regularspatula> for comparison, I was doing a bit of a look at some other pull based XML parsers in other languages and they all seem to include the name in the element end signals

15:30 <discocaml_> <limp.biskit> why does Uri.query give a (string * string list) list

15:30 <discocaml_> <limp.biskit> the inner list always seems to contain one element even with duplicate keys

15:34 <discocaml_> <limp.biskit> is there some parsing on the value itself i’m unaware of?

15:37 <discocaml_> <deepspacejohn> I can only guess the specific rationale that the xmlm authors had, but including the name in the end tag is arguably just extra information with no real benefit. If you wanted to validate that they match start tags, then you have to do that at runtime.

15:38 <discocaml_> <regularspatula> Yeah that is what I always assumed as well. But looking at some other pull-based parsers got me wondering if my assumptions were reasonable

17:11 <discocaml_> <leviroth> It will split on commas I believe

20:51 <discocaml_> <kakadu18> I'm looking at qcheck library, and I want to generate identifiers, which are not keywords. I was expecting `QCheck.Gen.filter` or similar function, but it is not there. I was going to fix this using bind, but I can't find obvious empty generator either. Any advice?

21:11 <companion_cube> There's assuming and the likes, but ideally you'd avoid filtering out bad values, it carries a risk of non termination

21:11 <companion_cube> (what if invalid values are a lot more likely than valid values?)

21:59 <discocaml_> <kakadu18> Yes, in the ideal situation I need to make prefix tree of my keyword, and modify generation of the next character in the identifier to avoid generation of a keyword. But what about quick and dirty solution?

22:00 <companion_cube> Ah if it's sparse, ok I guess

22:00 <companion_cube> Just use assume to filter out the test case

22:03 <discocaml_> <kakadu18> But 'assume' leads to slow generate&filter approach. Any better solution?

22:04 <discocaml_> <sim642> What are you actually trying to quickcheck though? Maybe you can just generate names of some specific form that definitely isn't a keyword

22:08 <discocaml_> <kakadu18> That parsing after pretty-printing is identity. Yes, I'm looking for short way to generate identifiers, that are not in the small predefined list of keywords.

22:12 <discocaml_> <limp.biskit> cool. is that a part of the RFC?

22:12 <discocaml_> <leviroth> As far as I could tell it is not

22:26 <discocaml_> <leviroth> I don't even think the key=value thing is really part of the rfc

22:42 <discocaml_> <limp.biskit> ah

22:42 <discocaml_> <limp.biskit> odd

22:42 <discocaml_> <limp.biskit> don’t think i’ve seen the comma separated syntax

22:42 <discocaml_> <limp.biskit> i have seen duplicate keys in the wild

22:58 <discocaml_> <anmonteiro> the actual reason is because you can duplicate keys `?foo=bar&foo=baz`

23:00 <discocaml_> <anmonteiro> `key=value` is mentioned in section 3.4 of the RFC https://datatracker.ietf.org/doc/html/rfc3986#section-3.4

23:39 <discocaml_> <leviroth> But the library *doesn't* use the inner list to represent repeated keys.

23:42 <discocaml_> <anmonteiro> yeah you're right, that's weird