Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit

Yeah and that's annoying IMHO. :)
It's not really important though.
Aristid
Am 07.01.2012 15:39 schrieb "Felipe Almeida Lessa"

On 01/07/2012 04:21 PM, Aristid Breitkreuz wrote:
Yeah and that's annoying IMHO. :)
It's not really important though.
What would you prefer ? At the moment, i'm inclined to someday move cryptohash apis to be similar to crypto-api. i.e. from a result type being a bytestring to an opaque type with serialize/show instance. -- Vincent

2012/1/8 Vincent Hanquez
What would you prefer ?
At the moment, i'm inclined to someday move cryptohash apis to be similar to crypto-api. i.e. from a result type being a bytestring to an opaque type with serialize/show instance.
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... So talking purely about convenience, I would prefer hash :: HashType -> InputData -> ByteString. That would probably not be extensible enough, so I'm not sure how to optimally do it. Aristid

On Sat, Jan 7, 2012 at 10:12 PM, Aristid Breitkreuz
2012/1/8 Vincent Hanquez
: What would you prefer ?
At the moment, i'm inclined to someday move cryptohash apis to be similar to crypto-api. i.e. from a result type being a bytestring to an opaque type with serialize/show instance.
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it...
So talking purely about convenience, I would prefer hash :: HashType -> InputData -> ByteString. That would probably not be extensible enough, so I'm not sure how to optimally do it.
You could use 'hash :: Hash h => Proxy h -> ByteString -> ByteString'. where 'data Proxy a = Proxy'. Defined for you in the 'tagged' package. Antoine

Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it...
What would you think if Crypto.Classes exported Data.Serialize.encode? Or how about if it exported Antoine's hash suggestion (under a different name)? Cheers, Thomas

On Sun, Jan 8, 2012 at 12:39 AM, Thomas DuBuisson
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it...
What would you think if Crypto.Classes exported Data.Serialize.encode?
This suggestion is probably a win even if you do nothing else.
Or how about if it exported Antoine's hash suggestion (under a different name)?
Cheers, Thomas
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote:
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... The whole rationale i believe, is having meaningful types associated to your values so that the type checker can do its job. i.e. you don't start mixing a hash (in binary form) and a random piece of file.
My only problem with the Serialize instance, is that dependencies (cereal in this case) trickle through to the user of the API, which would be solved by Thomas' suggestion. -- Vincent

To use the hash, I have to convert it to a ByteString, and then I
suddenly have lost all this safety. I don't really see how there is
any real safety gained.
That said, just exposing a direct method of getting to that ByteString
without cereal (as Thomas proposed) would be an improvement.
Aristid
2012/1/8 Vincent Hanquez
On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote:
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it...
The whole rationale i believe, is having meaningful types associated to your values so that the type checker can do its job. i.e. you don't start mixing a hash (in binary form) and a random piece of file.
My only problem with the Serialize instance, is that dependencies (cereal in this case) trickle through to the user of the API, which would be solved by Thomas' suggestion.
-- Vincent

On 01/08/2012 02:35 PM, Aristid Breitkreuz wrote:
To use the hash, I have to convert it to a ByteString, and then I suddenly have lost all this safety. I don't really see how there is any real safety gained. Using the hash and carrying it around are two different things. You don't get any usefulness once you have converted it indeed, but before hand this is quite handy sometimes. It's very similar to phantom types or newtype-ing.
It also have a useful self-documentation factor, for example the later tell the user of "myFunction" more information than the former: myFunction :: ByteString -> ByteString -> SomeType myFunction :: ByteString -> Hash SHA1 -> SomeType -- Vincent

Aristid Breitkreuz
To use the hash, I have to convert it to a ByteString, and then I suddenly have lost all this safety. I don't really see how there is any real safety gained.
But that isn't true for all users. Sometimes a hash is computed long before it is transmitted, so while you're passing it around you can be sure it won't be confused with other raw data (basically, what Vincent said). Also, some users never want to convert to a bytestring - using the Eq and Ord instances are enough.
That said, just exposing a direct method of getting to that ByteString without cereal (as Thomas proposed) would be an improvement.
I'll do this and release crypto-api 0.9 soonish. Cheers, Thomas
Aristid
2012/1/8 Vincent Hanquez
: On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote:
Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it...
The whole rationale i believe, is having meaningful types associated to your values so that the type checker can do its job. i.e. you don't start mixing a hash (in binary form) and a random piece of file.
My only problem with the Serialize instance, is that dependencies (cereal in this case) trickle through to the user of the API, which would be solved by Thomas' suggestion.
-- Vincent
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Antoine Latter
-
Aristid Breitkreuz
-
Thomas DuBuisson
-
Vincent Hanquez