A bit of Boolean Logic, and Simplistic Keyboard Input
The nuts and bolts of personal computers are not just the idea of ‘1′ and ‘0′, one and zero, or ‘pretty much electricity’ (not that much actually, just a couple of volts or so) and ‘very little electricity’, but also how we combine these 1s and 0s, or 'bits', by means of so-called Boolean AND, and Boolean OR.
We say 'Boolean' (or 'boolean') to distinguish digital computer versions of AND and OR, and some more like NOT, from the far richer, deeper and more nuanced versions we operate with eg in English natural language, in writing, thinking, talking, reading, reasoning.
You might say to some friends--"Are we going to a pool, or to the real wild beach? But the beach will be an expedition!" Notice the word 'or'. It really means something exclusive in this case. The digital computer version of it would be, in this case, more XOR than OR. For the normal, much-used OR in dealing with bits is highly inclusive.
We call these things 'boolean' to honor a philosopher, George Boole, who worked out some of these notions in the middle of the 19th century, in England; although of course people had been musing about these things in various parts of the world ever since the beginning of thought, more or less.
Well, there's a lot more to these themes; but let's get on with our example program. For now, the key point is this: a digital computer offers you a way to check whether one or both bits are 1, by its Boolean OR. In G15 PMN, this is, conveniently enough, a two-letter predefined word, OR (we write it in this text by capital letters, although when you type it in, it's important to avoid using the capital form, although the ROBOTFONT always look rather capital {a bit like russian letters in this sense}.
So the OR fetches the two upmost numbers on stack, assuming that they are either 0 or 1. In other programming languages, it may be other values to represent the 'yes' or 'no', the 'true' or 'false', but this is a simple rugged good classical way of doing it that really works quite well, and which is intuitively entirely easy. So OR produces 1 when both are 1 as input to it, or at least 1. Otherwise, with both 0, it produces 0. These boolean operators, as they are also called, typically presume that you only feed them with 1 or 0. {Elsewhere, we look into N? and YE, which elegantly also handle other numbers than 1 and 0 so that they can be inputted into functions expecting only a zero or a one.}
In contrast, the Boolean AND--we just write "AN" in G15 PMN--is more demanding. It gives a yeah, a 1, only when BOTH are 1.
All this is fine, but what can we do with it? Well, we need to have some sort of action that is dependent on 1s and on 0s,--conditioned, we might say, by these bits. We want gates, in a way, that open given a certain condition. So you can see the meaning of the term 'conditional expression' and also, as used in electronics, 'digital gates' or 'boolean gates'. In terms of electronics, we are speaking of how such as the little components called 'transistors', made of metals that aren't quite electricity-conducting metals but halfway so--semi-conductors, we call them--and germanium and silicium are the two most well-known examples: these transistors can be used pretty much to handle what in programming languages are 'conditional expressions', ie, expressions, or statements, or commands, that perform given a certain boolean input, but not with other types of boolean input. All these long words! But our example is very easy. Let's go straight at it. The word we need, though, to act on the 1s and 0s to get a variation, in this case, is "SE". You can easily think of it as an abbreviation of the word "see". It can be thought of this way: 'Have a look at the input. Is it 1, then do what's on the next line. If not, just skip the next line.'
Turning now to the program, we this time use disk F, cards F1, F2 and so on. An example output is shown first. What I typed isn't shown, because the program doesn't have an instruction to show what's typed. But I typed 1 and 1, then I typed 1 and 0, and finally 0 and 0. The outputs are different in each case. After the two first runs, I typed F and NN also, to check that the stack, the desk you know, has good paper-order! And it does, since 123456 is produced. This result came about by using the High-powered PMN Terminal. If you use the elementary form of G15 PMN without all the extra predefined words and all the extra high-level functions, or subprograms, in the High-Powered programs, just skip the F and NN part, for it doesn't have 123456 lying on the desk, on the stack, as a standard. But both can run these cards, for they are programmed using only elementary G15 PMN words.
Now, if you do a lot of work with putting stuff to cards, you may want to check that the next card after the final card is properly empty: so that the G15 PMN compiler knows where to stop, and when to start your program. So here we have included a screencopy of what a socalled "nilcard" looks like. It has Ascii values 0 all over the place. This you can check, if you like, by going into the {MENU} mode, by CTR-W, and then clicking with the mouse on the folder-like symbols. Still in this mode, you can do PgUp and PgDn or CTR-L to another card, and you can click on various numbers and letters and learn something of their inner values, their ASCII values. You will also see, if you click on the digit 0, that it shows that it has value 48. In addition to the ASCII value, you will also get the 'coordinate' of the character you clicked on, namely what position on the line, and which of the 8 lines, in the large ROBOTFONT cards in the CAR editor in G15 PMN. This is a graphical approach to presenting stuff that evolved naturally together with the G15 CPU concept and the PMN programming approach. Let me also say that CTR-R brings you to the middle of the card, where the second column begins. Pressing CTR-R also allows you to test if you are using slim enough columns. G15 PMN is very strict about this: the words must be short, they must fit within these narrow columns; and then we read the columns vertically; but we have two of them, and so both sides, in a way, of the brain, have some stimulation in this. Also, the slenderness tends to suggest elegant shapes.
Anyway, if the next card after the final card you have filled in with a new program isn't the nilcard, you can just copy the nilcard from somewhere else. For instance, go to K:1000 or L:1 or anywhere where there is a nilcard. Press CTR-C to copy it, and press lineshift or ENTER or what you call it. Then do CTR-L to open the F5 card that you want emptied. Press CTR-T to put it there, and press space to confirm.
In the first card, which in our example is F1, but you can put it anywhere you like--of course, it is somewhat easier to make new programs where you have small-sized cardnumbers, rather than going into card-numbers involving many digits,--for you have to type them in all the time--that's part of the mind-stimulating process of programming in this way--anyway, in the first card, there are comments. These are preceeded by a vertical bar | at the first position in the column. It is a good norm also to have vertical bars right after the naming of a new function to tell what should be given to the function and what comes out of it, except where it is very obvious.
So at F1, we have two simple functions, or programs, or algorithms, or subprograms,--call them what you like--that simply gives some text on the screen.
In F2, we invoke a very simple form of keyboard input, one that has more advanced forms, such as KI, to handle also function-keys and that is part of the High-Powered PMN Terminal. This High-Powered stuff you can incorporate into the beginning of any program. It is the normal thing to do,--either this one, or the even more high-powered part that is at the start of the Calendar program on the home page G:15. The KK gets the ASCII value of what is typed. A space becomes 32, a capital A becomes 65, an 'a' becomes 97, and, what is significant in this case, the digit 1 gets the value 49 (0..9 has ASCII values 48..58). The operator or function, the PD, predefined word EQ, compares for equality, and produces a 1 when the two numbers it fetched from the stack are equal, otherwise a 0. So this function outputs 1 or 0, after having a wait for keyboard input. Anything typed of letters and so on will give a 0 as output, in this case. Typing 1 gives 1.
In F3, we call on this routine, the CHKINPUTFOR1, twice. We store the results in some very useful locations. We use S1 and S2 to store in location I1 and I2. What is beautiful about these so-called local variables, of which you have twenty automatically for each function, is that they don't affect the variables of other functions, as a general rule. They are like private folders or mini-desks for each function. The ease with which this can be done, in with as speedy and computationally effective results as in this case, is rare amongst programming languages; and the way done it here is not something we've seen elsewhere. You can say T1 and T2 instead of S1 and S2 but then the output is by means of using J1 and J2 instead of I1 and I2.
So, in F4, we apply what we know about OR and AN: we get the PMN to say that 'at least one is 1' when the OR outputs a 1, and we get the PMN to say that 'all are 1' when the AN outputs 1. The SE sees to this selection, it reads the output of the OR or AN just before it--it expects a 0 or 1 on the stack. What follows after SE--and there are some others also, but this one is eminently useful--you should have a simple function call, not a quote or number or something like that. The line doesn't have to follow right after SE, by the way--you can have several blank lines after it. It is often a good practise to put a blank line in before and after a SE, when there is otherwise room, because any such conditional action is such a critical point in a program that it deserves maximal attention. Nevertheless, the exception to the rule that proves the rule, in the final column on the right side of F:4 we don't have these extra blank lines. This is because we wanted to fit in the ZZ part, that tells how the program should start up.
When you compile it, by typing ^F1 and, on the next line, CC, in the High-Powered PMN Terminal in the utility menu, then you can type TRYIT again and again until you're satisfied your program works well, then QU to get back to CAR editor, CTR-Q to exit CAR, and REB to reboot the G15 PC. Whenever you have done any changes to cards, this is a way to flush the conctent to the disk, so that, if your program causes the platform to somehow stop, you still have saved your works. Programmers should do REB all the time, to refresh the whole lot. Remember that the CAR editor is written in G15, and so if your program runs into doing lots of funny changes of RAM, it can change the CAR editor temporarily: that's why the use of REB is such a key-thing while we program much. And don't worry if the computer stops when you program. As a rule, the errors with the most drastic effects are the easiest to fix!













