View source for Forth for the Mill and/or Forth-like variants, better suited to the Mill

An interpretetd language and interpreter would provide an another way to get software running on the Mill 
(versus the LLVM compiler port that is in process, but not yet ready as of this writing, 03Jan2015.)  This idea was first proposed in the forums [[http://millcomputing.com/topic/simulation/#post-1548]].  Mill architect Ivan Godard has expressed some interest (in the forum discussion linked above), but keep in mind that this is not an official Millcomputing effort.  

Why would one want an interpreter instead of the compiled languages (C, C++ and ??) that LLVM will support?

* '''Timing''' (Namely, I hate to wait!)  The LLVM port won't be ready for some time,  but the genAsm language [[http://millcomputing.com/wiki/GenAsm_(language)]] and assembler are getting close to alpha/beta/possibly-usable-under-NDA status.

* '''Simplicity.'''  Some interpreters, especially threaded/stack-based interpreters like Forth (see [http://en.wikipedia.org/wiki/Forth_%28programming_language%29]) are simple enough to be feasible assembly-language projects.  So an interpreter could be written for the Mill using either Mill concrete assembler or Mill genAsm.  Ivan strongly recommends genAsm over conAsm.

* '''Size.'''  An interpreter can run in a small (think kilobytes) amount of memory, and is thus likely to run on Mill simulator well enough to be usable, instead of frustrating.

* '''Hands-on Mill experience.'''  Although watching the presentations and reading the discussions is interesting, I think there's no substitute for programming itself.  I see this project as a means to learn more about the Mill CPU and the associated infrastructure and toolchain.  IMHO, it's also possible that, as early non-insider users, we will uncover rough spots/opportunities to improve the tool-chain or potentially expose architectural aspects that the Millcomputing team might choose to change/improve.


'''Why Forth? (Why not Lisp, Tcl, Python or some other interpreted language?)''' 

{LarryP's opinion) 
Forth is small, simple, powerful -- and I have experience how Forth works inside.  I've heard that Lisp  interpreters can be "relatively" simple, but I know very little Lisp, and have never looked into how Lisp interpreters work.  So I'm not the right guy to drive the requirements/design phase of a Mill-lisp effort.  (And please; friends don't let friends code in BASIC!)  
/{LarryP's opinion)

Gentle wiki readers, feel free to add your opinions here!


'''What is Forth?'''  I'd describe it like so:  

Picture an H-P/RPN calculator (one with an enter key, instead of an equals key) that has keys for doing most things you'd ike to do -- including adding new keys!  Here's the start of a short cartoon series on RPN [http://ars.userfriendly.org/cartoons/?id=19990826] that may give you a feel for it.  (Imagine a programming language that works the way Yoda talks.)  

----

'''Contributors, feel free to identify yourselves here.'''

LarryP (also reachable at ursine at G00gle's free email service)  

----

'''Please put links about Forth, per se here.'''

'''A Beginner's Guide to Forth''' by J.V. Noble [http://galileo.phys.virginia.edu/classes/551.jvn.fall01/primer.htm] is IMHO a good place to start, because it gives both a Forth tutorial as well as an overview of how Forth is structured and works.  

An early edition of Leo Brodie's book, _Thinking Forth_ is available for free (and creative commons licensed) download at: [http://sourceforge.net/projects/thinking-forth/files/reprint/rel-1.0/thinking-forth-color.pdf/download?use_mirror=softlayer-dal&r=http%3A%2F%2Fthinking-forth.sourceforge.net%2F&use_mirror=softlayer-dal]

The GNU Project's Gforth: [https://www.gnu.org/software/gforth/]

'''Updating the Forth Virtual Machine''' by Stephen Pelc outlines the classic Forth VM and proposes an alternative VM: 
[http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/pelc.pdf]
----

{LarryP, 03Jan2015} '''My current thoughts on how to proceed:''' 
I think the best initial strategy is to design a minimal version of Forth, assuming that we'll soon be able to use parts of Millcomputing's tool-chain (genAsm, specializer and simulator) for development, test and demonstration.  It sounds like an NDA will probably be required for early access to the partial tool-chain.  

Even a fairly basic (if you'll pardon a pun on another well-known interpreter), minimally-functional Forth interpreter, running on a simulated Mill CPU, would be no small feat.  A successful port might well be the largest scale test of the partial Mill toolchain and simulator(s) until either the LLVM compiler port can generate Mill code or Millcomputing develops something bigger and better (and hopefully discloses it!)

Once we have a working Forth implementation, we could go a number of ways: 

* Port the rest of standard/ANSI Forth, implementing the rest in our minimal Forth. 

* Experiment with interpreter designs, to see what's the most efficient way to make Forth run on the Mill. 

* Make more informed decisions on what features and characteristics ought to go into a Mill-optimized interpreted language.


[[Preliminary Design for Mill-Forth]]

----

'''Please put links to Forth-like, but non-Forth languages here.'''

FIRST & THIRD almost FORTH (author regrettably unknown) [http://www.ioccc.org/1992/buzzard.2.design] 
This is a minimal and portable design, and the included source is impressively short. 
----

'''Please discuss non-Forth-ish ideas (extensions/variants) here''' (or create and link sub-pages instead.)

'''Type safety/type versatility:''' 
One issue with Forth is that one cannot tell the intended type of any datum on the Forth stack, simply by examining the datum itself.  So, the user/programmer has to keep track of the intended types of everything on the data stack.  This can make Forth code harder to debug and much harder for would-be-collaborators to work together efficiently.  A related issue is "size tyranny."  In the Forths I've seen, all (scalar) operands on the data stack must be of the same size -- and that size must be large enough to hold an address   on the target machine (or at least an index to anywhere in the dictionary.)  IMHO, on the Mill, we'd like to be able to work with operands of all the types and sizes that the Mill supports.  Similarly, I'd like, if not perfect type safety, at least some support/tools to find type errors. 

'''Memory Management beyond Forth's linear, non-garbage-collected dictionary:''' 
Except for the data stack, all Forth memory allocation is via Forth's dictionary, one big, contiguous buffer with no garbage collection.  Code (executable words) and user variables all co-exist in Forth's dictionary, without anything to distinguish which is which except program context. 

'''Namespaces:'''  
The Forth implementations I've seen have a single, flat namespace.  This is another issue for writing large Forth programs. 

'''Security/protection:''' 
The Forth implementations I've used basically have no security whatsoever, except for those that run in a "sandboxed" environment.  Even in those Forths, any security or protection come from the sandboxing, rather than from Forth itself.  I like Forth, but it permits (and in some ways even encourages) a degree of changing '''everything''' that I've rarely seen (outside of stories about Lisp.)  As an example, take the Forth colon  ":" word; it's normally used to define a new word.  However, the way colon and the Forth dictionary (specifically the default search order) normally work, colon also functions to redefine any existing operator, including itself, at any point during execution.  This is incredible power and flexibility, but it can also bring in all the problems of "monkey patching."  Offhand, I don't see a graceful way to add security and protection to the Forth language, without creating something that's so different it's no longer really Forth in spirit.  Perhaps externally imposing the Mill's security model, via the turf and permissions given to the interpreter will be sufficient.  

----