ABLE - Assertion Based Language Experiment

Inspired by object oriented computer programming
languages, this is an attempt at an experimental
constructed language that might be spoken by
intelligent machines, or used as an interlingua
between human and intelligent machines ("Similar in
most respects to the binary language of moisture
vaporators").

The only motivation for the language is to explore the
possibilities of computer-like "thought processes" as
applied to language.  To avoid confusion I have opted
not to use the conventional object oriented terms
since they would only mislead the reader because the
way in which the concepts are applied here are quite
different from the way they are used in conventional
object oriented programming.  I have avoided
conventional grammatical terms for the same reason.
The use of conventional terms might tend to channel
the development of the system down conventional
pathways, and the avoidance of such terms seems to
allow for greater possiblilty of unexpected novelty.

Things

A thing is any entity, real or imaginary, abstract or
concrete, physical or immaterial that we wish to
discuss.

Assertions - Global and Instance

An assertion may specify something universal, or
something about a specific thing.  Assertions that
specify something that is universal, i.e. not
associated with any specific thing, are refered to as
global assertions.  Global assertion take some clause
in parentheses as their argument.

        Not( tuesday )

asserts, logically enough, that it is not tuesday.

Assertions that _do_ attach to a specific thing are
appended to that thing with a dot.  Assertions of this
type are called instance assertions.

        thing.Assertion( arguments )

Attribute Assertions

An attribute assertion is an instance assertion that
specifies the value of a particular attribute for an
object.  For example, to state that the color of a
balloon is red, we would write:

        balloon.Color( red )

The specific value of the attribute is placed in
parentheses as the argument of the assertion.  If we
wish to assert that the balloon is not red we would
use the global assertion "Not" which takes the entire
above clause as its argument:

        Not( balloon.Color( red ))

Attribute assertions may take more than one argument,
but each argument is assumed to be of the same type.
For example we might wish to say the flag is red,
white and blue:

        flag.Color( red white blue )

As long as the arguments are of the same type they are
considered to be a single multi-item argument.  This
statement, however, is not valid:

        *flag.Color( red white skinny )

since "skinny" is not a valid argument of type Color.

Action Assertions

An assertion that specifies that an action is, was, or
will be taking place which involves the object in some
manner is called an action assertion.  These typically
take more than one argument, and some arguments may be
optionally omitted.  It is required, therefore, that
each argument be identified as to its type.  For
example, to assert that John gives the book to Mary we
would write:

        john.Give( TO:mary WHAT:book )

Since each argument is tagged with its type the order
is irrelevant.

        john.Give( WHAT:book TO:mary )

We might also wish to include the optional tagged
argument "TENSE" and specifiy that John gave the book
to Mary, past tense:

        john.Give( TO:mary WHAT:book TENSE:past )

An argument may be further elaborated by attaching
attribute or action assertions to it.  For example,
"John gives the red book to Mary" would be writen:

        john.Give( TO:mary WHAT:book.Color( red ))

And to state that John gives the book to Mary who is
running home we would write:

        john.Give( TO:mary.Run( TO:home ) WHAT:book.Color(
red ))

As statements grow in length and complexity it becomes
increasingly difficult to parse them visually.  To
facilitate understanding we can use an indented form
of the statement as illustrated below:

john.Give
(
    TO:mary.Run( TO:home )
    WHAT:book.Color( red )
)

While indented form is not really necessary for that
statement, more complex statements will require this
form of presentation to be comprehnsible.  Consider
even this simple statement, for example:

Not
(
   Possible
   (
      Repair
      (
         BY:Include
         (
            All( horse.BelongTo( king ))
            All( man.LoyalTo( king ))
         )
         WHAT:humpty_dumpty
      )
   )
   TENSE:past
)

as compared to:

Not( Possible( Repair( BY:Include( All(
horse.BelongTo( king )) All( man.LoyalTo( king )))
WHAT:humpty_dumpty )) TENSE:past )

Note also the use of the "TENSE" type tag as an
argument to the "Not" global assertion.  While we
might not think of words like "not" as having tense,
in this application the word "Not" actually asserts
that "it is not the case that...".  The implied verb
in this instance being "is".  Thus "Not( ...
TENSE:past )" means "It _was_ not the case that...",
or in this example, "All the king's horses and all the
king's men _were_ not able ...".

This also illustrates the case where a global
assertion that normally takes only one un-tagged
argument can take an optional additional tagged
argument.

Concatenation of Assertions

It is often required to make more than one assertion
about a single thing.  For example, "The man wearing
the black hat is smiling at me."  Here we have two
things to say about the man, first that he is wearing
a black hat, and second that he is smiling at me.  We
do this by concatenating the assertions one after
another:

man.Wear( WHAT:hat.Color( black )).Smile( AT:me )
   OR
man.Smile( AT:me ).Wear( WHAT:hat.Color( black ))

Notice that this can be translated back into English
in a number of ways:

The man wearing the black hat smiles at me.
The man who is smiling at me is wearing a black hat.
The man is wearing a black hat and smiling at me.

In ABLE such distinctions appear to be lost.  Perhaps
there is a way to regain them, but I haven't explored
that yet.