[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