[linux-l] Re: [linux-l] Re: [linux-l] [OT (?)] FPLs und Anderes Gesülze (Re: [linux-l] LinuxScript?)
Steffen Dettmer
steffen at dett.de
So Apr 7 04:12:54 CEST 2002
* Oliver Bandel wrote on Sat, Apr 06, 2002 at 19:17 +0200:
> On Fri, 5 Apr 2002, Steffen Dettmer wrote:
> > * Oliver Bandel wrote on Fri, Apr 05, 2002 at 16:27 +0200:
> > > On Fri, 5 Apr 2002, Steffen Dettmer wrote:
> > > > * Oliver Bandel wrote on Thu, Apr 04, 2002 at 22:21 +0200:
> > > > > On Thu, 4 Apr 2002, Steffen Dettmer wrote:
> > > > > [on this ident level]
> [...]
>
> (hoffentlich klappt das mit den Einrückungen auch wirklich... ;-))
Mein vim macht immerhin abwechseln farbig. Sonst könnte man das
kaum noch zuordnen :)
> ausdenken, aber irgendwie weiß ich halt nicht,
> wie Du darauf gekommen bist, daß man Zahlen und Listen
> von Zahlen vergleichen will.
Kaum aus dem Beispiel.
> Hattest Du wegen des Haskell-Codes irgendwie noch Fragen?
Erstmal nicht. Geht mir mehr um das Allgemeine.
> > > Auch nicht, wenn sie "rein passen", wie in C?
> > > In C wird dann nämlich implizit konvertiert.
> >
> > Ja, hat eben so alles seine Vor- und Nachteile. Das ist's ja
> > eben: nichts ist ideal, kommt immer auf das Problem an.
>
> Ja. Nur ist's eben, daß wenn man eine Sprache auswählen will, weil
> sie mit der Typisierung streng umgeht, und das als absoluten
> Vorzug hält, als wichtiges Instrument, um zu verhindern, sich
> in ewig dauernden Debugging-Arien auszumehren, dann sollte man
> sich freuen, wenn es da Sprachen gibt, die noch strenger sind und
> erwägen, auch diese einzusetzen.
Finde ich eben nicht. Weil da eben auch Nachteile dranhängen,
nimmt man eben nicht Ada oder sowas ganz strenges. Hängt immer
sehr vom Problem ab.
[...]
> Man gucke sich dann an, wie es in Firmen läuft: Zu rigide Planung
> oder garkeine Planung, alles mit netten Worten verdeckt,
> und die Projekte semmeln regelmäßig ab: Termine platzen,
> weil die teils wirklich zu knapp ghehalten sind, teils die Leute
> ewig debuggen, statt sich vorher nen Kopf zu machen...
>
> Naja, was reg' ich mich eigentlich auf... :(
:) Echt, geht uns doch allen so :)
> > > > ["int" cast in "char"]
> > [...switch(int)...]
> > > > > Statt dessen casten?
> > > >
> > > > Ja.
> > >
> > > Ich würde das mit if's abfragen und entsprechend zuweisen; dann
> > > habe ich die Umwandlungsbedingung *explizit* im Code stehen.
Bleibt dann aber ein cast.
> > Das ist ja analog zum switch. Wird bei langen, langweiligen
> > Kolonnen schnell albern.
>
> *Ein* if zum Abfragen des Bereichs:
>
> if(value <= 0 || value >= 255) /* Kommentar, worum's hier geht */
> return dies_und_das_veraendern(value); /* dies_und_das ggf. erläutern */
> else
> return value;
Wo wird hier denn ein Typ geändert? Es ging doch in meinem
Beispiel um eine Konvertierung eines int's, der einen ASCII-Wert
darstellt, in ein char. Das ohne cast geht ja nur mit switch.
> > > Bitmaske z.B.. => alle oberen Bits wegschnippeln.
> >
> > Bitmaske auf reele Zahlen ist ja auch schon wieder unschön...
>
> int's sind nicht reele Zahlen, sondern Ganzzahlen.
Wobei Ganzzahlen eine Teilmenge der reellen Zahlen sind, also
doch :)
> Oder meinst Du, weil int's keine Bitmasken sind?
> Ok, so gesehen ist der Einwand ok.
Weil bitmasken schon wieder Maschinenabhängig sind. Das
Bitmaskengespiele funktioniert vielleicht auf ASCII Maschinen,
aber auf EDEBI.. Wie hieß der Kram gleich? 6 Buchstaben
jedenfalls :) DA haut das mit dem 7. Bit überhaupt nicht mehr
hin. Und auch ganz andere Codes sind denkbar. Jedenfalls sind
Bitmasken auf nicht-byte/octet-Typen nicht sicher.
> > > Auch dann hat man die Konvertierung expliziert (= lesbar
> > > im Code, was man macht).
> >
> > Na, dann wird ein int vorher eben in ein Byte konvertiert,
> > bleibt implizit.
>
> Was meinst Du?
Wenn Du - auch im if oder sonstwo - plötzlich einen int als char
returns, ist es auch nur ein cast.
> [...]
> > > Den Lambda-Kalkulus kann ich Dir nicht runterbeten, das lernt man
> > > ja offensichtlich nicht mal im Informatikstudium.
> >
> > Ich glaube, man vergißt es nur zu schnell ;)
>
> Na, also sowas... wenn ich mir vorstelle, ich hätte die
> die Kirchhoffsche Gesetze verlernt, nur weil das ein
> paar Jahre her ist, daß ich sie gelernt und gebraucht habe...
> ...also wirklich... tse, tse, tse...
Wenn ich nicht 95% vom dem, was ich mal gelernt hab, vergessen
hätte, würde ich vermutlich schon längst den Verstand verloren
haben :)
> wenigstens das Grundprinzip solch wichtiger dinge sollte man
> noch im Schädel haben, so daß man sich das mathematische ggf.
> herleiten kann...
Es gibt soviel "wichtige" Dinge... Manchmal braucht man es eben
nicht :)
> > > Der Vorteil der Flexibilität fällt einem da auf die Füsse!
> >
> > :) Ich mag das und mir fiel das noch nicht auf die Füße. Aber
> > lassen wir das...
>
> Ich mag das auch, und wenn man sauber arbeitet, kann man das
> Gewicht des fallenden Gegenstands auch gut minimieren, aber
> es ist ein prinzipielles Problem, das da weiterhin bleibt.
Es ist maximal risk-management. Wenn es einem mit 5%
Wahrscheinlichkeit auf die Füße fallen kann, aber man dafür 50%
zeit spart, lohnt es sich ja oft.
Sonst gäbe es ja nur Ada :)
> > Aha, also eine Liste von nur Ints oder nur Floats, ja?
>
> Ja.
> Haskell macht das auch so.
> Aber in Scheme kann man gemischte Listen haben.
Also dann ähnlich zu Perl :)
> [...]
> > > > Natürlich kann ein Compiler keine wirkliche Konsistenzprüfung
> > > > machen, weil diese ja erst zur Laufzeit möglich ist klar, das
> > > > gilt natürlich für alle Sprachen.
> > >
> > > Nein. Eben nicht.
> > > Typenkonsistenz kann man eben erzwingen.
> >
> > Ja, schon klar.
>
> Wieso schon klar?
> S.o.: Da sagst Du, daß das garnicht geht.
> Wieso geht das denn nun doch?
Typkonsistenz heißt ja nur, daß Typen passen. Aber das hängt von
den Typen ab. Ist eine Ganzzahl ein Typ (Java)? Oder spielt auch
das Vorzeichen eine Rolle, spricht Natürliche Zahlen anders als
Ganzzahlen (C++)? Oder ist ein Typ mit einem Wertebereich von
1..5 was anderes als ein Typ mit einem WB von 2..6 (Ada)? Oder
gibt es "nur" Zahlen (in etwa: Perl)? In Perl sind skalare Typen
so gesehen eben immer konsistent. In Ada kann aber ein i = i + 1;
zum Fehler führen (wenn es dadurch aus dem Bereich kommt). Also
kann man die Konsitenz zur Compilezeit erzwingen, wenn man die
Typen locker genug macht. Und macht man sie streng (Ada), muß man
eben zur Laufzeit pürfen. Aber so genau wolltest Du es bestimmt
nicht wissen :)
> [...]
> > Programmieren ist ja im Prinzip übersetzen eines Algortihmus in
> > eine Programmiersprache.
>
> Also ich fasse unter Programmieren auch das Designen.
Ich nenne das Entwicklung. Programmieren ist im Prinzip nur
Implementation.
> Programmieren umfasst also meiner Auffassung nach
> Design + Coding.
Programmieren ist bei mir das, was mit Programmiersprachen zu tun
hat. Vielleicht "Implementation mit Mitdenken". Na ja, kann man
nehmen, wie man möchte.
> > Wenn ich eine GUI in C bauen soll, weiß
> > ich aus Erfahrung, daß das umständlich wird, und nehme lieber
> > Java.
>
> Objective-C ist was feines. Ex-Java-isten, die auf
> Objective-C umgestiegen sind, fragen sich immer wieder,
> wieso sie sich so lange mit Java haben quälen lassen...
Vermutlich fragen sich das auch die Ex-Objective-C-isten, die auf
Java umgestiegen sind.
> > Ich denke, Funktionales Programmieren sollte man in prozeduralen
> > Sprachen mehr oder weniger gut abbilden können. Natürlich muß man
> > einige Sachen mehr machen, klar.
>
> Ist ebenso wieder eine Sache, inwieweit man OO in C
> machen kann. Kann man auch abbilden... natürlich
> können einige Sprachen mehr machen, klar.
Na ja, OO in C geht eben nicht mehr gut genug, finde ich. Wie
weit man mit funktionaler "Emulation" kommt, weiß ich nicht.
> > Manchmal hilft es vielleicht, wenn man ein Problem nicht
> > funktional lösen kann (weil man z.B. Java benutzen muß), es so
> > "funktional wie möglich" zu lösen. Der Punkt ist sehr interessant
> > für mich.
>
> Ja, das hiesse dann "functional design", aber dann mit einer
> imperativen/OO-Sprache implementieren.
>
> Ist durchaus nichts gegen zu sagen, ebenso, wie man
> OO-Design auch mit ANSI-C implementieren kann.
Na ja, eben nicht wirklich. Das Ergebnis wird vermutlich ziemlich
häßlich. Kommt drauf an, auf welche Eigenschaften man Wert legt.
Hier kommt dann hinzu, daß man kaum noch Vorteile gewinnt, finde
ich.
> > Ja, dachte ich auch. Danach kann man aber diese Sachen auch
> > brauchbar in z.B. Perl abbilden. Vielleicht sollten wir mal ein
> > konkretes Problem probieren?
>
> Gib mir noch etwas Zeit mit OCaml.
> Ich mag keine halben Sachen. Wenn ich die Sprache beherrsche,
> können wir das gerne mal machen. Im Moment erkunde ich noch
> die schier unvorstellbar genialen Möglichkeiten. :)
Vielleicht bist Du auch noch in der Phase der Begeisterung, die
ja bekanntlich vor der Ernüchterung (und diese vor der
Resignation) kommt :)
> > > Mit anderen Worten: Das beste Vorgehen, mit der Sache weiter zu kommen
> > > ist, daß Du Dir eine FPL installierst und es ausprobierst.
> >
> > Na ja, dazu braucht man Zeit.
>
> Die Installation ist recht einfach. ;-)
> OK, das Lernen der Sprache braucht ein Weilchen. ;-)
> (Ist immerhin reichlich unähnlich zu den typischen
> anderen Sprachen...)
Die Frage ist, wann kann man damit Geld verdienen oder Zeit
sparen. Da ich selten Primzahlen berechnen muß, lohnt es sich
vermutlich nicht.
> > Und erst am Ende kann ich erkennen,
> > ob es mir was gebracht hat.
>
> Wird auf jeden Fall was bringen.
> Wie hatte der Master of The Bazaar mal geschrieben:
> Lisp lernen erweitert den Horizont. Hier wird es nicht
> anders sein. :)
Na ja, wenn FPL soviel bringt wie Lisp, muß ich es wohl lassen...
Na ja, ich kenne aber nur ne Handvoll Leute, die überhaupt ein
bißchen was mit Lisp gemacht haben.
> > Ich werde in der Praxis sicherlich keine funktionale Sprache
> > verwenden
>
> Was ist "die Praxis"?
> Nur berufliche Praxis, oder auch private?
Ja, beruflich. Privat mache ich keine > 10.000 Zeilen Projekte...
> (OK, ich kann verstehen, wenn Du nach einem langen Arbeitstag
> nicht weiter kompilieren willst... ;-))
Ich hab privat auch selten den Bedarf dafür. Privat reicht
meistens Perl.
> > Es geht nicht darum, daß das nicht verständlich war. Ich bin eben
> > nur der Meinung, daß man es prozedural abbilden kann. Das mal
> > also die Vorgehensweise eben auch in Perl verwenden könnte.
>
> Naja, man kann es vermutlich ähnlich schlecht oder noch schlechter
> Abbilden, als OO in ANSI-C.
Mach doch mal ein Beispiel. Code in OCaml und in Perl für ein
einfaches Beispiel. Dann kann man sich das endlich mal angucken
:)
> Ob OO oder non-OO imperativ, man arbeitet mit Variablen
> und Zuweisungen an Variablen, etc..
> All das ist schon Arbeiten mit Seiteneffekten!
Du mit Deinen Seiteneffekten... Lokale Variablen in Funktionen,
die man übrigens immer weglassen kann, die sind nur ne Art "short
hand" oder "Term-Namen", erzeugen keine Seiteneffekte, weil deren
Zustand beim Funktionseintritt immer gleich ist.
> In funktionaler Programmierung geht das aber nicht. Da gibt es
> nur name-value-bindings.
Das sagtest Du bereits, und ich hab's tatsächlich gemerkt :)
> Und ein solches kann man nur einmalig machen. Macht weist man
> dem selben namen eine Value zu,
Häh? Ich denke, daß geht eben nicht?!
> dann besteht die alte Value weiterhin, wird aber von der neuen
> verdeckt und ist daher im scope nicht verfügbar.
ist bei i = 5; i = 6; auch so. 5 gibt's immernoch.
> Ein Beispiel, wo man z.B. Probleme mit Seiteneffekten
> offensichtlich sieht, sind in C die && und ||
> Konstrukte und wenn man in solchen Konstrukten
> Funktinen aufruft, die eine Rückwirkung auf
> die Auswertung dieses Konstrukts haben.
Ja, mit genügend krimineller Energie geht sowas. Normalerweise
vermeidet man Ausdrücke, die einen Wert benutzen und verändern.
> => Abarbeitungsreihenfolge ist wichtig (in FP
> ist die Reihenfolge der Abarbeitung egal,
> denn eine mathematische Gleichung löst man auch
> immer auf die selbe weise...,
In der Mathematik ist die Reihenfolge der Operatoren nicht egal.
Das ist sehr analog zu C. Punktrechnung geht vor Strichrechnung,
und ++ geht vor &&. Wer sowas wie "++i+++++i++" schreibt, ist
kriminell. Aber für Dämlichkeit des Programmiers kann die Sprache
ja nix.
> unabhängig davon, wo man anfängt (z.B. Polynom bei höchster
> oder niedrigster Potenz zuerst auszurechnen...))
Man muß aber die Bindungsrichtungen und Operatorbindungsstärken
beachten.
> > Das kann man in C++ sehr gut abbilden: man nimmt eine Referenz. Der
> > kann (muß!) man einmal (bei der Erzeugung) einen Wert verpassen.
>
> > Die Referenz hat damit immer (zu ihrere Lebenszeit) den selben
> > Wert.
>
> Kann mit nur solchen Konstrukten in C++ programmieren?
> Und falls ja, geht das auch ohne zu umständlich zu werden?
Ja, natürlich, gängige Praxis. Referenzen (außer bei
Methodenparametern) werden fast immer bevorzugt gegenüber z.B.
Zeigern. Zeiger braucht man ja nur, wenn das "Eigentum" eines
Objektes übertragen wird (also A es erzeugt und B es löscht).
Deshalb braucht man in Java auch nur Referenzen und keine Zeiger,
weil man ja Objekte nicht löschen muß. Manchmal nimmt man auch
keine Referenzen, wenn man das Objekt explizit kopieren
möchte.
> > - keine globalen Variablen
> > - keine static's in Funktionen
>
> - keine Zuweisungen an Variablen
Warum? Lokale Variablen erzeugen keine Seiteneffekte.
float func (float a, float g)
{
float prozent = g/a * 100;
return (prozent + 10);
}
ist äquvivalent zu:
float func (float a, float g)
{
return ( (g/a * 100) + 10);
}
Ersteres ist nur lesbarer, besonders bei Komlizierten Ausdrücken.
Man kann natürlich auch Funktionen nehmen:
float prozent (float a, float g)
{
return = g/a * 100;
}
float func (float a, float g)
{
return (prozent(a,b) + 10);
}
Na ja, die letzte Möglichkeit der drei ist aber meist nicht mehr
äquvivalent, sondern langsamer. Aber meistens ist das egal.
> (einigen wir uns auf einmalige Zuweisung, wie bei Referenzen,
> um dem Ziel nahe genug zu kommen.)
Das ist keine richtige Zuweisung; das ist eher ne Konstruktion.
const int i = 5;
ist auch keine Zuweisung. i hatte nie einen anderen Wert. Es wird
nur die gleiche Syntax wie bei einer Zuweisung verwendet.
> > Dann kann man keine Seiteneffekte mehr produzieren.
>
> Doch, s.o.
Bitte mal ein Beispiel für einen Seiteneffekt durch lokale
Variable!
> > Seiteneffekte; jedoch fallen mir keine bei guter Software ein
> > (wenn ich mal an meine Praxis denke).
>
> Jede Variablenzuweisung; Arbeiten auf Arraydaten z.B. fallen
> darunter. :)
Beispiel bitte! Verstehe ich nicht.
> Was ich meinte, ist aber implizite Typ-Konvertierung.
> Die Typen passen nicht zusammen, also würden Sprachen
> mit strenger Typprüfung es nicht gestatten, diesen
> Aufruf durchzuführen.
Na ja, in Ada z.B. passen 1..5 und 2..6 nicht zusammen, auch wenn
der Wert gerade 3 ist. Aber das kann auch nervig sein. Und
strenggenommen ist auch Ada nicht ausreichend, denn es kann ja
zwei a..b Typen geben, wo die a's und b's gleich sind, die Typen
jedoch nicht...
> In manchen Sprachen hilft dann ein cast.
> Und in wieder anderen muß man explizit eine Konvertier-
> Funktion nehmen, oder eben eine Funktion nutzen, die
> mit dem Typ übereinstimmt (bzw. Parameter entsprechend
> entgegennimmt).
>
> Letzteres ist am klarsten, weil am explizitesten.
In C++ muß man ja (fast immer) explizit casten.
> um alles berechnbare zu berechnen (Informatiker faseln
> dann gerne von Turingvollständigkeit), dann kann
> man mit den Sprachen auch alles machen.
> Also geht's auch in Assembler, oder TeX.
> Oder mit nem Abakus ;-)
:) Nee, der hat keinen unendlichen Speicher, ist also keine
Turingmaschine :)
> > sub filter ($@)
> > {
[...]
> > }
> >
> Im Prinzip geht das.
> Du hast hier aber z.B. auch wieder keine Typprüfung.
Doch, bloß nicht so streng wie vielleicht in OCaml. Und OCaml ist
nicht so streng wie Ada. Warum soll nu gerade OCaml das richtig
non-plus-ultra sein?!
> Die must Du selbst einbauen, oder, wenn man es
> anders wendet: Da Du hier keine Typprüfung eingebaut hast,
> könnte man böswillig sagen, die Disziplin des Programmierers
> läßt hier zu wünschen übrig.
Ich muß ja nicht prüfen, da die Funktion ja für alle Typen
funktioniert. Die Condition-Funktion muß evtl. Typen prüfen, je
nach dem, wie sie aussieht. Der copyFilter, mit condition = true
z.B. muß keine Typen prüfen und ist trozdem Typsicher.
> Aber eben da ist dann der Haken: Bei der Prüfung der Argumente
> - und diese kann erheblich aufwendig werden, wenn man
> es richtig machen will - muß man eben wieder selbst
> Arbeit rein stecken.
Kannst Du im OCaml einen Int definieren, dessen Wertebereich von
1 bis 5 geht?
> Und selbst, wenn Du prüfst: Es bleibt das Problem, daß
> man die Daten immer nur als scalar bekommt - auch bei
> Referenzen -, und wenn die Daten "gefaket" sind
> - z.B. wollte man Referenzen mit regexps ändern,
Das geht überhaupt nicht. Du kannst höchstens die
String-Repräsentation der Ref ändern, dann ist es aber eine
Stringmanipulation...
> weil man "so coole features" nutzen wollte, und dabei hat man
> einen Fehler gemacht -, dann hast Du das Prinzipielle Problem,
> daß Perl Dir nichtsicher stellt, sowas tatsächlich auch zu
> erkennen.
Woher soll Perl auch wissen, ob man i = 5 nu richtig oder falsch
ist?!
> Wenn Du eine falsche Referenz übergibst,
geht was schief, genau, wie wenn man in OCaml eine falsche Liste
übergibt...
> Was zum Beispiel, wenn Du print als test (condition)
> übergibst? Mit Typprüfung wäre sowas aufgefallen.
> So hast Du nun immer true.
Ja, für einen copy-Filter ja auch richtig. Vielleicht möchte ich
ja genau das. Aber Du hast Recht, in Java würde ich auch lieber
ein Interface definieren. Sowas ginge in Perl aber auch, muß man
noch eine ISA Abfrage einbauen. Macht Perl eben nicht implizit.
Hat eben alles seine Vor- und Nachteile.
> Das ist natürlich alles nur eine Notlösung.
> wie Perl mit all zu tiefen Rekursionen umgeht,
> weiß ich auc nicht.
Na ja, irgentwann ist der Swap auch voll :)
> > > > Perl also für die Helferchens und so.
> > >
> > > Naja, man kann auch schon Applikationen damit bauen.
> >
> > Wieviele TOCs ungefährt? Mehr als 1000?
>
> TOC?
> Oder LOC?
LOC natürlich.... Na ja, spät hier :)
> > > Ja. Entweder direkt, oder CGI.pm.
> >
> > CGI ist schon richtig, aber egal.
>
> CGI.pm ist auch richtig, aber egal.
Ja, sagte ich doch, oder?
> > Na ja, stimmt, aber muß man eben einen guten Compiler nehmen.
> > Aber Du hast Recht, wenn man es ganz genau nimmt, gibt es nicht
> > ein C, sondern hunderte C-Sprachen. Die C-Sprachfamilie :)
>
> Aber nur ein ANSI-C.
Ansi-C läßt sicherlich auch noch Fragen offen. Vermutlich ist das
const handling auch nicht genau definiert.
> [...]
> > > Welcher MUA?
> > > (Neugier!)
> >
> > Na, ich verwende mit Begeisterung "mutt", der alles übertrifft,
>
> wat mutt, dat mutt? ;-)
Jenau so schauts klaus.
> > was ich sonst so kenne, wenn man viel Mail schreibt. Aber muß man
> > dafür erst ziemlich konfigurieren, damit er bunt wird etc.
>
> Also, Bunt ist mir nicht so wichtig.
Mir schon, wichtige Mails von wichtigen Leuten eben rot, sonst
kommt man mit der Flut so schlecht klar :)
> Aber struktur der Anzeige. Wenn ich einen newstgread habe,
> willich, das der aufgegliefdert dargestellt wird
> (Baumstruktur). Wenn das ein Mailer auch bietet, hat er gute
> Chancen, mit mir einen neuen Nutzer zu gewinnen.
Ja, das ist *eines* der Features, die mutt so hat.
> [...]
> > Objekte zu übertragen (muß man ja händisch serialisieren und so),
> > und bei CORBA kann man eben schlecht die Schnittstelle ändern.
>
> Übertragen von Objekten über's Netz?
Nein, eher Aufrufen von Objekten, die woanders leben.
> In Objective-C/cocoa-Environment rufst Du da nur die
> entsprechende Methode auf und bekommst die Objekte
> ausgedumpt.
Nützt ja nix (Serialisierung braucht man natrülich für die
Parameter).
> > Also haben wir eine flexible CORBA Schnittstelle und davor
> > Wrapperklassen (genauer: Adapter und Dekoratoren) gebaut, damit
> > man es komfortabel benutzen kann. Ist echt nicht einfach, wenn
> > man Schnittstellen braucht, die "abwärtskompatibel" sein sollen.
> > Aber das hängt immer stark von den Anforderungen ab.
>
> Naja, so kompliziert kann das doch auch nicht sein. ;-)
Doch, natürlich, woher soll man denn wissen, was man morgen
braucht?
> Verschiedene Schnittstellen nicht OO-mäßig, sondern
> über unterschiedliche Syntaxen zu verkoppeln,
> die dann halt ineinander übersetzt werden müssen,
> das wäre eina nderer Ansatz; einer, der den FPLs
> entspräche, und einer, der vermutlich letztlich
> einfacher zu realisieren sein wird.
Verstehe ich nicht. Syntax wovon? Was in was übersetzen?
> > Bei mir gab's irgendsowas. Frag mich nicht warum, aber ich
> > hatte ein blaues Auge davon (ungelogen! Es war blau, als
> > hätte ich mich gekloppt!). Nervig war das.
>
> KRASS!
Fand ich auch, da rennt man dann ne Woche rum, wie so'n
Schläger...
> Da hast Du zu dem Spruch "jemandem auf den Zahn fühlen"
> wahrscheinlich ein etwas anderes Verhältnis, als vorher, was?
Der Zahn tat überhaupt nicht weh. Lag ruhig in der Schachtel :)
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
Mehr Informationen über die Mailingliste linux-l