Thelop Word

ThelopWords are the basic building blocks of the ThelopLanguage. They are used to form ThelopNames (sometimes called ThelopSentences) according to the ThelopRules following the ideas of LanguageOrientedProgramming.

ThelopWords work according to their meaning in ThelopWordClasses. There are currently four word classes: Objects (O), Actions (A), Properties (P) and Modifiers (M). In general a ThelopWord may belong to and work in one or more ThelopWordClasses. But this is not true for ThelopActionWord?s which belong to and work only in the ThelopActionClass?.

Most ThelopWords are either short English words or abbreviations of English words. They have been chosen carefully to avoid collisions and to build an efficient vocabulary.

In the ForthLanguage each construct is a word. So it might be an ideal candidate to experiment with the ThelopLanguage. -- fp

I know little Forth and never thought about using THELOP for it. Perhaps because the terse naming ideology of Forth doesn't fit well to the much longer ThelopNames. Technically it would be trivial to redefine Forth words to fit into LanguageOrientedProgramming, e.g. :

: TosPrintDrop . ;
: TosPrint dup . ;

but somehow I doubt that Forth people would like it. On the other hand using names *completely* describing functions would reduce the need to look into the documentation for stack effects and the potential naming problem (I think there must be a problem to find 5000+ consistent names for tomorrow's APIs) would disappear.

Perhaps because the terse naming ideology of Forth

What ideology is this? If ANSI Forth is at all a consideration, then remember that the core wordset documents only common usage of historical words. Literally all other Forth wordsets are packed with long-hyphenated-names-just-like-Lisp.

That being said, one can say that Forth coders have adopted an ad hoc convention -- the more you type it, the shorter it becomes. Note that this is just like a spoken language, where the more it's said, the shorter it becomes. For example, is not becomes isn't, and television becomes just TV.

As such, the most primitive of all Forth words tend to be atomic: @ ! + - * / AND OR XOR IF THEN ELSE DUP DROP SWAP OVER etc. The only really shorthand here is @ (fetch) ! (store) and DUP (duplicate).

Coding conventions involving atomic concepts also abound. Many words originally intended for use internally to a program, but which are used often, have short names. <# # #s and #> come immediately to mind. */ is perhaps an exception -- it is short for * / (the difference being that it uses a double-precision intermediate representation, which means */ is more precise than * and / in succession).

Conventions then find themselves using common symbols as prefixes. # maps to number of. / maps to size of. I personally use & to map to address of (from my C experience), though this is generally not necessary. So, for example, most Forth systems have a terminal input buffer (TIB) of a certain size (/TIB), with a certain number of characters inside it (#TIB). Some might argue that this bears much resemblence to Hungarian notation, and there is some argument for it. However, back in the day when Forth systems rarely allowed more than 8 characters in a word's name, adopting conventions like this were commonplace.

Today, I prefer to use longer names for most things, generally following a distinctively Smalltalk-ish look and feel. But, I will regularly adopt the use of short, concise, almost symbolic names for use with private words. There are generally less than 12 lines of code separating their definition from their use(s), so there is no problem at all with context. And with ForthLanguage being a HyperStaticGlobalEnvironment language, there is zero problems with re-using names either. The name p might draw a pixel to the screen in one part of the code, while in another it could establish a pipe with another process. Of course, I never intend you to call such names yourself; I'd rather you called drawPicture_toSurface_ or spawnProcessUsingCommand_ (note I use underscores in the order parameters appear on the stack; again, just another CodingConvention).

--SamuelFalvo?

CategoryThelop