Posts tagged PLT
“One of the PL community questions that has been bugging me for a long time is what is and what isn’t a programming language […] the way we construct what is a programming language is social, groups decide what is in and out […] If we want to study this phenomenon, we cannot do that in the realm of PL itself, you will need theories about how social constructs work, and that is where feminism can help!”
—Felienne Hermans
Truffle is a framework for writing interpreters with annotations and small bits of extra code in them which, when Truffle is paired with its sister project Graal, allow those interpreters to be converted into JIT compiling VMs … automatically. The resulting runtimes have peak performance competitive with the best hand-tuned language-specific compilers on the market. For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks. The RubyTruffle engine is faster than all other Ruby implementations by far. The TruffleC engine is roughly competitive with GCC. There are Truffle implementations in various stages of completeness
via https://medium.com/@octskyward/graal-truffle–134d8f28fb69
The basic unit of meaning in Escher is the reflex. A reflex is a named black-box computational device, which interfaces with other objects in the linguistic environment through a set of named valves. Metaphorically, the valves can be viewed as labeled communication pipes coming out of the black-box.
http://www.maymounkov.org/memex/abstract
This post is a crash course on the notation used in programming language theory (“PL theory” for short). For a much more thorough introduction, I recommend Types and Programming Languages by Benjamin C. Pierce and Semantic Engineering with PLT Redex by Felleisen, Findler, and Flatt. I’ll assume the reader is an experienced programmer but not an experienced mathematician or PL theorist. I’ll start with the most basic definitions and try to build up quickly.
http://siek.blogspot.be/2012/07/crash-course-on-notation-in-programming.html
Programming is complicated. Different programs have different abstraction levels, domains, platforms, longevity, team sizes, etc ad infinitum. There is something fundamentally different between the detailed instructions that goes into, say, computing a checksum and the abstractions when defining the flow of data in any medium-sized system. I think that the divide between coding the details and describing the flow of a program is so large that a programming language could benefit immensely from keeping them conceptually separate. This belief has led me to design a new programming language - Glow - that has this separation at its core.
http://fendrich.se/blog/2013/09/03/big-programming/