Thomas Linder Puls

1

• Visual Prolog Object System
• APPSEM II 2005
• Thomas Linder Puls
• Prolog Development Center
• Denmark

2
Thomas Linder Puls

• Masters Compiling ?-prolog
• PhD Higher order logic (type theory)
• Computer Resources International
• AI system for shock absorber design (constraint
  resolution engine)
• Oersted satellite on-board software (Ada)
• Prolog Development Center
• Staff Planning Scheduling
• Visual Prolog (6 years)

3
Prolog Development Center

• Founded in 1985
• Prolog Compiler for MS-DOS (masters project)
• Copenhagen, Denmark (50 employees)
• Staff Planning Scheduling
• Aviation Planning Scheduling
• Production Planning Scheduling
• Hospital Booking
• Emergency Management
• Speech Recognition
• St. Petersburg, Russia (15 employees)
• Visual Prolog
• Agile Team Team/Project Management

4
Language Characteristics

• Logical programming language based on Prolog
• not ISO-Prolog compliant
• Successor of Turbo Prolog and PDC Prolog
• Compiled for Microsoft Windows (i386)
• Object-Oriented
• Non-determinism/backtracking
• Unification, pattern matching
• Algebraic data types
• Fact databases
• Functions
• Statically typed
• Multithreaded
• Garbage Collected
• Industrial Strenght

5
Object System

• Class based object system
• Separate
• Interfaces
• Class declarations
• Class implementations
• Support of multiple interfaces
• Multiple inheritance
• State is completely hidden
• Object callbacks (seamless C delegates)

6
Interfaces Object Types

• Interfaces define object types
• interface person predicates getName
  () -gt string Name. setName (string
  Name).end interface person
• person is an object type
• All objects of the person type has predicates
  getName and setName
• person is not bound to any particular class any
  class can support the person interface

7
Interface Support

• An interface can support other interfaces
  (hierarchically)
• The support hierarchy is a subtype/is a
  hierarchy
• interface user supports person predicates
  getLoginName () -gt string Name.end
  interface user
• user is an object type
• user is subtype of person
• A user object can be used as a person object
  (subsumption)
• A user object has predicates getLoginName,
  getName and setName
• Multiple supports is supported
• Support does not imply any code inheritance

8
Class Declarations

• A class can construct objects of some object type
• A class does not define a type
• class userClass user constructors
  newUser (string LoginName, string Name).end
  class userClass
• userClass is a class that constructs objects of
  type user
• userClass has a constructor named newUser
• To construct an object newUser is invoked as a
  function
• User userClassnewUser(thomas, Thomas
  Puls),UsersetName(Thomas Linder Puls)
• Class declarations are declarative (for the
  programmer, not for the compiler)
• Implementation details not mentioned
  (inheritance, override, etc)

9
Implementation Inheritance

• A class must have an implementation
• implement userClass inherits personClass
  facts loginName string. clauses
  newUser(LoginName, Name) -
  loginName LoginName,
  personClassnewPerson(Name). clauses
  getLoginName() loginName.end interface person
• State is hidden in the implementation, and can
  only be accessed there
• Inheritance is hidden in the implementation

10
Specialities (1)

• Objects are completely abstract
• This is the only exception
• Objects can only be accesseed through their
  interfaces
• This also goes for objects of the same class
• classes do not define types
• This also goes for inherited objects
• seamless multiple inheritance
• Classes do not define object types
• Liberty to re-implement any object type
• No access modes (no protected, no friends, etc)
• Class declaration is separate from implementation
• Separate version control (declaration is a
  contract)
• More files for the same class

11
Specialities (2)

• Support (subtype) is separate from inheritance
• Conceptually clear
• Liberty to be something without being forced to
  inherit anything
• Inheritance is hidden/private
• Natural to hide information that has no
  interest for users
• Complicates implementation (compiler lacks
  information)
• State is hidden (non-optional)
• In line with best practice hide representation
• Sometimes to elaborate
• Information for programmer, not for compiler

12
Additional

• Object Callback (object in predicate closure)
• Pred UsersetName, Pred(W.A.M.)
• Invocation of Pred acts on the User object
• Delegate (dynamic inheritance)
• implement someClass delegate interface
  person to currentPerson facts
  currentPerson person.
• The person interface is delegated to the
  currentPerson fact variable
• I.e., inherit person behavior from the
  currentPerson object
• The effective inheritance can be changed
  dynamically

13
Future

• Generics (parametric polymorphism)
• List comprehension
• Structured language constructs (if-then-else,
  foreach)
• Name spaces
• Anonymous predicates (?-expressions)
• Properties
• F-bounded polymorphism
• Guarded monitors
• .net CLR (managed code)

14
More info

• Visual Prolog
• http//www.visual-prolog.com
• Discussion forum
• http//discuss.visual-prolog.com
• Prolog Development Center
• http//www.pdc.dk
• CD
• Visual Prolog 6.3 Personal Edition
• including Visual Prolog 7.0 alpha