Simon Peyton Jones, a Haskell compiler researcher, hosts his papers, book, and advice on writing research papers and giving talks.
HN commenters praise his advice on research papers and talks, and call his book on implementing functional languages one of their favorites.
Coming from the paper on Verse Calculus and having watched Simon Peytonjones’ talk last year I was super excited to try Verse in UEFN last week. Much to my dismay instead of a rich functional language I was met with something that looked like a DSL with python inspired syntax. As I played with the language I couldn’t stop thinking about “choice” and the other feature of verseMax I felt I was missing out on but after making a few toy maps I realized that epic had released a language entirely meant for the public. Reading Verse can be accomplished by anyone who can write a python for loop. The language is VERY accessible.
From the comments below I can see a lot of people are turned away by the idea of FP and this language was clearly meant to address those concerns. The type system is interesting from a high level view but for non-coders I can see how it would make sense.
For instance writing `if var = int` looks perfectly reasonable for someone who has never programmed before and it just works in verse.
So all in all while I was upset on a personal level at what Epic has released, I hope it is a stepping stone to their overall goal of verseMax. Furthermore I am excited at the idea of millions of people (kids) learning functional programming as their first language and think this iteration of verse may just be the perfect gateway drug.
[1] https://m.youtube.com/watch?v=832JF1o7Ck8
[2] https://simon.peytonjones.org/assets/pdfs/verse-conf.pdf
[3]…
> Can you expand on your understanding of GRIN doing parts of supercompilation?
GRIN, if I am not mistaken, performs partial evaluation. For example, it constrains, for each eval site, a set of tags and set of heaps allocations an eval site can receive. This is close to a partial evaluation step of a supercompilation. GRIN does not perform unification, though, it is not described in the original thesis, but data flow graph matching would be close to unification, reducing code size.
> The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.
This can be constrained. Supercompilation usually gets ran to a fixed point, where no partial evaluation steps can be performed that are not unifiable with previously encountered evaluation steps. But supercompilation can be stopped at any point.
I believe you can read on that in Simon Peyton-Jones works, I am unable to find a link to that paper right now, I have troubles with the internet connection.
EDIT: here it is: https://simon.peytonjones.org/improving-supercompilation/
EDIT: Note "tag-bags," it rhymes with the tag sets of GRIN.
> What value would Fuse get from equivalence of terms, do you think?
I think that equivalence of terms is an efficient way to verify properties of programs. Myself, I am looking at consensus protocol implementation verification.
> The Misty Programming Language is a dynamic, (...), secure, distributed actor language
In this day-and-age, dynamic programs should be considered insecure (in the broad sense) by design. There have been lots of efforts in the past ~15 years to make distributed systems more robust (e.g. Cloud Haskell [0], choreographic programming [1]).
The term "secure" as used here is quite specific, used in reference to a capability model. This is quite nice and innovative. However, static typing and capabilities need not be mutually exclusive: capabilities can be modeled at the type level using algebraic effects [2].
[0]: https://simon.peytonjones.org/haskell-cloud/
[1]: https://en.wikipedia.org/wiki/Choreographic_programming
[2]: https://github.com/yallop/effects-bibliography
> I think that depends on what you meany by "pattern matching"
Oh, yes, that's true. "Pattern matching" as that what normally is used in "functional programming languages". This kind of pattern matching does not need unification. The IMHO best (correct, but understandable and with all needed definitions) explanation of it is in chapters 4 "STRUCTURED TYPES AND THE SEMANTICS OF PATTERN-MATCHING" and 5 "EFFICIENT COMPILATION OF PATTERN-MATCHING" of Peyton Jones et al., "The implementation of functional programming languages".
https://simon.peytonjones.org/slpj-book-1987/
> In programming cirlces "pattern matching" usually means matching strings.
Depends on the "circle" ;) https://en.wikipedia.org/wiki/Pattern_matching
Thank you. This is beautiful.
Related gems from Simon Peyton Jones are below. In the first, he also advocates telling a story.
https://www.microsoft.com/en-us/research/uploads/prod/2016/07/How-to-write-a-great-research-paper.pdf
https://www.microsoft.com/en-us/research/uploads/prod/2016/07/How-to-give-a-great-research-talk.pdf
https://simon.peytonjones.org/assets/pdfs/writing-a-proposal-mar23.pdf
This is a bit Haskell oriented, but the "Implementation of Functional Programming Languages" by SPJ is one of my all time favorite books.
https://simon.peytonjones.org/slpj-book-1987/
These compilers were pulling heroic data structure optimization stunts in 1985, that no modern production compiler for major compiled languages can replicate in 2024.