LtU Forum

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
Programming Languages to be published by ALA/Neal-Schuman Publishing.

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
Ron Brown and Beth Thomsett-Scott

Avoiding Actor Deadlocks--JActor

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.

Any ideas? Or am I thinking about this the wrong way entirely?

Multimethods over structural types


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)

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

def width(shape)
return square_size(shape)

def height(shape)
return square_size(shape)

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.

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.

Julia has no dependent types

sorry if this has already been posted; i don't read here much and ltu was mentioned in the link above (but i can't find anything).

i want to ask some questions about my limited, practical, non-theoretical understanding of dependent types:

it seems to me that in julia i can define a datatype (something like a struct in c), that has an associated parametric type that contains information about the data. so, for example, i could put the length of an array in there. and then, as long as any code that constructs or modifies an instance of that datatype follows the contract implicit in the associated parametric type, the code will work correctly and i can dispatch on array length.

now, it seems to me that this differs from how i expected dependent types to work, in that there is no inspection of the actual data value on dispatch. when i dispatch on the array length i am using information in the parametric type associated with my datatype that i trust is correct. but there is, at the moment of dispatch on that type, no inspection. length(array) is not called.

so the correctness of my code depends on the correctness of functions that construct and modify the datatype, rather than on functions that inspect it.

so my questions are:

1 - do other dependent type systems inspect the data?

2 - is this just an implementation detail, or is it connected with what was argued about in the link?

3 - please can someone explain the link like i am five? if the above is not connected with the argument, then i don't get it... in particular, julia often (usually?) compiles code specific to particular types. it doesn't do type unification (HM), afaik, but it does propagate types from annotations, and all concrete types are final (leaf), so the compiled code is "static" in some sense.


[edit: i don't know in detail how julia works, but my impression is that although it's called a "jit" it's basically a static compiler that is triggered only when dispatch on a new combination of function and types is encountered. wherever possible it extrapolates type information to compile static code with fixed types. this is why it is fast.]

Limitations of FRP?

I'm doing some research on programming paradigms that deal with time, like functional reactive programming, and I was wondering if anyone has explored how far one can go with FRP? From my own personal experience when doing Superglue (an OO reactive PL based on FRP-like signals), I had to abandon FRP when working on incremental compilation and language-aware editing: although FRP should be suitable for this problem (lots of consistency to maintain between code, AST, type system, and UI), it turned out that the problem required adding things to collections in distributed locations (e.g. in parse tree computations), whereas FRP seems to require everything for some state to specified centrally.

The best source I can find for pushing FRP for more complex programming domains is Antony Courtney's thesis. This still seems to be where things are at.

The last time we discussed this topic was in 2007. Are there any new developments in FRP expressiveness?

The Evolution of CS Papers

A blog post by Crista Lopes discussing the evolution of CS papers away from positions into the realm of science; excerpt:

Note this (Dijkstra's GOTO considered harmful) was not a letter to the editor, it was a full-blown technical, peer-reviewed paper published in a Mathematical journal. Seen in the light of current-day peer reviewing practices in CS, even considering the fact that the paper was proposing a clear solution for a clear problem, this paper would likely be shot down. First, the problem for which the solution was proposed was clear but not well motivated: how important was it for programs [of the time] to call routines recursively? — maybe it wasn’t important at all! If it was important, what were other people doing about it? Any paper with only 1 reference in the bibliography goes immediately to the reject pile. Second, given that the concept had already been proposed (in writing) by H. Waldburger, the author of this paper would at least be requested to express his ideas in terms of how they were different from those described in H. Waldburger’s paper rather than spending most of the paper describing how to do procedure calls using stacks. Finally, the work is borderline an “engineering issue” rather than a scientific one.

These are complaints often seen in today’s CS peer reviews.

XML feed