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

[Joe Armstrong]

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)

> 
> >2) *Proper* structs
> 
> Has any progress been made toward this one?  At least some internal
> political discussion at Ericsson? :)
> 
> >3) !!
> >4) Higher order receive
> >5) A *tiny* implementation (written 99% in Erlang and 1% in ANSI standard
> C)
> 
> How tiny do you want to go?
> 
  Without any space allocated for processes I'd like the run-time down to
less than a 500KB - a decent app should be less than 1 Meg.

> If nothing else, I'd like to see most of the BEAM opcode combination stuff
> in beam_load.c be rolled into the compiler.  This would be a big win in
> terms of reducing complexity.

  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.

  /Joe


  > > James >