`column.Substring(1, column.Length - 2)` could use the new-ish range indexing syntax.
column[1..^1]World's Smallest CSV Parser (C#)
21–30 of 72 posts
Re: World's Smallest CSV Parser (C#)
#22What's the utility of defining the "Error" exception. Why not use an existing one, say InvalidOperationException, or a plain Exception. Is making your own better practice?
> Why not use ... a plain Exception. It is forbidden. https://learn.microsoft.com/en-us/dotnet/standard/exceptions... > Exception ... None (use a derived class of this exception). https://learn.microsoft.com/en-us/dotnet/standard/design-gui... > DO NOT throw System.Exception or System.SystemException.
It’s a guideline not to. It’s not a hard rule or forbidden.
Re: World's Smallest CSV Parser (C#)
#23To the author: please consider using an actual license.
I infer from the tone of your license that you intended it to give away the code to any "human" who wants to "use" it.
What if I modify it? Is modification "use"? (No.)
What if a shell script calls it? Is that a "human" using it, or a "computer"? Is linking "use"?
The result is probably a license which is non-free, which doesn't appear to be your intention.
Re: World's Smallest CSV Parser (C#)
#24Don't just parse - convert. In a pipeline to split-parseable data, if you like, such as the possibly smaller, faster, and more general: https://github.com/c-blake/nio/blob/main/utils/c2tsv.nim (And, ideally, convert all the way to a mmap & go binary format like nio so you don't have to re-parse.)
Fun! Convert to js: csv.split('\n").join('".split(\',\'));a.push("'); So that each line becomes: a.push("foo,bar,baz".split(',')); And then we have an array of arrays.
Is also expressible (and is vectorized) in C#. But that's author's code, not mine :)
Re: World's Smallest CSV Parser (C#)
#25To the author: please consider using an actual license. I infer from the tone of your license that you intended it to give away the code to any "human" who wants to "use" it. What if I modify it? Is modification "use"? (No.) What if a shell script calls it? Is that a "human" using it, or a "computer"? Is linking "use"? The result is probably a license which is non-free, which doesn't appear to be your intention.
Maybe part of the license is proving you are (human) by interpreting it reasonably.
Or maybe it’s a trap. Who can say?
Re: World's Smallest CSV Parser (C#)
#26The code seems fairly nice on first glance, but the world's smallest?
Re: World's Smallest CSV Parser (C#)
#27Earlier quoted context omitted.
Iterating over the `char`s does not support the full range of what can be stored in a C# string (for instance, UTF-8 graphemes that are serialized as surrogate pairs are usually two `char`s in a C# string. .Net provides a TextElementEnumerator that will iterate over graphemes instead: https://learn.microsoft.com/en-us/dotnet/api/system.globaliz... There's a fairly comprehensive guide to working with .net character en…
The return value of StreamReader.Read() will always be within bounds of -1 and char.MaxValue. All surrogate pairs will be drained into the StringBuilder, working correctly. Most implementations usually agree that torn UTF-16 surrogate pairs (which are strictly the code points outside of basic multilingual plane) may exist in the input and will be passed as is, which is different to what UTF-8 implementations choose (…
If you (a consuming dev) want the world's smallest (in your code) - use the .net built in parser[0]. Bonus, it's RFC4180 compliant.
If you (competing/learning) want to write the world's smallest (code golf style)... this isn't it, and has some weird superfluous lines (if that's your measure - per the original question).
If you (learning) want to write an efficient parser.. this isn't it. You don't need a StringBuilder, you can seek the Stream to collect the (already formed) strings directly from source vs char-by-char memory copy and rebuild. Yes; that limits your stream choices, but since the example/tests only use FileStreams (which are seekable) you might not come across other kinds. If you need to use un-seekable streams, then you'll need to use a large enough buffer.
[0]: https://learn.microsoft.com/en-us/dotnet/api/microsoft.visua...
Re: World's Smallest CSV Parser (C#)
#28Earlier quoted context omitted.
The return value of StreamReader.Read() will always be within bounds of -1 and char.MaxValue. All surrogate pairs will be drained into the StringBuilder, working correctly. Most implementations usually agree that torn UTF-16 surrogate pairs (which are strictly the code points outside of basic multilingual plane) may exist in the input and will be passed as is, which is different to what UTF-8 implementations choose (…
If you (a consuming dev) want the world's smallest (in your code) - use the .net built in parser[0]. Bonus, it's RFC4180 compliant. If you (competing/learning) want to write the world's smallest (code golf style)... this isn't it, and has some weird superfluous lines (if that's your measure - per the original question). If you (learning) want to write an efficient parser.. this isn't it. You don't need a StringBuilde…
This is not a correct link (it refers to VB.NET). There are better parsers out there (Sep).
I'm not sure what is your point but it certainly misses the idea behind this HN submission and makes me sad as it would be nice to see words of encouragement in .NET submissions here instead.
Re: World's Smallest CSV Parser (C#)
#29Earlier quoted context omitted.
Fun! Convert to js: csv.split('\n").join('".split(\',\'));a.push("'); So that each line becomes: a.push("foo,bar,baz".split(',')); And then we have an array of arrays.
Is also expressible (and is vectorized) in C#. But that's author's code, not mine :)
That's right - pure splitting is much more SIMD-friendly than..the whole syntax melange. This is another charm to the "partitioned" design. The conversion to split-parseable TSV can run on its own CPU core and the SIMD splitting on its own core. As long as pipe bandwidth suffices, you have very easy parallelism. This kind of design/intent was popular on Unix at the dawn of multiprocessing when there were still Giant Kernel Locks. But it still has merits, even on Windows.
If you have a lot of data (and space for it, e.g. in /dev/shm) you can also save all the converted data to a TSV file. That's now soundly "partitionable" at the "nearest ASCII newline to 1/N bytes" and you can then go core-parallel as well as SIMD within cores (but that N-wise pass with memory mapping or mem.views). Admittedly this is probably more helpful when you are doing more computation than just splits, like ASCII-to-binary conversion of fields or such.
Plus, someone might have actually exported from Excel (or whatever) into some sound TSV instead of weird quote-escaped-CSV that some think is standardized by rfc 4180 (which itself disavows being a "standard"). In that case, at least, you needn't convert at all.
So, I see at least 3 reasons to layer this part of a system as a convert-then-split: pipeline parallelism, file parallelism, and entire pass elision.
Re: World's Smallest CSV Parser (C#)
#30Don't just parse - convert. In a pipeline to split-parseable data, if you like, such as the possibly smaller, faster, and more general: https://github.com/c-blake/nio/blob/main/utils/c2tsv.nim (And, ideally, convert all the way to a mmap & go binary format like nio so you don't have to re-parse.)
Fun! Convert to js: csv.split('\n").join('".split(\',\'));a.push("'); So that each line becomes: a.push("foo,bar,baz".split(',')); And then we have an array of arrays.
Of course the “hard part” of CSV parsing is dealing with escapes, which break simple splits.
But now I’m wondering if a good approach might be to split on the escape character and then reassemble / parse from there, safe in the knowledge that every character has exactly one interpretation.