HN user
The catch is that you can't actually measure the rule-and-compass construction with infinite precision. You can perform more operations on the construction and then measure later to verify that it produced the correct result, but so can a turing machine acting on a mere "representation" of the number.
OPAM and Dune (jbuilder) work very nicely IME. You don't need to touch a Makefile, you don't need to build anything by hand outside of the package manager.
To add onto the point about expanding stacks: What's especially nice about this feature is that it means that you don't need to tune your algorithms to be tail recursive when they could be expressed more clearly as non-tail recursion. Functions like map would actually be less efficient on average if it was tail recursive because you would need to re-iterate the list to reverse it.
It's also possible to have, say, a trillion tokens on the board and it's legal to pick any one of them as a target
Even more entertaining, is the fact that (IIRC) there are certain combos that cause infinite loops that can't interrupted, e.g. if neither player has a counter or kill spell, then the turn lasts indefinitely.
They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.
I wish I had a language that did optional typing
they exist, but I don't use them.
:/
The author's thoughts (I want to write dynamically to get the code working, but then make it static afterwards) are nearly the exact thing I've heard from Matthias Felleisen when he talks about the motivation behind Typed Racket.
I don't think it's possible to create a satisfying diagram like this. It's already been said, but compartmentalizing languages into "paradigms" is generally pointless.
Hindley-Milner is cool, but if you're planning on implementing a language with type inference, I strongly suggest you take inspiration from bidirectional type inference, notably Pierce-Turner[1] and subsequently Dunfield-Krishnaswami[2]. These algorithms are capable of inferring much more complex types and generally produce better error messages. Typically, there are very few programs which can't be typed when you combine Dunfield-Krishnaswami type inference and have the user place annotations on major function definitions.
[1] http://www.cis.upenn.edu/~bcpierce/papers/lti-toplas.pdf
Does Racket support non-Lisp-like syntax for DSLs written in it?
Yes! You can override the reader so that it parses anything, and there are modules for writing grammers[1][2]. Still, it is usually much easier to just use the built in s-expression parser, and if you're writing a lot of lisp, you probably don't mind s-expressions anyways :)
Hackett has interested me too, I hope that progress can continue to be made, it would be a nice alternative to Typed Racket (which is great, but very complex).
I'm working with the author of the "Type Systems as Macros" paper right now, we're working on implementing a linear language (along the lines of Rust) using Racket's macro facilities and the turnstile[3] package. Being able to embed arbitrary type systems in Racket really shows the insane power of the macro system.
[1] http://docs.racket-lang.org/parser-tools/LALR_1__Parsers.htm...