So now all I'd like in Erlang is...

[Tony Rogvall]

On Tuesday, Feb 17, 2004, at 20:43 Europe/Stockholm, Joe Armstrong 
wrote:

> On Tue, 17 Feb 2004, James Hague wrote:
>
>> Joe Armstrong wrote:
>>
>>> So now all I'd like in Erlang is:
>>>
>>> 1) Higher order code
>>
>> Could you elaborate?
>
> First order code is code that I can manipulate as regular data.
>
> I'd really like a do thinks like this ...
>
> 	% define a module
> 	Mod = {{export,[{foo,2},{bar,1}....]},
> 	       {code, [{foo,2,fun(X,Y) -> ...end},
> 		       {bar,1,fun(X) -> ... end}]}},
> 	% compile it
> 	Code = compile(Mod),
> 	% call code without "publishing it"
> 	Code:foo(1,2)
> 	% publish it
> 	publish(Code, bar),
> 	% now you can use it
> 	bar:foo(1,2), ...
> 	% modify it
> 	Code1 = replace_fun(Code, foo,2,fun(X,Y) -> ... end)
> 	% test it
> 	Code1:foo(1,2)
> 	% publish
> 	publish(Code, bar)
> 	% ...
> 	% get the code back
> 	Code2 = getCode(bar)
> 	...
>
> 	GC should sweep away unreachable code
>
> 	There should be multiple versions of old code (not just two)
>
I have implemented this once, in the (in)famous Multi Pro Erlang.
It worked like a charm.
I also thought a bit of adding functionality to upgrade code in generic 
servers by using
"unpublished" code.
The implementation overloaded register and unregister instead of 
publish/unpublish, it used a new
dynamic type "Module" to distinguish the cases. Of course the Module 
had a external representation
as any Erlang Term so loading code and register looked like.

	{ok, Bin} = file:read_file("mymod.beam"),
          Mod = binary_to_term(Bin),
          register(mymod, Mod).

In a multipro environment the register part was a bit tricky but we (me 
and Pekka H) think we
solve it.

.......

>
>   I am current playing with the idea that one should "write as much in
> Erlang as  possible and  write as  little C as  possible" and  also if
> possible write  a program  to write  the C rather  than writing  the C
> myself.
>
>   I am experimenting with a code generator, you give it rules like 
> this:
>
> 	{{pushAtom, a}, {opCode, i}, "*Code++ = &&Opcode;
> 		      		      *Code++ = *codeBuff++;"
> 		
>          "*Stop++ = *PC++;"}
>
>   This means there is an instruction pushAtom with argument an Atom to
> serialize it generate an opcode followed by an integer. To deserialise
> it and make it into threaded code evaluate *Code++=...  and to execute
> execute do "*Stop++ = ..." etc.
>
>   My code generator splits out chucks  of C and Erlang which get glued
> together to make the back-end  of the assembler and the input routines
> for deserialising the data and the inner loop of the the emulator.
>
>   It is my  hope that even tricky  things like GC can be  written in a
> combination of C and Erlang.  I can imagine Erlang (say) administering
> the GC sweeps and making policy  decisions about when to do GC etc and
> just write a single process  stack/heap collector that is triggered by
> the Erlang process.
>
>   Writing C is like performing open brain surgery - it seems easier to
> write programs which write C rather  than writing it myself - that way
> you  only have  to get  the code  generator right  *once*  rather than
> getting every single C program right.
>
(CRAZY IDEA SECTION)
Ok what about Forth, the forth has the tiny interpreter (talking about 
a few bytes). I have had a project
that has been in my mind for years. That  is to rewrite the erlang 
runtime system in forth
(yes I have written a forth system capable of such a task).
Then let the erlang compiler generate forth (in some nice loadable 
format).
When loading such a module a range of transforms (even jit assembler 
stuff is available)
(I do however think that this require an even bigger brain surgery than 
writing C code :-)

Forth is truly mind boggling

/Tony