selsl/README

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 fattigue 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.





SELSL is object oriented but not class based. In stead it is prototype
based much like the SELF language. In SELSL, everything is an object.
Objects have slots that can contain other values. 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 Return causes the block to end execution early. A Throw
will keep on unless if it is stopped with a Catch.

Variables, and also arguments are simply slots of the current activation
record of an executable object.  There are no stand alone variables.
Eveything exists in something else, except for the top level "world".
There is also a "me" object which represents the the current actor
that is operating on the state of the world.

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".

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 if door's open then
		Set door's open to false.
		Tell an actor to: Format "You close the %s" with door's name;
	else do
		Tell an actor to: Format "The %s is already closed" with door's name;
	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 ke

cast cure light at smart bob



(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.
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.
OBJECT-> word ATTRIBUTES .
ATTRIBUTES -> OFS EXPRESSION | .
OFS -> of | s .
BLOCK -> ob SCRIPT END .
END -> end COMMAND .

Including queries:

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 COMMAND .

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