Author Archives: dmbarbour

Modular Manipulation of the Link-Time Environment

Posted on 2013 April 16

I’m in the process of hammering out a concrete design for Awelon, and my design efforts have taken me to some interesting places. My current application model looks like this: An Awelon application consists of a set of anonymous modules. … Continue reading →

Posted in Language Design, Modularity, Open Systems Programming, Security, State | 3 Comments

Why Not FFI

Posted on 2013 April 16

FFI – foreign function interface – is a common way for new languages to integrate with existing systems. But FFI is problematic in many ways. FFI represents ambient authority (the ability to ‘import’ authority to ad-hoc resources without a specific … Continue reading →

Posted in Language Design, Modularity, Open Systems Programming, Security | 3 Comments

Declarative State Machines

Posted on 2013 March 27

Lately, I’ve been wondering what state-machines would look like if specified for declarative systems. Traditional state machines are specified to receive a stream of events as input. Each event may shift the machine into a new state. The transitions are … Continue reading →

Posted in Concurrency, Open Systems Programming, State | Leave a comment

Ad-Hoc External State Models

Posted on 2013 March 23

Encapsulation, Accessibility, Security One of the main reasons we encapsulate state is to gain more control over how it updates. For example, take your traditional, imperative, mutable state variables that respond to get and put actions. We might use one … Continue reading →

Posted in Concurrency, Language Design, Modularity, Open Systems Programming, Reactive Demand Programming, State, Types | 1 Comment

Progress Report: Loops and Restarts in Sirea

Posted on 2013 March 12

I’ve been working on Sirea quite a bit in the last few months, albeit making less progress than I had hoped. Mostly, I’ve been running in circles. In Reactive Demand Programming, all loops are indirect, via a shared external resource … Continue reading →

Posted in Modularity, Reactive Demand Programming, Stability | Leave a comment

Objects as Dependently Typed Functions

Posted on 2013 March 7

One issue I have with objects is that I cannot compose them like functions (i.e. `f . g . h`). The reason for this is the method-set associated with each object – it requires a lot of wiring to compose … Continue reading →

Posted in Language Design | Tagged , | Leave a comment

Anticipation in RDP Reduced

Posted on 2013 February 28

Some time ago, I described anticipation in RDP. In that article, I envisioned a behavior intially called `anticipate`, that I eventually shortened to `bpeek`. For discrete-varying signals, it might be specialized to `bpeekL`. — observe a specific distance into a … Continue reading →

Posted in Reactive Demand Programming, State | Leave a comment

Exponential Decay of History, Improved

Posted on 2013 January 24

In an earlier article, I described exponential decay of history as an alternative to ring buffers. In this article, I’ll provide a full recap and an improved design. Exponential decay of history is a pattern that competes with ring-buffers, least-recently-used … Continue reading →

Posted in Language Design | 5 Comments

Sirea RDP Progress Update: Demand Monitors are Working

Posted on 2013 January 14

My implementation of Reactive Demand Programming (RDP), Sirea, is gradually approaching a usable state. After vacation, I sat down and in just a couple programming sessions I got demand monitors into a working order. The implementation of demand monitors further … Continue reading →

Posted in Concurrency, Open Systems Programming, Reactive Demand Programming, State | 1 Comment

Stateless Sound

Posted on 2012 December 11

Most audio abstractions involve relative start and some finite bound (end time). That is, we might play(sound) starting at some given instant, and we expect the sound to continue playing until finished. The representation of sound may be stateless (e.g. … Continue reading →

Posted in Stability, State, UserInterface | Leave a comment