Here's my checklist:

• Strings which work nicely, but pretty minimally
• Vectors which work nicely, but pretty minimally
• Ability to source the above from a memory mapped file
• Ability to read strings in lazy chunks from a file with copying

The fact the IO stuff works with String is more just a detail, it's really IO functions, and gives a nicer symmetry to the library.

I wrote:

f_uncons :: F.ByteArray -> Maybe (F.Word8, F.ByteArray)
f_uncons x = case x F.! 0 of
    Nothing -> Nothing
    Just c -> Just (c, F.drop 1 x)

But seems like it should be in the library, which is likely more efficient. Naturally generalise to all the things.

Currently Functor/Monad are next to each other and Applicative is miles away. Put the type classes in the right order.

Since the repo has moved to Foundation's organisation the CIs are no longer enabled:

• travis
• appveyor

this issue has a work around:

stack ghci --ghci-options '-fobject-code'

Something like:

fileMapReadWith :: FilePath -> (UArray Word8 -> IO a) -> IO a

Possible definition of ArrayUArray is:

    import Foundation.Array
    data ArrayUArray ty = ArrayUArray (Array (UArray ty))

It should be more efficient than a simple array for many things like streaming, appending in the begin/middle/end

It's got very little in it - not worth a separate module to be exposed.

As it stands, things like cons, snoc and sortBy are all in SemiOrdered, but seem to require ordering... Examples of where Set's (for example) live would be useful.

I believe if the Element type of the chunks is already an instance of Eq, Ord or Show, it must not be that hard to add the default instance of these classes

subtract is not flip (-).

^^ seems a little redundant normally to me, and especially in this new world.

It's a big module of stuff you rarely want. Having it in the Prelude seems weird.

Perhaps add a Raw data type to Encoding and fromBytes Raw x = (String x, empty)?

I ported a piece of Hoogle, available at https://gist.github.com/ndmitchell/6828df5eeca3776b32a0420c73dc95ed.

Profiling this code shows 98% of the time is in copyAtRO, even though to convert between ByteString and ByteArray I go via a list... Specifically, 47% of the time is due to break on newlines, and 51% due to uncons on the result. If there were a separating function that could be optimised to avoid the repeated recopy, but that means users can't write their own copy without going O(n^2), which is sad. I think String must support slicing, and given your nice design, that means Array must too.

Should make things like copyAtRO go much faster. They're native in GHC 7.6 and above, but slightly broken in 7.6, so make it conditional on 7.8 or above.

It would be nice to also have builders for strings and boxed arrays like the one for unboxed arrays. That would make it much easier to start building your destination collection while going over an input collection if you can't know the length of the destination collection.
Maybe even a Buildable type class?

* and + have the same precedence leading to fundamental bug

What does it do? Is each thing a line? Or is each thing a fixed size? Or no guarantees? Any blanks?

What I really want is to push the String values into a conduit, which requires a different API anyway...

compare `on` f

Is quite a bit clearer - comparing adds relatively little. Usually having sortOn is way better than overloading the comparing anyway.

strict2 f !x !y = f x y

Could be useful?

it might be useful to split the rev functions from the Sequential typeclass, and have a RevSequential ?

possible alternative, could it be done by abstract types like a:

newtype Reverse a = Reverse a that has a Sequential typeclass that works from the end ?

I'd move the mmap stuff to it (in my mind, mmap is about IO, not foreign).

I'd also move the Core.String.IO to it, since its only 2 functions.

> print $ F.fromBytes F.UTF8 $ F.fromList [169,32,50,48,48,56,32,98,121,32,65,110,100,121,32,71,105]
("",[169,32,50,48,48,56,32,98,121,32,65,110,100,121,32,71,105])

Seems that it shouldn't just get wedged and ignore the rest of the bytes entirely.

Not sure why this one has changed type?

the C function pollute the exported symbol, and the haskell equivalent isn't very complicated

Features I'd like from the String type:

• Small strings should be moveable on the heap so they don't cause excessive fragmentation.
• Large strings should be pinned in memory so they don't cause excessive GC time.
• In certain applications I might want to never use large strings (or set the threshold much higher) - particularly long running server applications where fragmentation is likely to build. Controlling this with an environment variable seems reasonable (e.g. you can put it in a CAF so it doesn't add much overhead).
• I want to be able to create a String from a memory mapped file, without copying the string. At the moment that requires creating a String from a Ptr, but happy with other formulations.

Currently you have to go via a list, which is grim and not performant.

Often useful! Just data Pair a b = Pair !a !b

Add efficient way to convert GHC modified UTF-8 encoding to:

• string
• bytearray

Safe in one direction, unsafe in the other, but still handy.

Writing UArray Word8 helps people learn all pieces of the library faster. And it shows the nice symmetry. I think this is something to show off, rather than hide behind a type alias.

Noone likes Arrow. Why not supply first/second as either restricted to Tuple, or over Bifunctor?

fromJust/head/tail/fromLeft/fromRight are all useful functions. They should exist somewhere.

Just for completeness.

Improve UTF8 next/write to use the unsafeIndexer capability instead of unsafeIndex

It's very useful in practice, and currently people are just going to do:

F.filePathFromString $ F.fromString "C:/Neil/hs-foundation/examples/FieldTrip.txt"

Which isn't really safer, just less convenient. (I remain unconvinced about reinventing virtual file paths at the same time as doing the rest, but this lets me ignore that for the most part.)

• UTF16 decoding
• UTF16 encoding
• UTF8 Lenient decoding
• 7bit ASCII support decoding
• 8bit ISO 8859-1 decoding
• Modified UTF-8 (GHC UTF-8 encoding for Strings) support for IsString optimisation

Just a thought, given its the more "natural" name and you are very much replacing base which has array.

Having Overture is weird. I'd either make it Core.Prelude or Foundation. I'd probably make all the other modules Foundation.Number etc.

Should reexport the nice Partial stuff, plus some partial functions, e.g. fromJust.

What are typical values for arch? That's the obvious question when looking at the function.

Add a module and functions to:

• detect operating system
• detect cpu endianness
• detect number cpus

I can call Core.Foreign.fileMapRead, to get a FinalPtr Word8, but I really want an UArray Word8. Why not just have fileMapRead return that directly?

I couldn't find them?

• extension manipulation
• path dropping / append filename
• parent
• windows support
• OS support (readdir)

Admittedly with a strict element, but calling it StrictList might be a better name? Or maybe it has sufficiently little value that it's unnecessary.