Live data from Hacker News

Write You a Haskell: Building a modern functional compiler from first principles

dev.stephendiehl.com

31–40 of 48 posts

Re: Write You a Haskell: Building a modern functional compiler from first principles

#31
post #30

Very interested in seeing how he'll deal with lexing Haskell. It's a major pain, tools like Parsec are very good out of the box with whitespace insensitivity, but not whitespace sensitive stuff.

I suppose using haskell-src-exts is cheating...

Re: Write You a Haskell: Building a modern functional compiler from first principles

#32
post #30

Very interested in seeing how he'll deal with lexing Haskell. It's a major pain, tools like Parsec are very good out of the box with whitespace insensitivity, but not whitespace sensitive stuff.

I suppose using haskell-src-exts is cheating...

"I will build haskell by taking the source code and running it"

I jest, but this is an issue I've thought about idly for a while. Maybe it's possible to write a two-step parser: one that turns chars into tokens (and cheat a little bit by stripping spaces in some contexts to make it context free), and then you have a nice CFG that you can do easily.

Re: Write You a Haskell: Building a modern functional compiler from first principles

#33
post #30

Very interested in seeing how he'll deal with lexing Haskell. It's a major pain, tools like Parsec are very good out of the box with whitespace insensitivity, but not whitespace sensitive stuff.

IIRC, Haskell has a well-defined mapping of whitespace to explicit braces and semicolons -- I suppose one could perform that transform first to desugar, then parse the resulting token stream normally...

Re: Write You a Haskell: Building a modern functional compiler from first principles

#34

As a sidenote, Stephen is also the author/maintainer of "What I Wish I Knew When I Was Learning Haskell"[0] which is a great resource both for those who are learning and for slightly advanced programmers. [0] http://dev.stephendiehl.com/hask/

Your comment implies that programmers stop learning once they are slightly advanced.

Re: Write You a Haskell: Building a modern functional compiler from first principles

#35
post #32

Earlier quoted context omitted.

I suppose using haskell-src-exts is cheating...

"I will build haskell by taking the source code and running it" I jest, but this is an issue I've thought about idly for a while. Maybe it's possible to write a two-step parser: one that turns chars into tokens (and cheat a little bit by stripping spaces in some contexts to make it context free), and then you have a nice CFG that you can do easily.

See eg http://michaeldadams.org/papers/layout_parsing/

Re: Write You a Haskell: Building a modern functional compiler from first principles

#36

As a sidenote, Stephen is also the author/maintainer of "What I Wish I Knew When I Was Learning Haskell"[0] which is a great resource both for those who are learning and for slightly advanced programmers. [0] http://dev.stephendiehl.com/hask/

Your comment implies that programmers stop learning once they are slightly advanced.

No, it doesn't imply that, at all. My least favorite thing on the Internet nowadays are shallow fault-finding comments like yours from people who just want to interject themselves into discussions where they have nothing substantive to say. I used to be that guy and still have to actively resist the temptation. Don't be that guy.

Re: Write You a Haskell: Building a modern functional compiler from first principles

#37
post #5

Now this is very interesting! There are plenty of compiler writing tutorials for conservative, imperative programming languages with a straightforward static type system (like C). I did study a little bit of compilers for functional languages from Simon Peyton-Jones' old book "The Implementation of Functional Programming Languages" [0]. It predates the Haskell programming language and uses a contemporary research lan…

Thanks for sharing, and for anyone else reading you might also like the following book--`Modern Compiler Implementation in ML' by Appel. (http://www.cs.princeton.edu/~appel/modern/ml/)

Re: Write You a Haskell: Building a modern functional compiler from first principles

#38
post #30

Very interested in seeing how he'll deal with lexing Haskell. It's a major pain, tools like Parsec are very good out of the box with whitespace insensitivity, but not whitespace sensitive stuff.

Its not that hard to implement some form of whitespace sensitive parsing, you need to maintain explicit state, essentially a stack and a number of combinators. See for example

https://github.com/purescript/purescript/blob/master/src/Lan...

The state is defined in https://github.com/purescript/purescript/blob/master/src/Lan...

(its just the column number). I believe the whitespace rules for Haskell are somewhat subtle, but shouldn't be much harder.

Re: Write You a Haskell: Building a modern functional compiler from first principles

#39
post #12

I'd like to recommend The Programming Language Zoo by Andrej Bauer. It is a collection of programming language implementations, small and clear, written in OCaml. http://andrej.com/plzoo/

Oh, wow. I've been learning OCaml lately, specifically to dive into Hack, Facebook's new statically-typed PHP derivative. This will really help with that, thanks so much for the link!

Re: Write You a Haskell: Building a modern functional compiler from first principles

#40
post #33
post #30

Very interested in seeing how he'll deal with lexing Haskell. It's a major pain, tools like Parsec are very good out of the box with whitespace insensitivity, but not whitespace sensitive stuff.

IIRC, Haskell has a well-defined mapping of whitespace to explicit braces and semicolons -- I suppose one could perform that transform first to desugar, then parse the resulting token stream normally...

If you think of well-defined as combining the most subtle aspects of Javascript semicolons and Python braces, I agree. As hobby projects, I have coded a significant fraction of a Haskell parser and a majority of a Python parser. It was good I did the Python one first. The Haskell rules include a clause which says if you don't yet have a syntax error from your tokens, and you have a syntax error by adding the next token, and you would not have a syntax error if you added first a closing brace and then the next token, then insert the corrective closing brace. So you can't just tokenize, infer what's missing, then parse the tokens.
Post reply on HN