Turbo Toolbox

home *** CD-ROM | disk | FTP | other *** search

/ Turbo Toolbox / Turbo_Toolbox.iso / spezial / 01 / statis / statis.doc < prev next >

Wrap

Text File | 1987-07-03 | 51.2 KB | 934 lines

PRAKTISCHE ERFAHRUNGEN MIT TURBO-PROLOG Erfahrungbericht eines "ganz nor- malen" Programmierers über eine Be- gegnung der dritten Art. Um es gleich vorweg zu sagen, wenn mir vor einem Jahr jemand gesagt hätte, daß ich heute in und über Prolog schreibe, dann hätte ich zumindest an dessen Zurechnungsfä- higkeit gezweifelt. Das sieht man auch an meinem Artikel in der PASCAL Nr. 1, wo ich Prolog nur vom Papier her kannte. Nun grassierten aber schon längere Zeit Storys und Gerüchte in den Me- dien mit Stichworten wie AI (Artifi- cial Intelligence), Expertensysteme, intelligente Datenbanken, 5. Compu- tergeneration, etc.. Ich ließ mich aber nicht weiter irritieren, freute mich an Turbo- Pascal, programmierte AI-Spielereien in LOGO auf einer Z80-Maschine und staunte ansonsten über die horrenden Preise die für Prolog- und Lisp-Sy- steme verlangt wurden. Dann erschienen erste "Tests" von Turbo-Prolog in Fachzeitschriften. Die Anführungsstriche habe ich hier mit Bedacht gewählt. Also, ohne mei- nen Kollegen von der schreibenden Zunft etwas zu wollen: in diesen "Tests" wurde, von wenigen Ausnahmen abgesehen, die Benutzeroberfläche beschrieben, bestaunt wie schnell der Compiler ist und zum etwa 36ig- sten Mal das Beispiel mit den Ver- wandschaftsverhältnissen (oder al- ternativ "Türme von Hanoi") ge- bracht. Ansonsten blieb stets das Gefühl zurück, daß kein Mensch ei- gentlich so genau wußte, was der Ot- to-Normal-Hobby- oder auch Berufs- programmierer eigentlich mit dem Sy- stem anfangen soll. In dieser Situation fand ich, dessen einzige AI-Sprachen-Erfahrung in ei- nigen Stunden Lisp auf einem Groß- rechner (abschreckend!) bestand, mich wieder, als das Schicksal in Gestalt meines Chefredakteurs (Wort- laut: "Du willst doch auf dem lau- fenden bleiben.") mich in die Arme von Turbo-Prolog trieb. Da saß ich nun mit zwei Disketten und einem englischen Handbuch vor meinem Rech- ner, im Ohr Sprüche die jüngst auf einem AI-Kongress gefallen sind (sinngemäß: "Turbo-Prolog? Micky- Maus-System!") und im Kopf die Über- legung ob so ein Möchtegern-16 Bit- Rechner mit so was nicht doch über- fordert ist. (Übrigens... Hinweis an die Herren Experten: Wenn ich versu- chen würde eine Expertensystembasis für 20000 DM (!) an den Mann zu bringen, würde ich wohl auch solche Sprüche klopfen.). Und da die üblichen Schlagworte nun schon einmal gefallen sind, möchte ich an dieser Stelle versuchen, ein- mal einige Mißverständnisse auszu- räumen, die durch eine unsaubere Be- griffsfindung in den Medien aufge- treten sein können: 1. Turbo-Prolog ist kein Expertensy- stem. 2. Turbo-Prolog ist kein Datenbank- system. 3. Turbo-Prolog verkörpert selber keine künstliche Intelligenz. (Die Übersetzung "Intelligenz" für "intelligence" geht übrigens haar- scharf an der Bedeutung vorbei. Sie- he auch CIA.) 4. Programmieren muß man immer noch selber. Aber: Die Punkte 1-3 kann man mit Prolog-Programmen erfüllen. (Genauere Definitionen dieser Be- griffe finden Sie in dem Bericht über den AI-Kongreß in dieser Ausga- be.) Meine ersten Kontakte mit Turbo-Pro- log waren erstmal nur positiv. Das System war schnell, komfortabel (oh- ne zu einem nagetiergesteuerten Vi- deospiel zu entarten) und die Einar- beitung fiel mit den Beispielpro- grammen ziemlich leicht. Besonders positiv fiel mir z.B. auf, daß das System, wenn man eine Datei laden will und den Namen nicht kennt, beim "leeren" drücken von RETURN die Na- men aller Files im aktuellen Direc- tory zur Verfügung stellt. Dies ist zwar kein Zeichen von wie auch immer gearteter Intelligenz, aber ein Hin- weis darauf, daß die Programmierer des System erstens Praktiker waren, und zweitens für's Denken bezahlt wurden (und nicht für Anschläge pro Minute). Es ist wohl generell posi- tiv zu werten, wenn so ein System von Praktikern geschaffen wird, und nicht von irgendwelchen Esoterikern in ihren Elfenbeintürmen. Extrem hilfreich ist auch das On- line-Manual, das durch drücken von F1 erreichbar ist, und wildes blät- tern im Handbuch nach Tastenbelegun- gen und Predikatennamen erspart. An- genehm im Zeitverhalten macht sich auch bemerkbar, daß der Compiler in- crementell arbeitet. D.h. das er, wenn man aus dem Dialog mit F9 in den Editor geht, dort Änderungen vornimmt und mit F10 wieder zu Dialog übergeht, nur die geänderten Teile neu compiliert, wie er über- haupt für den Dialog nur die benö- tigten Predikate übersetzt. Dabei war recht schnell zu merken, daß in Prolog z.B. eine wissensba- sierte, "intelligente" Datenbank mit wenigen Zeilen zu schreiben ist. Such- und Sortieralgorithmen entfal- len durch das Backtracking (s.u.) quasi völlig. Da ich in diese Rich- tung aber keine Intentionen habe (ich bin Naturwissenschaftler, und meine 20 Schallplatten kann ich ge- rade noch so eben im Kopf "verwal- ten"), war meine nächste Idee, ange- sichts der phantastischen Möglich- keiten für Benutzeroberflächen, mit Turbo-Prolog eine "Shell" (UNIX-Neu- Deutsch) für Numerikprogramme (z.B. statistische Meßwertauswertung) in anderen Programmiersprachen (Pascal und FORTRAN) zu schreiben. Die Tücke lag wie üblich im Detail, Murphy hatte infolgedessen wieder alle Chancen zuzuschlagen, und die Linkerei sowohl mit IBM-Professio- nal-FORTRAN als auch mit MS-Pascal ging prompt in die Hose. (Turbo- Pascal ist leider erst in der näch- sten Version linkfähig.) Aber dazu weiter unten mehr. (Fast) unverdrossen (jetzt erst recht!) machte ich mich daran, das zu tun, was angeblich eine Schwach- stelle aller AI-Sprachen sein soll, nämlich numerische Sachen in Prolog zu programmieren. (Ich erdreistete mich also, ein ganz normales Pro- gramm schreiben zu wollen.) Bevor ich meine Vorgehensweise und meine Klauseln näher beschreibe, möchte ich aber noch die von mir verwendeten Konventionen erläutern (scheinen auch so unsinnig nicht zu sein). Wie es anscheinend üblich ist, stehen die Input-Parameter ei- nes Predikats links im Kopf, während die Output-Parameter rechts stehen (solange das Predikat nicht "umge- kehrt" verwendet wird). Ich habe die Wahlfreiheit von Turbo-Prolog aus- genutzt was den Syntax von "IF" bzw. ":-" und "AND" bzw. "," angeht. Falls es mir auf den prozedualen Charakter der Klausel ankommt, diese also im wesentlichen aus Predikaten besteht, die immer "successfull" sind und nur Seiteneffekte wie Wert- zuweisungen und I/O-Operationen ha- ben, verwende ich ":-" und ",". Wenn ich hingegen den logischen Charakter betonen möchte, verwende ich "IF" und "AND". Beim Einsetzen des Cut zur Ablaufsteuerung mische ich auch schon einmal beide Notationen. Pre- dikate, die nur Hilfsfunktionen für ein anderes sind, stehen (soweit möglich) unmittelbar unter diesem. Ich begann mit dem, was in dem Lis- ting als mathematischer Teil be- zeichnet ist. Hier implementierte ich Predikate, die standardmäßige statistische Berechnungen machen können (---> siehe auch Mathemati- scher Background). Zur Representa- tion meiner Liste von Werten wählte ich (nah, wer hätt's gedacht) eine Liste von REALs. Um mehrere Datensätze gleichzeitig verwalten zu können, werden die Wer- te und Bezeichnungen für eine Meß- reihe zusammen mit einem Stichwort, das zur Identifikation dient, in ei- nem Verbundtyp mit dem assert-Predi- kat in die Datenbasis eingefügt. Da- her resultiert der Menuepunkt "Da- ten-Setup" bei dem dieses Stichwort und Variablenbezeichnungen verein- bart werden. "Natürlich" werden bei Anfragen alle schon vorhandenen Stichworte in einem Fenster ange- zeigt. Das Suchen dieser Stichworte wird sehr elegant mit dem Systempre- dikat "findall" in "zeige_alle_- Stichworte" erledigt. Diese Vorgehensweise hat auch den Vorteil, daß diese häufig benötigten Größen nicht ständig als Parameter mitgeschleppt werden müssen, sondern quasi global sind. Die gesammelten Eingaben einer "Sitzung" können abgespeichert und später auch wieder geladen werden. Selbstverständlich können eingegebene Werte auch wieder geändert werden. Der erste Stolperstein war die Tat- sache, daß ich alle Daten rekursiv verarbeiten mußte. Das Kochrezept dafür ist aber recht einfach, wie ich am Beispiel einer Aufsummierung der Elemente einer Liste erläutern möchte (hier hab' ich mich das erste Mal gefragt, was eigentlich das Ge- rede soll, daß angeblich in Prolog alles, was in anderen Sprachen üb- lich ist, ach so schwierig sei). Als erstes kommt die Klausel für den Re- kursionsabbruch. Hier das Faktum listsum([],0), da trivialerweise die Summe der Elemente einer leeren Liste 0 sein muß. Dann kommt als zweite Klausel die Regel für nicht- leere Listen, und zwar trennt man schon im Kopf der Klausel mit dem "|"-Operator den Kopf der Liste vom Schwanz ab, listsum([H|T],Res). Res ist die Rückgabevariable der Klau- sel. Dann macht man im Rumpf der Klausel als erstes den Rekursions- aufruf mit dem Schwanz der Liste und einer neuen Variablen für das Zwi- schenergebniss, listsum(T,Res). Als letzter Schritt wird der Ergebniss- variablen der Klausel die Summe aus dem Kopf der Liste und dem Zwischen- ergebniss zugewiesen, Res = H + NRes. Jemand der andere Programmier- sprachen gewohnt ist, wird fragen, warum unbedingt eine neue Variable NRes benötigt wird, schließlich gin- ge auch listsum(T,Res), Res = Res + H. Aber: in Prolog kann nur einer ungebundenen Variable (ohne Wert) ein Wert zugewiesen werden. Wenn die Variable schon gebunden ist, wirkt das Predikat "=" nur noch als Ver- gleichsoperator. Die Bindung einer Variablen kann nur durch ein Back- tracking, das durch das "Fail" einer Klausel ausgelöst wurde, rückgängig gemacht werden (s.u.). Sämtliche da- tenverarbeitenden Klauseln arbeiten nach diesem rekursiven "teile und beherrsche"-Prinzip. Das Schreiben solcher Predikate wird einem von Turbo-Prolog sehr leicht gemacht, da alle wesentlichen trans- zendenten Funktionen ("sqrt") vom System zur Verfügung gestellt werden. Als es nun darum ging die Benutzer- oberfläche zu realisieren, habe ich erstmal das vermutlich einzig rich- tige getan, nämlich nachgeguckt was an Material so alles vorhanden ist (aufhören das Rad neu zu erfinden). Eine wahre Fundgrube ist dabei das Geobase-Programm, wie überhaupt auch die mitgelieferten Beispiele allein schon ihr Geld wert sind. Fenster- handling wird vom System ja ohnehin unterstützt, und im Geobase ist ein Modul vorhanden, das PopUp-Menüs produziert. Dies änderte ich soweit ab, daß man die zu benutzenden Fen- sternummern parametrisch übergeben kann, und übernahm es ansonsten un- verändert mit den benötigten Hilfs- predikaten in mein Programm. (Teile aus den Demoprogrammen sind übrigens an der englischen Kommentierung er- kennbar.) Gewöhnungbedürftig ist die Realisie- rung von Fallunterscheidungen bei der Ablaufsteuerung (z.B. Menue-Op- tionen). Hier wird für jeden Fall der auftreten kann, eine eigene Klausel geschrieben. Dabei wird die eigentliche Fallunterscheidung durch den Klauselkopf oder Vergleiche zu Beginn des Klauselrumpfs gemacht. Um auch einen angemessenen Komfort bei der Dateneingabe (Programmteile Dateneditor und Mini-Parser) zu er- reichen, benutzte ich natürlich den Systemeditor. Bei diesem gibt es die Möglichkeit, schon einen Input- String zu übergeben, so daß man qua- si eine Maske vorgeben kann. Leider wurde eine Möglichkeit vergessen, den Benutzer daran zu hindern diesen String zu manipulieren, so daß es passieren kann, daß der Benutzer un- beabsichtigt Bildschirmmasken zer- stört. Dies muß dann in dem Filter- Predikat, das die Maske wieder aus dem Rückgabestring entfernt, berück- sichtigt werden. Hier war die Sache insofern einfach, als daß die "Mas- ke" nur aus den Überschriften der Eingabetabelle besteht. Der einge- bene String dann wird mit dem Predi- kat fronttoken in einzelne Zahlen "zerpflückt". Man muß allerdings be- achten, bei dieser "Filterung" Leer- zeichen und Zeilenvorschübe nicht zu entfernen. Da es häufig vorkommt, daß z.B. bei einer Messung lange Zeit derselbe Wert gemessen wird, können Wiederholungen in den Tabel- lenspalten mit einem "w" eingegeben werden. Berücksichtigen muß man bei der Zerlegung des Strings die unter- schiedlichen Spaltenzahlen der Ein- gabetabelle (1 oder 2 dim. Vertei- lungen, Fehler bekannt oder nicht). Der Graphikteil für zweidimensionale Verteilungen wurde so konzipiert, daß der Benutzer Begrenzungen der Graphik, Achsenschnittpunkt und Ach- senteilung vor der Darstellung fest- legt. Die Meßwerte werden als Kreuze (gegebenenfalls mit Fehlerbalken) dargestellt. Durch die Punkteschar wird eine Ausgleichsgrade gezeich- net. In der Realisierung hat es sich als günstig erwiesen, die Benutzer- koordinaten zentral in Bildschirmko- ordinaten umzurechnen, da man da- durch im Graphikteil eine Menge Pa- rameter spart. Auf automatische Ska- lierung und Beschriftung der Achsen wurde verzichtet, weil das doch den Rahmen dieses Beispielprogramms ge- sprengt hätte. Der Leser sollte dies aber, wie auch das ganze Programm, als Anregung zum experimentieren und weiterentwickeln auffassen. Paradoxerweise wird der Hauptteil des Programms von der Benutzerober- fläche ausgemacht, während der ei- gentliche Rechenteil nur ca. 50 Zei- len lang ist. Hierbei muß man aber bedenken, daß das Programm in einer anderen Sprache geschrieben, wohl um vielfaches länger wäre, und daß ein Prolog-Profi für diese Programm wohl nur halb soviel Zeilen gebraucht hätte. Hier kommt es sehr stark auf die Effizients des Ansatzes an (Nachdenken lohnt sich). Ich hänge hier wohl noch zu stark prozeduralen Denken an. Backtracking und der "Cut": Es ist häufig günstig, insbesonders wenn viele Klauseln zu ein und dem- selben Predikat existieren, an dem Faktum für den Rekursionsabbruch, oder ähnlichen Stellen, einen Regel- teil zu schreiben, der lediglich ei- nen Cut ("!") enthält. Dies hat fol- gende Funktion: Normalerweise geht Prolog seine Wis- sensbasis von oben nach unten durch und versucht die Klauseln der Predi- kate zu erfüllen. Wenn eine Klausel nicht erfüllbar ist, geht das Sy- stem, falls Alternativwege zur Ver- fügung stehen, zurück bzw. versucht die nächste Klausel zu erfüllen. Dieser Prozeß wird Backtracking ge- nannt. Aber auch wenn die Klausel erfüllbar war, versucht das System noch andere Lösungen zu finden. In praxi sieht es aber oft so aus, daß es Erfahrungswerte (Heuristiken) gibt, daß, wenn ein bestimmter Punkt erreicht wird, es keine Lösungen (mehr) gibt, oder man ist ohnehin nur an einer Lösung interessiert. An solchen Stellen kann man einen Cut setzen, um dem System mitzuteilen, daß es weitere Suche an vorhergegan- genen Verzweigungen unterlassen möge, wenn es diese Stelle über- schritten hat. An diese Stelle gehört auch der Hin- weis, daß der Cut unbedingt notwen- dig ist, um effektive Expertensyste- me zu schreiben. Es ist naiv zu glauben, daß es ausreicht, das Sy- stem mit einem Wust an Fakten und Regeln zu füttern, und zu denken, der Rechner wird schon eine Lösung finden. Dies scheitert an der Reali- tät der heutigen Maschinen, da kein Rechner schnell genug ist, um mit der Kombinatorischen Explosion fer- tig zu werden, von Schwierigkeiten, wie Rekursionsstacküberlauf u.ä. ganz abgesehen. Der Programmierer muß bei größeren Systemen sein Welt- wissen in Form der Steuerung mit dem Cut einbringen. Leider hat der Cut auch negative Auswirkungen, da er häufig die Wirk- samkeit eines Predikats für "beide Richtungen" (Analyse und Synthese) beeinträchtigt. Dies ist aber eine der Hauptforderungen der Prolog- "Philosophie". In dem vorliegenden Programm habe ich darauf aber keine größere Rücksicht genommen (prozedu- raler Charakter). Auf dieses Problem möchte ich aber in einer der folgen- den Ausgaben eingehen. "Narrensicherheit" von Turbo-Prolog: Bei meinen ersten Gehversuchen hatte ich hinreichende Gelegenheit, mit den informativen und meistens den Punkt treffenden Fehlermeldungen des Systems Bekanntschaft zu machen. Auch Laufzeitfehler wurden gut abge- fangen (einschließlich Endlosschlei- fen). Derart in Sicherheit gewiegt ver- nachlässigte ich das Zwischenspei- chern. Die Strafe folgte auf dem Fuße. Ich machte einen Fehler, der wohl so idiotisch ist, daß keiner damit gerechnet hat, daß man ihn überhaupt machen könnte; und zwar verwendete ich ein Database-Predikat als Verbundparameter in einer Klau- sel (wie ich darauf gekommen bin, wissen nur die Götter). Als das Pro- gramm merkwürdige Ergebnisse liefer- te, wollte ich der Sache mit der Trace-Funktion auf den Grund gehen. Dabei konnte ich beobachten wie das System konfuss im Programm herum- sprang und dieses mit einer ansehn- lichen Sammlung Sonderzeichen ver- zierte. Anscheinend versuchte es verzweifelt, die Database mit den übergebenen Parametern zu vereinba- ren. Meinen anschließenden (zugege- bener Maßen nicht besonders intelli- genten) Versuch die kläglichen Reste zu sichern, nutzte das waidwunde System um der Programm- und BackUp- Datei den Gnadenstoß zu versetzen, und anschließend mit jämmerlichen Piepsen selber in die ewigen Jagdgründe einzugehen. (Folge dieser Erfahrung: 6 Stunden Tipparbeit an- hand eines Listings.) Anscheinend ist es wohl doch nicht möglich, ein System gegen den Einfallsreichtum menschlicher Unvernunft vollkommen abzusichern. Etwas empfindlich scheint das System auch bei großen Programmen mit schlecht definierten Klauseln, die hohen Rekursionsgrad mit intensivem Backtracking kombinieren, zu reagie- ren, wenn man diese mit der Trace- funktion verfolgt. Dort kollidiert anscheinend der große Platzbedarf der Trace-Funktion mit dem Expan- sionsdrang der Klausel, was dann zu "merkwürdigen" Verhalten führt. Dies läßt sich aber leicht vermei- den, indem man Rekursionen "anstän- dig" terminieren läßt. Vorsicht geboten ist auch wenn man Graphikbefehle verwendet, obwohl man gar nicht im Graphikmodus ist. Da- raus können arithmetische Fehler (?) wie Division durch Null resultieren. Laufzeitverhalten von Turbo-Prolog: Im amerikanischen Orginalhandbuch wird ziemlich dreist mit der Aussage "Programme die schneller ausgeführt werden, als diejenige auf den Proto- typen des japanischen '5th Genera- tion Project'" geworben, und irgend- wo im Hinterkopf habe ich auch, daß schon der Satz "bis zu 10000 mal schneller als herkömmliche Systeme" gefallen ist. Hierbei muß man wis- sen, daß die Hardware dieser Proto- typen direkt auf Prolog zugeschnit- ten ist, so daß solche Aussagen ei- gentlich unglaubwürdig sind. Ich suchte dann eine M╙glichkeit, mir einen Eindruck von dem Geschwin- digkeiten des Systems zu machen. Meine erste Idee war, dies anhand eines größeren Programms, nämlich GEOBASE, zu testen. Aber dabei konn- te ich letztlich nur feststellen, das Abfragen, die bei der Abarbei- tung Heuristiken nutzen, enorm schnell abgearbeitet werden (keine messbare Reaktionszeit), während nicht-deterministische Abarbeitung durchaus einige Sekunden dauern kann (fragen Sie mal nach der größten Stadt). Hier kocht auch Borland nur mit Wasser. Zufällig fiel mir ein Artikel aus der "Computer Persönlich" 9/86 in die Hände, wo die Laufzeit von "Türme von Hanoi" (ich weiß, arg strapaziert) für mehrere Systeme ab- gedruckt war. Das schnellste, compi- lierende System brauchte dort für 9 Scheiben 1.3 Sekunden (ohne Bild- schirmausgabe). Beispielprogramm 55 nutzt exakt denselben Algorithmus. Ich ließ das Programm laufen (ohne Bildschirmausgabe), mußte aber zu meiner Verblüffung feststellen, daß das Programm so schnell lief, daß ich keine Laufzeit bemerkte. Zuerst dachte ich an einen Fehler meiner- seits, und baute die Bildschirmaus- gabe wieder ein, nur um dann festzu- stellen, daß alles korrekt funktio- nierte. Ich stoppte dann die Zeit mit der Systemuhr und kam auf 6/100 Sekunden (ohne Ausgabe). Bei hundert Durchläufen mittelte sich die durch- schnittliche Zeit für einen Durch- lauf zu 0.0472 Sekunden (8088 mit 8 MHz). D.h. Turbo-Prolog ist über 27 mal schneller als das bis dato schnellste System auf einem PC. Da man dieses Zeitverhalten wahrschein- lich verallgemeinern kann, muß ich mich wohl oder übel davon überzeugen lassen, daß die obigen Aussagen zu- mindest größenordnungsmäßig richtig sind. Damit wird Turbo-Prolog auch für den kommerziellen und wissen- schaftlichen Bereich interessant. Da, wo bis jetzt spezielle Hardware für Performance sorgen mußte, tut es jetzt schon eine Maschine und Soft- ware, die preislich für ein größeres Unternehmen überhaupt nicht ins Ge- wicht fällt. Dabei muß man auch noch erwähnen, daß die Geschwindigkeit auf einem Rechner der jüngste MS-DOS Generation (80386 Prozessor) noch- mals etwa 10 mal höher ist. Kurz vor Fertigstellung dieses Be- richtes erreichten mich weitere In- formationen in Form eines Ver- gleichsberichts in der "Computer Persönlich" 22 dieses Jahres. Dort wurde Turbo-Prolog mit Prolog II, einem sehr modernen, leistungsfähi- gen, aber nichts desto trotz "klas- sischen" (und teuren) System, das von einer Forschungsgruppe der Uni- versität Marseille entwickelt wurde, verglichen (siehe auch Buchbesprech- ung "PROLOG" in dieser Ausgabe). Bei rekursiven Problemen war Turbo-Pro- log immerhin noch um Faktor 2 bis 9 schneller. Hingegen konnte Prolog II bei einem intensiv Backtracking for- dernden Problem (intensiv ist gut, exzessiv ist das richtige Wort) eine um Faktor 5.2 kürzere Laufzeit ver- buchen. Turbo-Prolog und andere Sprachen: Im Handbuch wird behauptet, daß Tur- bo-Prolog-Module mit anderen Spra- chen zusammengelinkt werden können. Dabei ist die Rede von Assembler, Pascal, FORTRAN und C. Vorgeführt wird dies an einem Assembler- und einem C-Beispiel. Hat auch seinen guten Grund. Linken mit FORTRAN-Pro- grammen ist eigentlich von vorneher- ein ausgeschlossen, da keiner der mir bekannten FORTRAN-Compiler sich dazu überreden läßt den Unterstrich "_" in Identifiern zu akzeptieren. Der Unterstrich wird aber zum Linken mit Prolog (siehe Handbuch) unbe- dingt benötigt. Alle gängigen Pascal-Compiler akzep- tieren aber den Unterstrich, und nachdem ich das MS-Pascal dazu über- redet hatte mit 32-Bit-Pointern (EX- TERNAL und VARS-Deklarationen in ei- nem MODULE) zu arbeiten, ging die Linkerei auch fehlerfrei ab. Leider verabschiedete sich der Rechner beim Laden solcher Programme sang- und klanglos. Mit C scheint sich Turbo- Prolog hingegen prächtig zu verste- hen (haben ja auch z.B. dieselben Stringkonventionen), wobei ich aber bis jetzt definitiv nur sagen kann, daß die Zusammenarbeit mit Lattice-C einwandfrei klappt (großes Speicher- modell). Wer bisher viel mit C gearbeitet hat ist also fein raus, Freunde von FOR- TRAN und Pascal müssen aber darauf hoffen, daß sich doch noch ein ver- träglicher Compiler findet (hier ap- peliere ich an die Leserschaft, Laut zu geben), oder auf Turbo-Pascal 4.0 (voraussichtlich 2. Quartal '87) warten. Prolog und strukturierte Programmie- rung: Allen, die die Konzepte der struktu- rierten Programmierung liebgewonnen haben, muß ich jetzt eine herbe Ent- täuschung bereiten. Struktogramme sind bestenfalls in Ausnahmefällen für die Entwicklung von Prolog-Pro- grammen brauchbar, was schlichtweg daran liegt, das es keinen Sinn macht, mit Gewalt Schleifenkonzepte anderer Sprachen in eine deklarative Sprache wie Prolog zu übertragen. Aber: Prolog, und speziell Turbo- Prolog, zwingt einen, auch wenn man's nicht merkt, Programme zu strukturieren. Diese Struktur hat aber eine ganz andere Qualität als in imperativen Sprachen, da sie sich weniger aus dem Zwang eine Arbeits- vorschrift zu formulieren ergibt, als daraus, Anforderungen an das Sy- stem zu formulieren. Der Unterschied mag so auf dem Papier vielleicht nicht offensichtlich sein, aber man merkt es beim programmieren, wenn es einem nach geringer Eingewöhnungs- zeit egal wird, wie das System das gestellte Ziel erreicht. In erster Näherung wird die Frage nach dem "wie" also durch die Frage nach dem "was" ersetzt. Zum Eingewöhnen in diese Sprache hat sich für mich die folgende Vorge- hensweise bewährt: 1. Ein grobes Gesamtkonzept für das Programm erstellen. 2. Anhand dieses Konzepts überlegen, welche Detailanforderungen wohl an das System gestellt werden. Dabei konsequent in kleinsten Einheiten denken, da lange Klauseln schnell undurchschaubar werden können. 3. Die Predikate für diese Anforde- rungen realisieren. 4. Diese Predikate interaktiv aus- testen. Dieser Punkt ist besonders wichtig, da Fehler, die irgendwo im Logik-Dschungel verborgen sind, selbst mit den hervorragenden Debug- gingmöglichkeiten von Turbo-Prolog nur schwer gefunden werden können. 5. Anschließend diese "Primitiv"- Predikate von ablaufsteuernden Pre- dikaten benutzen lassen. Diese Strategie der Bottom-Up-Ent- wicklung wird durch die Interaktivi- tät von Prolog hervorragend unter- stützt. Modulare Programmierung ist, wie es sich für ein modernes System eigent- lich auch gehört, voll verwirklicht. Zum einen auf der Ebene der Klau- seln, wo alle Variablen lokal sind, und zum anderen in Form von echten Modulen mit wohldefinierten Schnitt- stellen. Turbo-Prolog und der Standard: Tja..., da muß man erst einmal ganz klar sehen, daß es so etwas wie ei- nen Standard gar nicht gibt. Es gibt zwar einen sogenannten Standard-Syn- tax (eine scheußliche, Lisp-ähnliche Notation), aber eingebürgert hat sich der Edinburgh-Syntax wie er von Clocksin & Mellish beschrieben wird. Bis auf geringfügige Details (z.B. "=" anstatt "is") die mit der Erset- zungsfunktion des Editors korrigiert werden können, versteht Turbo-Prolog den vollen Edinburgh-Syntax (mit den unten genannten Einschränkungen), so daß Programme, die in diesem Dialekt geschrieben sind, problemlos über- nommen werden können. Dabei muß man lediglich beachten alle Predikate und Domains zu deklarieren und Klau- seln desselben Predikats unmittelbar untereinander zu schreiben. Dies ist wohl der Preis, den man für die Vor- teile eines Compilers bezahlen muß. Jemand, der vorher in Pascal-ähnli- chen Sprachen gearbeitet hat, wird dies, weil gewohnt, nicht als stö- rend empfinden. Für jemanden, der von BASIC/FORTRAN kommt, tut sich ohnehin eine neue Welt auf. Ledig- lich Jünger des "puren Prolog" (s.u.) werden mit Turbo-Prolog wohl nicht hundert-prozentig glücklich sein, es aber schließlich doch be- nutzen, weil es schnell, komfortabel und preisgünstig ist. Ähnliches konnte man ja auch bei Turbo-Pascal beobachten, was nicht die volle ISO- Norm erfüllt und trotzdem eine Rie- senverbreitung hat. Etwas aufpassen muß man auch bei der Verwendung des Cut, weil er gering- fügig andere Auswirkungen haben kann. Dieses Problem ist aber bei der Verwendung verschiedener Prolog- dialekte üblich, und rührt aus den unterschiedlichen Backtracking-Algo- rithmen der Systeme her. Der umgekehrte Weg, Turbo-Prolog auf andere Systeme, ist leider nicht so einfach, da man sich in der Regel doch das Leben leicht macht, die Features von Turbo-Prolog ausnutzt, und dabei Inkompatibilitäten in Kauf nimmt. Allerdings sehe ich für mei- nen Teil keinen Grund, mit Gewalt Turbo-Prolog-Programme auf ein ande- res System rüberkriegen zu wollen. Wie ich zu dieser Meinung gekommen bin ? --> Siehe Laufzeitverhalten. Der einzige echte Nachteil gegenüber anderen (meist interpretierenden) Systemen sehe ich darin, daß während der Laufzeit nur noch Fakten und keine Regeln mehr in die Datenbasis eingefügt werden können. Dies wird wohl gerade (und vielleicht auch nur?) von AI-Profis angekreidet wer- den, kann aber umgangen werden, in- dem für diese Zwecke ein Mini-Inter- preter für Turbo-Prolog in Turbo- Prolog geschrieben wird (Münchhausen zieht sich am Zopf aus dem Sumpf). Die prinzipielle Vorgehensweise da- für wird auch an einem einfachen Beispiel im Handbuch vorgeführt. Dies ist zwar etwas für höhere Seme- ster, aber mittlerweile würde ich mir durchaus zutrauen, sowas zu bau- en. Der Autor des zuletzt unter "Lauf- zeitverhalten" erwähnten Artikels, anscheinend ein Prediger einer ziem- lich puristischen Prolog-Schule, und zudem ohne Pascal-Erfahrung, bemän- gelte die Typbindung, die in Turbo- Prolog existiert, und die verhindert z.B. Listen zu konstruieren, die ge- mischt beliebige Typen aufnehmen. Stattdessen muß ein Funktor defi- niert werden, der als Objekte Werte und Variablen aller Typen aufnehmen kann, und eine Liste dieses Funktors definiert werden. (Siehe auch Turbo- Prolog-Handbuch Kap.11, Abschn. "Compound Terms or Structures".) Auch kritisiert er, daß Turbo-Prolog kein vollständiges Operator-Konzept hat, so daß keine infix-Notation von Operatoren möglich ist (in den mei- sten anderen Dialekten auch nicht), sondern nur prefix-Notation als Funktor möglich ist (z.B. "Karl ist_Vater_von Martin" muß geschrie- ben werden als "ist_Vater_von( Karl, Martin)" ). Begründet wird diese Kritik damit, daß mit infix-Notation Programme in "natürlichen" Sätzen geschrieben werden können. Ich für meinen Teil sehe aber den Sinn dessen nicht so ganz. Die Zeiten, wo jeder Anwender auch Programmierer sein mußte, sind letztlich und endlich vorbei, so daß die Programm-Lesbarkeit für den End- anwender kein Argument sein sollte. Und für den Programmierer bietet das Funktor-Konzept meiner Meinung nach nur Vorteile aufgrund der besseren Strukturierung (Vorsicht mit dieser Aussage: Ich bin "Pascal-Jünger"). Aber sei's drum: Dies sind alles ei- gentlich philosophische Überlegun- gen. Ganz praktisch betrachtet kann man in Turbo-Prolog alles machen, was auch in anderen Dialekten geht, auch wenn man bei einigen Sachen et- was "basteln" muß. Dafür kann man in Turbo-Prolog vieles machen, was mit anderen Systemen wohl überhaupt nicht geht, z.B. maschinennahe Pro- grammierung. Selbst wenn man nicht gewillt ist, diese "Basteleien" sel- ber vorzunehmen, kann man wohl davon ausgehen, daß in absehbarer Zeit Tool-Boxen angeboten werden, die z.B. Interpreterkerne oder Experten- system-Basen enthalten. Durch seinen angenehmen Syntax und noch viel mehr durch seine anderen Vorzüge kann Turbo-Prolog es meiner Meinung nach durchaus erreichen, ein De Facto Standard zu werden. Wenn ich dies alles betrachte, hat Turbo-Prolog alle Chancen die Erwar- tungen von Borland zu erfüllen, die angepeilten 2 Millionen Prolog-Pro- grammierer weltweit zu stellen. Das System ermöglicht (mit den erwähnten Einschränkungen) alles was man von einem Prolog-System erwarten kann, bietet zusätzliche Möglichkeiten für "normale" Programme (viele numeri- sche und Seiteneffektpredikate) und ist für PC-Maßstäbe unglaublich schnell. Ich möchte erstmal pauschal behaupten (bis zum Gegenbeweis), daß in Turbo-Prolog alles "geht" was auf einem PC in Hochsprachen überhaupt machbar ist. Abraten möchte ich nur von schlecht konvergierenden, nume- rischen Iterationsverfahren, da Tur- bo-Prolog den Numerik-Coprozessor anscheinend (ist nirgendwo erwähnt) (noch ?) nicht unterstützt. (Aber: Man nehme C ...) Dazu kommt noch die gute Benutzer- oberfläche, die auch in eigenen Pro- grammen verfügbar ist, und selbst dem absoluten Anfänger das Leben leicht macht. Was will man eigent- lich mehr ? Ich glaube, daß für die Zukunft ei- niges zu erwarten ist, und zumindest für mich persönlich hat sich das Abenteuer "Einstieg in Prolog" ge- lohnt (und Spaß gemacht hat's oben- drein). Und auch wenn ich jetzt vielleicht als blauäugig, fort- schrittsgläubig und über die Maßen begeisterungsfähig verschrien werde: Einsteigen Leute, durch deklarative Programmierung eröffnen sich ganz neue Möglichkeiten, und noch nie war es so einfach, gute Programme zu schreiben, wie heute.