[linux-l] Trennung von "readline" und Interpreter im Unix-Stil

[Peter Ross]

Hi Volker,

On Thu, 5 Apr 2007, Volker Grabsch wrote:

> 
> Wir haben hier also zwei grundverschiedene Ansätze: Auf der einen
> Seite die Aufgabentrennung im klassischen Unix-Stil:
> - "ledit" als universelle Kommandozeile
> - der Interpreter (z.B. Ocaml), der durch Pipelines angesteuert wird
> 
> Auf der anderen Seite eine enge Kopplung ala "ipython", die auch
> höhere Ansprüche bedienen kann. z.B. braucht man ne enge Verbindung
> für die Tab-Autovervollständigung. Die ist ja abhängig ist von dem,
> was man in der Interpretersitzung gerade definiert oder importiert hat.
> 
> Nun wird aber "ipython" intern ebenfalls eine Aufgabentrennung haben,
> und für alle "Interpreter-Aufgaben" entsprechende Libraries verwenden.
> Das heißt, die Ansätze konkurrieren eigentlich auf einer ganz anderen
> Ebene: Trennt man die Aufgabe in zwei Prozesse mit einfacher/universeller
> Schnittstelle, oder trennt man sie durch dynamisches Linken gegen eine
> entsprechende Bibliothek, d.h. mit einer API als Schnittstelle?
> 
> Wie seht ihr das? Sind das zwei gleichberechtigte Ansätze, oder
> gibt es sowas wie Design-Richtlinien, welchen man i.d.R. bevorzugen
> sollte?
 
Man koennte bestimmt einen Religionskrieg drum fuehren;-)

Ein Gedanke:

eine intelligente Eingabe kennt die Syntax einer Sprache, und der 
Interpreter kennt sie auch..

Also sollten sie sich den Parser teilen.

Der vim kennt auch Syntaxregeln.. die zumeist mehr oder weniger zufaellig 
mit einer existierenden Sprache uebereinstimmen..

Wenn die Parser einer Sprache, die ich gerade installiere, ueber eine API 
offenlege, dann koennten alle Texttools darauf aufbauen..

Inwiefern dass mit den Anspruechen einer Sprache und der Performance 
harmoniert.. nun ja, vielleicht eher nicht;-)

Da die Sprachen aber alle ihre eigenen optimierten Parser (gerneauch 
eigene interaktive Ijnterpreter) haben bleibt diese Idee illusorisch..

Ich befuerchte, die Diskussion ist ziemlich akademisch..

Gruss
Peter