Preposterous Programming Language
Language Specification of Preposterious Programming Language(PPL). Better Sorted.
I read about this idea in the 'List of Ideas' section of this wiki ( Preposterous Programming ).
This page is a special page because I tried to create some kind of real Language for it. This is a Work in Progress, and if anybody has some ideas, feel free to add them in the page, or on the discussion page.
Enjoy. ~Qqwy(no account yet)
Preposterious Programming Language(PPL)
PPL(pronounced 'People') is an Object Oriented Programming Language.
However, there are no child/parent objects. All objects are 'global'.
There are two kinds of objects:
- 'Calculate' Objects. These objects can only do one thing, which is something like 'add a to b' or 'print string x'. They are hardcoded into the language, and the programmer can only 'choose to use them' in the code. In that case, they have to define them and assign some price required for them fulfilling their action. - 'Proxy' Objects. These objects will use 'calls*' to the different proxy and calculate objects' methods. *However, these calls aren't direct since an object doesn't know all objects, but has a limited social network. It only knows of the existence other objects via the objects it knows first-hand.
Hence it calls the Proxy which it thinks has the best way of solving it. (Note that the 'best way' is not necessarily the same as what the programmer wants! Some objects only care about getting rich.) Additional notes: -A Proxy can have multiple methods and multiple fields. A Calculate only one method, and no fields. -When two objects of different classes have a method with the same name and parameter-amount, the method that will be used depends on the order they are discovered when an object interacts with other Proxy objects.
The most important objects are Proxy objects. The rationale is outline below:
In PPL, two things are important.: Relations and Money.
Proxy objects all have some behaviour. How a certain instance of an object behaves is different each time the program is run. (Calculate objects do not have behaviour. However, they have a basic 'price' needed to perform their simple operation.)
Proxy objects have money. The programmer determines what classes should have how much money at the beginning of the program.
Relationships are important. When an Proxy object is created, it only knows about a certain number (say, 10) of other proxy objects, and possibly a few (for instance 2) Calculate objects. The only way for a Proxy object to do what it is meant to, is to ask other Proxy objects for it. (These then again ask other proxy objects, to eventually find the correct Calculate object in the end) However, not all Proxy objects will always state the truth. Some objects won't trust each other, and some objects will simply always lie or give incorrect answers.
This is why Relations are important. When an Proxy object asks another Proxy object about something, the Relationship of both objects increases. Objects that behave in some way will more frequently use objects that they have a higher relationship with. Others groups however don't bother the relationships.
-Relationships increase when there is interaction between two objects. -Relationships decrease when there is no interaction for a long time, or when an object finds out that another object is lying.
How can an object find out how another object is lying? -By getting different answers on values that should stay the same. -By getting another result by another source that is trusted more at this point. -By getting many results from other sources that are trusted less.
Behaviours:
-Objects can have any combination of the following behaviours to different degrees. Each object will have some quantity in each score. -Truthful/Liar (Truthful: Always tell the truth to anyone. Liar: Never tell the truth to anyone. Middle: Lie sometimes, especially to those you don't trust.) -Learning/Stubborn (Learning: Increase your relationships with other objects fast, and help objects you have a higher relationship with more (redirecting trusted objects to other trusted objects. Redirect untrusted objects to other untrusted objects). Stubborn: Don't increase relationships much, and don't help 'friends'. Middle: Don't learn too fast.) -Charity/Dagobert (Charity: Only ask the minimum price for doing tasks. Dagobert: Ask a price as high as possible. Only lower this price when nobody goes to you since others are better. Middle: Ask for a rather decent price. More than needed, but not too high.) -Perfectionist/Pragmatist (Perfectionist: Always use the 'best' option, even if it is more expensive. Pragmatist: Use the option that is the least expensive. Don't bother if the option isn't completely working correct. Middle: Tries to find some option that is the best for its money.)
These behaviours are randomly determined when a certain object is created. The programmer has no way of knowing beforehand how an object will behave with other objects.
Flaws/Areas that need more thought:
-Money is given to new instances. However, by creating more and more instances, there will be more and more money? Or should there be some other way? Give money to objects for fulfilling some tasks, e.g. showing output?
Syntax
The language looks a lot like any other High-Level Object Oriented Language. The exact syntax still needs some thought.
Calculate objects need to be defined in a special way. Something like:
Define add(a, b), $105, 10
(This makes it possible to use the 'add' Calculate Object; all objects that want to use it need to pay 105, and there are a total of 10 'add' Calculate Objects.)
Calculate Classes
Only the calculate classes below exist. These are the only ways to finally calculate stuff, do Input/Output, et cetera.
This list may be incomplete, but it should remain as simple as possible.
Arithmetic: add(a, b) returns the result of adding the number in A to the number in B. (A+B) subtract(a, b) returns the result of subtracting the number in B from the number in A. (A-B) divide(a, b) returns the result of dividing the number in A by the number in B. (A/B) modulo(a, b) returns the result of the modulo of a division operation. (A%B)
Input: getKey(keyID) Returns false when the key with the keyID(the ID the key has on the keyboard) is not pressed. getInput() Returns the string the user inputted, until the user pressed the Return(enter) button. getMouseX() Returns the X position of the mouse on the emulated screen. -1 if the mouse is not on it. getMouseY() Returns the Y position of the mouse on the emulated screen. -1 if the mouse is not on it.
Output: print(string). Prints string to the text-output. drawpixel(x, y, red,green,blue) Sets a pixel on the emulated screen to a certain colour. drawtext(x, y, text, size, red, green, blue) Draws the text string on position x and y on the emulated screen, in the specified colour.
Possible additions: Multiply -> could be emulated by multiple add operations.
Possible subtractions: Divide -> could be emulated by multiple subtractions. Add -> could be emulated by subtracting a negative number.
Other Miscellaneous Ideas
These ideas do not yet have a heading to fit under.
Advice: The user can give objects "advice" about their behaviour, overriding whatever they have deduced.
- This is still a work in progress. It may be changed in the future.