In a Unix shell "cat" produces the contents of a file. "rm" removes a file by name. Looks like "cat-and-rm" might produce the content of a file and the delete that copy. So what? The original file is still there. It's a no-op.
In a Unix shell "cat" produces the contents of a file. "rm" removes a file by name. Looks like "cat-and-rm" might produce the content of a file and the delete that copy. So what? The original file is still there. It's a no-op.
It's not a nop. The function types out the contents of a file and then deletes it. The original file is gone. This is not meant to be a practical program, just an example of how a shell might be used.
@Heater
This is so unfair... you are using analogy and examples. And then you imply that you are using natural in a metaphorical sense. So natural just becomes subjective.... what you mean is easy, or reliable.
I worked for a few years in construction estimating with long hours of number crunching and amongst surveyors and engineers, RPN seemed extremely natural. Stacks allowed for very good error control, much better than regular 10 key paper tapes. I did not have to re-enter lengthy columns of numbers to verify sums; I could review each entry on the stack and then run the sum.
I am a bit uncertain how RPN compares against spreadsheets, but I find it is easy to bury errors very deeply in spreadsheets. So I still have a need for a calculator, and trust the RPN mode to be more efficient.
I'd say that when handling a great deal of numerical data, it is far better than other alternatives.... especially if you are auditing calculations for accuracy.
Heater,
It does two things..
A. displays the file
B. then removes the file.
Personally, I dislike the idea of linking these two as I use cat to see what is in a file. I would only remove a file after pondering what is in a file, not automatically.
Regardless, it is about saving the file name in duplicate and first calling cat, then calling rm.
"The function types out the contents of a file and then deletes it. The original file is gone."
That is really not clear to me. How can deleting the output of typing a file delete the original file?
The rm needs the name of the file to remove not the content of the file.
My function is this:
: cat-and-rm 2dup cat rm ;
called like this:
S" foo.bar" cat-and-rm
First, the S" word pushes a copy of the string that follows onto the stack as a pair of entries, address and length of the string.
The 2dup word will make a copy of the top two entries in the stack which will be the address and length of a string. The cat word will pop a pair off the stack and use it as the name of the file to "cat". That leaves two more entries on the stack that also point to the same string. The rm work pops that pair off the stack and uses it as the name of the file to delete. Make sense now? As I said, this isn't a function you'd really use. My point is that to be a useful shell language Forth would have to support arbitrary parameters to words like cat and rm not just inline literal strings.
The fun thing about "natural" is that nature does it so many different ways!
An example from Wiki on word order in languages:
[h=3]Hungarian[/h] In Hungarian, the enclitic -t marks the direct object. For "Kate atea piece of cake", the possibilities are:
TTo make a Forth word look forward into the input buffer and operate on things not yet processed rather than thing on the stack, Dave H. showed one way. You could also have cat and ls and the other unix shell-like commands pull strings off the stack but this makes the commands foreign in how they "naturally" operate. It is probably also more efficient to look forward into the input buffer if you just want to grab user input strings. Words forget, dictionary listers and some others (like the compiling word ';' look forward because it makes more sense.
The problem with "looking ahead in the input buffer" is that it doesn't allow for arbitrary expressions to be used to determine the argument to the "cat" or "rm" words. The argument must be a literal. This greatly reduces the power of Forth to be used as a scripting language.
Funny you should mention spread sheets and such. I happen to be living with a woman who has been a book keeper for a very long time. On her desk she keeps a big old Sharp printing calculator with a big plasma seven segment display.
Why does she do that? Because, despite having to do accounting with various software packages over the years she does not trust them and they are not so easy to work with. That 20 year old printing calculator is the final arbiter of correctness.
When she trains young people fresh out accounting school, full of IT brainwashing, as to how to work in the real world they look at that old calculator with derision. The smart ones eventually realize how brilliant it is and want to get one of their own!
Now, I imagine that can happen with an RPN machine or perhaps an abacus in Asia for example.
Still, I don't believe anyone stacks up all the operands in their minds and the applies the operators in reverse order:) It's not "natural".
The words INCLUDE and RM call the standard postfix versions to perform their functions. They are defined in pfth as follows:
: include bl word count included ;
: rm bl word count delete-file
if
." File does not exist" cr
then
;
So instead of "include file.fth" and "rm file.fth" it's possible to do "s" file.fth" included" and "s" file.fth" delete-file". I plan on doing a similar thing with the CD command, where there will be a postfix version of it. One advantage of the postfix version is that it can be used in a compiled word, where the prefix version can not.
The words INCLUDE and RM call the standard postfix versions to perform their functions. They are defined in pfth as follows:
: include bl word count included ;
: rm bl word count delete-file
if
." File does not exist" cr
then
;
So instead of "include file.fth" and "rm file.fth" it's possible to do "s" file.fth" included" and "s" file.fth" delete-file". I plan on doing a similar thing with the CD command, where there will be a postfix version of it. One advantage of the postfix version is that it can be used in a compiled word, where the prefix version can not.
Okay, now I understand. The functionality is there at a lower level and the unix-like words are just syntactic sugar for interactive mode. Makes sense.
But, as far as I know nobody stacks up operands in their mind and then applies the operators to them all in reverse order. As in:
"grain mouse cat dog human eat eat eat eat".
That is what I mean by "not natural". Do correct me if I'm wrong.
You are being plain stupid with your example but let's use it just like you said.
Ham cheese pickles bread butter stack stack stack eat
Yes, I don't want to eat the sandwich before it's made
However simple maths are normally executed as operands are available (just like the sandwich), not right at the end.
bananas apples + fruit !
not bananas apples fruit rot rot + swap !
because that is just a load of rot doing it that way
What a digression from the topic...
So here is my bit to the thread...
In English we say That red ball is NOT blue.
In some other languages they effectively say
That red ball is blue NOT.
Notice the positioning of the "NOT". It has become so fashionable by the younger generations (here in OZ at least) that they deliberately place the "NOT" at the end.
Other languages even have the subject, being the ball, having a defined gender as in male [le/der], female [la/die], or neuter [das].
This is just to say, the spoken languages have major differences, so why should programming be any different??? (not to say it is good, because it's not).
I have to twist my head around pasm, because the destination comes first, followed by the source. I grew up on an ICL (Singer/Frieden) minicomputer (production 1969-1993, supported to 2000) which was programmed in assembler (initially 15 instructions, memory to memory, with add, subtract, multiply and divide [in decimal !!! A & B were length 1-10 digits, and multiply resulted in a 20 digit decimal answer, and divide was the reverse of multiply] and edit instructions included) which was quite uncannily similar to pasm. But, you typed
label add a,b
where b=b+a
In pasm of course it is
label add b,a
Now of course in DOS we learnt / used
COPY sourcefile destinationfile
This was the same as the ICL mini.
Of course, we are never going to get consensus. However, reading the discussion about forth just makes me glad I have never looked at it. It looks as daunting as an English speaking (writing) person trying to learn to write Chinese or Japanese.
Now, back to reality..
Why use LS, CAT, RM when DIR for directory, TYPE for typing out (meaning display, so perhaps we should have used DISPLAY), DEL for delete makes much more sense? That is what I (and others I have followed) have done with PropOS. But for those who want LS, CAT and RM, all that is required in my PropOS is renaming _DIR.CMD as _LS.CMD, _TYPE.CMD as _CAT.CMD, and _DEL.CMD as _RM.CMD. In fact, you can just copy the files and have both worlds. No changes to the OS are required, and it is very simple to create new OS commands because they are all separate binary files.
I even have commands to display the CPM filesystem that we use in ZiCog, and commands to program the EEPROM (lower of upper 32KB) from a binary file.
Note they are not free-standing because they use the mailbox system with resident cogs performing I/O which means that the input (serial as in pc or terminal, or keyboard/keypad) and output (serial as in pc or terminal, or TV or VGA or LCD) can just be changed on the fly without any change to the OS.
Just to confirm heater's note above, FAT16/32 is not required to be used on the SD card. In fact, as soon as ZiCog is loaded, it locates filenames under FAT16/32 that represent the HDD's in CPM. Once found, all file I/O to the disk files is direct sector addressing. However, provided you knew where each HDD block resides (ie it starting sector number on the SD card), all I/O can be (in fact is already) direct sector addressing. So, quite simply, no FAT16/32 is required. The advantage of FAT16/32 is that we can unplug the SD card and place it in a reader to be written/read by the pc, using Windoze or Linux.
All languages are learned, THAT's what humans do. Just because you speak English, do you think you can claim Chinese is "wrong"? Well, you could, but some of the Chinese folks might disagree.
...... My point is that to be a useful shell language Forth would have to support arbitrary parameters to words like cat and rm not just inline literal strings.
You want to use Forth for a shell language, but that might not be the best way to look at it. You might instead want to use forth as a bunch of little scriptable functions that CAN DO SOME SHELL LIKE STUFF, but is not really going to be a shell. Its just not like that, unless you make it like that, in which case you end up with your exact linux shell. But we already know the regular linux shell won't fit. If we can't stuff a linux kernel into the prop, then we cannot implement all the function of linux in forth and expect that to fit in the prop.
What we CAN do, is decide which functions we REALLY need, and skip all the rest, until we get something that both fits and does enough of what we want to get the job done.
So while you could do arbitrary parameters, it would tend to take up all your space, leaving nothing for an application.
This is just my opinion, the smart people may have more to say about it.
You are being plain stupid with your example but let's use it just like you said.
Ham cheese pickles bread butter stack stack stack eat
Yes, I don't want to eat the sandwich before it's made
However simple maths are normally executed as operands are available (just like the sandwich), not right at the end.
bananas apples + fruit !
not bananas apples fruit rot rot + swap !
because that is just a load of rot doing it that way
+1 for the rot reference, nice
As for Jazzed and Heater still on this thread after they saw the FORTH word and didn't NMI Abort, I'm impressed.
It could be argued that the "not" is in the wrong place here. After all you cannot "not" anything until you have one in mind. So let's have "blue not"
But then we have the same problem with the "is", the thing cannot be said to exist "is" until you have one in mind. So let's have "blue not is".
By similar reasoning we have "ball red" and we might end up with, which is
short for "considering the set of balls I mean the one that is red."
And we end up with: "Ball red blue not is that".
Make sense to me:)
Why use LS, CAT, RM when DIR for directory, TYPE for typing out (meaning
display, so perhaps we should have used DISPLAY), DEL for delete makes much more
sense?
Only because that's how they did it when they invented Unix. Everything on Unix was pretty minimal, they only had small machines and it was a kind of rebellion against the huge multics project. More over they wanted to use the least characters for the most used commands as typing on those old teletypes was a drag.
@Braino
All languages are learned, THAT's what humans do.
Except by saying that you have introduced a "chicken and egg" problem. After all there was a time when languages did not exist, so where did we learn them from?
There are those who would argue that sophisticated language (not any specific one) co-evolved with us humans.
You can imagine that those with greater communication skills had a better chance of surviving and rearing their young in societies of cooperating individuals than those with less skill. That results on selective pressure, evolution, of bigger brains and more language skills.
In a way, language drove our evolution, as much as we invented language it invented us!
So, in that light, I repeat "All languages are natural, that's what humans do." Which is not to say we are born with the specifics of any particular language built in, clearly we learn that.
@D.P.
NMI Abort
No way. Despite all my jibes at Forth, which should not be taken so seriously, I am very impressed at what the Forth heads have done with Forth on the Prop. It's amazing what they can fit into such a small machine and have it run at a nice speed to. There must be something I'm missing out on.
@Peter Jakacki,
You are being plain stupid with your example...
Yeah, I know. I was over streching the example in making my point thus defeating said point. No one would code like that for real.
Funny you should mention spread sheets and such. I happen to be living with a woman who has been a book keeper for a very long time. On her desk she keeps a big old Sharp printing calculator with a big plasma seven segment display.
Why does she do that? Because, despite having to do accounting with various software packages over the years she does not trust them and they are not so easy to work with. That 20 year old printing calculator is the final arbiter of correctness.
When she trains young people fresh out accounting school, full of IT brainwashing, as to how to work in the real world they look at that old calculator with derision. The smart ones eventually realize how brilliant it is and want to get one of their own!
Now, I imagine that can happen with an RPN machine or perhaps an abacus in Asia for example.
Still, I don't believe anyone stacks up all the operands in their minds and the applies the operators in reverse order:) It's not "natural".
I am well aware of the paper-tape approach to verification. A 10-key calculator can run a huge sum, the paper tape is saved and annotated as to what it is for. Then, one may run a second tape to get a verification via checksum. If that doesn't work out, one can either run a third tape to get some indication of which tape is the right one, or one can jump in and start reading each and every item until the errors are eliminated. At that point, the correct and verified tape is annotated as such.
It is a good system... if you can stand inputing your number twice or thrice or even more. One begins to become psychotic as the machine churns. Being a heavy smoker seems to have a calming afffect, and maybe a good source of Benzedrine carries the day.
Or, you can use a HP calculator with RPN to verify your input... say 5 items at a time and then sum... just doing it all once to get the correct answer. If there is any doubt, one can do it a second time.. maybe with a bit different method just to make you less tired. It works extremely well as RPN allows you to revise the stack and you can save interim results.
The only thing lacking in most RPN calculators is the actual paper tape that is retained as evidence for any future auditors.
The problems with spreadsheets creep in with Cut and Paste transfers of blocks of formulas and not fully recognizing what is going on. Also, it a cheat wants to manipulate a spreadsheet, they can just eliminate the formulas from a key cell and insert a completely bogus number. So, the auditor has to return to a 10-key and paper tape to verify that the document is a genuine calculation.
The problem with "looking ahead in the input buffer" is that it doesn't allow for arbitrary expressions to be used to determine the argument to the "cat" or "rm" words. The argument must be a literal. This greatly reduces the power of Forth to be used as a scripting language.
While I get your point, I am not sure that Forth is really limited to a literal argument. I suspect that Forth can do anything you want if you understand it entirely.
The solution may not be a pretty or pleasant as other languages, but it is possible.
The PRIMARY utiltiy in Forth is to get quickly started with understanding the underlying limitations of the hardware and deploying solutions very rapidly. I like it because I could finally poke and prod the Propeller to confirm what the documentation describes. I also like it because it provides me with the means to make the Propeller a kind of electronic Swiss Army knife that is connected to the PC via a serial port.
For example, you can use it to zero in on positioning and rate behavior in a stepper motor. Once you have the values you really need, you can then generate your final program in C if you prefer... but you have saved a lot of time.
Another example, take a look at PropForth's Logic analyzer. Do you wish you had one, but dislike the cost? Here is a ready alternative that may server your purposes or provide you with better insight into what your needs really are.
As a system, Forth is handy and useful. It doesn't have to be everything for everyone.
While I get your point, I am not sure that Forth is really limited to a literal argument. I suspect that Forth can do anything you want if you understand it entirely.
The solution may not be a pretty or pleasant as other languages, but it is possible.
The PRIMARY utiltiy in Forth is to get quickly started with understanding the underlying limitations of the hardware and deploying solutions very rapidly. I like it because I could finally poke and prod the Propeller to confirm what the documentation describes. I also like it because it provides me with the means to make the Propeller a kind of electronic Swiss Army knife that is connected to the PC via a serial port.
For example, you can use it to zero in on positioning and rate behavior in a stepper motor. Once you have the values you really need, you can then generate your final program in C if you prefer... but you have saved a lot of time.
Another example, take a look at PropForth's Logic analyzer. Do you wish you had one, but dislike the cost? Here is a ready alternative that may server your purposes or provide you with better insight into what your needs really are.
As a system, Forth is handy and useful. It doesn't have to be everything for everyone.
I don't doubt that Forth has value. I've been intrigued by it for a long time. I just never seem to have time to dive deeply enough into it to get anything significant done.
I've been intrigued by it for a long time. I just never seem to have time to dive deeply enough into it to get anything significant done.
That's it right there. Playing with it with no specific goal just makes more questions. If one were to establish a specific set of goals, which are within the devices abilities, you could have a project where you might see how the tool is useful.
The easiest and most fun might be an erco-bot to do figure 8s. I think Nick's robot control language might work on pfth. Or you could use the full LittleRobot instructions, but those are designed for another forth.
A standalone terminal as you are imagining is also doable. One could use a prop demo board and SD; or you could have an Adroid device as terminal using the HC06 blue tooth. Your function CAT could be a script on SD:
: CAT CATsourceFile SD-read ; \ expects another filename on input line
You can put whatever you want in the CATsource, as long as it doesn't exceed available memory. As long as there are no new definiition (or you forget them at the end), cat won't consume any space.
This way, it not in memory until you need it. If you need to "pass" something to another function, just save the data to a another SD file, and the next program can find it there. It won't necessarily be fast, but this is a micro controller.
Having project goals is indeed helpful. Each to his own set. I am more into home and/or shop automation.
I am no longer particularly interested in rolling about in figure-e or following a line.
The interactive nature of Forth fits very nicely into my larger goals.. the write/compile/load cycle just seemed to not appeal to my ways of exploring and developing.
++++++++
I posted the eForth pdf above just because I think it is an excellent entry into mastering the whole concept of Forth. As I previously mentioned, most tutorials seem to enter the topic in a less comprehensive fashion.
++++++++
The debate about what Forth is will go on and on as it is neither fish nor foul to most of the mainstream programmers.
I'd rather not catagorize it. It is just an interesting and useful tool kit. I happen to believe that one learns more by learning contrasting methods than by merely mastering one.
And a lot of computer discussion is so abstract that nothing can easily be resolved.
Terms such as natural and language seem to be very deceptive. Most of us accept that what comes easy to us is what we mean by natural, but others are heavily vested in the purity of natural. And then, there is the snag of calling a symbolic system such as a 'computer language' a language. Language in its primary sense tends to be a means to communicate with others, not really a means to program a machine.. that is something else, maybe a semiotic representation would be a more precise description.
Since the 1970s we have extended a lot of terms to more and more abstract analogies and metaphorical senses. It get harder and harder to catch on to what computer geeks are really discussing at times.. or the importance of the points that are being debated.
The interactive nature of Forth fits very nicely into my larger goals.. the write/compile/load cycle just seemed to not appeal to my ways of exploring and developing.
It always seems to come down to this. I wonder if the vast majority of Forth users would also be satisfied with a more traditional language as long is it is interactive. I once wrote a Javascript-like language that had your standard read-eval-print loop and it was quite useful for debugging embedded systems. I think it was the interactive nature of the language rather than the specific language syntax that made the difference.
...there is the snag of calling a symbolic system such as a 'computer language' a language. Language in its primary sense tends to be a means to communicate with others, not really a means to program a machine..
I might agree with you if the primary purpose of programming languages were to for a human to get computers doing what he/she wants.
How ever I will argue that is not the case. Consider:
1) Most of a programmers time is spend reading and fixing/adapting/modifying existing code. That is to say the programming language is now a language of communication between humans. The programmer and whoever wrote the code originally. Which may or may not be the same person.
2) A lot of programs are the work of many programmers, both at the same time, or spread of long periods of time. Again the programming language is a language of communication between people.
3) Programming languages are a way of expressing ideas, algorithms and so on, in a rigorous and clear way for other humans to understand.
4) You only have to look at this forum and the thousands of code snippets that are included in posts to see that a programming language is a language between people.
Therefore I posit that programming languages are as much "real" language as English or Chinese or the notation of mathematics.
It always seems to come down to this. I wonder if the vast majority of Forth users would also be satisfied with a more traditional language as long is it is interactive. I once wrote a Javascript-like language that had your standard read-eval-print loop and it was quite useful for debugging embedded systems. I think it was the interactive nature of the language rather than the specific language syntax that made the difference.
When I think back to having a ColorBasic from Tandy that was interactive, I really feel that there is still a huge audience of new learners that are more comfortable with interactive programing and the industry has dismissed this mode as not professional. After all, it doesn't create a regime of documenting work for management.
So, the interpreted language doesn't have to be Forth. But Forth does have a lot of depth going for it that makes it a major contender. Plus, there is a corpus of reading material that allows the learner to go quite far with it. A new interpreted language would have to prove itself. An interpreted Basic might be something far less than Forth.
Just consider that we are never really going to ask kids to document their programing, and that for them an interactive mode adds a great deal of spontaneous fun and challenge to the learning process.
A lot of talk about engaging young people has been mentioned here, but I really am very serious that Parallax needs an interpreted language agenda as outreach to younger users.
I might agree with you if the primary purpose of programming languages were to for a human to get computers doing what he/she wants.
How ever I will argue that is not the case. Consider:
......
And yet, the only means you have of defending the idea that a computer language is a 'real' language, and not a semiotic sub-set is to revert to English... a real 'real' language.
Comments
But, as far as I know nobody stacks up operands in their mind and then applies the operators to them all in reverse order. As in:
"grain mouse cat dog human eat eat eat eat".
That is what I mean by "not natural". Do correct me if I'm wrong.
In a Unix shell "cat" produces the contents of a file. "rm" removes a file by name. Looks like "cat-and-rm" might produce the content of a file and the delete that copy. So what? The original file is still there. It's a no-op.
It's not a nop. The function types out the contents of a file and then deletes it. The original file is gone. This is not meant to be a practical program, just an example of how a shell might be used.
This is so unfair... you are using analogy and examples. And then you imply that you are using natural in a metaphorical sense. So natural just becomes subjective.... what you mean is easy, or reliable.
I worked for a few years in construction estimating with long hours of number crunching and amongst surveyors and engineers, RPN seemed extremely natural. Stacks allowed for very good error control, much better than regular 10 key paper tapes. I did not have to re-enter lengthy columns of numbers to verify sums; I could review each entry on the stack and then run the sum.
I am a bit uncertain how RPN compares against spreadsheets, but I find it is easy to bury errors very deeply in spreadsheets. So I still have a need for a calculator, and trust the RPN mode to be more efficient.
I'd say that when handling a great deal of numerical data, it is far better than other alternatives.... especially if you are auditing calculations for accuracy.
"The function types out the contents of a file and then deletes it. The original file is gone."
That is really not clear to me. How can deleting the output of typing a file delete the original file?
The rm needs the name of the file to remove not the content of the file.
It does two things..
A. displays the file
B. then removes the file.
Personally, I dislike the idea of linking these two as I use cat to see what is in a file. I would only remove a file after pondering what is in a file, not automatically.
Regardless, it is about saving the file name in duplicate and first calling cat, then calling rm.
: cat-and-rm 2dup cat rm ;
called like this:
S" foo.bar" cat-and-rm
First, the S" word pushes a copy of the string that follows onto the stack as a pair of entries, address and length of the string.
The 2dup word will make a copy of the top two entries in the stack which will be the address and length of a string. The cat word will pop a pair off the stack and use it as the name of the file to "cat". That leaves two more entries on the stack that also point to the same string. The rm work pops that pair off the stack and uses it as the name of the file to delete. Make sense now? As I said, this isn't a function you'd really use. My point is that to be a useful shell language Forth would have to support arbitrary parameters to words like cat and rm not just inline literal strings.
An example from Wiki on word order in languages:
[h=3]Hungarian[/h] In Hungarian, the enclitic -t marks the direct object. For "Kate ate a piece of cake", the possibilities are:
Funny you should mention spread sheets and such. I happen to be living with a woman who has been a book keeper for a very long time. On her desk she keeps a big old Sharp printing calculator with a big plasma seven segment display.
Why does she do that? Because, despite having to do accounting with various software packages over the years she does not trust them and they are not so easy to work with. That 20 year old printing calculator is the final arbiter of correctness.
When she trains young people fresh out accounting school, full of IT brainwashing, as to how to work in the real world they look at that old calculator with derision. The smart ones eventually realize how brilliant it is and want to get one of their own!
Now, I imagine that can happen with an RPN machine or perhaps an abacus in Asia for example.
Still, I don't believe anyone stacks up all the operands in their minds and the applies the operators in reverse order:) It's not "natural".
I think Hungarian has some strange relation to Finnish. I won't try to make an example in Finnish but effectively instead of saying:
"I am on the table"
It's basically:
"I am table on"
Confused by the fact that the "on" part is not a word but rather a suffix so we have:
"I am tableon"
There are 16 or so suffixes to express "in", "on", "at", "in front", "behind", "under", "over", "towards" "away from" and so on.
Yep, word order, or should I say "concept order" is not cast in stone.
: include bl word count included ; : rm bl word count delete-file if ." File does not exist" cr then ;So instead of "include file.fth" and "rm file.fth" it's possible to do "s" file.fth" included" and "s" file.fth" delete-file". I plan on doing a similar thing with the CD command, where there will be a postfix version of it. One advantage of the postfix version is that it can be used in a compiled word, where the prefix version can not.Ham cheese pickles bread butter stack stack stack eat
Yes, I don't want to eat the sandwich before it's made
However simple maths are normally executed as operands are available (just like the sandwich), not right at the end.
bananas apples + fruit !
not bananas apples fruit rot rot + swap !
because that is just a load of rot doing it that way
So here is my bit to the thread...
In English we say That red ball is NOT blue.
In some other languages they effectively say
That red ball is blue NOT.
Notice the positioning of the "NOT". It has become so fashionable by the younger generations (here in OZ at least) that they deliberately place the "NOT" at the end.
Other languages even have the subject, being the ball, having a defined gender as in male [le/der], female [la/die], or neuter [das].
This is just to say, the spoken languages have major differences, so why should programming be any different??? (not to say it is good, because it's not).
I have to twist my head around pasm, because the destination comes first, followed by the source. I grew up on an ICL (Singer/Frieden) minicomputer (production 1969-1993, supported to 2000) which was programmed in assembler (initially 15 instructions, memory to memory, with add, subtract, multiply and divide [in decimal !!! A & B were length 1-10 digits, and multiply resulted in a 20 digit decimal answer, and divide was the reverse of multiply] and edit instructions included) which was quite uncannily similar to pasm. But, you typed
label add a,b
where b=b+a
In pasm of course it is
label add b,a
Now of course in DOS we learnt / used
COPY sourcefile destinationfile
This was the same as the ICL mini.
Of course, we are never going to get consensus. However, reading the discussion about forth just makes me glad I have never looked at it. It looks as daunting as an English speaking (writing) person trying to learn to write Chinese or Japanese.
Now, back to reality..
Why use LS, CAT, RM when DIR for directory, TYPE for typing out (meaning display, so perhaps we should have used DISPLAY), DEL for delete makes much more sense? That is what I (and others I have followed) have done with PropOS. But for those who want LS, CAT and RM, all that is required in my PropOS is renaming _DIR.CMD as _LS.CMD, _TYPE.CMD as _CAT.CMD, and _DEL.CMD as _RM.CMD. In fact, you can just copy the files and have both worlds. No changes to the OS are required, and it is very simple to create new OS commands because they are all separate binary files.
I even have commands to display the CPM filesystem that we use in ZiCog, and commands to program the EEPROM (lower of upper 32KB) from a binary file.
Note they are not free-standing because they use the mailbox system with resident cogs performing I/O which means that the input (serial as in pc or terminal, or keyboard/keypad) and output (serial as in pc or terminal, or TV or VGA or LCD) can just be changed on the fly without any change to the OS.
Just to confirm heater's note above, FAT16/32 is not required to be used on the SD card. In fact, as soon as ZiCog is loaded, it locates filenames under FAT16/32 that represent the HDD's in CPM. Once found, all file I/O to the disk files is direct sector addressing. However, provided you knew where each HDD block resides (ie it starting sector number on the SD card), all I/O can be (in fact is already) direct sector addressing. So, quite simply, no FAT16/32 is required. The advantage of FAT16/32 is that we can unplug the SD card and place it in a reader to be written/read by the pc, using Windoze or Linux.
All languages are learned, THAT's what humans do. Just because you speak English, do you think you can claim Chinese is "wrong"? Well, you could, but some of the Chinese folks might disagree.
Done.
You want to use Forth for a shell language, but that might not be the best way to look at it. You might instead want to use forth as a bunch of little scriptable functions that CAN DO SOME SHELL LIKE STUFF, but is not really going to be a shell. Its just not like that, unless you make it like that, in which case you end up with your exact linux shell. But we already know the regular linux shell won't fit. If we can't stuff a linux kernel into the prop, then we cannot implement all the function of linux in forth and expect that to fit in the prop.
What we CAN do, is decide which functions we REALLY need, and skip all the rest, until we get something that both fits and does enough of what we want to get the job done.
So while you could do arbitrary parameters, it would tend to take up all your space, leaving nothing for an application.
This is just my opinion, the smart people may have more to say about it.
+1 for the rot reference, nice
As for Jazzed and Heater still on this thread after they saw the FORTH word and didn't NMI Abort, I'm impressed.
"That red ball is NOT blue."
It could be argued that the "not" is in the wrong place here. After all you cannot "not" anything until you have one in mind. So let's have "blue not"
But then we have the same problem with the "is", the thing cannot be said to exist "is" until you have one in mind. So let's have "blue not is".
By similar reasoning we have "ball red" and we might end up with, which is
short for "considering the set of balls I mean the one that is red."
And we end up with: "Ball red blue not is that".
Make sense to me:)
Only because that's how they did it when they invented Unix. Everything on Unix was pretty minimal, they only had small machines and it was a kind of rebellion against the huge multics project. More over they wanted to use the least characters for the most used commands as typing on those old teletypes was a drag.
@Braino Except by saying that you have introduced a "chicken and egg" problem. After all there was a time when languages did not exist, so where did we learn them from?
There are those who would argue that sophisticated language (not any specific one) co-evolved with us humans.
You can imagine that those with greater communication skills had a better chance of surviving and rearing their young in societies of cooperating individuals than those with less skill. That results on selective pressure, evolution, of bigger brains and more language skills.
In a way, language drove our evolution, as much as we invented language it invented us!
So, in that light, I repeat "All languages are natural, that's what humans do." Which is not to say we are born with the specifics of any particular language built in, clearly we learn that.
@D.P. No way. Despite all my jibes at Forth, which should not be taken so seriously, I am very impressed at what the Forth heads have done with Forth on the Prop. It's amazing what they can fit into such a small machine and have it run at a nice speed to. There must be something I'm missing out on.
@Peter Jakacki, Yeah, I know. I was over streching the example in making my point thus defeating said point. No one would code like that for real.
I am well aware of the paper-tape approach to verification. A 10-key calculator can run a huge sum, the paper tape is saved and annotated as to what it is for. Then, one may run a second tape to get a verification via checksum. If that doesn't work out, one can either run a third tape to get some indication of which tape is the right one, or one can jump in and start reading each and every item until the errors are eliminated. At that point, the correct and verified tape is annotated as such.
It is a good system... if you can stand inputing your number twice or thrice or even more. One begins to become psychotic as the machine churns. Being a heavy smoker seems to have a calming afffect, and maybe a good source of Benzedrine carries the day.
Or, you can use a HP calculator with RPN to verify your input... say 5 items at a time and then sum... just doing it all once to get the correct answer. If there is any doubt, one can do it a second time.. maybe with a bit different method just to make you less tired. It works extremely well as RPN allows you to revise the stack and you can save interim results.
The only thing lacking in most RPN calculators is the actual paper tape that is retained as evidence for any future auditors.
The problems with spreadsheets creep in with Cut and Paste transfers of blocks of formulas and not fully recognizing what is going on. Also, it a cheat wants to manipulate a spreadsheet, they can just eliminate the formulas from a key cell and insert a completely bogus number. So, the auditor has to return to a 10-key and paper tape to verify that the document is a genuine calculation.
While I get your point, I am not sure that Forth is really limited to a literal argument. I suspect that Forth can do anything you want if you understand it entirely.
The solution may not be a pretty or pleasant as other languages, but it is possible.
The PRIMARY utiltiy in Forth is to get quickly started with understanding the underlying limitations of the hardware and deploying solutions very rapidly. I like it because I could finally poke and prod the Propeller to confirm what the documentation describes. I also like it because it provides me with the means to make the Propeller a kind of electronic Swiss Army knife that is connected to the PC via a serial port.
For example, you can use it to zero in on positioning and rate behavior in a stepper motor. Once you have the values you really need, you can then generate your final program in C if you prefer... but you have saved a lot of time.
Another example, take a look at PropForth's Logic analyzer. Do you wish you had one, but dislike the cost? Here is a ready alternative that may server your purposes or provide you with better insight into what your needs really are.
As a system, Forth is handy and useful. It doesn't have to be everything for everyone.
That's it right there. Playing with it with no specific goal just makes more questions. If one were to establish a specific set of goals, which are within the devices abilities, you could have a project where you might see how the tool is useful.
The easiest and most fun might be an erco-bot to do figure 8s. I think Nick's robot control language might work on pfth. Or you could use the full LittleRobot instructions, but those are designed for another forth.
A standalone terminal as you are imagining is also doable. One could use a prop demo board and SD; or you could have an Adroid device as terminal using the HC06 blue tooth. Your function CAT could be a script on SD:
: CAT CATsourceFile SD-read ; \ expects another filename on input line
You can put whatever you want in the CATsource, as long as it doesn't exceed available memory. As long as there are no new definiition (or you forget them at the end), cat won't consume any space.
This way, it not in memory until you need it. If you need to "pass" something to another function, just save the data to a another SD file, and the next program can find it there. It won't necessarily be fast, but this is a micro controller.
I am no longer particularly interested in rolling about in figure-e or following a line.
The interactive nature of Forth fits very nicely into my larger goals.. the write/compile/load cycle just seemed to not appeal to my ways of exploring and developing.
++++++++
I posted the eForth pdf above just because I think it is an excellent entry into mastering the whole concept of Forth. As I previously mentioned, most tutorials seem to enter the topic in a less comprehensive fashion.
++++++++
The debate about what Forth is will go on and on as it is neither fish nor foul to most of the mainstream programmers.
I'd rather not catagorize it. It is just an interesting and useful tool kit. I happen to believe that one learns more by learning contrasting methods than by merely mastering one.
And a lot of computer discussion is so abstract that nothing can easily be resolved.
Terms such as natural and language seem to be very deceptive. Most of us accept that what comes easy to us is what we mean by natural, but others are heavily vested in the purity of natural. And then, there is the snag of calling a symbolic system such as a 'computer language' a language. Language in its primary sense tends to be a means to communicate with others, not really a means to program a machine.. that is something else, maybe a semiotic representation would be a more precise description.
Since the 1970s we have extended a lot of terms to more and more abstract analogies and metaphorical senses. It get harder and harder to catch on to what computer geeks are really discussing at times.. or the importance of the points that are being debated.
I might agree with you if the primary purpose of programming languages were to for a human to get computers doing what he/she wants.
How ever I will argue that is not the case. Consider:
1) Most of a programmers time is spend reading and fixing/adapting/modifying existing code. That is to say the programming language is now a language of communication between humans. The programmer and whoever wrote the code originally. Which may or may not be the same person.
2) A lot of programs are the work of many programmers, both at the same time, or spread of long periods of time. Again the programming language is a language of communication between people.
3) Programming languages are a way of expressing ideas, algorithms and so on, in a rigorous and clear way for other humans to understand.
4) You only have to look at this forum and the thousands of code snippets that are included in posts to see that a programming language is a language between people.
Therefore I posit that programming languages are as much "real" language as English or Chinese or the notation of mathematics.
When I think back to having a ColorBasic from Tandy that was interactive, I really feel that there is still a huge audience of new learners that are more comfortable with interactive programing and the industry has dismissed this mode as not professional. After all, it doesn't create a regime of documenting work for management.
So, the interpreted language doesn't have to be Forth. But Forth does have a lot of depth going for it that makes it a major contender. Plus, there is a corpus of reading material that allows the learner to go quite far with it. A new interpreted language would have to prove itself. An interpreted Basic might be something far less than Forth.
Just consider that we are never really going to ask kids to document their programing, and that for them an interactive mode adds a great deal of spontaneous fun and challenge to the learning process.
A lot of talk about engaging young people has been mentioned here, but I really am very serious that Parallax needs an interpreted language agenda as outreach to younger users.
And yet, the only means you have of defending the idea that a computer language is a 'real' language, and not a semiotic sub-set is to revert to English... a real 'real' language.