2016-01-25 16:17 GMT+03:00 Bram Moolenaar <[email protected]>: > > Lcd wrote: > >> On 25 January 2016, Nikolay Aleksandrovich Pavlov <[email protected]> wrote: >> > 2016-01-25 0:26 GMT+03:00 LCD 47 <[email protected]>: >> > >> > > On 24 January 2016, Bram Moolenaar <[email protected]> wrote: >> [...] >> > > > This is unexpected, but the same happens for other items with a >> > > > similar value but different type: >> > > > :echo 1.0 == 1 >> > > > 1 >> > > > :echo [1.0] == [1] >> > > > 0 >> > > > >> > > > Perhaps we should change that as well? It is related to, for >> > > > example, index(): >> > > > echo index([0, v:false], v:false) >> > > > echo index([1.0, 1], 1) >> > > > >> > > > Should these return 0 or 1? >> > > >> > > Both are fine as they are, I don't think either can be changed >> > > in a meaningful way. The difference comes from the fact that >> > > v:true, 1.0, and 1 have different values when converted to strings. >> > > No problem here. >> > > >> > > But you asked why would one want to normalize the values >> > > v:false, v:true, and v:null returned by jsondecode() to plain 0, 1, >> > > and '', and this is why: not doing it means they must be handled >> > > separately from the "normal" values. This isn't something that can >> > > (or should) be fixed by changing the semantics of dictionaries, IMO. >> > > Changing semanticvs would lead to even worse problems. >> > >> > Can you show real example where you do have problems with handling >> > these values separately? I usually use JSON for configuration or >> > for some simple data bases and for this purposes working :if and >> > type() are enough most of time. >> [...] >> >> First example: syntastic. Syntastic is a plugin that runs various >> linters against a file, parses their output, and puts it in a quickfix >> list. Some of these linters produce more precise reports when told to >> output JSON, and syntastic uses this function to parse said reports: >> >> https://goo.gl/ca8Tzb > > You could still do a string substitute over the JSON before giving it to > jsondecode(), to change 'true' to 1, 'false' to 0, etc. > >> The result is a list of error items, intermingled with statistics, >> pointers to docs, and the like. Syntastic filters the useful parts out >> of it, sorts the items, and reformats it for setloclist(). If I were to >> switch from the function above to jsondecode(), I'd have to either redo >> sorting to accomodate for v:true and v:false, or normalize the list to >> use 0 and 1 instead. >> >> Second example: parsing logs from a meteo station and producing >> reports. I have a small meteo station that produces a list of hardware >> events. Again the more useful format for the logs is JSON, and again, >> I'm using a function similar to the one above to parse it. Some >> events are duplicated, and I'm picking up only the first in a series. >> Comparisons would have to be redone if I were to use jsondecode(). >> Granted, most of this (but not all) could be done in Python, but the >> point is, the v:null in jsondecode() is complicating things. >> >> In both cases I'll probably keep using the scrub and eval() function >> to parse JSON. It's fast, it does proper error validation, and the >> output is easy to work with. If I'd need to save and restore states >> to disk as JSON, I'd probably also do it with a Python function over >> jsonencode() and jsondecode(). > > I suppose what would be useful here is a variant of map() that, when an > item is a list or dict, goes into that item, instead of evaluating the > expression. perhaps treemap()? That would find each leaf and evaluate > the expression, replacing the existing item. Since we already have > map() that would not be so difficult to implement.
In one of my plugins I named similar function “…recdictmap” (it is for traversing dictionaries only). I would suggest using `recmap()`. One can also implement this on top of map() using the same hack I used in previous message. > > -- > Portable Computer: A device invented to force businessmen > to work at home, on vacation, and on business trips. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
