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