Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Recommendation of a Forth to embed in C Date: Sat, 19 Apr 2014 03:08:36 -0400 Organization: Aioe.org NNTP Server Lines: 114 Message-ID: References: <85ca46a5-03d8-41ad-ab7e-8e5c3b781e48@googlegroups.com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:29713 On Fri, 18 Apr 2014 09:46:48 -0400, wrote: > I was hoping I could get some recommendations on a Forth system that I > can embed in C. > > What I'm currently looking for is > > - Able to produce Forth bytecode that can be transmitted over the > network and executed there I'm not sure of any that can produce bytecode ... That would dramatically limit the number of definable Forth words or dictionary size, although Forths which use bytecode probably do exist. As for "can be transmitted over the network", did you mean that the Forth needs to do that, or that you intend to do that? ... I suspect there aren't as many Forths available with built in networking. Some do have it though. > - Able to embed as an execution engine in C or C++ This most likely means coded in C or C++. There are numerous Forths coded in C. There are many in the Usenet archives (circa 1980s, 1990s) for various newsgroups not just Forth related, many on the web-based Internet, many in the various Forth archives, and within many in MUD games. Even the Bitcoin client has a limited and specialized Forth interpreter built into it. > - Able to have Forth words call C functions (no need for a full-blown > FFI, if I can modify the source and translate the call to C, that'd be > fine) This is probably not generally available feature for Forth, unless it's coded in C/C++. Most Forths coded in C are switch() based. If the Forth is coded in C, then the C code can call C functions when executing Forth words. So, you'd just need to pass a name or bytecode over the network to the Forth interpreter, the interpreter then calls a low-level Forth word ("primitive") with that name/bytecode, that primitive executes whatever C code you want. You could pass and push C arguments that way too. > - Preferrably have a small memory footprint Eliminate the dictionary headers on the server side (execution side). That saves a little bit of space. Eliminate the outer/text interpreter. But, you still need two stacks, the compiled definitions, low-level words ("primitives"), and inner/address interpreter, etc. > - It must be open source Most Forths are without copyright, i.e., Public Domain, or copyright voluntarily surrendered. If you meant "open source" as in copyrighted and licensed, the typical meaning of "open source", then that's far less common. If you're combining the code with other copyrighted and licensed code, it's probably best to use similar/same license too, e.g., don't mix MIT with GPL, etc. This prevents a problem known as "license pollution". Also, you might want to avoid Public Domain in that case since technically it's not copyrighted and merging in copyrighted code could be a legal complication. > What I'd really like to avoid is rolling my own Forth. I've done that > before, but right now I need something that is robust. Bytecode (8-bits) limits you to 256 Forth words. Interpreted Forths need about 35 low-level words ("primitives"). So, that leaves you with 221 Forth words that you can define. Is that too limited for the dictionary? Even if 256 Forth words isn't too limited, why bother with Forth? ... You only want a measely 256 operations. You've already stated you're implementing code in C on the server side. So, why not implement a switch() statement in C to decode the bytecodes? Reiterating, most Forths coded in C are switch() based. A switch() in C can support far more than 256 labels too. With a switch(), the bytecodes can represent any function or operation which is codeable in C, not just simple Forth operations. > I'm only going to execute some simple IF statements and then > inspect return values to the C environment from the top of the stack. With just a few operations it's better to use a switch(), and setup a data stack as an array. If your work is that limited, you wouldn't need an interpreter and return stack. The switch and stack will suffice. Also, although some here claim that Forth is safe enough to put on the Internet. Be warned that interpreted Forth suffers from many of the same safety issues as C, such as unchecked pointers, stacked control-flow which is accessible by the user, unchecked buffer limits, ability to modify executable code, etc. Also, if you're still interested in the idea Forth, but you're willing to consider other interpreted languages, you might try another language, say BrainFuck. Yes, Brainfuck is too limited with only eight operations. *BUT* BF is easily extendable, and some enhanced varieties already exist. More importantly though, BF works against an array which is fixed in size, i.e., no unbounded pointers, no user access to interpreter control-flow, etc. Obviously though, it's simplicity may be a drawback, unless you can invest some time to enhance it, but a few more operations shouldn't take you long. This website covers many experimental languages: http://esolangs.org/ E.g., Brainfuck derivatives include pbrain (procedures), Toadskin (Forth style definitions), etc. These two show you what other standard languages look like: http://rosettacode.org http://www.99-bottles-of-beer.net/ Rod Pemberton