|
Post by grimblefritz on Nov 19, 2020 17:47:17 GMT -5
Sometimes "CSV" is more generally "grouped and delimited". For example, "quote" might actually be "%" and instead of a comma the delimiter might be "*". And sometime EOR (end of record) might not be chr$(13)/CR or chr$(10)/LF or chr$(13,10)CR/LF, but something like chr$(12)/FF or chr$(7)/BEL. These commands would allow assignment of these: csvquote "%" csvdelim chr$(9) csveor chr$(12) Applied, of course, to my proposed parsecsv / parseto$ additions
|
|
|
Post by Brandon Parker on Nov 21, 2020 12:12:13 GMT -5
I personally have never seen or heard anyone call a Comma Separated Values file "grouped and delimited" in order to delimit values by anything other than a comma.
{:0)
Brandon Parker
|
|
|
Post by Carl Gundel on Nov 21, 2020 12:29:28 GMT -5
My philosophy is to keep Liberty BASIC as small as I can. I'm not against enhancing INPUTCSV to make it more powerful but whatever changes I make should be maximum bang for the buck sort of things. If you need a function or subroutine to do something more you can always write your own.
|
|
|
Post by grimblefritz on Nov 21, 2020 13:50:50 GMT -5
I've received data -- in what the sender purported to be "CSV" format -- where data was only (quoted fields), delimited (field separators), and chunked into records (lines)... with whatever the sender decided those delimiters should be. Sometimes quotes, often any character that wouldn't be found in the field data; sometimes commas, often a | or ~ or control character; sometimes EOR as CR or LF or CRLF or NUL, often an arbitrary string including a literal "EOR". One guy even used the rest of the line after EOR for comments! And then decided to add data IN THE COMMENTS!! This is all a common reality when dealing with those challenged to even spell PC, who are just needing to get their jobs done and will spew out whatever they think works. I found it much easier to parse their incoming wackiness than to try to retrain them from three languages and half a world away. Of course, I'd like to say it has improved over time, but that's only because the apps got better at data interchange. The people in general have not kept pace. The only thing I've not seen other than in LB is a "CSV" stream without some form of an end-of-record. That's a new one. Yes, CSV is a real thing and you can argue that only the real thing need be supported; however, a more general "CSV" concept is identical except for the actual delimiters. I like flexibility, but it does breed complexity. I think a better "CSV" handler would be a good thing, but as with anything, the developer decides. Which is why there are other tools instead of just a hammer. I prefer not to reinvent rubber just because I need a bigger tire I suspect, once I'm done fixing up this LB app that I wrote in 1990-something -- and was shocked to find was still in daily use, along with an old Visual FoxPro app from the late 1990s, and an even older Dbase IV app from the early 1990s, and a much older dbMan app from the 1980s! (I mean, I never figured when I wrote them they'd still be around this long, unmaintained even) -- anyway, I suspect that I will then put LB away again. Who knows, maybe another 20+ years? Although, I have a grandson who might want to learn to code. It's a good primer for that.
|
|