2011/6/6 Bryan O'Sullivan b...@serpentine.com:
On Sun, Jun 5, 2011 at 11:00 AM, Yitzchak Gale g...@sefer.org wrote:
If behind the scenes the concat is copying directly from slices of the
original
input, then no, in principle we're not saving much then.
I thought there were *two* copies going
Bryan O'Sullivan wrote:
Now that I think of it: in principle, you could
write a specialised concat that would check the pointer/offset/length
combinations of its arguments and, if they all abutted perfectly, would just
return a new view into that same array, sans copying.
Gregory Collins
On Tue, Jun 7, 2011 at 1:40 AM, Simon Meier iridc...@gmail.com wrote:
Why would you need 'unsafePerformIO'. You can scrutinise the 'PS'
constructors of the slice without dropping down to IO.
True. Oops :-)
Using a Builder for concatentation makes sense, if you want to exploit
that copying
2011/6/7 Bryan O'Sullivan b...@serpentine.com:
On Tue, Jun 7, 2011 at 1:40 AM, Simon Meier iridc...@gmail.com wrote:
Why would you need 'unsafePerformIO'. You can scrutinise the 'PS'
constructors of the slice without dropping down to IO.
True. Oops :-)
Using a Builder for concatentation
On Sun, Jun 5, 2011 at 11:00 AM, Yitzchak Gale g...@sefer.org wrote:
If behind the scenes the concat is copying directly from slices of the
original
input, then no, in principle we're not saving much then.
I thought there were *two* copies going on.
If you're using the specialised functions
I wrote:
I was thinking of even lower level: allocating a moderate chunk of
memory and writing the results directly into it consecutively as a
special case.
Bryan O'Sullivan wrote:
Surely that would save only one copy compared to creating a list of results
and then concatenating them, no?
Bryan O'Sullivan wrote:
I'd like a no-copy combinator for the same reasons, but I think it's
impossible to do without some low-level support.
I wrote:
...does the internal representation easily admit such a combinator?
Not very easily. Internally, attoparsec maintains just three pieces of
Mario Blažević wrote:
I don't know if this helps, but the incremental-parser library has
exactly the combinator you're looking for.
Wow, that is a beautiful implementation of a general parser
library. So much simpler than Parsec. Thanks for pointing it out.
Why are you hiding those nice
On 11-06-03 06:00 AM, Yitzchak Gale wrote:
Mario Blažević wrote:
I don't know if this helps, but the incremental-parser library has
exactly the combinator you're looking for.
Wow, that is a beautiful implementation of a general parser
library. So much simpler than Parsec. Thanks for
On Fri, Jun 3, 2011 at 11:52 AM, Yitzchak Gale g...@sefer.org wrote:
Bryan O'Sullivan wrote:
I'd like a no-copy combinator for the same reasons, but I think it's
impossible to do without some low-level support.
I wrote:
...does the internal representation easily admit such a combinator?
On Fri, Jun 3, 2011 at 2:52 AM, Yitzchak Gale g...@sefer.org wrote:
I was thinking of even lower level: allocating a moderate chunk of
memory and writing the results directly into it consecutively as a
special case.
Surely that would save only one copy compared to creating a list of results
I often find while using attoparsec and attoparsec-text that I need to
match a number of text parsers consecutively and concatenate the
result. By text parser I mean Parser ByteString for attoparsec and
Parser Text for attoparsec-text.
It seems the best I can do is to collect them all in a list
On Thu, Jun 2, 2011 at 7:02 AM, Yitzchak Gale g...@sefer.org wrote:
It seems the best I can do is to collect them all in a list and then
apply concat. But that still copies the text several times.
Right. I'd like a no-copy combinator for the same reasons, but I think it's
impossible to do
On Thu, Jun 2, 2011 at 10:02 AM, Yitzchak Gale g...@sefer.org wrote:
I often find while using attoparsec and attoparsec-text that I need to
match a number of text parsers consecutively and concatenate the
result. By text parser I mean Parser ByteString for attoparsec and
Parser Text for
14 matches
Mail list logo
