Thelop Rule

ThelopRules are used in the ThelopLanguage to help creating ThelopNames from ThelopWords. Usually ThelopNames are CamelCase names looking like Wiki LinkPatterns:

FileOpen SystemGetTime StrFindChr

There is no real need to follow this "rule" strictly. If we use the words Screen and Clear to form a LOP name, we can form ScreenClear, screen_clear or SCREEN_CLEAR without destroying the readability or the meaning of the words. Usually (1) is preferred, but we may choose (2) or (3) or even a mix if there is a good reason for it. This depends on the ThelopHostLanguage and the situation (e.g. Java: Long and long).

List of THELOP name formation rules:

A ThelopName is built from ThelopWords
Each ThelopName contains at least two ThelopWords
Each ThelopName must start with a THELOP object word
Each ThelopName must contain at least one THELOP action word
ThelopNames are formed following ThelopNamePatterns.
ThelopNamePatterns are written using the shorthand characters for ThelopWordClasses (OAPM).
Typical patterns are: OA OAP OAPP OAPPP OAPM OAO OAOM ...
There are ThelopNameSignatures.
There are ThelopWordSignatures.
ThelopWordSignatures must add up according to the pattern to form the ThelopNameSignatures.
The function parameters must be in the same order as the corresponding ThelopWords within the function name.
Special words (e.g. "All") may change the signature of a ThelopWord in the Context of the affected ThelopName.
Unabbreviated ThelopNames may be simplified by stripping an obvious "RetErr" from the end of the name. E.g. the function name "FileSetPosRetErr" may be reduced to "FileSetPos" (the obvious error is that the position is out of range).
ThelopNames may be further simplified by stripping the second identical THELOP object word on binary actions. E.g. the function name "ImageCpyImage" may be reduced to "ImageCpy".

...(work in progress)

Additional THELOP rules for OO languages:

Static methods are named like functions
Instance method names may drop the initial object specification and Start with the THELOP action word. Thelop then relies on the programmer's proper naming of the object to make the meaning of the method call fully visible.

Additional THELOP rules (mixed):

Any ThelopWord must contain at least two characters.
Two character words (with a few exceptions like the THELOP action words "Is" and "In") are considered slang words and are only used as THELOP modifier words.
The default meaning of an English word used in THELOP is its computer world meaning, not its real world meaning. Examples: "File", "Window", "Parent", "Child" and even "String". If you need the real world meaning unambiguously, consider adding the slang modifier "Rw" (short for RealWorld) to build object specifications like "ParentRw" (like you and me) or "WindowRw" (your house or car).
There is never a plural form of a Thelop word. Any plural is expressed by modifiers (e.g. "All", "List", "Multi", "Count", ...).
All functions may assume that they get valid object references. Functions containing the word "Save" in their name check the validity of object references. Cleanup action words like "Free" or "Close" imply "Save" (such functions should be tolerant).
If there are more than one alternatives for a name, choose the most simple action. Prefer "Set", "Get", "Ret", "Cpy" and "Create" (in that order). Choose the more common words.
To extend the dictionary: choose reusable words. Keep the dictionary as small as possible.

So the rule for a name is...

: <noun> <verb>

Wouldn't the noun be redundant for Object Oriented methods? Sounds like LOP is intended for procedural programming languages. -- JeffGrigg

Personally I would prefer to have this redundant naming of OO instance methods but I think OO people would not like to change their habits so much. So the two rules (added above) are a compromise intended to build a bridge between procedural and OO languages. If you look at the symmetry of

 OO: object.setProperty(prop);
 PP: ObjectSetProperty(ob,prop);

this seems to make a lot of sense, especially if you consider the implicit passing of "this".

(actually LOP in a procedural language uses the convention ClassSetProperty( instance, property )).

LOP is about ideas, goals and principles. THELOP seeks to implement them in a way usable for any programming language. If a language has limits or very strong traditions then Thelop has to adapt to these boundary conditions. Almost every progamming language has special features, data types or built in classes that must be addressed and become part of the ThelopLanguage.

LOP and THELOP have been created to communicate and not to enforce rules.

If you want to create a grammar, why not use English as its base? Instead of using <object><verb> use <verb><object> for actions. In the example above, instead of writing ScreenClear() why not ClearScreen() or better yet ClearTheScreen().

Also, how does this apply to boolean tests? How would I define a function that determines if the screen is clear? I would again go the English route and write IsTheScreenClear().

in THELOP you would name it ScreenIsClear() or Screen.isClear()

English provides a grammar we already know. Why not use it? Of course, those of you who are not native English speakers should probably use the grammar of your native language.

Instead of using <object><verb> use <verb><object> for actions. In the example above, instead of writing ScreenClear() why not ClearScreen() or better yet ClearTheScreen().

Because we are sending a message. If you are talking to me, you don't have to preface each word intended for me with the name Robert.

robert: Robert, sit down. robert: Robert, stand up. robert: Robert, spin around.

Instead, you can just do the following:

robert: Sit down.

Just as you can:

screen: Clear yourself. screen: Draw a square using x,y,z and the color c

This is why they are called objects. They are the object of the sentence. The object provides a context. When someone writes:

 ClearScreen( screen_handle );

They are being redundant. In OO, we say that the screen_handle should be a private implementation detail of a screen object. Because of this, we prefer to say:

 screen.clear();

Because of this, if we change to a different system that uses something other than handles to represent the device context of a screen, we are not tied to it.

-- RobertDiFalco

...why not use English... ...why not use <action><object>...

In THELOP we try to unify the approaches of procedural programming and object oriented programming. You can do this with ScreenClear() and Screen.clear(). You can't do this with ClearScreen() and Screen.clear().

According to LOP any word in a name should "mean" something. It should tell us something about what the function is doing. E.g. the word "The" in ClearTheScreen carries no additional meaning (compared to ClearScreen), so it shouldn't be added. Also: names that tell us *completely* what a function is doing tend to become long. So we have to try to keep them short and simple. So: no "The" again. See also: OccamsRazor, SmallIsBeautiful.

THELOP names work also as namespaces. This is impossible if you use names like "OpenWindow" and "OpenFile". Functions that do similar things should also be near each other in alphabetic ordering. This eases the use of API reference ("what functions do I have available for Window...") considerably. Example: look up all functions in the Win32 API that have to do with "Window".

THELOP tries hard to reduce the number of possible names by goals and rules. This gives a high chance that two programmers will choose the same name for the same purpose. Even if this is not the case: correct use of LOP guarantees that two functions with the same name - written by independent programmers - have the same signature and do the same thing.

-- HelmutLeitner

"THELOP names work also as namespaces"

Why not use a language with proper support for namespaces? I can see the need for strict naming conventions in a language such as C which does not have a good module system, but in Java or C++ you already have support for namespaces at the module level, to group related classes, and at the class/object level, to group related functions and data into a single, named concept.

THELOP is not meant to enforce certain language feature, such as namespaces. THELOP wants to operate on top of any programming language. If a language doesn't have namespaces, THELOP may ease the problem. If a language does have namespaces the problem of consistent naming is still not touched.

"... names that tell us *completely* what a function is doing tend to become long. So we have to try to keep them short and simple."

What is wrong with long names? Isn't descriptive and readable preferable to short and terse? Why create a set of 3 letter abbreviations when there are perfectly good words that are already well known? Why not use fully descriptive names rather than a terse pidgin-language description?

I don't know a single programmer that works without abbreviations. Look at your own code. But the worst abbreviations are in functions like "doit" where all the words that are completely missing and might explain its meaning are abbreviated to nothing.

You have just met one. I gave up abbreviations shortly after compilers support variable names of more than 8 characters. I also include articles (a, an, the, my) with variable names for improved readability. And I am talking about what I actually do in my own code.

Variables are easy. What about function names?

"This gives a high chance that two programmers will choose the same name for the same purpose."

Why is it desirable for two different programmers to choose the same name for different functions? I would gladly accept variability in naming if in return I got descriptive names. In fact, in most languages without namespaces duplicate function names are a huge problem, not an advantage.

Using THELOP they can't do this. If they use the name by accident this means that they implement the same function (perhaps in different ways). If you are the one that is doing the CodeHarvesting choose the better implementation for your library module. If the second programmer notices the name clash first, he needn't implement the function, the job is already done. There is an immense benefit of making the function names coherent to what the function do.

Who is the global naming authority which ensures no duplication of data type names? Who gets ownership of "str"? Is it a C char *, a C++ std::basic_string<char *>, a VB variant holding a BSTR, or a myriad of other possibilities? Does CloseWindow() apply to a Microsoft window, a UNIX X-Window, or a car window in an onboard micro?

Currently there is no global naming authority, except that I created THELOP and currently define and describe it. In the future there might be a Wiki community that takes this position and maintains a ThelopDictionary.

There is no need to have different words for a BASIC "String" or a Java "String" or a C "Str". Just consider "String" and "Str" as synonyms and semantically equivalent and as the default data type used for text strings.

Then, to repeat the question from above, how does LOP prevent duplicate function names? If this is about API calls, then the function names will be shared among different languages. I still fail to see the advantage of your restrictive naming scheme.

The word "Window" is used in its computer world meaning. If you need the real world meaning (which is rare), I would suggest to create a special THELOP modifier word, e.g. "RealWorld" (perhaps abbreviated to a slang word "Rw") so that one can write

     WindowOpenTitleRect(...)
     CarSetWindowRwPosition(...)
     parent=WindowRetParent(...)
     PersonSetParentRwName(...)

but up to now, there was no need to add such a word. Again there is no need to have separate words for MS or UNIX GUI windows.

"Rw" sounds too much like "read/write" to me.
Ok, then this suggestion wasn't so good. What would you suggest? Perhaps just WindowReal? -- HelmutLeitner
Name it what it actually is. PowerWindow of course. --SamuelFalvo?

And let's add WindowIP for the IP sliding window. And maybe WindowRL for the window to launch a rocket. And WindowAR for displaying a window in an architectural drawing.

There is no need for sarcasm. I can't talk about your IP sliding window (no experience). The window for launching a rocket seems to be a "TimeRange". The window of an architectural drawing will be a redefinable construction pattern with its own namespace in a database (you will hardly have a function named to draw it, at least if the software design deserves its name).
It may look careless to introduce a "Rw" slang word, but it isn't. It would be a simple solution to a very general naming problem. Only after some time you see whether such a suggestion is accepted or not.

I thought LOP was supposed to support natural language programming. In the real world, names are reused.

A misunderstanding, LOP and THELOP are not meant to support natural language programming. Natural languages are not fit for this task. THELOP names are reused, but - if at all possible - with a consistent meaning.

You can't create a context free set of universal nouns.

You can try to be as context free as possible. A language for programming needs fewer words than a natural language and can create new words to avoid collisions.

Why try?

To ease reuse. To reduce the need for documentation. To display meaning without the need to interpret a context.

Have you ever ported programs between MS and UNIX? How do you prevent naming collisions?

No, I have not. There are no collisions between THELOP and the MS Win32 API. I suppose there won't be big problems between THELOP and UNIX. THELOP might be used as a portability wrapper.

CategoryThelop