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 04:55:05 -0400 Organization: Aioe.org NNTP Server Lines: 72 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:29717 On Sat, 19 Apr 2014 03:59:43 -0400, Andrew Haley wrote: > Rod Pemberton wrote: >> On Fri, 18 Apr 2014 09:46:48 -0400, wrote: >>> - 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. > > OK, I'll bite. Why do you believe that? Do you think that a bytecode > Forth would be limited to 256 words? A byte by definition is exactly 8-bits. Bytecode uses only one byte to represent all instructions. With a 1:1 mapping of instructions to integer values, how can you have more than 256 words using only 8-bits per instruction? http://en.wikipedia.org/wiki/Pigeonhole_principle > And if you do believe that, why do you not believe that a bytecode > Java would not be similarly limited to 256 methods? The Java Virtual Machine, the last time I checked which admittedly was a few years ago, had exactly 206 bytecodes. >>> - 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". > > This is nonsense. There is no incompatibility between MIT and GPL > licences. No, it's not. The GPL has more restrictive terms. Mixing of licenses, i.e., applying more than one license to one piece of code results in "license pollution". There used to be a page on this on Wikipedia. I can't seem to locate it currently. Basically, it recommended releasing code changes for an individual file/block of code under the original license so that multiple licenses wouldn't be applied accidentally to the same code file/block. Open source licenses are not necessarily 100% compatible with each other. Each has terms which limits combinations with the others. See here: http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses >> 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. > > And the legal opinion on which ths is based is what, exactly? I have > certainly never heard it before. How can you apply a copyright to a work which cannot be copyrighted? If you make a change to a Public Domain work (no copyright), and require that your change be GPL'd without specifying which code is yours and which isn't, as is typical for GPL slap-on, viral-ware licensing, then you've done exactly that. You've claimed copyright to code which isn't yours and can't be copyrighted. Fortunately for open-source software, no one is going to file a court case if Public Domain code turns up with copyright claims. Rod Pemberton