README 6.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283
  1. SELSL is a Simple English Like Scripting Language
  2. It is implemented in Go language for use with Go muds, such as my Woe
  3. MUD engine. It is indended to be usable both as an interective command
  4. interpreter for the users of the MUD as well as a scripting language
  5. for the builders.
  6. While the goal is to be english like, a second goal is to be simple,
  7. so it does not use any advanced AI like techniques to parse the
  8. input. Rarther it uses a few simple rules to reduce the user input to
  9. commands, and blocks of commands.
  10. he
  11. him
  12. his
  13. she
  14. her
  15. hers
  16. they
  17. them
  18. their
  19. theirs
  20. it
  21. its
  22. me
  23. myself
  24. i
  25. Rethinking the OOP part: SELSL is focused for use in MUDS and similar.
  26. Thinking about it pure OOP is a bad fit for that. We can see this from this
  27. example command: "Move apple from tree to box." On which object this
  28. command is acting? On the apple as it would seem? But the apple itself is
  29. basically unchanged, only it's membership changed from being part of the tree
  30. to being in of box. The tree and box are also changed, but which one of the two
  31. should get the method then? It does not make sense to define the method on
  32. either.
  33. Furthermore, there's another object in play and that is the player/actor
  34. themselves who actually moves the object. In a MUD this may e.g.
  35. add fattigue to the player, like it does in real life.
  36. And then there is the environment in which these objects may be present,
  37. or even absent. In a MUD this will be a room in a zone in a land. That room,
  38. or even other adjacent rooms can be modified by the action of the actor.
  39. For example a text message may need to be displayed to all other actors in the
  40. room.
  41. All in all the OOP model is too simple because it put primacy on a single
  42. object, and defines the operation to one of the involved objects while
  43. treating the others as second class parameters.
  44. What I think would be better for SELSL is ACtor Oriented Programming (ACOP)
  45. where the actor defines all the operations, but where the environment is always
  46. an implicit parameter (may be expicit in the Go side). Like this actor
  47. permissions also become trivial because actors can be defined to only
  48. know about those actions they are allowed to perform, and furher permission
  49. checks can be done if necessary before even calling the action.
  50. This shifts the burden away from the actions themselves which might
  51. then be implemented ignoring permissions since that is checked an a higher
  52. level. The only exception to this would be commands that can afffect other
  53. actors.
  54. Of course, then typing does become relevant again, because opening a door
  55. is different from opening a container. Still it should me possible to overload
  56. these two operations based on the types of the objects involved. Having
  57. automatic overloading is easier and more flexible than having to manually
  58. extend the open operation every time it has to act on some different object.
  59. Of course, all this this goes for object simulation in a MUD-like world.
  60. For simpler operations like maths or string concatenation, or any pure
  61. functions without side effects for that matter, the result of the operation
  62. does not depend on the environment, only on the operands, so maybe a special
  63. scheme is needed for lower level pure functions or similar operations.
  64. These might be defined on some kind of "universe" level.
  65. SELSL is object oriented but not class based. In stead it is prototype
  66. based much like the SELF language. In SELSL, everything is an object.
  67. Objects have slots that can contain other values. There are basic objects
  68. which evaluate to themselves, and excutable objects which perform
  69. some computation to produce their result.
  70. An object also has an effect on computation. Normal objects have no effect,
  71. but a Return causes the block to end execution early. A Throw
  72. will keep on unless if it is stopped with a Catch.
  73. Variables, and also arguments are simply slots of the current activation
  74. record of an executable object. There are no stand alone variables.
  75. Eveything exists in something else, except for the top level "world".
  76. There is also a "me" object which represents the the current actor
  77. that is operating on the state of the world.
  78. A SELSL script consists of commands. Commands operate on the state of the
  79. world and may cause output to be produced as well.
  80. A command begins with a verb and is optionally followed by the objects the
  81. command perates on. If a command has no objects it will operate on the
  82. "me" object. Commands are separated from each other by one of
  83. the English prepositions or conjunctions that SELSL accepts. See below for
  84. the lists. Commands are also separated by the particles "a", "an", "the",
  85. or the demonstratives "this", "that", "those".
  86. A command is ended by a period. A column in a command announces the start of a
  87. block. The command end ends a block.
  88. Teach an actor to open a door do
  89. Check if door's open then
  90. Set door's open to false.
  91. Tell an actor to: Format "You close the %s" with door's name;
  92. else do
  93. Tell an actor to: Format "The %s is already closed" with door's name;
  94. end of check.
  95. End of teach.
  96. Set hp of me as add 1 with divide hp of me by 2 end end
  97. Create a red door as a door.
  98. open red door with green ke
  99. cast cure light at smart bob
  100. (This is (nestable)
  101. multi line comment)
  102. # This is single line comment for compatibility with shell scripts.
  103. end of command with `.` or newline
  104. start of block with `:`, do.
  105. end of block with 'end', ';', ''
  106. Syntactic sugar: `as` and `with` are translated to `to do`
  107. SCRIPT -> COMMAND eoc EOC SCRIPT | .
  108. EOC -> eoc EOC | .
  109. COMMAND -> word EXPRESSIONS .
  110. EXPRESSIONS -> EXPRESSION separator EXPRESSIONS | .
  111. EXPRESSION -> OBJECT | number | BLOCK.
  112. OBJECT-> word ATTRIBUTES .
  113. ATTRIBUTES -> OFS EXPRESSION | .
  114. OFS -> of | s .
  115. BLOCK -> ob SCRIPT END .
  116. END -> end COMMAND .
  117. Including queries:
  118. SCRIPT -> COMMAND eoc EOC SCRIPT | .
  119. EOC -> eoc EOC | .
  120. COMMAND -> word EXPRESSIONS .
  121. EXPRESSIONS -> EXPRESSION separator EXPRESSIONS | .
  122. EXPRESSION -> OBJECT | number | BLOCK | QUERY .
  123. QUERY -> ISQUERY | QWQUERY.
  124. ISQUERY -> is EXPRESSION qm .
  125. QWQUERY -> qw EXPRESSION qm .
  126. OBJECT-> word ATTRIBUTES .
  127. ATTRIBUTES -> OFS EXPRESSION | .
  128. OFS -> of | s .
  129. BLOCK -> ob SCRIPT END .
  130. END -> end COMMAND .
  131. Conjunction List
  132. After
  133. Although
  134. As
  135. Because
  136. Before
  137. Even
  138. If
  139. Inasmuch
  140. Lest
  141. Now
  142. Once
  143. Provided
  144. Rather
  145. Since
  146. So
  147. Supposing
  148. Than
  149. That
  150. Though
  151. Till
  152. Unless
  153. Until
  154. When
  155. Whenever
  156. Where
  157. Whereas
  158. Wherever
  159. Whether
  160. Which
  161. While
  162. Who
  163. Whoever
  164. Why
  165. Preposition List.
  166. about
  167. aboard
  168. above
  169. across
  170. after
  171. against
  172. along
  173. amid
  174. among
  175. around
  176. as
  177. at
  178. before
  179. behind
  180. below
  181. beneath
  182. beside
  183. between
  184. beyond
  185. but
  186. by
  187. concerning
  188. considering
  189. despite
  190. down
  191. during
  192. except
  193. following
  194. for
  195. from
  196. in
  197. inside
  198. into
  199. like
  200. minus
  201. near
  202. next
  203. of
  204. off
  205. on
  206. onto
  207. opposite
  208. out
  209. outside
  210. over
  211. past
  212. per
  213. plus
  214. regarding
  215. round
  216. save
  217. since
  218. than
  219. through
  220. till
  221. to
  222. toward
  223. under
  224. underneath
  225. unlike
  226. until
  227. up
  228. upon
  229. versus
  230. via
  231. with
  232. within
  233. without