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 Eugene likes candy and Skittles is cheap. But as Eugene’s career advances, he becomes more concerned with health than money, so the rule changes to buy skittles if Eugene likes candy and Skittles is low in calories. Should this happen, this program would need to be modified and redeployed introducing all of the risks very familiar to software developers that are associated with such a process.

 

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.