Erlang + Forth?!?

[Peter-Henry Mander]

Good Lord! I had forgotten that remarkable language!

I have never used it, but over 20 years ago I pondered buying a Jupiter ACE instead of a Sinclair Spectrum, but was beguiled by the spectrum "colour" capability. Young fool! (-:

Has anyone heard of or remember the Jupiter ACE, made by Jupiter Cantab? It was the only interesting competitor of the Sinclair ZX Spectrum in the 1980's, and it's native language was forth, not BASIC. It beat the pants off the competition in terms of pure speed.

Pete.


On Tue, 17 Feb 2004 22:55:09 +0100
Tony Rogvall <tony@REDACTED> wrote:

> 
> 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
> 


-- 
"The Tao of Programming
 flows far away 
 and returns 
 on the wind of morning."