BIKE LANE LANG

ok, so idea for interesting PL semantics.

concept: “lanes”

most programming languages are 1 laned in that they follow computation linearly. do this, then this, wait for this async to finish, do this, etc.

some programming languages have semantics for operating on 2 lanes. for instance a promise chain in JS operates in 2 lanes. you follow the then path until and error then you are shunted into the catch path. In fact, catch is a specialized railroad switch for shunting the results of lane 2 back to lane 1. what’s even worse, track shifts are necessarily written vertically b/c editors don’t handle writing different code horizontally.

anyway, here’s some syntax examples of what I’m thinking about.

So you’d write a bunch of functions (that cannot directly manage control flow) and you’d have a second syntax that describes the control flow, maybe something like:

func_a_lane1
func_b_lane1 | func_c_lane2
               func_d_lane2
func_e_lane1 |              | func_f_lane3
             | func_g_lane2

those are all functions in a pipeline which accept data from 1 lane and return data to 1 lane.

so func_a_lane1 accepts data from lane 1 and might return data to lane 3 which means it would pass result directly to func_f_lane3.

contrived example:

goodness_test(number) {
  if number == 4 return L1(number)
  if number < 0 return L2(number)
  else return L3(number)
}

this syntax is a superset of the famous Result aka Either type but is more agnostic. it might be overkill but also this isn’t really an explicit feature of any language I know so it might be unexpectedly useful.