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:

  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.

https://repl.it/@mrgriffin/unpickle

IIRC the pickle format can define new classes, but I haven't looked at it in over a decade so I might be misremembering.

You might be right, it's been a long time for me too. But if it can define new classes, then I'd expect that the code for those classes' methods would also be in the pickled format, at which point there's no particular reason you couldn't deserialize it in Haskell too... with some caveats about either needing to know what types those functions should have, or needing to build a run-time representation of those types so that they can be checked when called, or (hopefully!) crashing if you're okay with just unsafeCoercing things around.

read :: String -> Maybe PlainPythonObject

read :: String -> Maybe Json

goes a long way.

But as soon as you're using "Maybe", you're impeding much of a type systems strengths, as the article outlined.

Only if there is actually anything more you can say about String that would let you avoid the Maybe. If this is raw data and you don't even know that the JSON is well formatted (else why can a parse straight to a generic JSON object fail) then there's not any better way to type it.

You might want to return an error message on failure, or provide a mechanism for recovery, but those are somewhat specific to the use case and don't really address the key point of the article.

It's really a matter of what you care about to accomplish.

My point is that Python objects are certain data structure and if you bother to create type for it them then you can use it in function type.