syntax is a bit ugly but I like it anyway because it seems consistent with the way Forth does things. I'm a big advocate of the concept of "least surprise". Language features should work the way you expect them to given your other knowledge of the language. I know there are words that take arguments but I think they are mostly "defining words" like "create". I don't think "cat" fits into that category.
Well, I can't believe we are thinking about this seriously but:
As far as I understand in Forth we have a list of tokens that are generally either values or operations. eg, 2 1 +
In a shell the tokens are just file names that can be values, i.e. the things you read and write, or they can be operations, like the commands "ls", "cat" or "|" or "<". Or perhaps they are just strings that represent themselves, eg, echo "Hello string".
Hence my example above. How you mangle that into actual Forth syntax I have no idea but the idea of a post fix shell is surely possible.
Yes. Stack based languages have that built-in and hidden under the covers. Thank goodness most languages do not expose the users to such abuse by requiring them to have it in the program's syntax.
On my good old machine with front pannel key switch input it goes more like:
1) Set address and data switches like so: 0101100100111001 01011001
2) Hit the WRITE button.
How you get to prefix or post fix from that I don't know.
Now you might say that this is 1) Present the data (including address) 2) Hit the operate button which coud be:
address data write
or
data address write
I never said my comuputer does not have latches, which of course work in forward order of time, that does not imply all the stack confusion. For example I cannot do:
1) Set address and data switches like so: 00101100100111001 01011001
2) Set address and data switches like so: 0101000100100100 01000101
3) Set address and data switches like so: 0101000100101001 00001111
4) Hit the WRITE button.
5) Hit the WRITE button.
6) Hit the WRITE button.
If stacks were a good idea the Propeller would have one in hardware:)
Someone needs to contact Charles Moore to get a ruling on this. But then again, the concept of supporting linux commands in Forth would be quite appalling to him. I'm sure he would suggest using the appropriate BLK commands to access the block that the text resides in.
Someone needs to contact Charles Moore to get a ruling on this. But then again, the concept of supporting linux commands in Forth would be quite appalling to him. I'm sure he would suggest using the appropriate BLK commands to access the block that the text resides in.
Ah yes, no filesystem, just block I/O. I think that's one of the main reasons I passed on Forth early on. I had forgotten that part.
I suppose a Block system could be used, but the SDcard forces the FAT16/32 file system on the hardware. Why not go with it? It provides the added ability to copy whole directories from one computer or archive to the SDcard for immediate use via swapping SDcards from PC to Propeller.
The main item that Dave Hein's provided was TED, a line text editor for Forth. If Tackyon and PropForth adopted TED, it would be pretty much all the same to provide the other file manipulations.
The Main Point, is that it doesn't take much to have Forth on the Propeller provide a complete system for use with a dumb terminal. You don't need to have a complete PC with USB interface. Tachkyon, pfth, and PropForth are all capablable of a complete system at this point.... choose your own poison based on your personal preferences and knowledge.
The SDcard also creates some interesting problems with providing bootable LiveCD versions of Linux. Linux wants to use EX2, 3, or 4 for its file system these days, but booting from an SDcard requires the FAT16/32 as that is what the BIOS allows. FAT16/32 does not provide all the Unix security features that EXT2, 3, and 4 do, and I don't think it is journalizing for greater stability. So it takes quite a bit of juggling just to get a LiveCD version adapted to FAT16/32 for booting and active use... it is much easier to use a LiveCD directly.
FAT16/32 is adequte for single users on microcontrollers, so why not have Forth evole to accept SDcards in FAT16/32 rather than have the tail wag the dog? Blocks are lovely for storage in NVRam, but the Propeller is not usually providing that outside the 32K Hubram that is already fully used by Forth and its dictionary.
Thanks Dave. Isn't it kind of un-forth-like to accept parameters following the word? :-)
Would it be hard to get S" to work from the interpreter?
Well, if you insist on RPN for everything, I suppose so. But the stack is really for local variables and even ANSI standard Forth broke rank with file system names. This approach has been acceptible for a long time.
It seem to me a bit more ergonomic to have these 'borrowed file commands' to behave as they were originallly expected to do. Why do computer programmers love to be 'terminally unique' by imposing a huge retraining burden on the end-user?
Backwards is of course relative and subjective. I can see how if one is limited to a specific approach, any other approach would seem more difficult.
Assembly langage and even Spin have always seemed backwards to me.
After all ... we say
B = A when we desire to set B to the value in A. Personally I suspect that there is a long Masonic tradition in computer programming to make it harder than it has to be.
the SDcard forces the FAT16/32 file system on the hardware.
No it does not. Using SD cards generally leads people to want to use FAT because that is what is used. It need not be so.
My first versions of the CP/M operating system running on the Propeller used raw block I/O to the SD card which was in turned used by CP/M to maintain it''s own file system on the cards. There was no FAT anywhere. That was nice because we could still run a 24K Byte RAM version of CP/M on the Prop without external memory.
I always thought we should have a very simple file system for the Prop that does not take up all the HUB space of a FAT driver code. You can always make a corresponding simple program for the PC to read and write your new file system.
Someone needs to contact Charles Moore to get a ruling on this. But then again, the concept of supporting linux commands in Forth would be quite appalling to him. I'm sure he would suggest using the appropriate BLK commands to access the block that the text resides in.
Yes, Chuck doesn't care as to what's accepted and the way it should be done (according to the vocal bourgeois masses) and this includes the ANS Forth bourgeois too. For instance, if the chip design tools are inadequate he just rolls his own in a new dialect of Forth and it turns out to be so simple, not at all glorious and monstrously complex as it's made out to be. I remember writing a CPLD compiler totally in Forth that ran on the target micro that also burned the chip too. Turned out to be very simple and effective unlike the 5 digit offering from the vendor.
Yeah, use of = for assignment has always bugged me. I mean "a = b" in maths is a statement that a is equal to b. I like the symmetry and balance of the thing. How it happened that program language designers messed that up years ago I have no idea.
Spin of course uses "a := b" as in "a becomes equal to the value of b". I like the symmetry of that as well, the operation is right there between the things it is operating on. Rather than potentially being at the other end of the line where the operands are mentioned, cough, Forth, cough.
Now I realize it's the aesthetics of the symmetry thing that drives my language biases. Not any logical argument.
"A + B" symmetrical, beautiful.
"(+ A " or "A B +", unsymmetrical, lopsided, deformed, and ugly.
It's the same reason I prefer:
if (A == B)
{
// Do something
}
As opposed to:
if (A == B) {
// Do something
}
Which totally wrecks the vertical symmetry of the block.
Well, if you insist on RPN for everything, I suppose so. But the stack is really for local variables and even ANSI standard Forth broke rank with file system names. This approach has been acceptible for a long time.
It seem to me a bit more ergonomic to have these 'borrowed file commands' to behave as they were originallly expected to do. Why do computer programmers love to be 'terminally unique' by imposing a huge retraining burden on the end-user?
I don't have a problem with prefix notation for these commands rather than postfix which is more normal for Forth as long as you can pass the value of an expression as an argument to these commands. It is my understanding that the only way to do that in Forth is to use the stack, hence my suggestion to use postfix notation for "cat", etc. Is there some other way to pass a "variable" as the value following "cat" or must it be a constant string?
In Forth, parameters that follow a word are normally treated as space-delimited strings. It's similar to the parameter list used by Linux commands. The word WORD is used to extract parameters from the input buffer. ECHO would look something like this in Forth.
: echo
begin
bl word ( Get the next parameter from the input buffer )
count dup ( Get the address and count, and duplicate the count )
while ( Check for zero length )
space type ( Type the parameter )
repeat
2drop cr ( Drop the address and count of the null string )
;
As someone stated earlier, the OS is really the kernel. The user talks to the kernel through the shell, and the commands are either implemented directly in the shell or consist of other programs. A Linux-like OS can be implemented in any language, and for the most part the details of the language are hidden from the user. So a Linux-like OS written in Forth should hide most of the details of Forth from the user. However, since Forth is already a scripting language, it would be convenient to use Forth for the shell scripting language.
Of course, it's also possible use Forth itself as the OS. In that case it is no longer a Linux-like OS, and the commands should probably be more Forth-like.
In Forth, parameters that follow a word are normally treated as space-delimited strings. It's similar to the parameter list used by Linux commands. The word WORD is used to extract parameters from the input buffer. ECHO would look something like this in Forth.
: echo
begin
bl word ( Get the next parameter from the input buffer )
count dup ( Get the address and count, and duplicate the count )
while ( Check for zero length )
space type ( Type the parameter )
repeat
2drop cr ( Drop the address and count of the null string )
;
As someone stated earlier, the OS is really the kernel. The user talks to the kernel through the shell, and the commands are either implemented directly in the shell or consist of other programs. A Linux-like OS can be implemented in any language, and for the most part the details of the language are hidden from the user. So a Linux-like OS written in Forth should hide most of the details of Forth from the user. However, since Forth is already a scripting language, it would be convenient to use Forth for the shell scripting language.
Of course, it's also possible use Forth itself as the OS. In that case it is no longer a Linux-like OS, and the commands should probably be more Forth-like.
So how would I define a word that uses "cat" to type out the contents of a file and then deletes the file? If cat and rm took their arguments on the stack I could do this:
: cat-and-rm 2dup cat rm ;
Then I could call it like this:
S" foo.bar" cat-and-rm
How would I do this using the current implementation of cat and rm?
Edit: Changed "dup" to "2dup" because S" leaves two values on the stack.
I don't know about backwards but it sure is not natural.
No language is "natural". Languages are habitual. Saying "uhm", "like", "you know" every few words is habitual too, but don't make communication easier, and yet people do this and can't seem to stop.
Some folks develop habits, and become inflexible. Its ok, just a minor burden on the rest of us.
pfth is best pronounced by imitating the sound of air being released from a tire valve. An alternative pronunciation is Pee Forth, but the immature amoung us may mock that pronunciation. If you find someone mocking the Pee Forth pronunciation then revert back to the fricative pronunciation. An ample amount of saliva in the mouth prior to the fricatve pronunciation will enhance the pronunciation.
Interesting question. I thought I knew, but my opinion could be entirely subjective. I ran into this problem in my English classes when Viagra first came out... there were at least two versions of pronunciation.
You could ask Dave Hein, but you may not like the answer. It is an odd word... all consonants, no vowels.
I wonder if the p or the f might be silent... maybe both.
I suspect that it mimics the sound of puncturing an under-inflated balloon. Is that a clear description?
Or, maybe it is closer to the sound you make to get the attention of a waitress in an expensive restaurant when you don't want everyone to hear you.
Or, it could be a very Zen presentation, a written word without sound representation that merely abbreviates P for propeller and fth for forth. (Somewhat akin to the sound of one hand clapping.)
I also seem to recall pfth being a sound that someone makes to indicate they dislike and dismiss something without further comment.
You would have to save the input buffer index before calling cat, and then restore it before calling rm remove. So it would look like this.
: cat-and-rm >in @ cat >in ! rm ;
pfth is best pronounced by imitating the sound of air being released from a tire valve. An alternative pronunciation is Pee Forth, but the immature amoung us may mock that pronunciation. If you find someone mocking the Pee Forth pronunciation then revert back to the fricative pronunciation. An ample amount of saliva in the mouth prior to the fricatve pronunciation will enhance the pronunciation.
I'm afraid you've lost me here. I don't know what >in does. Anyway, I guess you're saying what I am asking is possible.
I'm afraid you've lost me here. I don't know what >in does. Anyway, I guess you're saying what I am asking is possible.
>IN is the address of the input buffer index. It's used by WORD so it knows where to start looking for the next word. It's described mentioned in Starting Forth in chapter 9 -- Under The Hood.
EDIT: The ANS Forth standard specifies how >IN works. It's one of the required CORE words.
I'm afraid you've lost me here. I don't know what >in does. Anyway, I guess you're saying what I am asking is possible.
Hmmmm.... I haven't figured out >in either and I've been at this for several months now, over half a year.
What I have learned is that you can do a great deal in Forth without knowing how the buffers and inner and outer interpreter word. >in is a word that is part of lower levels of the system.
There is a document about eForth that explains all this more clearly than I can ever do so. Try page 26. The eForth document explains the system from the bottom up; while most Forth tutorials begin with presenting the ways and means to do things that are familiar to the reader and never cover the whole.
No language is "natural". Languages are habitual. Saying "uhm", "like", "you know" every few words is habitual too, but don't make communication easier, and yet people do this and can't seem to stop.
Some folks develop habits, and become inflexible. Its ok, just a minor burden on the rest of us.
I am not even sure a 'computer programing language' really qualifies as a language at all... And natural is just about the most abused adjective known to humanity. Everything that exists is part of nature.
>IN is address of the input buffer index. It's used by WORD so it knows where to start looking for the next word. It's described mentioned in Starting Forth in chapter 9 -- Under The Hood.
EDIT: The ANS Forth standard specifies how >IN works. It's one of the required CORE words.
Okay, I guess this achieves my exact example but not more general use of the cat-and-rm word. My intent was to allow that word to take a string that was computed as the result of an arbitrary expression. Your solution still requires an inline literal. I'm afraid I don't know enough Forth to give a better example. The point is that to use Forth as a shell you'd want to be able to use the power of the Forth language to compute the values of arguments to these shell-like functions. Just being able to use literals doesn't give you anywhere near as much power. What if you have an array of strings and you want to apply my cat-and-rm to each. How would you write that loop?
Comments
syntax is a bit ugly but I like it anyway because it seems consistent with the way Forth does things. I'm a big advocate of the concept of "least surprise". Language features should work the way you expect them to given your other knowledge of the language. I know there are words that take arguments but I think they are mostly "defining words" like "create". I don't think "cat" fits into that category.
Switches and lights....God love 'em!!!
Toggle in your address, latch it
Toggle in your data, latch it
Store it......
Wait, that's like:
address data store
or in Forth:
variable 1234 !
Life is all good again!!!!!
As far as I understand in Forth we have a list of tokens that are generally either values or operations. eg, 2 1 +
In a shell the tokens are just file names that can be values, i.e. the things you read and write, or they can be operations, like the commands "ls", "cat" or "|" or "<". Or perhaps they are just strings that represent themselves, eg, echo "Hello string".
Hence my example above. How you mangle that into actual Forth syntax I have no idea but the idea of a post fix shell is surely possible.
Not so fast.
On my good old machine with front pannel key switch input it goes more like:
1) Set address and data switches like so: 0101100100111001 01011001
2) Hit the WRITE button.
How you get to prefix or post fix from that I don't know.
Now you might say that this is 1) Present the data (including address) 2) Hit the operate button which coud be:
or
I never said my comuputer does not have latches, which of course work in forward order of time, that does not imply all the stack confusion. For example I cannot do:
1) Set address and data switches like so: 00101100100111001 01011001
2) Set address and data switches like so: 0101000100100100 01000101
3) Set address and data switches like so: 0101000100101001 00001111
4) Hit the WRITE button.
5) Hit the WRITE button.
6) Hit the WRITE button.
If stacks were a good idea the Propeller would have one in hardware:)
The main item that Dave Hein's provided was TED, a line text editor for Forth. If Tackyon and PropForth adopted TED, it would be pretty much all the same to provide the other file manipulations.
The Main Point, is that it doesn't take much to have Forth on the Propeller provide a complete system for use with a dumb terminal. You don't need to have a complete PC with USB interface. Tachkyon, pfth, and PropForth are all capablable of a complete system at this point.... choose your own poison based on your personal preferences and knowledge.
The SDcard also creates some interesting problems with providing bootable LiveCD versions of Linux. Linux wants to use EX2, 3, or 4 for its file system these days, but booting from an SDcard requires the FAT16/32 as that is what the BIOS allows. FAT16/32 does not provide all the Unix security features that EXT2, 3, and 4 do, and I don't think it is journalizing for greater stability. So it takes quite a bit of juggling just to get a LiveCD version adapted to FAT16/32 for booting and active use... it is much easier to use a LiveCD directly.
FAT16/32 is adequte for single users on microcontrollers, so why not have Forth evole to accept SDcards in FAT16/32 rather than have the tail wag the dog? Blocks are lovely for storage in NVRam, but the Propeller is not usually providing that outside the 32K Hubram that is already fully used by Forth and its dictionary.
Well, if you insist on RPN for everything, I suppose so. But the stack is really for local variables and even ANSI standard Forth broke rank with file system names. This approach has been acceptible for a long time.
It seem to me a bit more ergonomic to have these 'borrowed file commands' to behave as they were originallly expected to do. Why do computer programmers love to be 'terminally unique' by imposing a huge retraining burden on the end-user?
Assembly langage and even Spin have always seemed backwards to me.
After all ... we say
B = A when we desire to set B to the value in A. Personally I suspect that there is a long Masonic tradition in computer programming to make it harder than it has to be.
No it does not. Using SD cards generally leads people to want to use FAT because that is what is used. It need not be so.
My first versions of the CP/M operating system running on the Propeller used raw block I/O to the SD card which was in turned used by CP/M to maintain it''s own file system on the cards. There was no FAT anywhere. That was nice because we could still run a 24K Byte RAM version of CP/M on the Prop without external memory.
I always thought we should have a very simple file system for the Prop that does not take up all the HUB space of a FAT driver code. You can always make a corresponding simple program for the PC to read and write your new file system.
Yes, Chuck doesn't care as to what's accepted and the way it should be done (according to the vocal bourgeois masses) and this includes the ANS Forth bourgeois too. For instance, if the chip design tools are inadequate he just rolls his own in a new dialect of Forth and it turns out to be so simple, not at all glorious and monstrously complex as it's made out to be. I remember writing a CPLD compiler totally in Forth that ran on the target micro that also burned the chip too. Turned out to be very simple and effective unlike the 5 digit offering from the vendor.
Yeah, use of = for assignment has always bugged me. I mean "a = b" in maths is a statement that a is equal to b. I like the symmetry and balance of the thing. How it happened that program language designers messed that up years ago I have no idea.
Spin of course uses "a := b" as in "a becomes equal to the value of b". I like the symmetry of that as well, the operation is right there between the things it is operating on. Rather than potentially being at the other end of the line where the operands are mentioned, cough, Forth, cough.
Now I realize it's the aesthetics of the symmetry thing that drives my language biases. Not any logical argument.
"A + B" symmetrical, beautiful.
"(+ A
It's the same reason I prefer:
if (A == B) { // Do something }As opposed to:if (A == B) { // Do something }Which totally wrecks the vertical symmetry of the block.: echo begin bl word ( Get the next parameter from the input buffer ) count dup ( Get the address and count, and duplicate the count ) while ( Check for zero length ) space type ( Type the parameter ) repeat 2drop cr ( Drop the address and count of the null string ) ;As someone stated earlier, the OS is really the kernel. The user talks to the kernel through the shell, and the commands are either implemented directly in the shell or consist of other programs. A Linux-like OS can be implemented in any language, and for the most part the details of the language are hidden from the user. So a Linux-like OS written in Forth should hide most of the details of Forth from the user. However, since Forth is already a scripting language, it would be convenient to use Forth for the shell scripting language.Of course, it's also possible use Forth itself as the OS. In that case it is no longer a Linux-like OS, and the commands should probably be more Forth-like.
So how would I define a word that uses "cat" to type out the contents of a file and then deletes the file? If cat and rm took their arguments on the stack I could do this:
Then I could call it like this:
How would I do this using the current implementation of cat and rm?
Edit: Changed "dup" to "2dup" because S" leaves two values on the stack.
No language is "natural". Languages are habitual. Saying "uhm", "like", "you know" every few words is habitual too, but don't make communication easier, and yet people do this and can't seem to stop.
Some folks develop habits, and become inflexible. Its ok, just a minor burden on the rest of us.
Interesting question. I thought I knew, but my opinion could be entirely subjective. I ran into this problem in my English classes when Viagra first came out... there were at least two versions of pronunciation.
You could ask Dave Hein, but you may not like the answer. It is an odd word... all consonants, no vowels.
I wonder if the p or the f might be silent... maybe both.
I suspect that it mimics the sound of puncturing an under-inflated balloon. Is that a clear description?
Or, maybe it is closer to the sound you make to get the attention of a waitress in an expensive restaurant when you don't want everyone to hear you.
Or, it could be a very Zen presentation, a written word without sound representation that merely abbreviates P for propeller and fth for forth. (Somewhat akin to the sound of one hand clapping.)
I also seem to recall pfth being a sound that someone makes to indicate they dislike and dismiss something without further comment.
Just like with any Forth skill, the training must start early.......
EDIT: The ANS Forth standard specifies how >IN works. It's one of the required CORE words.
Hmmmm.... I haven't figured out >in either and I've been at this for several months now, over half a year.
What I have learned is that you can do a great deal in Forth without knowing how the buffers and inner and outer interpreter word. >in is a word that is part of lower levels of the system.
There is a document about eForth that explains all this more clearly than I can ever do so. Try page 26. The eForth document explains the system from the bottom up; while most Forth tutorials begin with presenting the ways and means to do things that are familiar to the reader and never cover the whole.
Or it's that sound of contempt when you don't need some trivial thing, as in "pfth don't bother me with that"
I am not even sure a 'computer programing language' really qualifies as a language at all... And natural is just about the most abused adjective known to humanity. Everything that exists is part of nature.
Dave Hein has deployed extremely deep irony into the naming of his product.. you will be asking yourself alternatives for many years to come.
I am going to say "good night" and read my eForth document.