Hi Nikita,
I've been thinking about data import issues recently as well (in this case, NetCDF files:
https://github.com/ian-ross/hnetcdf is kind of nasty and unfinished, but it will get there in the end). The easy access to data files of all different kinds in R is one of its really big advantages. I've done tasks in the past where I've needed to read CSV files, NetCDF files, GeoTIFF data and ESRI shape files, all for the sam job. R handles them all seamlessly, giving you a very open data analysis platform. I'd like Haskell eventually to be a similarly open platform with as easy a workflow as R for data analysis, but it's going to take some work to get there.
As you kind of say, one thing that's tricky is deciding on what matrix libraries to use. I don't have any good ideas about that. With the NetCDF stuff, I've been experimenting with making all of the get and put functions polymorphic in a "store" type, allowing you to read and write Storable.Vectors, Repa arrays and hmatrix arrays. I'm not convinced I'm doing it right, but the alternative is to support only a single array type, which, until the community settles on a single canonical array type (if that's even possible), seems restrictive.
I guess from the perspective of what you could do with your hmatrix-labeled code, aiming for something as flexible as R's read.table (which is specialised for read.csv and variants) that supports at least a few of the common Haskell array types would be nice. However, there's a danger of duplicating some of the good work that's already been done on fast CSV parsers (cassava, csv-conduit and pipes-csv). Cassava, in particular, has a nice lightweight API that's very suitable for interactive work. If you extended the Cassava parser to support a wider range of file formats (like read.table) and added some helpers for converting to array types where it makes sense, that might be enough.
Cheers,
Ian.