Summary: Prolog is a logical programming language that can help craft perfect sitemaps and workflows by ensuring solutions meet all business and technical constraints. Here, I'll chat a little about Prolog and how it might be used, with more detailed information coming in future.
Part of Thought Into Design's work is natural language interfaces. Among the many tools we use is a language called Prolog. This is a logic language, quite strong on declarative style. It works by defining facts and rules and then asking queries. In some ways, it's how I envisaged computer programming to be, back in the early 1980s, before I ever programmed anything.
Examples of facts are:
These say (in order) that the atom 'alan' is a 'man', as is 'tony', whereas 'jell' and 'ann' are both classed as woman.
Rules determine how atoms relate to each other. Using the above code, we could define some rules thus:
Everything classed as both 'man' and 'woman' is now also classed as 'human'.
With these in place, we can issue queries that tell us if a particular result is logically possible or not.
Prolog could be quite useful when crafting sitemaps and doing workflows, more so for the larger and complex sites rather than simple ones. There are often times when several different business rules need to be accounted for and the more complex the rule-set, the harder it is for a designer to navigate through them.
Prolog, or other logic languages, might be a way to help determine if particular sitemaps and workflows are valid solutions to problems or not.
My ideas are quite unformed as yet and this is something I hope to return to soon so watch this space!
Part of Thought Into Design's work is natural language interfaces. Among the many tools we use is a language called Prolog. This is a logic language, quite strong on declarative style. It works by defining facts and rules and then asking queries. In some ways, it's how I envisaged computer programming to be, back in the early 1980s, before I ever programmed anything.
Examples of facts are:
man(alan).man(tony).woman(jell).woman(ann).
These say (in order) that the atom 'alan' is a 'man', as is 'tony', whereas 'jell' and 'ann' are both classed as woman.
Rules determine how atoms relate to each other. Using the above code, we could define some rules thus:
human(X) :- man(X).human(X) :- woman(X).
Everything classed as both 'man' and 'woman' is now also classed as 'human'.
With these in place, we can issue queries that tell us if a particular result is logically possible or not.
human(X).And we get a print out of everyone who is human. This is a very basic example and seems similar to a query language, but Prolog's power is in being able to infer relationships from what it's been told.
Prolog could be quite useful when crafting sitemaps and doing workflows, more so for the larger and complex sites rather than simple ones. There are often times when several different business rules need to be accounted for and the more complex the rule-set, the harder it is for a designer to navigate through them.
Prolog, or other logic languages, might be a way to help determine if particular sitemaps and workflows are valid solutions to problems or not.
My ideas are quite unformed as yet and this is something I hope to return to soon so watch this space!
No comments:
Post a Comment