Re: [Haskell-cafe] fixed-length bit-vectors
On 22 November 2012 03:22, Greg Fitzgerald gari...@gmail.com wrote: Hi all, My goal, eliminate the failure case in 'byte': https://gist.github.com/4128503 I don't want my 'byte' function to fail at runtime or return $ Left vector not 8 bits. I want it to return a Word8 for an 8-bit bit-vector or not compile. Is there an existing library that offers fixed-length vectors as a thin veneer over the 'vector' package? I see 'vector-static', but it is unmaintained and hasn't been touched in years. Alternatively, there's 'VecN', but having already learned 'vector', I'd like to know if there is an existing solution that uses it. I'm not aware about such package. But you may want to take a look at fixed-vector[1]. It's not wrapper over vector but it have similar API. It also quite young and may lack features. [1] http://hackage.haskell.org/package/fixed-vector ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck Generators
An idea. You can make a type:
data TestContains = TestContains Tweet TweetSet
and the make an Arbitrary instance for it. When you do
a recursove call you have three different tweets one new tweet
and two from the sub-calls. Then you can place one of them in the
result. In the end you will have a random TweetSet with some value from it.
Here is a scratch of the implementation:
instance Arbitrary TestContains where
arbitrary = sized set'
where set' 0 = mkSingleTweet $ (arbitrary :: Tweet)
set' n = do
t0 - arbitrary :: Tweet
TestContains t1 ts1 - subTweets
TestContains t2 ts2 - subTweets
t - oneof [t0, t1, t2]
return $ TestContains t $ TweetSet t0 ts1 ts2
subTweets = set' (n `div` 2)
2012/11/21 gra...@fatlazycat.com
I have
data Tweet = Tweet {
user :: String,
text :: String,
retweets :: Double
} deriving (Show)
data TweetSet = NoTweets | SomeTweets Tweet TweetSet TweetSet
and trying to create some generators for testing, with
instance Arbitrary Tweet where
arbitrary = liftM3 Tweet arbitrary arbitrary arbitrary
instance Arbitrary TweetSet where
arbitrary = sized set'
where set' 0 = return NoTweets
set' n | n0 = oneof[return NoTweets, liftM3 SomeTweets
arbitrary subTweets subTweets]
where subTweets = set' (n `div` 2)
but wondering how I would go about generating a random TweetSet that
contains a known random Tweet I later have reference to and I would also
assume the known Tweet to be placed randomly.
Then I could test a contains function.
Thanks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
On 20/11/2012 6:08 PM, Richard O'Keefe wrote: On 21/11/2012, at 4:49 AM, c...@lavabit.com wrote: Well, I don't know. Would it save some time? Why bother with a core language? For a high level language (and for this purpose, even Fortran 66 counts as high level) you really don't _want_ a direct translation from source code to object code. You want to eliminate unused code and you want to do all sorts of analyses and improvements. It is *much* easier to do all that to a small core language than to the full source language. Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: we actually made our internal language *larger*, so that we could encode more invariants syntactically. This ended up making our jobs considerably easier, because we did not have to work so hard on doing fancy analyses to recover information that would otherwise have been completely obvious. Yes, there were a lot more cases, but each case was relatively easy; the alternative was a small number of extremely difficult cases. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] class Bytestringable or ToBytestring
Hi cafe, I've been adding lots of types recently that looks more or less like: newtype A = A ByteString data B = B ByteString This is great for extra type safety and letting the compiler do its job, however getting the bytestring back requires boiler plate. At the moment either you give access to the constructor, which is not always wanted, or you use the record syntax to create a function to extract just the bytestring. The latter is fine for 1 or 2 types, but the scheme fall apart when having many of those types and do pollute namespace. I'm basically after something that looks like this: class ToByteString a where toByteString :: a - ByteString Before anyone suggest the Serialize interface from cereal or the Binary interface from binary which both looks quite similar (from far away): - serialize work in the put monad, and you have to define a get instance: which is something that is not required or possible sometime. - binary works with lazy bytestrings and got the same problem as cereal. - a serialize instance that just do a single putByteString is really slow: 12 ns to 329 ns (26x time slower) on the same exact data on one isolated bench) - neither of those packages are in the platform. If that doesn't exists, could it be a worthy addition to bytestring ? is this a good idea in general ? is there any other way ? Thanks, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class Bytestringable or ToBytestring
Why not use http://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/Control-Newtype.html instead? On Thu, 22 Nov 2012 14:15:00 + Vincent Hanquez t...@snarc.org wrote: Hi cafe, I've been adding lots of types recently that looks more or less like: newtype A = A ByteString data B = B ByteString This is great for extra type safety and letting the compiler do its job, however getting the bytestring back requires boiler plate. At the moment either you give access to the constructor, which is not always wanted, or you use the record syntax to create a function to extract just the bytestring. The latter is fine for 1 or 2 types, but the scheme fall apart when having many of those types and do pollute namespace. I'm basically after something that looks like this: class ToByteString a where toByteString :: a - ByteString Before anyone suggest the Serialize interface from cereal or the Binary interface from binary which both looks quite similar (from far away): - serialize work in the put monad, and you have to define a get instance: which is something that is not required or possible sometime. - binary works with lazy bytestrings and got the same problem as cereal. - a serialize instance that just do a single putByteString is really slow: 12 ns to 329 ns (26x time slower) on the same exact data on one isolated bench) - neither of those packages are in the platform. If that doesn't exists, could it be a worthy addition to bytestring ? is this a good idea in general ? is there any other way ? Thanks, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
On Thu, Nov 22, 2012 at 7:56 AM, Jacques Carette care...@mcmaster.cawrote: On 20/11/2012 6:08 PM, Richard O'Keefe wrote: On 21/11/2012, at 4:49 AM, c...@lavabit.com wrote: Well, I don't know. Would it save some time? Why bother with a core language? For a high level language (and for this purpose, even Fortran 66 counts as high level) you really don't _want_ a direct translation from source code to object code. You want to eliminate unused code and you want to do all sorts of analyses and improvements. It is *much* easier to do all that to a small core language than to the full source language. Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: You're still using a core language, though; just with a slightly different focus than Haskell's. I already mentioned gcc's internal language, which similarly is larger (semantically; syntactically it's sexprs). What combination is more appropriate depends on the language and the compiler implementation. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Seattle Area Haskell Users Group
Greetings, (x-posted from /r/haskell) I am calling for any interested parties to come together and help me get a SEA HUG going. My boss has offered to provide facilities and foods. I don't think he's expecting much, maybe we can make him second guess the offer :P. I have put together a meetup http://www.meetup.com/SEAHUG group. I don't know what all Seattle area Haskellers are wanting from this kind of thing, so I thought our first meeting would be low key. Some time to shoot the bull and introduce ourselves. Some time to help each other on our stumbling blocks. Then talking about what we would want from further meetups. We'll need a central place for discussion and coordination, so aside from voicing your support, it would be great if you could take further commentary over to the meetup page. If that doesn't work for some, let me know. Hope to hear from y'all soon. - Eli ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class Bytestringable or ToBytestring
On 11/22/2012 03:42 PM, kudah wrote: Why not use http://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/Control-Newtype.html instead? interesting i didn't know about it, however it's seems relatively unknown (can't find any library on hackage that use it) and just like Serialize and Binary the interface goes both way, where i'm looking only at the unpack method. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
On 23/11/2012, at 1:56 AM, Jacques Carette wrote: On 20/11/2012 6:08 PM, Richard O'Keefe wrote: On 21/11/2012, at 4:49 AM, c...@lavabit.com wrote: Well, I don't know. Would it save some time? Why bother with a core language? For a high level language (and for this purpose, even Fortran 66 counts as high level) you really don't _want_ a direct translation from source code to object code. You want to eliminate unused code and you want to do all sorts of analyses and improvements. It is *much* easier to do all that to a small core language than to the full source language. Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: we actually made our internal language *larger*, so that we could encode more invariants syntactically. This ended up making our jobs considerably easier, because we did not have to work so hard on doing fancy analyses to recover information that would otherwise have been completely obvious. Yes, there were a lot more cases, but each case was relatively easy; the alternative was a small number of extremely difficult cases. I don't think we do disagree. We are talking about the same thing: ``not hav[ing] to work so hard on doing fancy analyses''. The key point is that an (abstract) syntax *designed for the compiler* and a syntax *designed for programmers* have to satisfy different design goals and constraints; there's no reason they should be the same. As a very very crude example of this, with its user-defined operators, Prolog lets you write rules using lots of (unquoted) operators to express yourself in an quasi-English sort of way, e.g., if Block must move and top of Block is not clear then clear top of Block. Readable. But lousy for processing. You'd want to change it to something like action(clear_top(Block), [ must_move(Block), \+ top_is_clear(Block)]). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
I believe the question you are asking is why do large software systems need to be designed in terms of levels or some other software engineering construct(s). To manage their complexity as opposed to getting mangled in their complexity. :D -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] To cabal install cabal-install on Windows ...
- completely remove the earlier Haskell Platform - reboot - defragment the partition/hard drive - reboot - install the newer Haskell Platform - reboot - defragment the partition/hard drive (recommended) - reboot - cabal update - cabal install cabal-install It seems like what is slowing down the install process (or hanging it) is the thrashing of your hard drive to find all the little file fragments it needs during the install Casey -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class Bytestringable or ToBytestring
On Thu, 22 Nov 2012 21:14:31 + Vincent Hanquez t...@snarc.org wrote: can't find any library on hackage that use it http://packdeps.haskellers.com/reverse/newtype ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
