minh thu ha scritto:

[...] I suggest you try an alternative strategy. That altenrative strategy is twofold, just like you have quiz' and quiz'. This alternate strategy avoid pattern matching on strings (which would be cumbersome for a bit more complex syntax).

But for this specific case it is very compact and elegant (IMHO).

[...] Now, given those two functions, try to apply them on your input string, feeding the next function application with the resulting string of the current application.

So, I should not split the string into lines? An useful feature of my program is that it parses both an input like: 1: 1046323,2005-12-19 and 1: 1046323 If I write a parser from scratch I need to implement two separate functions. I will give it a try, just to check if it has better performances. Thanks Manlio

2009/3/11 minh thu :

2009/3/11 Manlio Perillo :

...

minh thu ha scritto:

...

[...] I suggest you try an alternative strategy. That altenrative strategy is twofold, just like you have quiz' and quiz'. This alternate strategy avoid pattern matching on strings (which would be cumbersome for a bit more complex syntax).

But for this specific case it is very compact and elegant (IMHO).

I would say it is difficult to see what you're doing in the code without the desciption you gave in the mail. But you're right, it's not the string pattern matching which is the problem.

It is more the pair (Int, rest of the bytestring which can begin or not with ':')...

Why not have quiz' accepting just the bytestring (and not the id value), and returning the (Int,[Int]) ?

...

...

[...] Now, given those two functions, try to apply them on your input string, feeding the next function application with the resulting string of the current application.

So, I should not split the string into lines?

See below.

...

An useful feature of my program is that it parses both an input like:

1: 1046323,2005-12-19

and 1: 1046323

If I write a parser from scratch I need to implement two separate functions.

I didn't think to that but nothing prevent you to write the second function I suggested to account for that case, or for an end of line (if can 'eat' the ':' from the input, you can also eat a newline).

Thu

Ok, The approach I suggested is a bit overkill. You can indeed use L.lines to split the input into lines then work on that. But still, avoid the pair (Int, Bytestring). Instead, you can basically map on each line the unsafeReadInt modified to : - return the id - return if it is one kind of id or the other kind. so : type UserId = Int type MovieId = Int unsafeReadInt :: Line -> Either MovieId UserId Now you have a nice list [Either MovieId UserId] that you need to transform into (MovieId, [UserId]). Sorry, for the previous response. Thu

Manlio Perillo ha scritto:

minh thu ha scritto:

...

[...] The approach I suggested is a bit overkill. You can indeed use L.lines to split the input into lines then work on that.

But still, avoid the pair (Int, Bytestring). Instead, you can basically map on each line the unsafeReadInt modified to : - return the id - return if it is one kind of id or the other kind.

so : type UserId = Int type MovieId = Int unsafeReadInt :: Line -> Either MovieId UserId

Now you have a nice list [Either MovieId UserId] that you need to transform into (MovieId, [UserId]).

Thanks, this seems a much better solution.

Done: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2309 real 1m15.220s user 0m4.816s sys 0m0.308s 3084 KB memory usage Previous version required 4956 KB of memory. Thanks again for the suggestion, Minh. Manlio