## The theory behind the Terms language

Hi,

I would like to present to you a programming language I have developed. Reading through your getting started page, I can see that the focus in this forum is category and type theory, etc. I am not an expert, but I understand what these are about.

What I propose, however, is not in that sort of direction; it is academically quite unrelated. Its end result, though, is an implemented, working programming language [1], that I believe can be useful for certain problems, and that's the reason I address you here with it.

What I would like you to read and comment is a brief explanation of the theoretical foundation of this programming system [2]. I would really appreciate any comment.

I am not sure if my approach is original, and I am also not sure whether my conviction that this approach is useful is just a delusion.

This is not the first time I try to show this work in this forum. The first time there was some discussion, but it didn't get to the point I am trying to make. I have tried to be more to the point this time.

## Toward a better programming

I wrote a blog post for my talk from Strange Loop 2013 about the framework I've come up with for describing what's wrong with programming and how we might go about fixing it. Here's an excerpt:

The other day, I came to the conclusion that the act of writing software is actually antagonistic all on its own. Arcane languages, cryptic errors, mostly missing (or at best, scattered) documentation - it's like someone is deliberately trying to screw with you, sitting in some Truman Show-like control room pointing and laughing behind the scenes. At some level, it's masochistic, but we do it because it gives us an incredible opportunity to shape our world. With a definition for what programming is and a concrete understanding of what's wrong with it, we have a framework for capturing that opportunity and removing the rest. But in order to do so, we can't just bolt it on to what we have now. Another layer of abstraction won't be enough. Instead, we have to address these fundamental problems at the very foundation of our solution. No more teacups and no more compromises.

## using words and notation in domain specific language syntax

I face the following dilemma:
• it is easier to remember keywords in a language, but there can be a confusion when people take their meaning from plain English. Also, such a language might be wordy like Cobol
• Symbolic identifiers make expressions shorter but they might become cryptic and this refutes the whole purpose of a domain specific language, namely, that a domain expert with less experience with a general programming language can read it without effort
I would like to hear your opinion on this, with literature pointers when possible.

## Programming with Managed Time

Submitted for publication; abstract:

Time is of the essence when modifying state. Most programming languages expose the hardware's ability to update global state at any time, leaving the burden entirely on programmers to properly order all updates. Just as languages now manage memory to free us from meticulously allocating and freeing memory, languages should also manage time to take care of properly ordering state updates. We propose time management as a general language feature to relate various prior work but also to guide future research of this largely unexplored design space.

We propose a new form of managed time, Glitch, which ensures that all updates associated with an external event appear to execute simultaneously, removing the need to order execution manually. Glitch replays code as needed to reach an appearance of simultaneous execution. To do this, all updates must be commutative and capable of being rolled back, which is ensured through built-in state constructs and runtime monitoring. While these restrictions might seem onerous, we find them acceptable for many realistic programs. Glitch retains the familiar imperative programming model as much as possible, restricting rather than replacing it.

Managed time also aides in live programming that provides immediate programmer feedback on how code edits affect execution. Live programming to date has been limited to special cases like pure functions, spreadsheets, or at the top level of games and graphics. Glitch is fully live: past program executions can be replayed in an IDE, while executions are incrementally revised under arbitrary code changes.

Written with Jonathan Edwards and heavily inspired by his blog post; there might have been a few LtU posts on this subject in the past also.

## CFP: Book Chapters for "A Librarian’s Introduction to Programming Languages"

[Folks, This came across the CODE4LIB email list, along with a "feel free to share" not. LTU came to mind immediately. FYI, ALA is the American Library Association - they published a book of mine maybe 15 years ago, and they were great folks to work with. It's been a while, but the guy who as my acquisitions editor is now their Sr. Editor - so I expect their still good to work with.]

This is a call for book chapters for A Librarian’s Introduction to

This book will look at a variety of programming languages with the intent
to familiarize readers with the reasons for using each language. The book
will cover practical, real world examples to illustrate how a specific
language can be used to enhance library services and resources.

The target audience includes current practitioners, administrators,
educators, and students.

Some potential topics to be included in the book are below.

● Basic
● C#
● Java
● Javascript
● Perl
● Python
● Ruby

We are also interested in other topics. For more information email the
editors:
Ron Brown ronbrown@sc.edu and Beth Thomsett-Scott
beth.thomsett-scott@unt.edu

The problem is that actors do not always process messages in the order received, but may limit processing to selected messages based on their current state. This technique is often used when waiting for a response from another actor. Clearly this can lead to something like deadlock where several actors freeze up, even though no locks are used.

JActor takes a different tack. Messages are processed in the order received, but messages are mostly 2-way and are first class objects with each message only being used once. This means that while processing a message, it can be a place to save intermediate state. So if processing involves sending messages to other actors, there is no need to update the actor's state until message processing is complete.

Another difference is that when a message is returned as a response, it is dispatched differently from other messages. When a message is first sent, it serves as a request and is assigned a callback that will be used when the message is returned with a response value. But note that actors process messages one at a time as a means of thread safety, and this applies as well to the invocation of the callback when processing a response.

This is covered in a lot more detail in the JActor project README.

## Brendan Eich, CEO of mozilla

Correct me if I'm wrong, but I think this is the first case of a language designer making it to the top slot of a company!

## "null" is to tagged unions as ???? is to records

Many programmers are not aware of tagged unions and I love introducing them. I talk about how records and tagged unions are two complementary and fundamental constructs, and that null is a trick that lets you still hackily get stuff done without tagged unions.

But this got me thinking, if null is the crappy version of tagged unions, what's the crappy version of records? My initial thought was "pairs", but that's not quite right because pairs are more like Either.

## Multimethods over structural types

Hello,

I am interested to know if there are languages out there, or research projects, or people's wild private imaginings, that provide polymorphic multimethods over structural types.

I mean the non-parametric type of polymorphism where methods may have > 1 implementation. The dispatch mechanism would choose the most specific of those available for a given invocation.

I have found one mention of something that seems in this area, but I don't understand the paper enough to know if it's what I hope for:

Combining Structural Subtyping and External Dispatch
Donna Malayeri & Jonathan Aldrich

I'm not _even_ a language design noob, and have only recently found there is established terminology ("structural types") for what I've been edging towards for about 10 years.

But… I envisage that the dispatch mechanism would be able to examine implementations of a method for the signature they require of their arguments. Given a method invocation is would be able to find the most specific implementation given the types, or fail if there is no match or the match is ambiguous.

I also think that a kind of transitive closure is necessary here. I'll use an example to elucidate (the example is "single dispatch", btw):

 def area(shape) # implementation 1. return width(shape) * height(shape) end

 def area(shape) # implementation 2 return 2 * pi * radius(shape)^2 end def width(shape) return square_size(shape) end 

 def height(shape) return square_size(shape) end 

I can now evaluate:
 area( {width: 2, height: 3} ) -> 6 # This is just as you would suspect – implementations 1 is used.

 area( {radius: 1} ) -> 6.28318 # here implementation 2 is used. 

 area( {square_size: 2} ) -> 4 # here, the record itself doesn't directly fit implementation 1, but because of the "width" and "height" methods, it _can_ be used, so 1 is used. This is the kind of transitive closure. 

Implementations's parameters are not decorated with explicit type declarations because the type an implementation needs for each of its arguments _are_ the methods it calls on those arguments.

So, if this kind of thing is going on all over the place and well known, I'd love to know. Or if it's been tried and found a terrible idea, that'd be good to know too :-) I find the possibility enormously exciting because I think it'd "fix" an awful lot of what I find rather hobbling about the languages I generally use. Especially if it could be embedded in some kind of live-coding environment.

Thanks,
Benjohn Barnes

## bodyf*ck: an esoteric programming environment using camera input

A product of critical programming language design. Abstract:

bodyf*ck is a computer programming environment that translates bodily movement into computer programs. Each physical motion committed by the programmer/performer becomes an operation in the esoteric programming language brainf*ck. Theoretically, because bodyf*ck is Turing-complete, all computable operations are possible. Despite this, physical difficulty in implementing more complicated programs may prove to concede the theoretical limitations of the potentially computed output.

Expletives stared out because I'm a coward.