
When parametricity isn't an option, utf-8 is taken for granted, the
language is ambiently strict, it's quite a bit more straight-forward
what you want to do, even if the actual implementation is not trivial.
I'm not saying the decision should be trivial for us, I'm saying that
any attempt to unify the disparate things Haskell programmers want is
going to be much harder than it would be with other languages and
ecosystems.
Also, I use this library for my work regularly:
https://github.com/snoyberg/mono-traversable/blob/17eebcfa2e96e923270e128467...
With Text (Strict | Lazy) and ByteString (Strict | Lazy)
This suits me fine, but I know people for whom mono-traversable is a hard-no.
On Thu, Sep 29, 2016 at 9:43 AM, Heinrich Apfelmus
Relative no-brainer topics in other communities like how text should be represented are highly contentious.
Actually, choosing a good representation for text / strings is not a no-brainer, and the difficulty can be traced to several features of the Haskell language that are simply not present in other languages. Some of these features are:
1) Pattern matching.
We can extract the first character and subsequent characters of a `String` and distinguish cases while doing so:
isPrefixOf [] _ = True isPrefixOf (x:xs) [] = False isPrefixOf (x:xs) (y:ys) = isPrefixOf xs ys
This is not possible in, say, Python.
2) Parametric polymorphism.
The `isPrefixOf` function above is actually polymorphic. It works not only for `String`, but for any kind of list.
3) Lazy data structures.
We can represent text of *infinite* length!
cycle "Haskell" :: String
And we can use them in a streaming fashion
interact (take 10 . lines) :: IO ()
See also
https://wiki.haskell.org/Simple_Unix_tools
You cannot do this with a standard Python string.
Also, it's not like other languages all agree on their preferred method of representing strings: NULL-terminated (C) vs "length-byte-first" (Pascal) comes to mind.
Best regard Heinrich Apfelmus
-- http://apfelmus.nfshost.com
Christopher Allen wrote:
Batteries included is a bad idea when the community is this divided. Relative no-brainer topics in other communities like how text should be represented are highly contentious.
I'd sooner see some basic test cases hammered out and integrated into base before a real attempt at this is launched. Something that would help the Cabal devs.
On Tue, Sep 27, 2016 at 6:14 PM, Joachim Durchholz
wrote: Am 27.09.2016 um 23:25 schrieb Olaf Klinke:
Can someone please define what exactly a "batteries included" standard library is?
Anything you'll typically need is already available. For some value of "typically need", so it's slightly squishy - here's a list of batteries I'd like included: - Reading/writing files - Reading over HTTP (reliably - HTTP is surprisingly complex) - Search&replace in test streams - Easy-to-use string->string maps - JSON parsing and printing (bonus points for YAML) - GUI stuff - Website stuff - Sending mails - Solid ecosystem: - build system, - library directory, - no-brainer automated testing support. (Complicated testing means more bugs in test code than in production code - this diverges.)
IMHO that Python-Haskell comparison is unfair.
Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life.
I do not think that Python actually comes with all batteries included. And in some areas support is pretty bad.
I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines.
That, and the idea that class and function declarations are executable statements. Circular dependencies are "handled" by passing partially-initialized objects around; the Python interpreter handles this with no problems, but programmers have fun because nobody assumes incomplete initialization.
I.e. Python's language semantics is broken by design in pretty fundamental areas.
That said, it's good for banging something together quickly. Been there, done that, got the t-shirt. Just don't do anything that you need a team for with it, the lack of guarantees will really start to hurt.
What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem.
I think Python shares that problem with Lisp: it's so easy to add another meta-idiom that too many people actually do this, and most don't even think about composability or guarantees.
So please, developers: Write more
batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries.
I sense a conflict of objectives here. Having many batteries pushes you towards wide APIs. However, the wider an API, the harder it is to make it combinable. More surface that must be made to match.
Making an API that's feature-complete *and* narrow is really hard and takes a huge amount of designer and programmer time, plus the willingness to lose most of your existing user base for an unproven idea of improvement. This road is a really hard one, and you need corporate backing or personal obsession to follow it.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Chris Allen Currently working on http://haskellbook.com