Giter Club home page Giter Club logo

mason's Introduction

Twitter: @fumieval

Haskell

Name Stars Issues Merge Requests Status Hackage
barbies-th Stars Issues PRs CI Hackage
bindings-portaudio Stars Issues PRs CI Hackage
data-vector-growable Stars Issues PRs CI Hackage
deriving-aeson Stars Issues PRs CI Hackage
discord-vc-notification Stars Issues PRs CI Hackage
extensible Stars Issues PRs CI Hackage
incremental Stars Issues PRs CI Hackage
mason Stars Issues PRs CI Hackage
membership Stars Issues PRs CI Hackage
monad-skeleton Stars Issues PRs CI Hackage
objective Stars Issues PRs CI Hackage
tangle Stars Issues PRs CI Hackage
tehepero Stars Issues PRs CI Hackage
webauthn Stars Issues PRs CI Hackage
winery Stars Issues PRs CI Hackage
witherable Stars Issues PRs CI Hackage

mason's People

Contributors

bodigrim avatar fumieval avatar raehik avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

mason's Issues

Builder backends are only exposed in the Internal module

Yet they are used in public signatures. E.g.,

toStrictByteString :: BuilderFor GrowingBuffer -> ByteString

This means that to provide a signature for a function using this one the user will have to reach out for an internal module.

So could you either reexport the backend types in the public module or if you don't want to, could you at least expose aliases like the following?

type GrowingBufferBuilder = BuilderFor GrowingBuffer

Seeing that all this confusion is caused by the use of Internal module, I want to express other arguments and try to convince you to not expose internal modules.

No unboxing of Buffer under IO

As far as I know, GHC (up to 8.6.1 at least) does not unpack tuples under IO. Hence, s -> Buffer -> IO Buffer in BuilderFor always returns with an extra heap indirection. This can be fixed by using RealWorld# and unboxing manually. I'm not sure if this makes a significant difference here, I'm just noting it as a potential optimization.

Add benchmarks to haskell-perf/strict-bytestring-builders

Hi! Thanks for implementing and maintaining this awesome library! I'm currently looking for the ByteString builder library, and I wonder, what is the fastest option available in Haskell.

There's the benchmark of all bytestring builders in the haskell-perf organization:

But I see that it lacks the benchmark with mason. I think it would be lovely and beneficial for the community, if you could provide implementation of the existing bench suite for mason, so all existing libraries will be covered🙂 Also, according to the strict-bytestring-builders benchmark, the bytestring-strict-builder library is the fastest at the moment, but I'm curious, how it compares to mason 🤔

Impredictive polymorphism issue

Hi,

I tried to replace ByteString.Builder with Mason.
According to the docs it looks pretty easy - just replace imports and add new cabal dependency,
but GHC fails with on every function mentionting Builder with following error?

    • Illegal polymorphic type: forall s. Buildable s => BuilderFor s
      GHC doesn't yet support impredicative polymorphism
    • In the expansion of type synonym ‘Builder’
      In the type signature: mm :: IO (IORef (Int, Builder))
   |
52 | mm :: IO (IORef (Int, MB.Builder))

If Builder type cannot be use in functions this fact should mentioned, cause
it limits library capability.

If not an example with tricky configuration would be helpful.

Support text 2.0

Version 2.0 for the text package switched to UTF-8 for internal representation, which included changing functions in Data.Text.Array from using Word16 to Word8. Some CPP flagging should be able to fix this.

This should fix GHC 9.4 support, which seems to be failing because text-1.2.5.0 has some ghc-prim conflict with bytestring.

mason-0.2.5 fails to build with ghc-9.4.3 in Stackage Nightly

Building library for mason-0.2.5..                                                                                                  
[1 of 4] Compiling Mason.Builder.Internal                                                                                           
                                                                                                                                    
/var/stackage/work/unpack-dir/unpacked/mason-0.2.5-4eda0ef67a4f4475f8ab1dc38aca2a86ff5a522eab57e7c63ddc66b4da9bd874/src/Mason/Builde
r/Internal.hs:497:48: error:                                                                                                        
    • Couldn't match expected type ‘GHC.Word.Word16’       
                  with actual type ‘Word8’                        
    • In the first argument of ‘U16.chr2’, namely ‘w’
      In the second argument of ‘($)’, namely
        ‘U16.chr2 w (A.unsafeIndex arr (i + 1))’                                                                                    
      In the expression: ord $ U16.chr2 w (A.unsafeIndex arr (i + 1))
    |                                                                                                                               
497 |                         let c = ord $ U16.chr2 w (A.unsafeIndex arr (i+1))         
    |                                                ^                                                                              
                                                                                                                                    
/var/stackage/work/unpack-dir/unpacked/mason-0.2.5-4eda0ef67a4f4475f8ab1dc38aca2a86ff5a522eab57e7c63ddc66b4da9bd874/src/Mason/Builde
r/Internal.hs:497:51: error:                                                                                                        
    • Couldn't match expected type ‘GHC.Word.Word16’             
                  with actual type ‘Word8’                                                                                          
    • In the second argument of ‘U16.chr2’, namely                                                                                  
        ‘(A.unsafeIndex arr (i + 1))’                                                                                               
      In the second argument of ‘($)’, namely                                                                                       
        ‘U16.chr2 w (A.unsafeIndex arr (i + 1))’      
      In the expression: ord $ U16.chr2 w (A.unsafeIndex arr (i + 1))                                                               
    |                   
497 |                         let c = ord $ U16.chr2 w (A.unsafeIndex arr (i+1))                                                    
    |                                                   ^^^^^^^^^^^^^^^^^^^^^^^ 

New release

Can you please prepare a new release to include #9?

Intersperse's type signature is too specific

Currently, we have intersperse :: Buildable e => BuilderFor e -> [BuilderFor e] -> BuilderFor e. However, this is too restrictive, as it should be able to be applied to any linear collection. Is there anything stopping us from having something like:

intersperse :: (Buildable e, Foldable t) => BuilderFor e -> t (BuilderFor e) -> BuilderFor e

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.