So Gerry, I'd like to see PE as a suitable general-purpose (and commercial) programming front-end for Tachyon. What do you need?
What WE would need is:
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Plus time (I've got some to spare), a little money (I've got a little of that, too), and a lot of enthusiasm and perseverance. The usual stuff.
I get the idea. At least I think I do. But let's take an example. Your (well-written and humorous Tachyon FORTH manual) says I can turn on an LED with a statement like this...
4 HIGH
...and I can turn it off with this:
4 LOW
That's great. I can see novices easily coping with that, and experts doing that without even thinking. Then you go on to say that I can make my LED blink by defining a "word" like this:
: BLINKY 10 FOR 4 HIGH 100 ms 4 LOW 100 ms NEXT ;
And, having defined that word, all I have to say to make it happen it is:
BLINKY
Still great -- at least at the end. But the middle part is somewhat less than natural for both beginners and pros. Which, I presume, is where Plain English comes in. Here's how things would change. We would begin with two low-level routines something like these, already coded up and waiting for our users in our library of useful routines:
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
To turn off a pin;
To turn a pin off:
Tachyon LOW .
Note that two different "calling patterns" are defined for each routine. Note also that I'm assuming the compiler has already pushed "the pin" onto the parameter stack, and that everything following the word "Tachyon" would simply be handed to the Tachyon FORTH interpreter. Or something like that, only more efficient; I'm just trying to describe the general idea. We'd also have some kind of low-level WAIT routine in the same library of useful routines.
And now, the payoff. Instead of thinking at this level...
: BLINKY 10 FOR 4 HIGH 100 ms 4 LOW 100 ms NEXT ;
...our programmer would think more like he normally does:
To blink an LED:
Turn on the LED. Wait for 1/10 second.
Turn the LED off. Wait for 1/10 second.
Add 1 to a count. If the count is less than 10, repeat.
And after adding that to his own library of useful routines he could say things like:
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
Am I in the ballpark? If so, I'll reiterate. What WE need is:
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
Tachyon gets things done but it's not everyone's cup of tea. Since Tachyon get things done already then PE will allow anybody to tell it in Plain English WHAT they want done. Result? Big audience!
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
I mainly use Linux which means it's not a problem to run Windows This can be done in VirtualBox or perhaps via WIne if it is compliant enough.
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Full featured target platforms I have including one for the P2 which at present use the BeMicroCV-A9 card but has the footprint for the P2 when it's out. By full-featured I am not talking breadboarding and LEDs. This has dual SD cards, USB using smartpins plus FTDI, Ethernet using W5500, ESP8266MOD WiFi, sound in and out, VGA, RS-485 buses, plug-in modules or proto etc. The modules allow for special functions such as motor control, CAN bus, fibre-optic links etc
<snip> Here's how things would change. We would begin with two low-level routines something like these, already coded up and waiting for our users in our library of useful routines:
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
To turn off a pin;
To turn a pin off:
Tachyon LOW .
Note that two different "calling patterns" are defined for each routine.
<snip>
And after adding that to his own library of useful routines he could say things like:
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
Although it is just as natural for me to code in Tachyon Forth (no PICK and ROLL please) I would have no problem with PE and nor can I see how anyone else could. I like it.
So PE could output Tachyon Forth text which is just downloaded without any special protocol into a Prop and it would compile and run with TF providing all the hardware layers and services. Perhaps two-way serial communications can be used for debugging purposes too. It's a no-brainer to me.
So PE could output Tachyon Forth text which is just downloaded without any special protocol into a Prop and it would compile and run with TF providing all the hardware layers and services. Perhaps two-way serial communications can be used for debugging purposes too. It's a no-brainer to me.
Yes, the compiler could output Tachyon Forth text. There are several parts to that. Let's take the same example we had above. Routines like this, coded entirely by the user...
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
...would be translated into Forth text, I imagine, as follows:
The two variables ("the red light" and "the green light") would turn into Forth variable definitions with Forth-compatible spaceless names and the appropriate initial values. You'd have to tell me what those look like.
"Run" is the default name for where a Plain English program begins; we'll have to put that routine's generated Forth in the appropriate spot.
"Start up" is a call to our initialization stuff. It may not be needed. If it is, the name (which has spaces) would be converted to something like "START~UP" and would appear in the generated Forth just like that (which would eventually execute whatever code is associated with that "word" in the Forth dictionary.
"Blink the red light" is just slightly trickier. The compiler, in this case, would again convert the name to something spaceless (like THE~RED~LIGHT) and would put that, together with whatever is needed to get it's address on the stack (Plain English assumes that all parameters are passed by address, not value). That would be followed by the name of the routine, which in this case is just "BLINK".
And so on for the rest of this routine. Now the BLINK routine itself...
To blink an LED:
Turn on the LED. Wait for 1/10 second.
Turn the LED off. Wait for 1/10 second.
Add 1 to a count. If the count is less than 10, repeat.
...has a couple of other things we need to think about. First we need to turn the header into the start of a Forth word defintion (which can assume there's a value already on the stack from the calling routine) followed by the equivalent Forth text for the various statements in the routine.
Note that "Add 1 to a count" doesn't just add but also implicitly defines a local variable ("the count"). We'll need to deal with that. We'll also have to deal with the conditional statement ("count is less than 10") which, in Plain English, calls a comparison routine. And the "repeat" at the end of the routine which jumps back to the top will also have to be handled appropriately. And let's not forget to clean up the stack when we're done...
One last but easy thing. In lower-level routines like this...
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
...we simply need to copy the supplied code following the keyword "Tachyon" into the output.
I think if we're going to take a shot at this it would be easier to communicate directly. My email is gerry.rzeppa@pobox.com. And I think you should see if you can get Plain English to run on your Linux box, one way or another, so you can test this stuff on your various target platforms. The whole shebang is here: www.osmosian.com/cal-3040.zip
I think if we're going to take a shot at this it would be easier to communicate directly. My email is gerry.rzeppa@pobox.com...The whole shebang is here: www.osmosian.com/cal-3040.zip
Looks like you've recovered from a "spiral". Please keep us posted.
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Full featured target platforms I have including one for the P2 which at present use the BeMicroCV-A9 card but has the footprint for the P2 when it's out. By full-featured I am not talking breadboarding and LEDs. This has dual SD cards, USB using smartpins plus FTDI, Ethernet using W5500, ESP8266MOD WiFi, sound in and out, VGA, RS-485 buses, plug-in modules or proto etc. The modules allow for special functions such as motor control, CAN bus, fibre-optic links etc
A benefit of using Tachyon, rather than PASM, is that PE can target both P1 and P2 more naturally, as well as other FPGA derivatives that might spawn down the line...
That context system has a nice hardware board with some practically useful I/O and a domain specific language all people to drive it in customized ways.
I'm all for such domain specific languages to tackle specific problems. On the other hand it's hard to recognize the context language as a "programming" language. It has no variables, no state. It has no tests (if, while) other than on tests on inputs. You can not write algorithms in that language.
It's all a bit too simple. I'm guessing one could create an interpreter for language like context for the Propeller in a day or two.
Actually, it reminds me of the scripting language we used to create tests that ran on customized test rigs for testing the Primary Flight Computers of the Boeing 777. Basically it allowed us to set inputs to the PFCs and read outputs and try various sequences and timing of doing all that. What it actually did was create the ARINC bus messages that went in and out of the PFCs.
That test rig language also had no variables. On one occasion I needed to maintain state in a test. I got around the lack of variables by setting fields in a dummy output message which would get echoed back, then I could read my "variables" back from the inputs. This seriously upset our quality control guys who could not get their heads around what I did!
The simple test rig language hand been built so that tests could be created by non-programmers. That plan fell apart because although the language was simple and writing scripts was trivial, actually understanding the Requirements Specification well enough to create meaningful and rigorous tests required quite a lot of skill and experience. The whole team was comprised of expensive contract software engineers!
A quick update. I'm sorry to say it doesn't use any Parallax devices, but it does manage to connect Plain English with "robotics" at a level a ten-year-old (and his dad!) can deal with on his (their) first attempt. For the full story, see here:
Comments
Forth looks like a language you can teach Plain English to. Look at the section "Teaching Forth to learn new words".
What WE would need is:
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Plus time (I've got some to spare), a little money (I've got a little of that, too), and a lot of enthusiasm and perseverance. The usual stuff.
I get the idea. At least I think I do. But let's take an example. Your (well-written and humorous Tachyon FORTH manual) says I can turn on an LED with a statement like this...
4 HIGH
...and I can turn it off with this:
4 LOW
That's great. I can see novices easily coping with that, and experts doing that without even thinking. Then you go on to say that I can make my LED blink by defining a "word" like this:
: BLINKY 10 FOR 4 HIGH 100 ms 4 LOW 100 ms NEXT ;
And, having defined that word, all I have to say to make it happen it is:
BLINKY
Still great -- at least at the end. But the middle part is somewhat less than natural for both beginners and pros. Which, I presume, is where Plain English comes in. Here's how things would change. We would begin with two low-level routines something like these, already coded up and waiting for our users in our library of useful routines:
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
To turn off a pin;
To turn a pin off:
Tachyon LOW .
Note that two different "calling patterns" are defined for each routine. Note also that I'm assuming the compiler has already pushed "the pin" onto the parameter stack, and that everything following the word "Tachyon" would simply be handed to the Tachyon FORTH interpreter. Or something like that, only more efficient; I'm just trying to describe the general idea. We'd also have some kind of low-level WAIT routine in the same library of useful routines.
And now, the payoff. Instead of thinking at this level...
: BLINKY 10 FOR 4 HIGH 100 ms 4 LOW 100 ms NEXT ;
...our programmer would think more like he normally does:
To blink an LED:
Turn on the LED. Wait for 1/10 second.
Turn the LED off. Wait for 1/10 second.
Add 1 to a count. If the count is less than 10, repeat.
And after adding that to his own library of useful routines he could say things like:
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
Am I in the ballpark? If so, I'll reiterate. What WE need is:
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Your turn.
What WE would need is:
1. An big enough audience (with a problem that is best solved with Tachyon + Plain English) to make the effort worthwhile.
Tachyon gets things done but it's not everyone's cup of tea. Since Tachyon get things done already then PE will allow anybody to tell it in Plain English WHAT they want done. Result? Big audience!
2. A development platform big and fast and fully-featured enough for the Plain English IDE (currently Windows).
I mainly use Linux which means it's not a problem to run Windows
3. A target platform big and fast and fully-featured enough for the generated Tachyon code.
Full featured target platforms I have including one for the P2 which at present use the BeMicroCV-A9 card but has the footprint for the P2 when it's out. By full-featured I am not talking breadboarding and LEDs. This has dual SD cards, USB using smartpins plus FTDI, Ethernet using W5500, ESP8266MOD WiFi, sound in and out, VGA, RS-485 buses, plug-in modules or proto etc. The modules allow for special functions such as motor control, CAN bus, fibre-optic links etc
<snip>
Here's how things would change. We would begin with two low-level routines something like these, already coded up and waiting for our users in our library of useful routines:
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
To turn off a pin;
To turn a pin off:
Tachyon LOW .
Note that two different "calling patterns" are defined for each routine.
<snip>
And after adding that to his own library of useful routines he could say things like:
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
Although it is just as natural for me to code in Tachyon Forth (no PICK and ROLL please) I would have no problem with PE and nor can I see how anyone else could. I like it.
So PE could output Tachyon Forth text which is just downloaded without any special protocol into a Prop and it would compile and run with TF providing all the hardware layers and services. Perhaps two-way serial communications can be used for debugging purposes too. It's a no-brainer to me.
The red light is on pin 4.
The green light is on pin 5.
To Run:
Start up.
Blink the red light.
Blink the green light.
Shut down.
...would be translated into Forth text, I imagine, as follows:
The two variables ("the red light" and "the green light") would turn into Forth variable definitions with Forth-compatible spaceless names and the appropriate initial values. You'd have to tell me what those look like.
"Run" is the default name for where a Plain English program begins; we'll have to put that routine's generated Forth in the appropriate spot.
"Start up" is a call to our initialization stuff. It may not be needed. If it is, the name (which has spaces) would be converted to something like "START~UP" and would appear in the generated Forth just like that (which would eventually execute whatever code is associated with that "word" in the Forth dictionary.
"Blink the red light" is just slightly trickier. The compiler, in this case, would again convert the name to something spaceless (like THE~RED~LIGHT) and would put that, together with whatever is needed to get it's address on the stack (Plain English assumes that all parameters are passed by address, not value). That would be followed by the name of the routine, which in this case is just "BLINK".
And so on for the rest of this routine. Now the BLINK routine itself...
To blink an LED:
Turn on the LED. Wait for 1/10 second.
Turn the LED off. Wait for 1/10 second.
Add 1 to a count. If the count is less than 10, repeat.
...has a couple of other things we need to think about. First we need to turn the header into the start of a Forth word defintion (which can assume there's a value already on the stack from the calling routine) followed by the equivalent Forth text for the various statements in the routine.
Note that "Add 1 to a count" doesn't just add but also implicitly defines a local variable ("the count"). We'll need to deal with that. We'll also have to deal with the conditional statement ("count is less than 10") which, in Plain English, calls a comparison routine. And the "repeat" at the end of the routine which jumps back to the top will also have to be handled appropriately. And let's not forget to clean up the stack when we're done...
One last but easy thing. In lower-level routines like this...
To turn on a pin;
To turn a pin on:
Tachyon HIGH .
...we simply need to copy the supplied code following the keyword "Tachyon" into the output.
I think if we're going to take a shot at this it would be easier to communicate directly. My email is gerry.rzeppa@pobox.com. And I think you should see if you can get Plain English to run on your Linux box, one way or another, so you can test this stuff on your various target platforms. The whole shebang is here: www.osmosian.com/cal-3040.zip
Looks like you've recovered from a "spiral". Please keep us posted.
Will do.
A benefit of using Tachyon, rather than PASM, is that PE can target both P1 and P2 more naturally, as well as other FPGA derivatives that might spawn down the line...
What forths are there on Rasp Pi ?
https://pc-control.co.uk/control/products/boards/context.php
I especially like the line that says, "As you can see the instructions are designed to be as close to plain English as possible."
That context system has a nice hardware board with some practically useful I/O and a domain specific language all people to drive it in customized ways.
I'm all for such domain specific languages to tackle specific problems. On the other hand it's hard to recognize the context language as a "programming" language. It has no variables, no state. It has no tests (if, while) other than on tests on inputs. You can not write algorithms in that language.
It's all a bit too simple. I'm guessing one could create an interpreter for language like context for the Propeller in a day or two.
Actually, it reminds me of the scripting language we used to create tests that ran on customized test rigs for testing the Primary Flight Computers of the Boeing 777. Basically it allowed us to set inputs to the PFCs and read outputs and try various sequences and timing of doing all that. What it actually did was create the ARINC bus messages that went in and out of the PFCs.
That test rig language also had no variables. On one occasion I needed to maintain state in a test. I got around the lack of variables by setting fields in a dummy output message which would get echoed back, then I could read my "variables" back from the inputs. This seriously upset our quality control guys who could not get their heads around what I did!
The simple test rig language hand been built so that tests could be created by non-programmers. That plan fell apart because although the language was simple and writing scripts was trivial, actually understanding the Requirements Specification well enough to create meaningful and rigorous tests required quite a lot of skill and experience. The whole team was comprised of expensive contract software engineers!
Oop's, OK rambling of topic again....
http://www.pc-control.co.uk/control/articles/article10.php