In the style TFA you should wrap pickle.load() with a function that will unpickle the specific type you are expecting. So you should write a unpickleArrayOfInts() or whatever.
The actual type would be a rather large union type, which would be unwieldy to use (but in an untyped system like python you still would need to deal with all of those corner cases to have a program that is correct in the face of arbitrary input).
Really the biggest annoyance of type systems is that they make you deal with corner cases that you don't think are practically possible. If you are right, then they are wasting your time. If you are wrong, then they are saving you from having bugs.
I'm pretty confident that you could write something that was equivalent to all the useful `pickle` calls. By that I mean you'll need to know which operations you'll want to do on your unpickled object:
readAny :: forall c r. [TypeWithReadAnd c] -> String -> (forall a. c a => a -> r) -> Maybe r
readAny types string handle
I think it's fair to say "hey, pickle doesn't require me to list all my types explicitly", but on the other hand, it's not like pickle can conjure those types out of thin air--it considers only the types that are defined in your program.
Here's an example that uses Read as the serialization format and only deals with Int, Char and String; but hopefully you can imagine that I could replace the use of read with a per-type function that deserializes from a byte string or whatever.
In the style TFA you should wrap pickle.load() with a function that will unpickle the specific type you are expecting. So you should write a unpickleArrayOfInts() or whatever.
The actual type would be a rather large union type, which would be unwieldy to use (but in an untyped system like python you still would need to deal with all of those corner cases to have a program that is correct in the face of arbitrary input).
Really the biggest annoyance of type systems is that they make you deal with corner cases that you don't think are practically possible. If you are right, then they are wasting your time. If you are wrong, then they are saving you from having bugs.
It would be this
https://www.stackage.org/haddock/lts-13.21/base-4.12.0.0/Pre...
I think that's different. `read` requires you to know what you're deserializing up-front, while `pickle` decodes the type dynamically from the data.
Dynamic languages really can have functions whose behavior cannot be expressed as some sort of type signature.
I'm pretty confident that you could write something that was equivalent to all the useful `pickle` calls. By that I mean you'll need to know which operations you'll want to do on your unpickled object:
I think it's fair to say "hey, pickle doesn't require me to list all my types explicitly", but on the other hand, it's not like pickle can conjure those types out of thin air--it considers only the types that are defined in your program.
Here's an example that uses Read as the serialization format and only deals with Int, Char and String; but hopefully you can imagine that I could replace the use of read with a per-type function that deserializes from a byte string or whatever.
https://repl.it/@mrgriffin/unpickle
2 replies →
read :: String -> Maybe PlainPythonObject
read :: String -> Maybe Json
goes a long way.
3 replies →