Software Development Team (King's College London)

Alas, most parser generators don't have very good error recovery (and some have such terrible error recovery that I think it's worse than not having any!). It turns out that this isn't inevitable: there's been a long strand of research on decent error recovery for LR parsers, at least, but it needed a bit of a refresh to be practical. If you'll forgive the blatant self promotion, we tackled this problem in https://soft-dev.org/pubs/html/diekmann_tratt__dont_panic/ which is implemented in our Rust parsing system https://github.com/softdevteam/grmtools/. It won't beat the very best hand-written error recovery routines, but it's often not far behind.

You might find the following papers interesting. [1] O. Kiselyov, K. Kameyama, Rethinking Prolog. http://okmij.org/ftp/kakuritu/rethinking.pdf [2] E. Barrett, C. F. Bolz, L. Tratt, Unipycation: A Case Study in Cross-Language Tracing. https://soft-dev.org/pubs/pdf/barrett_bolz_tratt__unipycation_a_study_…

There is another use case for JIT compilers that has not been considered: speeding up programming language development. PyPy's meta-tracing JIT-compiler framework [1] allows you to generate reasonably fast tracing JIT compilers for languages essentially by writing an interpreter. Laurie Tratt has written a nice description of this, and the advantages this delivers [2]. This make the development of new programming languages much simpler, because you don't have to invest a lot of time and effort into producing a reasonably fast compiler (whether JIT or AOT) at the beginning of language development. Yes, in many cases you can build AOT compilers that beat JITs produced by meta-tracing an interpreter, but not easily so. Tratt's team has used this approach for building impressive multi-language tools [3] that allow you to write programs in heterogeneous languages like Python, Prolog and PHP at the same time. [1] http://stups.hhu.de/mediawiki/images/f/f5/Tracing_JITs11_tracing_the_m… [2] http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast_enough_ti… [3] http://soft-dev.org/

The one I'm most excited about is improved error recovery: https://soft-dev.org/pubs/html/diekmann_tratt__dont_panic/ https://drops.dagstuhl.de/storage/00lipics/lipics-vol166-ecoop2020/LIP…

The twisty maze of parens I never understand. (And the fact that TI won is probably, imho, only vaguely to syntax, kids barely use calcs anyway, and I'd argue that if you'd show them RPL immense programming surface, lists, vectors, lambdas, they'd use it more than the usual fix function graphing calc) I never had a chance to see proper CASE tools, my education started in 2000.. java/uml took the light and the few environments I saw were very very subpar (post IBM, eclipse based, rational suite). The grammar composition is still a big open problem, I think Lawrence Tratt tried to attack it (maybe this https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_composed_grammar… ?) but concluded it was still fragile/difficult.

Interesting stuff. To learn that it can take 190 iterations for warm-up to finish may be a revelation to VM developers. The idea about some runs having slowdowns might not be significant if it's just one run out of 30 that does it though. The result in the last Diagram of TruffleRuby on spectralnorm having 25 slowdowns and 5 no steady-state is interesting. Full paper at : http://soft-dev.org/pubs/html/barrett_bolz-tereick_killick_mount_tratt…

Wow the class from which this video is taken looks really interesting, and has more videos! Thanks for the link. http://soft-dev.org/events/vmss16/

Additionally, they published this paper last year with an early demo of the editor linked on Youtube. I've posted it on here a few times but it hasn't had much response. http://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_composed_grammars… https://www.youtube.com/watch?v=LMzrTb22Ot8

CHERI is not specific to C/C++ but aims to provide primitives at the hardware level that can be used to make software safer (including programming languages) in terms of (spatial and temporal) memory safety and also to compartmentalize your software stack (e.g., separate third-party software libraries from the core of your application). It is true that the only currently stable CHERI-extended SDKs for programming languages are CHERI LLVM [1] (for CHERI-RISC-V) and LLVM for Morello [2] for CHERI C/C++ [3]. However, there have been more projects that extend other SDKs for CHERI: Rust [4] [5], JavaScriptCore and WebKit [6] [7], OpenJDK [8]. [1] https://github.com/CTSRD-CHERI/llvm-project [2] https://git.morello-project.org/morello/llvm-project [3] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf [4] https://github.com/kent-weak-memory/rust [5] https://soft-dev.org/events/cheritech22/slides/Cooksey.pdf [6] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-webkit.ht… [7] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-975.pdf [8] https://www.dcs.gla.ac.uk/~jsinger/cheritech23_slides/anisbet_cheritec…