Higher order receieve anybody

[Shawn Pearce]

Joe Armstrong <joe@REDACTED> wrote:
> 1) Higher order code

Then we'd have LISP.  :-)

> 2) *Proper* structs

Ah, yes, this debate.  When will they be ready?  :-)

> 3) !!

Timeouts are a concern.  Perhaps the timeout can be set as a
process flag: process_flag(default_rpc_timeout, Ms).  With the timeout
throwing an exit:  exit({rpctimeout, To, Message}).  This is really just
a parse transform:

	begin
		Tag = make_ref(),
		To ! {rpc, Tag, Message},
		receive
		{reply, Tag, Response} ->
			Response;
		after process_flag(default_rpc_timeout) ->
			exit({rpctimeout, To, Message})
		end
	end

We just need the process flag.  :-)

But, if !! ever comes into Erlang/OTP, it better work with the gen_server
call format.  :)

> 4) Higher order receive

Well, a better receive over all that does everything we're all wishing
receive could do would be great.  Especially if I could write:

	receive
	{java, WorkingProgram} ->
		{no_more_work_for_shawn, WorkingProgram}
	end

and quit my day job.  :-)

> 5) A *tiny* implementation (written 99% in Erlang and 1% in
> ANSI standard C)

Ever since I was introduced to Erlang right after the initial open
source release, I've thought about doing this for fun.  Squeak (the
Smalltalk created by Disney I believe) is built like this.  Most of
the Squeak runtime is actually Smalltalk code compiled with a simple
compiler.  Only some of the language and its features is supported
when the low level parts of the runtime get built, but I've heard that
even the GC in Squeak is written in Smalltalk.

I've often thought over the years that an Erlang runtime could be
built by creating a primitive Erlang language that was a subset of
most of the language, with perhaps destructive updates allowed against
binaries (and only binaries).  This would let you map the memory of
your host into the runtime, then write the entire GC, tuple BIFs, etc
in Erlang code.  When that turns into native machine code, it should
come out close to what the hand written C would have been.  Clearly
destructive updates would be limited to only a very small segment of
code, and would be disallowed by the real code loader used at runtime,
to prevent users from trying to use the really low level feature.

A few times I've theorized to myself that it may be possible to do this
in pure Erlang, without destructive update, so long as a copying
garbage collector is used to manage the heap.  One implementation might
be to model each half-heap as a binary.  Allocation is performed by
splitting the half-heap binary in two parts, with the A part being the
space used by the new cons cell, tuple, binary, etc. and the B part
being the remaining free space, which is now just a slightly smaller
binary.  The problem is, how do you update the A part and fill in the
tuple's data, or the cons cell data, etc. initially in a single
assignment, non-desctructive language.  :)

I've just never gotten to this project, I've always had something else
that was distracting me.  I wish I had, because I'm getting into
Erlang more, and wondering why I didn't try to do this several years
ago instead of screwing around with Java.

-- 
Shawn.

  share, n.:
  	To give in, endure humiliation.