Introduction to SCL™
by Eugene Asahara
September 2005
Last Updated: January 2, 2006
Audience: CIOs and other IT decision makers.
Level: 200
Technologies: .NET Framework
Introduction
SCL (Soft-Coded Logic) is my
implementation of Prolog enhanced with a new set of features outfitting it with
the capability of providing malleable logic services for distributed
applications. As the number and variety (embedded devices, RFID, etc) of
“nodes” on the Internet grows, the complexity, evolution (the rules are always
changing), and the mix of factors contributing towards decisions the
applications on these devices makes becomes overwhelming. This creates a need
for a mechanism that is geared towards handling complex and evolving logic.
SCL is such a mechanism. The
Prolog language itself is designed to deduce logical conclusions for a query by
inferring logical relationships from a list of facts. Complementing that
purpose with the capability of locating, aggregating, and refreshing facts from
multiple, diverse sources (other devices/applications/databases) fulfills that
need. I call the new Prolog features providing this capability “MetaFacts”.
Incorporation of SCL into
software applications results in a “separation of logic and procedure”. In a
nutshell, by “logic” I’m referring to the “IF” part of an IF-THEN statement and
“procedure” as the “THEN” part. For example, IF some set of conditions are met,
THEN a traffic light will turn the lights red in one direction and green in the
other. The action taken (changing the color of the lights) is always the same,
but the conditions to trigger that action evolve. Factoring the conditions out
of the software application allows the conditions to evolve without forcing the
software application to change. Such a separation is somewhat analogous in
terms of both methodology and value to the separation of data and presentation
that XML/XSLT provides over HTML.
Overview of Prolog - Inference
Prolog is one of the two most well-known languages used in
artificial intelligence (the other is LISP). Whenever I mention SCL as a
Prolog-based language, I’m told usually with a smile, “I loved Prolog. I used
it in college!” It is a declarative language, based on predicate logic that in
Sherlock Holmes fashion deduces conclusions from a set of facts that are
explicitly stated or inferred from other facts. For example, if supermarkets
sell food and a banana is food, I can likely find a banana at a supermarket.
As a declarative language, Prolog units describe a domain of
knowledge as opposed to listing instructions (to a CPU or “virtual machine”) as
do programs written in conventional languages such as C#. They are more like
little databases. In fact a Prolog “program” is known as a “database”. They
exist as a text file consisting of a set of facts and rules about a domain of
knowledge.
Figure 1 depicts a very basic Prolog database describing the
domain of a family tree. Each fact consists of a predicate (relationship) and
one or more arguments of the relationship. For example, the fact “married(susie,al)”, explicitly states Susie is married
to Al. A rule is a fact with a body that infers facts based on other facts. The
rule:
female(@Person) :-
mother(@Person,@blank).
states that we can infer that a @Person is
a female if she is a mother. With a few rules and explicitly stating primarily
wife/husband and mother/child relationships, we can infer many other types of
relationships without the need to state them explicitly. Practically any domain
of knowledge can be modeled in this manner.
Figure 1 – What does a Prolog database look like?
Like SQL databases, Prolog databases are queried for answers
using a special querying language. The most basic form of a Prolog query is: predicate(variable | constant). Variables begin with a “@”
and constants do not. If a constant contains an “@”,
it must be enclosed in double-quotes (“).
If we wish to determine all the nieces for Laurie, we issue
the query: “niece(laurie,@Niece)”.
The niece rule towards the bottom of Figure 1 states that a
niece is the female children of a @Person’s siblings. In turn, femalechildren and siblings are rules. Kate, Samantha and
Brandi are determined to be nieces of Laurie. However, unlike Brandi who is
explicitly declared a niece – the “niece(laurie,brandi)“
fact at the bottom of Figure 1), Kate and Samantha, are determined to be nieces
without explicitly stating this relationship via the niece rule.
As a language intended to develop “artificial intelligence”,
Prolog obviously falls short (otherwise, AI would be much more prevalent
today). There is more to the robust intelligence of humans than predicate
logic. One thing is that many facts change. The facts listed in Figure 1 are invariant. Meaning,
they are valid no matter what the context. The fact, “mother(ann,kate)” is always true and the definition of a grandparent
is always the parent of my parent. However, in many cases facts are quite dynamic.
For example, it may be a fact that I have $5 in my checking account. But that
is a very dynamic figure that changes every time I write or deposit a check.
Obviously, decisions should be made based on the most current facts.
SCL, my Prolog-based language, solves this
problem by including syntax that describes where to obtain facts in addition to
just simply stating them.
Concepts of SCL – Separation of Logic and Procedure
As Borland’s Delphi
breathed new life into Pascal in the 1990s by enhancing it with new
capabilities arming it for new the GUI world, SCL can open the door for
Prolog’s full potential by retrofitting it for distributed systems, which
didn’t really exist during Prolog’s 80s heyday. SCL is my implementation of
Prolog enhanced with a new set of features outfitting it with the capability of
providing malleable logic services for distributed applications. As the number
and variety of nodes on the Internet grows (Web Services, embedded devices,
RFID, etc), the complexity, evolution (the rules are always changing), and the
mix of factors contributing towards decisions the applications on these devices
makes becomes overwhelming. This creates a need for a mechanism that is geared
towards handling complex and evolving logic.
SCL is such a mechanism.
The Prolog language itself is designed to deduce logical conclusions for a
query by inferring logical relationships from a list of facts. Complementing
that purpose with the capability to locate, aggregate, and refresh facts from
distributed, multiple, diverse sources (conventional
ADO.NET/OLEDB/ODBC data sources and other SCL databases) fulfills that
need. I call the new Prolog features providing this capability “MetaFacts”.
Incorporation of SCL into
software applications results in a “separation of logic and procedure”. In a
nutshell, by “logic” I’m referring to the “IF” part of an IF-THEN statement and
“procedure” as the “THEN” part. For example, IF some set of conditions are met,
THEN a traffic light will turn the lights red in one direction and green in the
other. The action taken (changing the color of the lights) is always the same,
but the conditions to trigger that action evolve. Factoring the conditions out
of the software application allows the conditions to evolve without forcing the
software application to change. Such a separation is somewhat analogous in
terms of both methodology and value to the separation of data and presentation
that XML/XSLT provides over HTML.
Prolog programs are
databases and return tabular results. Therefore, SCL is exposed to clients as
an ADO.NET provider. This makes integration with .NET applications very easy.
Figures 2a and 2b depict a
very simple example of separation of logic and procedure. Figure 2a shows a
method from a DLL that will execute the “BuyCandy(Skittles)” method if
Figure 2a – Current procedural languages mix logic and procedure
By moving the logic out of the DLL into a Prolog database and changing the IF part of the C# code to a Prolog query, as depicted in Figure 2b, only a new Prolog database must be redeployed. This is less risky in terms of deployment and offers the ability to change rules as often as needed. This separation of logic from procedure is possible because Prolog programs can encode any logic that IF-THEN-ELSE statements can encode and more. That “and more” is realized when we consider that new classes of applications, programs that attempt to be more “intelligent”, will require greater versatility as far as changing rules are concerned.
.
Figure 2b – Separation of Logic and Procedure.
As powerful as separation of logic from procedure is, it’s just the first part of the battle. “Facts”, which are the elements of Prolog results are constantly changing. Hard-coded facts are no help to malleable rules (outdated facts will lead to incorrect conclusions). To ensure a Prolog query considers the most up-to-date facts, facts subject to change are entered into a Prolog database as MetaFacts; descriptions of how to obtain the facts.
Figure 3a depicts a Prolog database with facts and two MetaFacts mixed in with a couple of regular facts. The database holds a list of players for a company that markets to weight-lifters. The parts of the first MetaFact, starting with “player({SQL~” are color-coded and described. It retrieves the members of the Pro Club and the type of membership they have.
Figure
3a – What does a MetaFact look like?
Figure 3b details how the XML MetaFact – “maxlift({XML~” - from Figure 3a outputs facts. It reads the specified XML file and uses the specified XSLT file to format it into Prolog facts.
Figure
3b – Another type of MetaFact
Figure 4 depicts the Prolog database MetaFact, central to the discussion beginning with the next paragraph. Another important type of MetaFact is the Web Service MetaFact. It will be discussed in the “Example of SCL” section.
Figure
4 – MetaFact as a result of a Prolog call.
Complementing the concept of separation of logic and procedure is “relentless decoupling of logical concepts”. Enabling the relentless decoupling of logical concepts is the Prolog MetaFact as depicted in Figure 4. In this figure, two MetaFacts will resolve into a set of facts; a list of members. But only the “strong guys” from their respective clubs. Pro Club and Gold’s Gym, being gyms attracting different demographics of members, have different ideas for what “strong” means. Gold’s Gym may consider only the straight weight. Pro Club may consider body weight to weight lifted ratio, age, gender, etc. Therefore, each MetaFact queries a SCL database defined and made accessible by each gym. These SCL databases contain the rules determining how each club considers a member “strong” and returns these members as facts.
This concept resembles the way our brains make decisions and how our brains leverage the brains of other people. We make decisions by inferring things from things we know and new things we discover in the pursuit of making the decision. Facts can be elemental and variable, elemental and invariant, or the result of another decision. Examples of each, in respective order, are that I have $50 in my wallet, my date of birth is December 8, 1961, and “What would I like to eat today?”
Most facts we consider when making decisions are actually composites of other decisions that in turn could be based on other decisions. For example, when walking down a street deciding where to eat, we consider things such as how hungry you are, how much money you have, whether a place is too crowded for you, etc. Each of these things we consider is bound to be different under different situations (time and place, elements involved). “Do I have enough money?” depends on many other things that will be different under different circumstances. The value of this scenario will be appreciated when mobile embedded devices proliferate, bringing computers out of the carefully managed world of the IT environment and into the real world where anything will happen.