Sprache Lava
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Lava ist eine experimentelle objekt-, pattern- und komponentenorientierte Programmiersprache, die zunächst am Fraunhofer-Institut SIT (Institut für sichere Telekooperation) von KlausGünther und seiner Frau Irmtraut entwickelt wurde und seit ihrem Eintritt in den Ruhestand von beiden noch "auf kleiner Flamme" weiterentwickelt wird. Lava ist OpenSource (GPL-Lizenz) und wird im FSF/UNESCO FreeSoftwareDirectory aufgeführt.

Bitte auf Seitentitel klicken um eine Liste der Seiten zu bekommen, auf denen diese Seite zitiert wird.


Die Lava-Programmierumgebung LavaPE benutzt für das Programmieren keine Texteditoren mehr, sondern ausschließlich Struktureditoren. Text-Eingabe ist nur noch für Kommentare, Konstanten und neue Bezeichner erforderlich. Formale Fehler werden entweder von vornherein unmöglich gemacht oder sofort im Moment des Entstehens gemeldet.

Änderungen an Deklarationen ziehen, wo immer möglich, automatische Folge-Änderungen an den Referenz-Stellen nach sich. Z. B. werden geänderte Bezeichner an allen Referenzstellen automatisch auch geändert; ändert man die Reihenfolge oder Anzahl der Fomalparameter einer Methode, so werden an allen Referenzstellen die Aktualparameterlisten entsprechend angepasst.


Zur Einordnung von Lava:

Lava-Statements kann man als logische Statements ansehen. "Ausführen" eines Statements kann als "Verifikation" aufgefasst werden. Sie liefert einen Wahrheitswert (wahr/falsch). Das Semicolon kann als logische UND-Verknüpfung von Statements (genau wie das Lava-and, aber mit niedrigerer Priorität) aufgefasst werden. Die logischen Verknüpfungen werden jedoch sequentiell ("von oben nach unten") ausgewertet/verifiziert. Insbesondere sind if-Bedingungen keine Ausdrücke, sondern zu verifizierende Statements (die aber keine Wertzuweisungen enthalten können). Variablen sind keine "Datenbehälter" mit wiederholter Zuweisung wechselnder Inhalte, sondern "Unbekannte", denen durch sequentielles Ausführen (in gewissem Sinne "Auflösen") von Assignment- und Function-Statements Werte/Lösungen zugewiesen werden. Funktions-Parameter sind entweder Input- oder Output-Parameter. Dadurch ist eine "Auswertungsrichtung" innerhalb des Funktions-Rumpfes und an den Aufrufstellen vorgegeben. Input-Parametern darf im Funktions-Rumpf kein neuer Wert zugewiesen werden (sie haben ja schon einen, = eine "Lösung": Single-Assignment), nicht-optionalen Output-Parametern muss hingegen in jedem Programmzweig des Funktions-Rumpfes ein Wert zugewiesen werden (wird schon zur Programmierzeit geprüft, was erst durch das Single-Assignment und die Abwesenheit traditioneller Variablen und Schleifen möglich ist).

Aus all dem mag man schließen, dass Lava ein Zwitter ist, der zwischen den objekt-orientierten, imperativen und den prädikativ-funktionalen Sprachen steht: logisch-funktionale Semantik, aber mit traditionellem Auflösungsverfahren (statt Unification / Resolution oder Lambda-Kalkül / Termersetzung), das auf sequentieller Auswertung logischer Verknüpfungen und Quantoren (mit endlicher Grundmenge) und sequentieller Wertzuweisung an Single-Assignment-Variablen / Unbekannten basiert.

Lava als deklarative Sprache zu bezeichnen hätte ich jedoch große Hemmungen. Lava ist jedenfalls weder funktional noch prädikativ im üblichen Sinne. Stattdessen gibt es die mehr traditionellen Begriffe der Wertzuweisung an eine Variable und der sequentiellen Ausführung von Statements. Es gibt zwar Single-Assignment, und herkömmliche Schleifenkonstrukte werden durch Rekursion und Quantoren ersetzt; insofern nähert sich Lava einer mehr mathematischen Sicht mit Funktionen und Prädikaten an. Aber "funktional" und "prädikativ" haben, denke ich, doch eine enger gefasste Bedeutung (vgl. auch ProgrammierParadigmen und ProgrammierParadigmen/Begriffe). Lava ist jedoch gewiss objektorientiert.


Weitere Lava-Highlights:

Näheres siehe http://lavape.sourceforge.net/doc/html/LavaOverview.htm.


Kommentare

...automatisch...geändert... ...solche Fähigkeiten werden z. B. bei ExtremeProgramming (siehe WardsWiki:RefactoringBrowser) stark forciert und werden durch eigene Produkte in den Sprachen relativ mühsam "nachgerüstet". Verwendet ihr das Refactoring-Gedankengut?

Bislang nur auf der Basis von ein paar eigenen, naheliegenden Ideen. Man könnte da sicher noch viel mehr machen. Z. B. automatisches Erkennen von Teilen einer (immer mehr gewachsenen) Klasse, die sich als Basisklasse abspalten ließen, o. ä.

Eine ganze Reihe mehr elementarer "Refactorings", wie sie zum Beispiel von JRefactory angeboten werden (Umbenennen, Verschieben, Kopieren, ...), gehören jedoch zu dem Standard-Repertoir der Lava-Struktureditoren.

Frage zu ...automatisch...geändert...: Was passiert, wenn ich zu einer hundertfach verwendeten Funktion einen Parameter hinzufüge? Wie wird die erforderliche Änderungsarbeit in der Oberfläche organisiert bzw. automatisiert?

Bislang nur dadurch, dass in allen Aktualparameterlisten an der entsprechenden Stelle ein (dann noch auszufüllender) Expression-Platzhalter für den neuen Parameter eingesetzt wird. Platzhalter (= syntaktische Variablen) werden in rot dargestellt, wie auch Fehler, und man hat zwei Navigations-Buttons "next error" und "preceding error", mit denen man sich von einem Fehler/Platzhalter zum nächsten/vorigen bewegen kann.

Frage: Gibt es noch die Möglichkeit, auf rein textuelle Art auf den Source zuzugreifen und über grep (über Projektgrenzen hinweg) oder global replace schematische Arbeitschritte durchzuführen?

Nein. Das wäre auch sicher aufwendig zu realisieren und schwer mit dem Structure-Editing zu vereinbaren. Aber ich glaube, man muss überhaupt aufhören textuell zu denken, sondern muss in syntaktischen und höheren strukturellen Bausteinen denken und sinnvolle Verfahren zu deren Manipulation ersinnen.--KlausGünther

Ein zum System passender Ansatz würde wahrscheinlich darin bestehen, dass LavaPE ein API anbietet, über das ein "Lava-AST" oder ein "Lava-DOM" bearbeitet werden kann. Die ganzen üblichen Tools müssten dann statt auf Textdateien auf diese Schnittstelle zugreifen.

Nur - bis alle Tools zu diesem Zweck neu geschrieben oder angepaßt wurden, würde viel Zeit vergehen, so dass eine Zwischenlösung schon sehr wichtig wäre. Ich würde mir dafür wünschen, dass man Lava-Programme oder -Bibliotheken in Textdateien exportieren und aus diesen importieren könnte. Dabei wäre es schön, wenn verschiedene Formate zur Verfügung stünden. Ein XML-Format wäre recht gut geeignet, um mit gängigen Tools Manipulationen durchzuführen, die sich relativ leicht tatsächlich auf strukturelle Elemente beziehen könnten. Es gibt aber auch Situationen, wo traditioneller - für Menschen gut lesbarer - Source-Code sehr wertvoll ist, z. B. um ihn in ein traditionelles, bereits vorhandenes Source-Code-Verwaltungssystem zu übernehmen. (Auch wenn es natürlich schade ist, dass das Potential, das in einer AST/DOM-orientierten Lösung gerade für so ein Tool stecken würde, damit ungenutzt bliebe. Aber wir können vielleicht nicht für jede Programmiersprache ein eigenes Source-Code-Verwaltungssystem einführen.) -- her

http://www-106.ibm.com/developerworks/java/library/j-javaml/ --AnonymerFeigling?

http://developers.slashdot.org/article.pl?sid=03/06/13/1815241


KategorieProgrammierSprache KategorieProgrammierSprachenKonzepte KategorieLava
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 28. Juni 2008 15:35 (diff))
Suchbegriff: gesucht wird
im Titel
im Text