Lambda the Ultimate

The main advantage of defer-recover exception handling over the try-catch is that it doesn't complicate the control flow of the program. This not only makes programs using defer-recover more readable, but also makes the implementation of this feature in a language much simpler than implementing try-catch exception handling.

On the other hand, the main disadvantage (in Go) is that, it does not allow handling exceptions in place close to where exceptions may arise, and the normal execution has to be resumed in the caller of the function that handles the exception.

Recently I supported Go-style panic/exception handling by defer-recover in my hobby language Dao (it was mentioned here before, but there have been many changes since then). I solved the mentioned problem in Dao by supporting a new type of code block (tentatively called framed block for convenience). Such framed block allows to handle exceptions around the place they arise, and to resume normal execution right after the framed block (namely in the same function where the exception is handled). This is achieved by executing framed blocks in new stack frames, which reuse/share the stack data of their surrounding functions and trigger execution of deferred blocks at exit as normal. You can find more details in a blog I just wrote.

Are there many people here finding Go-style exception handling interesting? I wonder if my improvements could make exception handling by defer-recover more interesting, and better than try-catch?

A paper by Paul W. Abrahams circa 1993, abstract:

Using extended typography, we can design programming languages that utilize modem display and input technologies, thus breaking out of the ASCII straitjacket. We assume that a language has three representations: a visual representation that describes its displayed form, an internal representation defined for each implementation, and an interchange representation, expressed in pure ASCII, that is defined across all implementations. Using extended typography we can use distinctive typefaces to indicate keywords, thus removing the need to reserve them, and can introduce a variety of new symbols more meaningful than those used in most current programming languages. One benefit is the possibility of arbitrary user-defined operators. We can also introduce new kinds of brackets and methods of pairing brackets visually. Extended typography also helps to solve the problems of writing programs in languages other than English.

Sorry I couldn't find a non digital library link, but maybe this would help. I'm surprised no one has looked at this topic again since, at least in academia. Thoughts?

I'm confused by the issue of producing programs using quasi-quotation that themselves use quasi-quotation. Lets use <...> for quotation and ~ for splicing. Consider the expression <...<...~e...>...> where e is some term that produces code. Should that evaluate to the program ...<...e...>... with e spliced in, or should that evaluate to the program ...<...~e...>... that contains a splicing sub-expression? Given the first choice, how would you achieve the behavior of the second choice? And given the second choice, how would you quote a program with a splice outside of a quote? How does that all fit together in a coherent and expressive whole? What about indicating at the splice point to which quotation that splice belongs? Or introduce an escape construct \ so that you can express quoting a splice as <...<...\~e...>...>?

I noticed a fun thing in the Rust manual, a list of languages that influenced rust. So here's the challenge (insiders ineligible): Which features are inspired by which of these languages?

What? MLWorks is an "industrial strength" Standard ML compiler and integrated development environment, developed by Harlequin in the 1990s, recovered in 2013 and open sourced.

This is a paper we presented at OOPSLA 2012:

Molecule is a domain specific language library embedded in Scala for easing the creation of scalable and modular concurrent applications on the JVM. Concurrent applications are modeled as parallel process networks that exchange information over mobile and type-safe messaging interfaces.

In this paper, we present a concurrent programming environment that combines functional and imperative programming. Using a monad, we structure the sequential or parallel coordination of user-level threads, without JVM modifications or compiler support. Our mobile channel interfaces expose reusable and parallelizable higher-order functions, as if they were streams in a lazily evaluated functional programming language. The support for graceful termination of entire process networks is simplified by integrating channel poisoning with monadic exceptions and resource control. Our runtime and system-level interfaces leverage message batching and a novel flow parallel scheduler to limit expensive context switches in multicore environments. We illustrate the expressiveness and performance benefits on a 24-core AMD Opteron machine with three classical examples: a thread ring, a genuine prime sieve and a chameneos-redux.

We have been asked several times if the code was open source during the reviews but unfortunately we did not have the permission to share the code at the time. Now that we have it, I'm pleased to announce that the sources of the library and the benchmarks are available on GitHub. There is also a mailing-list for project specific questions.

I've been busy developing the SPREAD language. After a lot of tinkering, I'm pretty much done with the semantics. I believe the result can be considered 'kind of weird' but very powerful.

I have a hard time classifying the SPREAD language - may be you can help me classify it? The best classification I've come up with is that SPREAD is 'a retro-active programming language'.

Bold claim: retro-active programming subsumes reactive functional programming, and much more.

Comments are very much appreciated!

Intuitively, the semantics of STM is appealingly simple. However, as researchers are coming to discover, this simplicity is illusory and the actual semantics offered by implementations are often counterintuitive—programs that look “obviously correct” may behave in unexpected ways.

to be seen in C# and maybe Python.

While comprehending the syntax of a programming language can be challenging to novices, the computational mechanisms represented in a program text can be even more difficult to understand. It is very useful for programmers to develop ways of mentally visualizing a program's computational process. I have been experimenting with an approach that develops the user’s ability to visualize computational processes through puzzle solving and macro building. As the user issues the commands to solve a puzzle, these steps are recorded as a program sequence (similar to recording a macro).
An interactive flash demo of this approach can be found here.

I would much appreciate your ideas/feedback regarding this approach.

Summary:
Relational data bases have been an outstanding success and become dominant in the commercial world. However, computing has changed dramatically in the decades since the Relational Model was developed. Consequently, the Relational Model and SQL have become obsolete because of the limitations listed above and innovations like the Actor Model and ActorScript[1] are required to address current and future needs.

References:
1. Hewitt, C. ActorScript. arXiv. Cornell University. May 2013. http://arxiv.org/abs/1008.2748

URL:
https://docs.google.com/file/d/0B79uetkQ_hCKb20xSFUzUkg3NzQ/edit?usp=sharing