Relative time futures seem really weird to me. It seems that they cannot be used as an interface to the real world, because the real world would behave differently depending on what time you observe it. You end up having to abandon caching (implementors everywhere cry tears of joy), and then you end up with some IO-action-like thing with no real semantics at all, because the value is different every time you use it.

Maybe all this just means the “foreign interface” still makes more sense with absolute time semantics, and at runtime you just start your relative-time program at some point on the real-world timeline.

Is this an area of relative time FRP you have thought much about?

]]>I think that you may find some interesting reading on a similar vein and with some curious twists in the book “Probability Theory, The Logic of Science” by E T Jaynes, specifically chapter 2. This derives the quantitative rules of probability theory from the ‘basic desiderata’ of ‘plausible reasoning’. What I find interesting is firstly another fine example of the approach you have applied here and from what I surmise quite widely elsewhere; the approach is the same and the particular steps are also similar although as the problem is more general the equations involved are more general functional equations, one being ‘The Associativity Equation’. But it is also interesting that the author took this approach, with some inspiration from G Polya, around 65 years ago and while active in applying computation to probability and statistics was certainly not of a theoretical computer science orientation.

]]>In a category with an initial object, AFAIK it’s standard to encode constants as morphisms from the initial object.

Sorry, of course I meant terminal object (1 or Unit).

]]>

-- Primitives Prim ∷ Prim (a → b) → (a ↣ b) Const ∷ Prim b → (a ↣ b)

I’m not happy with the similarity of Prim and Const. Perhaps there’s a simpler formulation.

Wouldn’t you want to model `Const b`

as a primitive `p`

of type `Unit → b`

, and then construct `Prim p`

of type `Unit ↣ b`

? In a category with an initial object, AFAIK it’s standard to encode constants as morphisms from the initial object.

The polymorphic `a`

in `Const`

result type seems especially unfortunate, since you can inadvertently pass whatever argument (you will likely still get some error, but probably not the best one).

I see you’re sharing `Prim`

with Haskell code, so those constants should also be encoded without the `Unit →`

part of the type in some places. Unfortunately I don’t see a perfect solution to that: it might be best to have a different type of primitives for CCCs, with a constructor for function primitives and one for constants which adds the `Unit →`

part, because that at least keeps the CCC language precisely matching its spec.

(Sorry for my bad quoting, I can’t find how to format comments properly, so I just tried out some Markdown dialect which kind-of-works).

]]>