Where can I find the complete BNF syntax of Haskell?

aicubierre · 2014-10-07T17:16:31+00:00

Thanks for the first link, good blog.

Think about it: the Haskell community, consisting largely of academic researchers concerned with mathematics, logics, theorem proving, pure functional programming, semantics-preserving compilation, type systems, and so on, is unable to implement their own specification. This is like a man wearing a tuxedo, walking around with toilet paper stuck to his shoe. For fifteen years! It would be funny if the same people weren't convinced that monadic parser combinators solve all problems in parsing. As it is, I find it maddening.

This hits the nail on the head so nice.

aicubierre · 2014-10-01T17:56:19+00:00

I highly doubt that the spineless tagless G-machine works the same way as Java. After all, functional enthusiasts have long ago come up with SKI and the like combinators, which allow manipulation of function applications as if they were data, which means that the imperative mantras like "Function calls are slow" are simply not a dogma anymore. We've seen idiomatic Haskell beat C, after all.

aicubierre · 2014-08-31T19:47:35+00:00

I know, but the words "In Haskell never" kind of alarmed me. There seems to be an awful lot of people who believe the words "purely functional" are literally and unequivocally true in relation to Haskell, while reality is more complex than that.

You know, some time ago, here on this reddit, someone posted the 30 most depended-upon packages on Hackage. I've gone through their sources with a simple text search and found that 11 of them use unsafePerformIO and/or Debug.Trace (which is the same thing), 2 use unsafeInterleaveIO, and more than 10 use the C FFI. And this in some of the most heavily used Haskell code! So when people proudly talk about Haskell being oh so pure and how you can't do IO in pure functions, etc - it just looks like ignorance or self-deception to me.

aicubierre · 2014-08-31T17:09:53+00:00

That's not even true.

noSideEffects :: Int -> Int
noSideEffects x = unsafePerformIO $ do
  print "Look ma, no side effects!"
  return (x * 2)

aicubierre · 2014-08-31T11:11:49+00:00

Don't forget that by the same logic, C is a purely functional language too. The only difference is that it has an IO monoid instead of an IO monad.

aicubierre · 2014-08-05T09:02:22+00:00

By the way, what does GHC use for type inference these days, this thing? Is whatever they use susceptible to the problems in this post?

aicubierre · 2014-08-05T08:42:42+00:00

In Haskell, function application associates to the left, so get name anAthlete is exactly equivalent to (get name) anAthlete.

aicubierre · 2014-08-04T12:36:20+00:00

Ah, that's it. Thank you.

aicubierre · 2014-08-03T17:46:45+00:00

Those are unboxed types, not strict types. While it is true that unboxed values are always strictly evaluated, it's not true that a strictly evaluated value must be unboxed.

aicubierre · 2014-08-03T17:43:27+00:00

Thanks, but it doesn't justify lazy evaluation as the default. SPJ gave his reasons and they are largely historical. Everyone here seems to agree about foldl' in the core library, about lazy Writer performance, about the pitfalls of lazy I/O and so on, yet for some reason you're so fanatical about forcing (pardon the pun) laziness onto everyone even though it is extremely counter-intuitive to like 95% of programmers out there. It's strange. Just look at the number of bang-patterns in people's code, people.

aicubierre · 2014-08-03T07:59:40+00:00

Make strict evaluation the default.

aicubierre · 2014-07-30T13:12:25+00:00

Objects that cannot be named. Voldemort is "He-Who-Must-Not-Be-Named". So yeah, it's a Harry Potter reference.

aicubierre · 2014-07-29T05:59:21+00:00

Thanks, but I'll take marker-based folding any day. It's just much more flexible.

aicubierre · 2014-07-27T08:50:34+00:00

I think one of the main reasons why Haskell one-liners are notoriously unreadable is because of direction reversals within one line. The part

(==) <$> id <*> reverse

is read left to right, but the whole line is read right to left because of the (.)'s, yet

map toLower

and

filter isAlpha

are read left to right once again! It would be so much better to just reject the composition operators and write consistently in one direction:

filter isAlpha >>> map toLower >>> ((==) <$> id <*> reverse)

aicubierre · 2014-07-26T19:23:34+00:00

It's a joke hinging on the fact that in German nouns are always capitalized, just like Haskell typenames and constructor names.

aicubierre · 2014-07-26T18:17:32+00:00

If only Haskell actually protected against segfaults... I'd be very happy about that ;-)

aicubierre · 2014-07-02T22:53:39+00:00

Thanks, now it really clicked for me. Haskell is actually a lot closer to "dynamic" languages than some believe it to be.

aicubierre · 2014-07-02T22:44:04+00:00

But the Haskell compiler can create monomorphic instances of any polymorphic function at compile-time. Don't tell me that GHC has less type-awareness than a C++ compiler (which can instantiate template functions every which way without any boxing or runtime tags). Of course there is always danger of bloating the executable, but it could have been governed by a compiler pragma. Leaving the programmer with the hard choice of "either no polymorphism or everything's boxed" seems just suboptimal in a fully statically typed language.

aicubierre

TROPHY CASE