[linux-l] Re: Apropos Java-Bein-Klotz

Rocco Rutte pdmef at cs.tu-berlin.de
So Mai 29 17:55:12 CEST 2005


Hi,

* Oliver Bandel [05-05-29 17:23:29 +0200] wrote:
>On Sun, May 29, 2005 at 02:18:45PM +0000, Rocco Rutte wrote:
>> * Oliver Bandel [05-05-28 15:42:58 +0200] wrote:

>> Aber einen solchen Konstruktor braucht man, um ihn direkt als Argument 
>> einer Funktion zu benutzen. Zum Beispiel baut man einen neuen Datentyp 
>> 'Bit' so:

>> DATA Bit == 0 1

>> Diese '0' und '1' kann man dann für soetwas wie "Überladen" benutzen:

>Aha, interessant. Kann man so Datentypen via Beispiele konstruieren?
>Wie sieht das dann mit den Strings aus?
>Muesste man alle möglichen Strings in DATA pressen?
>Oder gibt es da eine "type"-Deklaration?

Ich verstehe die Fragen nicht.

Und Strings, in Opal "denotation", sind fest eingebaut. 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ß.

>> Allerdings ist das Problem, dass alles, was man direkt im Argument der 
>> Funktion schon nutzen will, auch in obiger 'DATA Bit ==' Anweisung 
>> stehen muss. Und bei Denotation gibt es keinen Konstruktor, der schon 
>> alle möglichen Strings umfasst. Deshalb musste ich in meiner Lösung erst 

>Das klingt allrdings wieder sehr aufwendig.

Jein, es ist nicht immer so. Wenn man es direkt im Argument bei der 
Funktionsdefinition nutzen will, dann braucht man es, sonst nicht. Ich 
kann auch folgendes machen:

DEF land (x1, x2) ==
  IF 1? (x1) and 1? (x2) THEN true
  ELSE false FI

('1?(x) s.u.)

>OK, Du sparst zwar solche "->" Bindings, aber hier machst Du ja irgend
>etwas, das einem Pattern-Match in Ocaml entspricht, aber Haskell-ähnliche
>Syntax nutzt.

>-- handling functionality
>FUN handle : denotation ** opts -> denotation
>-- the handle functions
>DEF handle (_, a) == "handle a"
>DEF handle (_, b) == "handle b"
>DEF handle (_, c) == "handle c"
>DEF handle (o, BAD) == o ++ ": bad option ;-("

Jein. Der erste Parameter von Typ 'denotation' ist genau der von der 
Kommandozeile und wird nur für die Fehlermeldung benutzt ('_' ist eine 
Art Wildcard nach dem Motto "egal was da steht"; hier verhindert es nur 
Warnungen, dass ich bei "handle [a-c]" den ersten Parameter nicht 
nutze). Der zweite Parameter sorgt dafür, dass ich mir die Mappings 
sparen kann.

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

Es ist ja eine funktionale Sprache und deshalb ist die Option 'a' kein 
Character, String oder was auch immer sondern eine Funktion mit dem 
Namen 'a', deren Ergebnis vom Typ 'opts' ist. Und gerade weil der 
Compiler sowas implizit nur für die angegebenen 'Wörter' in der DATA 
Anweisung macht, müsste bei Strings alle möglichen Werte stehen, was 
nicht geht. Genauso bei Zahlen: alle natürlichen Zahlen sind Funktionen, 
die den gleichen Typ 'nat' zurückliefern. Es ist nicht möglich/sinnvoll, 
alle natürlichen Zahlen jetzt mit 'DATA nat == 0 1 2 3 ...' zu 
definieren, etc.

  bye, Rocco
-- 
:wq!



Mehr Informationen über die Mailingliste linux-l