# Announcing convey

	   }	1"<  {"v
	{/+?  "+1  2|!}
	 >,^  }

Convey is a somewhat codegolf-y 2d esolang based on conveyor belts,
that will push values around in a factory.

Just browse https://λ.land/convey/ for an overview, with links to
an online interpreter and a manual. A repository will be published if
I get around to rewrite this whole thing. As I designed convey while
implementing it along the way, the code evolved into quite a mess that
supports several now disabled features. Here is a place for honorable
mentions.

# What worked and what not

## Rough design principles

	* 1-to-1 mapping of input characters to factory tiles.
	* The program's state should be as visible as possible.
	* Make compact programs possible.

## Variadic functions

One initial idea for convey was to support functions that behave based
on the number of in- and output ports. Like in J, where `x * y` is
multiplication and `* y` is signum, but with up to 4 variables:

	 v    ^    v    v    v    v   v
	>f<  <f>  >f<  >f<  <f>  >f  <f  etc.
	 ^    v

Turns out: while possible, it was quite confusing when belt direction
inference could not work out which function one meant if the program was
tightly packed.  And the added benefit of supporting multiple functions
for the same symbol was not really necessary. As it turns out ~50
functions is quite enough.

## Boxed values

`&` used to pack values into a box, i.e. an array, that would also
just behave like one value. Boxed values could then get unpacked by
`&.`. This opened the possibilities for functions that operate on arrays,
that would be otherwise more verbose for the current list representation:
indexing, rotating, sorting, 2d operations, ….

However: that meant more functions and straying away from the initial
view of seeing the values traverse the factory. So `&` just became a
stateful queue function.

## Sleepsort

`~` could have queued like `&`, but whenever a new value came in, every
sleeptimer would have been incremented by 1. That translated nicely into
sleepsort: if the values `4 2 3 7` would wait 4, 2, 3, and 7 ticks, they
would get returned in the correct order. But because values trickled in
one after the other, the sleep values must have been: `4 2 3 7 + 3 2 1 0`
– that is why every new value incremented the other values waiting time.

This was somewhat cool, but meant a complicated function with a very
specific domain: sorting. After I successfully implemented a somewhat
elegant sort without this feature, `~` got simplified again.

## Dot parsing

I tried parsing `f.` in the first step: modifying `f` internally to
`f.` and later replacing the `.` with a single undirected conveyor belt.
However, this turned out to make 'max of a list' quite complicated:

	    }
	{/+.?
	 >,>^

This would not work, as `?` would happily push values to the left,
even if no other value waited on the left side of `+.`. So `.` changed
function behavior after parsing. This was easy to implement, but limits
the modified function to have the same ports as the unmodified one.

## Port order

Another alternative to the strict order was making the main port on the
other side of the opposite port, i.e.

	  3      3             3
	2>->}  }<-<2  2>->}  2>->}
	                3
      
would all mean 2 - 3, because the main path was the straight one.
This felt intuitive most of the time, but whenever one wanted 3 - 2, some
verbose rerouting would have been needed. Also, corners, `@`, and `#`
still needed a port order, so that could have been only a special rule.
As I realized this also restricted things, this got immediately ditched.
F.e. you could not have

	{
	?;…
	?;…
	…

but always needed to loop back to get a straight line:


	{?;…
	v<
	>?;…
	 …