[linux-l] Opal (was: Apropos Java-Bein-Klotz)
Rocco Rutte
pdmef at cs.tu-berlin.de
So Mai 29 21:05:38 CEST 2005
Hi,
* Oliver Bandel [05-05-29 18:43:00 +0200] wrote:
>On Sun, May 29, 2005 at 03:55:12PM +0000, Rocco Rutte wrote:
>> * Oliver Bandel [05-05-29 17:23:29 +0200] wrote:
>Ginge ein
>DATA Triple 0 1 2
>?
Mit == ja, also 'DATA Triple == 0 1 2'
>Ist das so was wie enum in C?
In dem Fall: ja. Alles hinter '==' sind Funktionen, die Ergebnisse vom
Typ liefern, der vor '==' steht. S.u.
>Was passiert, wenn ich 0 1 2 und ggf. weitere Int's
>in Verbindung mit Bit einsetze?
Das muss alles einzeln als Funktion definiert werden (wenn du mischen
willst).
>Was macht man, wenn man komplexe Datentypen schaffen will?
Du gibst einfach die Definitionen an. Weil die Implementierung dann
implizit klar ist, macht das der Compiler für dich.
>Zum Beipiel ein pair mit int und string oder int und int
>oder int und float?
DATA point == point1 (x1 : int, x2 : int)
point2 (x1 : real, x2 : real)
...
Die zwei Funktionen zur Erzeugung eines Objekts vom Typ 'point' heissen
auch 'point[12]'. Man kann das aber auch anders lösen:
DATA value == foo1 (x : int)
xyz0 (x : real)
DATA point == # (x1 : value, x2 : value)
Einen Punkt erstellt man im Code mit:
... point (foo1 (10), xyz0 ("0.2!")) ...
("0.2"! ist String->Real, s. ganz unten)
>> Ein großer Teil
>> der Standard-Datentypen ist zwar selbst in Opal geschrieben/kann man
>> selbst in Opal schreiben, aber es hat eben seine Grenzen. Die Menge
>> aller möglichen Strings ist ja recht, äh, groß.
>Also doch wieder selber definieren von Strings?
>Obwohl es sie (namentlich als "denotatioN" gibt?
>Ich raff es nicht, was Du mir sagen willst.
Um einen Datentyp zu definieren, braucht man 'DATA [typ] == [werte]'.
Bei Strings ist das Problem, dass man das über den Weg nicht lösen kann,
weil bei '[werte]' dann eben alle möglichen Strings stehen müssten. Und
weil das eben _nicht_ geht, geht folgendes auch nicht:
FUN handle : denotation -> denotation
DEF handle ("a") == "Wert a"
DEF handle ("b") == "Wert b"
Wenn man das trotzdem eigentlich machen will, muss man entweder in der
Funktion handle() selbst if-Abfragen machen oder man definiert sich
einen Datentyp für handle(), damit man
DEF handle (a) == "Wert a"
DEF handle (b) == "Wert b"
machen kann. Die if-Abfragen bleiben, allerdings werden sie nur in einer
anderen Funktion erledigt, bei mir conv(), die denotation nach dem neuen
Typ mapt.
>> DEF land (x1, x2) ==
>> IF 1? (x1) and 1? (x2) THEN true
>> ELSE false FI
>> ('1?(x) s.u.)
>Was macht der Code?
>Was bedeutet das Fragezeichen?
Man bekommt bei einem DATA-Statement sehr viel Implementierung
automatisch: Funktionen zur Erzeugung von Werten dieses Typs und
Abfragen. Für
DATA bit == 0 1
bekommt man:
FUN 0? : bit -> bool
FUN 1? : bit -> bool
die einem angeben, ob ein Objekt von einem Typ ist. Es ist also nicht
'1Fragezeichen' sondern die Funktion hat '1?' als Name (es gibt ja
nunmal nur Funktionen ;-)
>
>[...]
>> Die Sache mit den Konstruktoren ist so: wenn man
>> DATA opts == a b c BAD
>> schreibt, dann wird automatisch eine ganze Menge Zeugs implizit vom
>> Compiler implementiert:
>> FUN a : opts
>> FUN b : opts
>> FUN c : opts
>> FUN BAD : opts
>Das heisst, es werden a,b,c,BAD alle als Funktionen
>des Type opts deklariert?
Yepp. Und zwar als Funktionen, die _keine_ Parameter kriegen, weshalb es
in diesem Fall ein C-enum ist. In anderen Fällen ist es das nicht.
>Gibt es keinen Typ int/integer oder sowas in Opal?
Yepp.
>Muß man das irgendwie indirekt definieren (z.B. über
>eine Funktion, die den nachfolger einer Funkion durch Addition
>von 1 erzeugt), oder wie soll ich das verstehen?
Yepp. 0 gibt es immer, der Rest wird über succ()/pred() geregelt. Die
Zahlen von 1-32 (und noch ein paar 10-er Potenzen) sind via
"Standardbibliothek" vordefiniert. Der Rest, also z.B. eine 33, muss man
sich anders besorgen (gängige Praxis: String->Zahl).
Bei natürlichen Zahlen gibt es zum Beispiel in der Std.-Bilbiothek:
DATA nat == 0
succ (pred : nat)
Man kann selbst eine natürliche Zahl nur so definieren, dass man
entweder 0 nimmt, oder mit succ() den Nachfolger einen anderen Zahl
bekommt. Hat man
FUN foo : nat -> nat
dann kann man
DEF foo (0) == 0
machen, aber
DEF foo (1) == 1
geht _nicht_, weil die 1 eben _nicht_ in DATA drinsteht. Wenn man scharf
auf DATA guckt, dann sieht man evtl., dass folgendes widerum geht:
DEF foo (succ (0)) == 1
weil sowohl succ() als auch 0 in DATA stehen. Das hat übrigens nichts
damit zu tun, dass es eine Funktion 'FUN 1 : nat' bereits schon irgendwo
gibt. Die 1 steht nicht in DATA und damit kann ich sie nicht direkt in
den Parameter von Funktionen schreiben.
Ich habe jetzt keine Ahnung von der genauen Opal-Architektur, aber
vieles ist in Opal selbst geschrieben, andere Sachen in C hardkodiert.
Das meinte ich auch mit den Strings: Es gibt kein 'DATA denotation ==
...', wo alle möglichen Strings vordefiniert sind sondern
String-handling ist in C geschrieben. Es gibt kein 'DATA nat == ...' wo
die komplette Menge der natürlichen Zahlen definiert ist, usw. usf.
bye, Rocco
--
:wq!
Mehr Informationen über die Mailingliste linux-l