[HN Gopher] Temporal Programming, a new name for an old paradigm
___________________________________________________________________
Temporal Programming, a new name for an old paradigm
Author : beefman
Score : 65 points
Date : 2022-11-27 19:46 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mrkeen wrote:
| > Temporal programs, as I am attempting to define them, are of
| the form x' = f(x) - a recurrence relation.
|
| Functions.
|
| > x = x + 1 would not be valid, while x' = x + 1 would be.
|
| Yep. void tick() { a@ = b + 1;
| b@ = a + 1; }
|
| Void, oh no!
| a1369209993 wrote:
| > Void, oh no!
|
| void is the unit type, not the uninhabited type. (I'm really
| not sure what Haskell was smoking when it messed that[0] up,
| but it's probably too late to fix now.)
|
| 0: Calling it Data.Void rather than something like
| Data.Noreturn or whatever.
| louthy wrote:
| Void is the uninhabited type, Unit is the singleton type.
| Void != Unit
| blowski wrote:
| Facinating how this sounds - to different people - like event
| sourcing, functional programming and "software transaction
| memory".
|
| Are people interpreting using their own experience, or is there a
| big overlap?
| 314 wrote:
| Some other names that I've encountered for these kinds of
| programming constructs:
|
| * simulation variables (presumably because the separation into
| x/x' is similar to the now/next calculation of state in a lot of
| simulations).
|
| * SSA (although there is a subtle difference as x' becoming x in
| the next period isn't really SSA without some extra edges in the
| graph).
|
| I wonder how phi nodes would fit into the author's scheme?
| pubby wrote:
| This sounds a lot like software transactional memory (STM)
| combined with static single assignment form (SSA).
|
| The idea behind STM is to specify some block of code as being one
| big fat atomic operation, and then the runtime will magically
| make it so. The idea behind SSA form is to only assign variables
| once, as doing so makes imperative optimization as easy as
| functional.
|
| I wonder if the author knows about these things, or if they're
| coming in at a different angle.
| parentheses wrote:
| The proposal here seems to make the idea of STM more natural by
| creating a language that keeps to that core concept.
| mjburgess wrote:
| As far as I can see this is just pure functional programming.
|
| The IO type in haskell is defined, newtype IO a
| = IO (State# RealWorld -> (# State# RealWorld, a #))
| dustingetz wrote:
| i think the cycle needs to be looped, see MonadFix and
| ArrowLoop, also recursive do extension. which is all connected
| with FRP
| charlieflowers wrote:
| Overlaps with functional reactive programming
| togaen wrote:
| Property 2 implies immutable state. I also used to think that was
| a great idea. Then I tried actually programming that way.
| AlchemistCamp wrote:
| I've done most my programming in the past several years in
| Elixir, where mutable variables aren't an option, and it's been
| a great dev experience. An entire class of bugs disappears and
| it makes concurrency very easy to reason about.
| meindnoch wrote:
| In game programming this is called "double-buffered state":
| https://gameprogrammingpatterns.com/double-buffer.html
| muhaaa wrote:
| You want to try temporal programming? Try clojure: immutable
| values, immutable & persistent data structures, software
| transactional memory.
|
| You need a data base with full history (transaction time), try
| datomic. Additionally if you need full history AND domain time
| (bi-temporal) included in your data base, try or xtdb.
| mpweiher wrote:
| Sounds a lot like Lucid?
| lalwanivikas wrote:
| Hmmm I got confused by the name. I thought it's related to
| https://temporal.io/
| gijoeyguerra wrote:
| Looks and sounds like event sourcing.
___________________________________________________________________
(page generated 2022-11-27 23:00 UTC)