SELSL is a Simple English Like Scripting Language It is implemented in Go language for use with Go muds, such as my Woe MUD engine. It is indended to be usable both as an interective command interpreter for the users of the MUD as well as a scripting language for the builders. While the goal is to be english like, a second goal is to be simple, so it does not use any advanced AI like techniques to parse the input. Rarther it uses a few simple rules to reduce the user input to commands, and blocks of commands. he him his she her hers they them their theirs it its me myself i Rethinking the OOP part: SELSL is focused for use in MUDs and similar. Thinking about, it pure OOP is a bad fit for that. We can see this from this example command: "Move apple from tree to box." On which object this command is acting? On the apple as it would seem? But the apple itself is basically unchanged, only it's membership changed from being part of the tree to being in of box. The tree and box are also changed, but which one of the two should get the method then? It does not make sense to define the method on either. Furthermore, there's another object in play and that is the player/actor themselves who actually moves the object. In a MUD this may e.g. add fatigue to the player, like it does in real life. And then there is the environment in which these objects may be present, or even absent. In a MUD this will be a room in a zone in a land. That room, or even other adjacent rooms can be modified by the action of the actor. For example a text message may need to be displayed to all other actors in the room. All in all the OOP model is too simple because it put primacy on a single object, and defines the operation to one of the involved objects while treating the others as second class parameters. What I think would be better for SELSL is ACtor Oriented Programming (ACOP) where the actor defines all the operations, but where the environment is always an implicit parameter (may be expicit in the Go side). Like this actor permissions also become trivial because actors can be defined to only know about those actions they are allowed to perform, and furher permission checks can be done if necessary before even calling the action. This shifts the burden away from the actions themselves which might then be implemented ignoring permissions since that is checked an a higher level. The only exception to this would be commands that can afffect other actors. Of course, then typing does become relevant again, because opening a door is different from opening a container. Still it should me possible to overload these two operations based on the types of the objects involved. Having automatic overloading is easier and more flexible than having to manually extend the open operation every time it has to act on some different object. Of course, all this this goes for object simulation in a MUD-like world. For simpler operations like maths or string concatenation, or any pure functions without side effects for that matter, the result of the operation does not depend on the environment, only on the operands, so maybe a special scheme is needed for lower level pure functions or similar operations. These might be defined on some kind of "universe" level. Another aspect is that of pass by name versus pass by reference. High level actions which the actor performed are based on the name of the objects. Lower level functions on the other hand have to operate on references to the objects or copies of the objects themselves. The named objects therefore need to be looked up by name, and then, if found, handled by reference or by copy. SELSL does have simplified objects, but without inheritance, only with message passing. Every object can also evaluate itself in a context. There are basic objects which evaluate to themselves, and excutable objects which perform some computation to produce their result. An object also has an effect on computation. Normal objects have no effect, but a Break causes the block to end execution early, a Return causes the wrapping function of mehod toreturn a value, and a Throw will keep on breaking out of scopes and bublle back to the top unless if it is stopped with a Catch. A SELSL script consists of commands. Commands operate on the state of the world and may cause output to be produced as well. A command begins with a verb and is optionally followed by the objects the command perates on. If a command has no objects it will operate on the "me" object. Commands are separated from each other by one of the English prepositions or conjunctions that SELSL accepts. See below for the lists. Commands are also separated by the particles "a", "an", "the", or the demonstratives "this", "that", "those". Text in the SELSL input that is not a quoted string or a number is normally a name. However, if it is peceed by a or an, it is a type, and if preceded by this, that, those, or such, it is a variable. If it is preceded by "the", it is explicitly a name. Selsl is case insensitive, by folding every character to lower case. This also goes for names, so internally Bob should be referred to as bob. A command is ended by a period. A column in a command announces the start of a block. The command end ends a block. Teach an actor to open a door do Check is that door's open then Set that door's open to false. Order that actor to: Format "You close the %s" with name of that door; else do Order that actor to: Format "The %s is already closed" with name of that door; end of check. End of teach. Set hp of me as add 1 with divide hp of me by 2 end end Create a red door as a door. open red door with green key cast cure light at smart bob SELSL sytax is configurable in that the key words can be configured before parsing. This could allow key words from non-English languages to be used. (This is (nestable) multi line comment) # This is single line comment for compatibility with shell scripts. end of command with `.` or newline start of block with `:`, do, then, else . end of block with 'end', ';', '' Syntactic sugar: `as` and `with` are translated to `to do` SCRIPT -> COMMAND eoc EOC SCRIPT | . EOC -> eoc EOC | . COMMAND -> word EXPRESSIONS . EXPRESSIONS -> EXPRESSION separator EXPRESSIONS | . EXPRESSION -> OBJECT | number | BLOCK | QUERY . QUERY -> ISQUERY | QWQUERY. ISQUERY -> is EXPRESSION qm . QWQUERY -> qw EXPRESSION qm . OBJECT-> word ATTRIBUTES . ATTRIBUTES -> OFS EXPRESSION | . OFS -> of | s . BLOCK -> ob SCRIPT END . END -> end COMMANDOFS . COMMANDOFS -> COMMAND | OFS . SCRIPT -> COMMAND eoc EOC SCRIPT | . EOC -> eoc EOC | . COMMAND -> word EXPRESSIONS . EXPRESSIONS -> EXPRESSION separator EXPRESSIONS | . EXPRESSION -> OBJECT | string | number | BLOCK | QUERY . QUERY -> ISQUERY | QWQUERY. ISQUERY -> is EXPRESSION qm . QWQUERY -> qw EXPRESSION qm . OBJECT-> WORD ATTRIBUTES . WORD -> name | variable . ATTRIBUTES -> OFS EXPRESSION | . OFS -> of | s . BLOCK -> ob SCRIPT END . END -> end COMMANDOFS . COMMANDOFS -> COMMAND | OFS . Conjunction List After Although As Because Before Even If Inasmuch Lest Now Once Provided Rather Since So Supposing Than That Though Till Unless Until When Whenever Where Whereas Wherever Whether Which While Who Whoever Why Preposition List. about aboard above across after against along amid among around as at before behind below beneath beside between beyond but by concerning considering despite down during except following for from in inside into like minus near next of off on onto opposite out outside over past per plus regarding round save since than through till to toward under underneath unlike until up upon versus via with within without