Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #29701 > unrolled thread

Recommendation of a Forth to embed in C

Back to article view | Back to comp.lang.forth

Contents

  Recommendation of a Forth to embed in C cslarsen@gmail.com - 2014-04-18 06:46 -0700
    Re: Recommendation of a Forth to embed in C Pablo Hugo Reda <pabloreda@gmail.com> - 2014-04-18 07:13 -0700
    Re: Recommendation of a Forth to embed in C Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-18 16:41 +0200
    Re: Recommendation of a Forth to embed in C jacko <jackokring@gmail.com> - 2014-04-18 11:31 -0700
    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 03:08 -0400
      Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 02:59 -0500
        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 04:55 -0400
          Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:15 -0500
            Re: Recommendation of a Forth to embed in C Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-19 23:47 +0200
            Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 22:12 -0400
              Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 02:41 -0500
                Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-21 21:16 -0400
                  Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 18:37 -0700
                    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 02:48 -0400
                      Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 16:15 -0700
                        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 20:58 -0400
                          Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 23:36 -0700
                            Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-22 21:38 -1000
                              Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-23 06:14 -0700
                            Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 21:10 -0400
                              Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-24 23:09 -0700
                          Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-24 00:31 -0700
                            Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 20:17 -0400
                              Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 20:29 -0400
                  Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:07 -0500
                    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 07:54 -0400
                      Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-22 05:27 -0700
                      Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:37 -0500
                        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 21:18 -0400
                          Re: Recommendation of a Forth to embed in C Melzzzzz <mel@zzzzz.com> - 2014-04-23 07:26 +0200
                          Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-23 08:40 -0500
                      Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 21:52 -0400
                        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 00:18 -0400
                          Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 01:10 -0400
                            Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 01:28 -0400
                              Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 01:42 -0400
                                Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 02:56 -0400
                                  Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 03:09 -0400
                                    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 05:07 -0400
          Re: Recommendation of a Forth to embed in C jkn_gg@nicorp.f9.co.uk - 2014-04-20 14:02 -0700
            Re: Recommendation of a Forth to embed in C albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-21 01:27 +0000
              Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-21 14:19 -0400
                Re: Recommendation of a Forth to embed in C Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 20:35 +0200
                Re: Recommendation of a Forth to embed in C andraszsoter@gmail.com - 2014-04-21 11:54 -0700
                Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-21 20:25 -0400
                  Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 18:26 -0700
                    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 03:29 -0400
                      Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 16:19 -0700
                        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 20:23 -0400
                          Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 23:16 -0700
                            Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 01:43 -0400
                              Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:33 +0100
                                Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:02 -0400
                                  Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 01:27 -0700
                                    Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-27 22:56 -1000
                                    Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 05:42 -0400
                                      Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 04:24 -0700
                                        Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-28 13:43 +0100
                                          Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 08:06 -0400
                                            Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-29 19:22 +0100
                                              Re: Recommendation of a Forth to embed in C David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
                                        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:54 -0400
                                          Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-29 06:06 -0700
                                            Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-29 19:07 +0100
                              Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 04:17 -0700
                                Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 08:20 -0400
                                  Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-29 06:09 -0700
            Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothaver.cqm> - 2014-04-21 20:39 -0400
      Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-18 22:24 -1000
        Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 05:02 -0400
    Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-04-19 01:43 -0700
    Re: Recommendation of a Forth to embed in C andraszsoter@gmail.com - 2014-04-21 09:30 -0700
    Re: Recommendation of a Forth to embed in C "VisualForth.com" <babruehl@gmail.com> - 2014-05-25 15:31 -0700
      Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-05-25 16:54 -1000
        Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-05-25 22:29 -0700
        Re: Recommendation of a Forth to embed in C "VisualForth.com" <babruehl@gmail.com> - 2014-05-26 10:45 -0700
          Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-05-26 09:39 -1000
    Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-05-25 16:30 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#29701 — Recommendation of a Forth to embed in C

Hi,

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
- Able to embed as an execution engine in C or C++
- 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)
- Preferrably have a small memory footprint
- It must be open source

Bonus points if

- Its codebase is small and readable
- I'm able to control execution from C, e.g. select number of cycles to run before going back to C (this is to be able to halt Forth programs that loop endlessly)

This is for a thesis project on networking, so I think Forth would fit very nicely, even though I'm only going to run it in software.

About calling C functions: I'm going to extract data from ethernet or IP packets. I already have those in C, so what I'm thinking of is a way to have this Forth call into C and get data back on the stack.  I don't need or want a full FFI; I'm going to compile them in statically (for instance by modifying the Forth code).

I've been looking at gforth, but to me it looks to be a bit too big.  I've looked at pforth, but that didn't compile cleanly on my system so I got cold feet. Currently I'm looking into PFE and possibly 4th.

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.

Also I probably *don't* need a *fully* ANS compliant Forth. 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.

If anyone can give me pointers, I'd be very happy.

Regards,

Christian

[toc] | [next] | [standalone]

#29702

See my :r4
https://code.google.com/p/reda4/
the interpreter execute all the code but is simple to add n-step execution of bytecodes.

[toc] | [prev] | [next] | [standalone]

#29703

cslarsen@gmail.com wrote:

Ok, I'm with 4tH. I designed that one for just that purpose.

> - Able to produce Forth bytecode that can be transmitted over the network
> and executed there - Able to embed as an execution engine in C or C++
Check. You can make tiny images. E.g. even the entire proprocessor, the
editor or a spreadsheet program don't do more than about 3K - 4K bytecode.
You can also transfer the source and compile it in situ. 

> - 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) -
You have to modify the source, but again: it was designed to do that. You
can even program your extensions separately and reintegrate them with a
newer version of 4tH - automated.

> Preferrably have a small memory footprint - It must be open source
You can decide how big you want it. Just need to execute code? Just embed
the VM and the bytecode loader.

> Bonus points if
> - Its codebase is small and readable
I can't make it much smaller given the functionality. Readability is par to
none (not my words).

> - I'm able to control execution from C, e.g. select number of cycles to
> run before going back to C (this is to be able to halt Forth programs that
> loop endlessly)
You can do that if you take care. E.g. you could embed a "PAUSE" into a
bytecode program, so it transfers control back to the calling C program.
Want to continue? Continue where you left off. Want to stop? Just don't
give back control and kill the code. There is a multitasker to illustrate
just that point.

> I've been looking at gforth, but to me it looks to be a bit too big.  I've
> looked at pforth, but that didn't compile cleanly on my system so I got
> cold feet. Currently I'm looking into PFE and possibly 4th.
Ok, now you know.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#29711

Can't help at present, I'm deep in Free Pascal ... :D

[toc] | [prev] | [next] | [standalone]

#29713

On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#29714

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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.

OK, I'll bite.  Why do you believe that?  Do you think that a bytecode
Forth would be limited to 256 words?  And if you do believe that,
why do you not believe that a bytecode Java would not be similarly
limited to 256 methods?

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

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

Andrew.

[toc] | [prev] | [next] | [standalone]

#29717

On Sat, 19 Apr 2014 03:59:43 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#29722

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sat, 19 Apr 2014 03:59:43 -0400, Andrew Haley  
> <andrew29@littlepinkcloud.invalid> wrote:
>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>>> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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?

With prefixes, obviously.  Only the core words need to be mapped to
single bytes.  You can define as many Forth words as you like.

For an example of variable length prefix coding, look at UTF-8.

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

That is not the question that I asked.  Why do you not believe that a
bytecode Java would not be similarly limited to 256 methods?

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

What does "license pollution" even mean?  Of course the work would
have to be licenced under the GPL and MIT licences, and any user would
have to abide by both.

> Open source licenses are not necessarily 100% compatible with each
> other.

No, they are not necessarily, but there is no conflict between MIT and
GPL.  There are incompatible licences, but MIT and GPL are not
incompatible.

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

There is absolutely nothing to stop you from taking a work that is in
the public domain (a folk song, say) and releasing your own version
with your own copyright.  It happens all the time.  The original song
is not under copyright, your version is.  So it is with software.

Andrew.

[toc] | [prev] | [next] | [standalone]

#29723

Andrew Haley wrote:
> With prefixes, obviously.  Only the core words need to be mapped to
> single bytes.  You can define as many Forth words as you like.
> 
> For an example of variable length prefix coding, look at UTF-8.

Or protobuf, which is more compact and very close to what Elizabeth has 
described.  The other option you have for byte code is primitive centric.  
You would have a byte code for each primitive, and a call <address> 
primitive which calls a high level word.  You would be limited to 256 
primitives, which isn't too bad.  For a C-embedded Forth, you would also 
have a call-c <address> bytecode to interface with C (you always have to be 
able to call in both directions).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#29726

On Sat, 19 Apr 2014 17:15:27 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> On Sat, 19 Apr 2014 03:59:43 -0400, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>>>> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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?
>
> With prefixes, obviously.  Only the core words need to be mapped to
> single bytes.  You can define as many Forth words as you like.
>
> For an example of variable length prefix coding, look at UTF-8.
>

As stated to Ms. Rather, that's not bytecode.  It's VLIW with the old
meaning of VLIW: "variable-length instruction word".

>>> 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.
>
> That is not the question that I asked.

Of course, it's not.  You've presumed what I don't believe, and then
asked why I don't believe that.  Isn't that a "strawman"?
Set up fake/different argument.  Knock down.

> Why do you not believe that a bytecode Java would not be
> similarly limited to 256 methods?

I have no idea whether Java is or isn't limited to "256 methods", whatever
"methods" may mean here.  I tend to think of "methods" as something
object-oriented, like classes.  But, I'd assume that functions or  
procedures
could be built up from sequences of bytecodes, just like Forth.  I.e.,
if that's what you're discussing, then "methods" obviously aren't limiting.

>>> 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".
>
> What does "license pollution" even mean?

See the last half of the sentence of mine above, starting with "i.e.,".

> Of course the work would
> have to be licenced under the GPL and MIT licences, and any user would
> have to abide by both.

...

>> Open source licenses are not necessarily 100% compatible with each
>> other.
>
> No, they are not necessarily, but there is no conflict between MIT and
> GPL.  There are incompatible licences, but MIT and GPL are not
> incompatible.
>

You didn't even bother to read content at the link did you?

If you had, you'd know the two licenses you cited are not 100% compatible.
Although, they may be approved to work together by the FSF and the OSI.
The GPL doesn't allow changes to be released under a different license.
I.e., if the work falls under both licenses, most likely because
it's indeterminable as to which license applies to that portion of code,
i.e., license pollution, then the changes, if released as GPL'd, can't
also be released as MIT.  Therefore, legal problem.

According to that page, you also can't link with non-GPL, in which case,
you can't legally combine GPL and MIT code together in one file/block
and apply both licenses, which is done all the time in the FOSS community.

Also, the GPL has more restrictive terms.  You can't bind the MIT portion
to the more restrictive terms of the GPL portion.  That's simply not legal.
This basically reiterates what I said in the section above which you  
skipped.

>>>> 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?
>
> There is absolutely nothing to stop you from taking a work that is in
> the public domain (a folk song, say) and releasing your own version
> with your own copyright.  It happens all the time.  The original song
> is not under copyright, your version is.  So it is with software.
>

I believe you're mistaken here, or exaggerating/promoting concepts.  It
has to be sufficiently different to constitute a new work in it's own
right.  U.S. copyright laws don't allow trivial changes to a work to be
copyright.  Generally, they require 70% or more to be different.  This
is to prevent theft of the work.  E.g., IIRC, one of the original cases
regarded a work that simply added the letter 'A' to the end of every
sentence in a book.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29729

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sat, 19 Apr 2014 17:15:27 -0400, Andrew Haley  
> <andrew29@littlepinkcloud.invalid> wrote:
>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>>> On Sat, 19 Apr 2014 03:59:43 -0400, Andrew Haley
>>> <andrew29@littlepinkcloud.invalid> wrote:
>>>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>>>>> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> 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?
>>
>> With prefixes, obviously.  Only the core words need to be mapped to
>> single bytes.  You can define as many Forth words as you like.
>>
>> For an example of variable length prefix coding, look at UTF-8.
> 
> As stated to Ms. Rather, that's not bytecode.  It's VLIW with the old
> meaning of VLIW: "variable-length instruction word".

Well, according to you, then, Java bytecode is not bytecode because it
uses variable-length instructions; neither is Smalltalk bytecode, for
the same reason; and neither is Pascal P-code.  Happily, the industry
does not depend on you for its definitions.

>>> Open source licenses are not necessarily 100% compatible with each
>>> other.
>>
>> No, they are not necessarily, but there is no conflict between MIT and
>> GPL.  There are incompatible licences, but MIT and GPL are not
>> incompatible.
> 
> You didn't even bother to read content at the link did you?  If you
> had, you'd know the two licenses you cited are not 100% compatible.

The page that says they are compatible, you mean?  Or some other,
wrong, page?

> Although, they may be approved to work together by the FSF and the
> OSI. 

The FSF and the OSI are expressing the best legal opinion about the
compatibility of those licences.  They're not approving anything.  In
their opinion, MIT and GPL licences are compatible, and code under
thses licences may legally be combined and released.

> The GPL doesn't allow changes to be released under a different
> license.  I.e., if the work falls under both licenses, most likely
> because it's indeterminable as to which license applies to that
> portion of code, i.e., license pollution, then the changes, if
> released as GPL'd, can't also be released as MIT.  Therefore, legal
> problem.

In what sense is this a problem?  The combined work can't be released
under the MIT licence.

> According to that page, you also can't link with non-GPL,

That depends on the non-GPL licence.

> Also, the GPL has more restrictive terms.

Surely the GPL has *less* restrictive terms: it's impossible for
anyone to make GPL code unfree, or make it into a proprietary product.
So, anyone who receives GPL code is free to study it, to change it,
and so on.

> You can't bind the MIT portion to the more restrictive terms of the
> GPL portion.  That's simply not legal.  This basically reiterates
> what I said in the section above which you skipped.

Of course if you use an MIT-licenced work with GPL code that does not
affect the original MIT-licenced work.  Any work that is derived from
GPL code must be released under the GPL.  A combined work must be
released under the GPL.

>> There is absolutely nothing to stop you from taking a work that is
>> in the public domain (a folk song, say) and releasing your own
>> version with your own copyright.  It happens all the time.  The
>> original song is not under copyright, your version is.  So it is
>> with software.
> 
> I believe you're mistaken here, or exaggerating/promoting concepts.  It
> has to be sufficiently different to constitute a new work in it's own
> right.

Yes, of course: it can't be a trivial change.

Andrew.

[toc] | [prev] | [next] | [standalone]

#29758

On Sun, 20 Apr 2014 03:41:32 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>> Also, the GPL has more restrictive terms.
>
> Surely the GPL has *less* restrictive terms: it's impossible for
> anyone to make GPL code unfree, or make it into a proprietary product.
> So, anyone who receives GPL code is free to study it, to change it,
> and so on.
>

That's true only for someone who confuses/conflates "*less*" with "*more*".

NOT being able to do something with the code, which is what you've
stated, is more restrictive, not less.  You are not free, or "unfree",
according to what you just stated, to use the code commercially,
i.e., for a proprietary product.  With MIT and BSD licenses you
are free to do just that, and employ programmers in the process.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29760

on 21/04/2014 18:16:16, "Rod Pemberton" wrote:
> On Sun, 20 Apr 2014 03:41:32 -0400, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> 
>>> Also, the GPL has more restrictive terms.
>>
>> Surely the GPL has *less* restrictive terms: it's impossible for
>> anyone to make GPL code unfree, or make it into a proprietary product.
>> So, anyone who receives GPL code is free to study it, to change it,
>> and so on.
>>
> 
> That's true only for someone who confuses/conflates "*less*" with
> "*more*".
> 
> NOT being able to do something with the code, which is what you've
> stated, is more restrictive, not less. You are not free, or "unfree",
> according to what you just stated, to use the code commercially, i.e.,
> for a proprietary product. With MIT and BSD licenses you are free to
> do just that, and employ programmers in the process.

Companies can use GPL code commercially on proprietary products. You are
probably using a wireless router that is a proprietary product that cost
you money running on GPL code modified by programmers employed by the
company that you bought it from. The only requirement is that the company
make the source code available for free.

> 
> 
> Rod Pemberton
> 

[toc] | [prev] | [next] | [standalone]

#29762

On Mon, 21 Apr 2014 21:37:27 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 21/04/2014 18:16:16, "Rod Pemberton" wrote:
>> On Sun, 20 Apr 2014 03:41:32 -0400, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>>>> Also, the GPL has more restrictive terms.
>>>
>>> Surely the GPL has *less* restrictive terms: it's impossible for
>>> anyone to make GPL code unfree, or make it into a proprietary product.
>>> So, anyone who receives GPL code is free to study it, to change it,
>>> and so on.
>>
>> That's true only for someone who confuses/conflates "*less*" with
>> "*more*".
>>
>> NOT being able to do something with the code, which is what you've
>> stated, is more restrictive, not less. You are not free, or "unfree",
>> according to what you just stated, to use the code commercially, i.e.,
>> for a proprietary product. With MIT and BSD licenses you are free to
>> do just that, and employ programmers in the process.
>
> Companies can use GPL code commercially on proprietary products.

I know that.  But, that's NOT what Andrew stated.  That's why I
clarified by stating the following in reference to what Andrew
did say:

   "... according to what you just stated ..."

You really seem to have failure to comprehend issues.

> You are probably using a wireless router that is a proprietary
> product that cost you money running on GPL code modified by
> programmers employed by the company that you bought it from.

Perhaps.  If not this router, most likely one of the others.

> The only requirement is that the company make the source
> code available for free.

How often do they actually do that?

I.e., they frequently hide the fact they've done so in order
to prevent leakage of proprietary interfaces or code.

I know that I can't get source code from any of the
router manufacturers for my products, GPL or otherwise.
I can get free, binary firmware updates, while they
provide them.

Anyway, this is now way off the OP's topic now that you
two decided to respond.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29782

on 21/04/2014 23:48:28, "Rod Pemberton" wrote:
> On Mon, 21 Apr 2014 21:37:27 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>> on 21/04/2014 18:16:16, "Rod Pemberton" wrote:
> > wrote:
>>> On Sun, 20 Apr 2014 03:41:32 -0400, Andrew Haley
> > wrote:
>>> <andrew29@littlepinkcloud.invalid> wrote:
> > wrote:
>>>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> wrote:
> 
>>>>> Also, the GPL has more restrictive terms.
>>>>
>>>> Surely the GPL has *less* restrictive terms: it's impossible for
>>>> anyone to make GPL code unfree, or make it into a proprietary product.
>>>> So, anyone who receives GPL code is free to study it, to change it,
>>>> and so on.
>>>
>>> That's true only for someone who confuses/conflates "*less*" with
>>> "*more*".
>>>
>>> NOT being able to do something with the code, which is what you've
>>> stated, is more restrictive, not less. You are not free, or "unfree",
>>> according to what you just stated, to use the code commercially, i.e.,
>>> for a proprietary product. With MIT and BSD licenses you are free to
>>> do just that, and employ programmers in the process.
>>
>> Companies can use GPL code commercially on proprietary products.
> 
> I know that.  But, that's NOT what Andrew stated.  That's why I
> clarified by stating the following in reference to what Andrew
> did say:
> 
> "... according to what you just stated ..."
> 
> You really seem to have failure to comprehend issues.

I can comprehend just fine.  

> 
>> You are probably using a wireless router that is a proprietary
>> product that cost you money running on GPL code modified by
>> programmers employed by the company that you bought it from.
> 
> Perhaps.  If not this router, most likely one of the others.
> 
>> The only requirement is that the company make the source
>> code available for free.
> 
> How often do they actually do that?

If they don't, they are in breech of the GPL.
http://gpl-violations.org/about.html

> 
> I.e., they frequently hide the fact they've done so in order
> to prevent leakage of proprietary interfaces or code.

Who is "they"? While anecdotes are nice, unsourced assertions are just
annoying.

> 
> I know that I can't get source code from any of the
> router manufacturers for my products, GPL or otherwise.
> I can get free, binary firmware updates, while they
> provide them.

They are in breech of the GPL. Again, who are they? Name them, and they
can be reported.

You seem to have a confusion over what is legal (the domain of the GPL)
and breaking a legal agreement (the domain of the courts).

> 
> Anyway, this is now way off the OP's topic now that you
> two decided to respond.

It's usenet. Stuff like this happens.

> 
> 
> Rod Pemberton
> 

[toc] | [prev] | [next] | [standalone]

#29785

On Tue, 22 Apr 2014 19:15:13 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 21/04/2014 23:48:28, "Rod Pemberton" wrote:
>> On Mon, 21 Apr 2014 21:37:27 -0400, Alex McDonald <blog@rivadpm.com>

>>> The only requirement is that the company make the source
>>> code available for free.
>>
>> How often do they actually do that?
>
> If they don't, they are in breech of the GPL.
> http://gpl-violations.org/about.html
>

So?  That hasn't stopped breaches of the GPL by for-profit companies.
I.e., court cases costs lots of money, fines are trivial, etc.

>> I.e., they frequently hide the fact they've done so in order
>> to prevent leakage of proprietary interfaces or code.
>
> Who is "they"? While anecdotes are nice, unsourced assertions
> are just annoying.

People who fail to keep up on current events and repeatedly ask
for citations are annoying too...

There have been a half-dozen cases mentioned in major U.S. media over
the past few years of companies violating the GPL in their products.
I'm sure if you search a reputable computer news website or use Google
you can find them.

Of course, there is a website which monitors this:
http://www.gpl-violations.org/

Just dropping "gpl violation" into Google brings up mentions of:
Nvidia, D-Link, Boxee, Android, Microsoft, Linksys, Cisco, Samsung,
HTC, Apple, Skype, Linux, etc.

Yes, you read that correctly, well over 90% of Linux distro's are
in violation of the GPL too...

There seems to be a variety of issues at play:
-ports of GPL code to a closed source OS (Apple App store apps)
-static linking with non-GPL libraries (Microsoft)
-failure to release original source code (Linux distro's)
-failure to release source code modifications (routers)

> You seem to have a confusion over what is legal (the domain of the GPL)
> and breaking a legal agreement (the domain of the courts).

You're confused, or not aware of U.S. law.  No license or contract
defines what is legal.  That only defines what the parties have
agreed to, legal or not.  The courts define what is legal.  The
court may throw out any contract or license term or add any required
legal constraints.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29790

on 22/04/2014 17:57:59, "Rod Pemberton" wrote:
> On Tue, 22 Apr 2014 19:15:13 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>> on 21/04/2014 23:48:28, "Rod Pemberton" wrote:
> > wrote:
>>> On Mon, 21 Apr 2014 21:37:27 -0400, Alex McDonald <blog@rivadpm.com>
> wrote:
> 
>>>> The only requirement is that the company make the source
>>>> code available for free.
>>>
>>> How often do they actually do that?
>>
>> If they don't, they are in breech of the GPL.
>> http://gpl-violations.org/about.html
>>
> 
> So?  That hasn't stopped breaches of the GPL by for-profit companies.
> I.e., court cases costs lots of money, fines are trivial, etc.

My point still stands.

> 
>>> I.e., they frequently hide the fact they've done so in order
>>> to prevent leakage of proprietary interfaces or code.
>>
>> Who is "they"? While anecdotes are nice, unsourced assertions
>> are just annoying.
> 
> People who fail to keep up on current events and repeatedly ask
> for citations are annoying too...

It's helpful to have trusted sources of information. 

> 
> There have been a half-dozen cases mentioned in major U.S. media over
> the past few years of companies violating the GPL in their products.
> I'm sure if you search a reputable computer news website or use Google
> you can find them.
> 
> Of course, there is a website which monitors this:
> http://www.gpl-violations.org/
> 
> Just dropping "gpl violation" into Google brings up mentions of:
> Nvidia, D-Link, Boxee, Android, Microsoft, Linksys, Cisco, Samsung,
> HTC, Apple, Skype, Linux, etc.
> 
> Yes, you read that correctly, well over 90% of Linux distro's are
> in violation of the GPL too...
> 
> There seems to be a variety of issues at play:
> -ports of GPL code to a closed source OS (Apple App store apps)
> -static linking with non-GPL libraries (Microsoft)
> -failure to release original source code (Linux distro's)
> -failure to release source code modifications (routers)

While the google search you give turns up some interesting names, you
didn't answer the question. Please provide the name (the "they") in
"I.e., they frequently hide the fact they've done so *in order to prevent
leakage of proprietary interfaces or code.*" (my emphasis.) I think
you're just guessing that "they" do this because it seems the sort of
thing you think "they" might do. I can't find an example, and I'm asking
you to justify your statement.

> 
>> You seem to have a confusion over what is legal (the domain of the GPL)
>> and breaking a legal agreement (the domain of the courts).
> 
> You're confused, or not aware of U.S. law.  No license or contract
> defines what is legal.  That only defines what the parties have
> agreed to, legal or not.  The courts define what is legal.  The
> court may throw out any contract or license term or add any required
> legal constraints.
> 

The courts make the law in the US? 

> 
> Rod Pemberton
> 

[toc] | [prev] | [next] | [standalone]

#29792

On 4/22/14 8:36 PM, Alex McDonald wrote:
> on 22/04/2014 17:57:59, "Rod Pemberton" wrote:
...
>> You're confused, or not aware of U.S. law.  No license or contract
>> defines what is legal.  That only defines what the parties have
>> agreed to, legal or not.  The courts define what is legal.  The
>> court may throw out any contract or license term or add any required
>> legal constraints.
>>
>
> The courts make the law in the US?

It's complicated. Congress can pass laws, as can states and 
municipalities. But laws can be invalidated by courts as 
"unconstitutional". As far as contractual relationships are concerned, 
two parties can agree to most anything that doesn't violate a law passed 
by Congress etc., but if one party accuses the other of violating the 
agreement, or of violating a law, the court decides the issue. A 
contract that does not violate any law is a "legal contract". But if one 
party violates the contract, the other party must go to court, and the 
court will decide who wronged whom; no question of "legality" arises in 
that case.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#29795

on 23/04/2014 00:38:09, "Elizabeth D. Rather" wrote:
> On 4/22/14 8:36 PM, Alex McDonald wrote:
>> on 22/04/2014 17:57:59, "Rod Pemberton" wrote:
> ...
>>> You're confused, or not aware of U.S. law.  No license or contract
>>> defines what is legal.  That only defines what the parties have
>>> agreed to, legal or not.  The courts define what is legal.  The
>>> court may throw out any contract or license term or add any required
>>> legal constraints.
>>>
>>
>> The courts make the law in the US?
> 
> It's complicated. Congress can pass laws, as can states and
> municipalities. But laws can be invalidated by courts as
> "unconstitutional". As far as contractual relationships are concerned,
> two parties can agree to most anything that doesn't violate a law
> passed by Congress etc., but if one party accuses the other of
> violating the agreement, or of violating a law, the court decides the
> issue. A contract that does not violate any law is a "legal contract".
> But if one party violates the contract, the other party must go to
> court, and the court will decide who wronged whom; no question of
> "legality" arises in that case.

That's what I thought. 
 
> 
> Cheers,
> Elizabeth
> 

[toc] | [prev] | [next] | [standalone]

#29802

On Wed, 23 Apr 2014 02:36:39 -0400, Alex McDonald <blog@rivadpm.com> wrote:

> While the google search you give turns up some interesting names, you
> didn't answer the question.

I did answer the question.

As usual, you either didn't comprehend or accept it.

The "they" are the "cases mentioned in major U.S. media over the
past few years".  Was I supposed to catalog them for you, pre-emptively,
on the expectation that I would have this conversation with you
or someone like you? ...

> The courts make the law in the US?
>

The courts interpret the law, which includes enforcement of contracts.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web