haskell-foundation / foundation Goto Github PK

> 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.

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.)

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 ?

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

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

• string
• bytearray

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

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.

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.

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

* and + have the same precedence leading to fundamental bug

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

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

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

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

Add a module and functions to:

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

I couldn't find them?

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

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

• 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

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

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...

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.

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

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?

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

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.

this issue has a work around:

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

Not sure why this one has changed type?

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.

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?

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.

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.

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.

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

strict2 f !x !y = f x y

Could be useful?

Just for completeness.

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

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

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

• travis
• appveyor

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

subtract is not flip (-).

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

Something like:

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

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

compare `on` f

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

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

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.

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