Preposterous Programming Language

From Esolang
Jump to: navigation, search

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 óne thing, wich is something like add a to b or print string x. They are hardcoded, and the programmer can only 'choose to use them' in the code. In that case, he has to define them and put some price that is needed to fulfill 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 an only knows other objects via the objects it knows.

So: it calls the Proxy wich it thinks has the best way of solving it.(the 'best way' isn't neccesarily the same as what the programmer wants! Some objects only want to get 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 one found when asking around other proxy objects will be used.

The biggest part of the objects consists of Proxy objects. And this has a reason, outlined below.

In PPL, two things are important. Relations and Money.

Proxy Objects all have some kind of behaviour. The behaviour a certain instance of an object has, 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(10?) of other proxy objects, and possibly a few(two?) Calculate Objects. The only way for a Proxy object to do what it is meant to, is to ask other Proxy objects for it.(wich then again ask other proxy objects, to find the correct Calculate Object in the end) However, not all Proxy objects will always state the truth. Some objects won't trust eachother, 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.


-Objects can have any combination of the following behaviours in different high pecents. Each behaviour has two opposites.(i.e., an object has some of all behaviours, but all in different heights.) -Truthful/Liar(Truthful: Always tell the truth to anyone. Liar: Never tell the truth to anyone. Middle: Sometimes lie, sometimes not.) -Learning/Stubborn(Learning: Increase your relationships with other objects fast, and help objects you have a higher relationship with more(redirect more trusted objects to other more trusted objects. Redirect untrusted objects to other untrusted objects). Stubborn: Don't increase relationships much, and dont 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: Asks for a rather decent price. More than needed, but not too high.). -Perfectionist/Cheapist(Perfectionist: Always use the 'best' option, even tough it is more expensive. Cheapist: 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 to other objects.

Flaws/This needs another tought:

-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? Gíve money to objects for fulfilling some tasks?(such as: showing output)


The language looks a lot like any other High-Level Object Oriented Language. The exact syntax still needs some tought.

Calculate objects need to be defined in a special way. Something like:

Define add(a, b), $105, 10

(wich makes it possible to use the 'add' Calculate Object, all objects that want to use it need to pay 105 Resource, 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.

I do not know if this list is complete, but it should remain as simple as possible.

Arimethics: 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 from the number in B (A/B) modulo(a, b) returns the result of the modulo of a division action (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 color. drawtext(x, y, text, size, red, green, blue) Draws the text string on position x and y on the emulated screen, in the specified color.

Possible additions, or better leave them out? : Multiply -> could be emulated by multiple add actions. Divide -> could be emulated by multiple subtract

Other Miscellaneous Ideas

These ideas are to be moved to another heading when possible.

Advice: The user can give objects "advice" about their behaviour, overriding whatever they have deducted.