Simon Peyton Jones' seminal work "Implementation of Functional Programming Languages" is available free of charge now that it's out of print[0]. If you haven't read it yet I'd highly encourage it!
The scope of the chapters in this book is huge. I have written one or two functional language compilers as hobby projects, and I have attempted to acquaint myself with the literature in the process.
It has got to be a challenge to create a tutorial sequence of chapters that builds to a satisfying state at each stage. Especially on this topic, which I believe covers almost everything we know about compiling and executing code. The rest of it would maybe require an implementation of Agda or something.
I have a copy but that is about programming Haskell and not about writing a functional language in Haskell. Also, it is still darn difficult to read (beginning with the lambda calculus). A lot of people absolutely love it though.
If someone could write a Haskell with a simpler build system, and better internal documentation so it becomes more "hackable", that would be great. The structure of GHC seems more complicated than necessary, as the first comment of [1] states. GHC seems much too monolithic for a functional programming environment.
I actually don't know how much my frustration relates to the hackability of the ghc.
I'd LOVE to "write me a haskell". I've been trying for the last 3 days to wrap my work style around cabal/stack... It's so so so frustrating (especially on Arch Linux). This is something I come back to every 6 months or so.
Ideally, I'd be able to write Haskell that compiles into concise, trimmed down, readable javascript bundles, (as you can compile OCaml with bucklescript). But I don't think it's really possible right now. Once upon a time I successfully managed to get ghcjs to compile code using a library I was interested in. It spit out a 1 MB bundle, without even doing much of anything. No thanks! Organizing a project around this system sounds not very enjoyable.
Yesterday I managed to get Reason (OCaml) running, but figured out that using any existing OCaml libraries means I have to manually manage & compile them. Also, it doesn't seem like the OCaml community has nearly as many libraries as the Haskell community.
It's weird to say, but I think I am spoiled by npm-based tools! As hard as it was to get used to, I actually really appreciate their hardiness.
I still may end up going with OCaml/Reason and bucklescript, and just not worry about libraries. Maybe writing more functional programs will decrease my reliance on libraries in the first place, since stuff can be done so concisely.
If anyone has advice about this stuff, I'd gladly take it!
> I've been trying for the last 3 days to wrap my work style around cabal/stack...
You have me puzzled! You can totally ignore/skip cabal and just use
- to create project dir with stack.yaml
stack new myproject simple
- to ensure all dependencies and a ghc for that stack.yaml are present
stack setup
- to rebuild any changes
stack make
- to live-code in your project
stack repl
- to run interpreted any one of your mains:
stack runghc some/tool.hs
- to grab 3rd-party dependencies for the project:
stack install some-external-lib
Pretty similar to most other modern languages' "canonical" build/run/package-management tooling really.
> Ideally, I'd be able to write Haskell that compiles into concise, trimmed down, readable javascript bundles, (as you can compile OCaml with bucklescript). But I don't think it's really possible right now. Once upon a time I successfully managed to get ghcjs to compile code using a library I was interested in. It spit out a 1 MB bundle, without even doing much of anything.
Well. For JavaScript from Haskell, other than GHCJS that "compiles the whole runtime system" to multi-MB packages, there's more lightweight options (outside of PureScript/Elm), namely: Fay and Haste. Fear not, a new from-scratch transpiler is also next on my agenda however! ;) that's because Fay parses Haskell to transpile, but I definitely want to transpile from the highly optimized and richly annotated-with-compilation-hints "STG" IR. Not sure how Haste does it, but I'd rather have full control over the JS I emit over the coming half-decade anyway and it's certainly a bit dated (ES 6+ can be emitted so much more "compactly" than legacy JS!)
That being said, from what you're saying I think you're better served with ReasonML or PureScript as these projects seem to already have matured somewhat yet also not-yet-stale =)
Thanks for the tips! I guess some of my frustration was that I was trying to get haste running with stack, but it needs ghc v7-something, but I'm getting ghc from pacman, so stack kept asking me to manually resolve libraries... there were other dramas and confusions too, but mostly I have little patience for making package managers play nicely, especially when I'm not very familiar with them in the first place and am new to the language! I get distracted and go off to play piano or something that's more straightforward to me :)
which gets you the version of GHC you need to be able to run $whatever_command into ~/.stack if you don't have it. Much less brittle than a system-wide installation, and perfect for working with multiple GHCs. Anecdotally: I setup the Arch Linux machine I'm typing this on yesterday. I installed[1] Stack/GHC before xorg :)
Just want to second this. As someone who did not know Haskell going in, I found PureScript to be quite useful because I could look at the generated Javascript to understand exactly what it's doing under the hood. I've since been able to use what I learned in PureScript in Haskell with very little difficulty.
If you are originally setting out to generate Javascript, I think PureScript is even more compelling. The code it outputs is really gorgeous. It is also optimised for that environment. Specifically some features in Haskell that would be difficult to implement in Javascript are not present. Also, the very few places where the syntax differs tends to make the code generation very predictable.
I haven't used it in a big project yet, but from playing around with it, I wouldn't hesitate to do so.
Is the author planning to continue? This sounds like a rich and interesting subject that I would enjoy following through to the end.
Another book I've found helpful for Haskell is:
Haskell Programming from First Principles (http://haskellbook.com/)