persistent byLine

Jonathan M Davis jmdavisProg at gmx.com
Mon Jul 22 16:28:30 PDT 2013


On Monday, July 22, 2013 13:08:05 Nick Treleaven wrote:
> Hi,
> I remember an example in some slides by Walter which had this snippet
> (slightly simplified):
> 
> stdin.byLine.map!(l => l.idup).array
> 
> Someone commented in a reddit post that the idup part was not intuitive
> (can't find the link now, sorry).
> 
> I made a pull request to re-enable using byLine!(char, immutable char).
> (Note this compiled in the current release, but didn't work properly
> AFAICT. It did work by commit 97cec33^).
> 
> https://github.com/D-Programming-Language/phobos/pull/1418
> 
> Using that allows us to drop the map!(l => l.idup) part from the above
> snippet. The new syntax isn't much better, but it can also be more
> efficient (as it caches front). I have an idea how to improve the
> syntax, but I'll omit it for this post.

I agree with monarch in that we really shouldn't try and mess with byLine like 
this. It would just be cleaner to come up with a new function for this, though 
I confess that part of me thinks that it's better to just use map!(a => 
a.idup)(), because it avoids duplicating functionality. It is arguably a bit 
ugly though.

> I've since thought that if most or all lines in a file need to be
> persistent, it may be more efficient to use
> readText(filename).splitLines, because that doesn't need to allocate for
> each line.
> 
> There are two enhancements for that approach:
> 1. readText should accept a File, not just a filename, so we can use stdin.

I'm opposed to this. I don't think that std.file should be using std.stdio.File 
at all. What we really need is for std.io to be finished, which will revamp 
std.stdio and give us streams and the like. And std.file really is not designed 
around using stdin - and shouldn't be IMHO. It's for operating on actual files.

> 2. splitLines makes an array. It would be more flexible to have an input
> range created from a function e.g. lineSplitter.

splitter will do the job just fine as long as you don't care about /r/n - 
though we should arguably come up with a solution that works with /r/n 
(assuming that something in std.range or std.algorithm doesn't already do it, 
and I'm just not thinking of it at the moment).

- Jonathan M Davis


More information about the Digitalmars-d mailing list