[Progra] Übung 12 1c

[Eshmael]

Moin Kinners,

Code: Alles auswählen

isPath :: Dir -> Tree -> Bool

Soll gemacht werden. Da wir aber nen Haufen von Dir's reinwerfen wollen ist nur Dir zu erwarten quatsch also:

Code: Alles auswählen

isPath :: [Dir] -> Tree -> Bool

Ein paar Passende Patterns und wenn Haskell das nun schlucken würde wäre diese Aufgabe abgehackt. Aber:

Instance of Eq Tree required for definition of isPath

Also ein Eq a davor und die Typen hinten so allgemein gemacht wie es geht:

Code: Alles auswählen

isPath :: Eq a => [a] -> b -> Bool

um mal zu schaun was passiert...und das ist folgendes:

Inferred type is not general enough
*** Expression : isPath
*** Expected type : Eq a => [a] -> b -> Bool
*** Inferred type : Eq Dir => [Dir] -> Tree -> Bool

Mag mir mal jemand meinen fehler vor Augen führen?
Wo ist der Denkfehler?

[O.D.]

Wie ist denn euer "Tree" definiert?
Aus den Funktsionsvereinbarungen die ich hier sehe würde ich etwas in der Form erwarten:

Code: Alles auswählen

[Edit]zensiert, da es wohl Aufgabe lösen würde[/Edit]

Sehe ich das richtig?
In dem Fall könntest Du Tree von Eq erben lassen. Das kann Haskell implizit. Du kannst aber auch schreiben

Code: Alles auswählen

instance Eq (Tree) where
  Node x r == Node y s = (x == y) && (r == s)

Dein Vorschlag mit

Code: Alles auswählen

isPath :: Eq a => [a] -> b -> Bool

funktioniert (wahrscheinlich) nicht, weil Du in isPath Benutzt, dass der erste Parameter oder der zweite zu der jeweiligen Klasse gehört.

[Eshmael]

Was den Tree angeht...fast:

Das ist die Aufgabenstellung a und wäre also ne Lösung wenn ich meins Poste =)
Aber nur so als tip: Es soll nen Binärbaum sein...da brauchts keine Listen von Tree...da reichen 2 =)

Was du mir da zur Vererbung schreibst ist ja schön... aber ich kann mich nicht erinnern sowas inner VL gesehen zu haben... Zu dem Eq gibts nur den Einzeiler von letztem Übungsblatt.
Vor allem ist Dir ja auch nicht erklärt...

Mag mich mal jemand aufklären was das mit dem Eq auf sich hat?
Ich kann Tree und Dir nciht vergleichen weil sie neue Typkonstruktoren sind, die Haskell nicht kennt?! Soweit richtig?
Und jetzt muss ich die wie bei deriving Show in ne Vergelichsfunktion werfen damit ich sie vergleichen kann ja? Da wird dann aus dem Empty Datenkonstruktor ein vergleichbarer String oder wie was?

Was ich mich nur frage... Wie benutze ich den kram dann?
Kann ich dann nicht

Code: Alles auswählen

isPath (Eq [Dir] =>Dir) ->(Eq Tree => Tree) -> Bool

schrieben?

[O.D.]

Du kannst viel schreiben, aber gültiges Haskell ist das soweit mir bekannt nicht.
Eq ist eine Klasse, wie auch etwa Num oder Ord.
Eine Instanz von Eq muss mindestens == und /= implementieren. Bei Ord sind es ein par mehr, und Num hat noch mehr.
Ich habs glaube ich schonmal irgendwo geschrieben, aber was soll der Geiz;
Wenn Du einen allgemeinen Typ vereinbarst, darf da wirklich alles reingeschrieben werden. Das könnte zum Beispiel ein Zahlenwert, eine Liste aber auch eine Funktion sein. Wirklich alles!
Benutzt Du nun Eigenschaften, muss das Argument auch diese Eigenschaften haben. Sagen wir Du hast:

Code: Alles auswählen

equals :: a -> a -> a
equals x y = x == y

, dann könntest Du das ja mit allem möglichen Aufrufen. Etwa so

Code: Alles auswählen

equals (\x -> x*7) (\x -> x+2)

Funktionen kann Haskell aber nicht vergleichen - sie sind keine Instanzen von Eq.

Soetwas könnte man jedoch definieren. Angenommen Du möchtest Funktionen (vom Typ a->b, wobei a eine Zahl (also aus der Klasse Num) und b vergleichbar (also aus der Klasse Eq) sein soll) vergleichen können müsstest Du Dir nur ausdenken wie Du das bewerkstelligen kannst. Beispielsweise könnte man sagen, dass sie gleich sein sollen, wenn sie an der Nullstelle gleich sind;

Code: Alles auswählen

instance (Num a, Eq b) => Eq (a->b) where
  f == g = (f 0) == (g 0)

Das ist natürlich überhaupt nicht kompatibel mit der Anschauung, aber man kann sich da ja auch gescheitere Reduktionen einfallen lassen.
Nun kannst Du aber tatsächlich schreiben
Main> (\x -> 4*x) == (\x -> 2**x -1)
und er gibt Dir True zurück.

[O.D.]

P.S.: Ein Blick ins Wiki könnte diesbetreffend auch nicht schaden

[davidM]

Mag mich mal jemand aufklären was das mit dem Eq auf sich hat?
Ich kann Tree und Dir nciht vergleichen weil sie neue Typkonstruktoren sind, die Haskell nicht kennt?! Soweit richtig?

Mal eine ganz andere Frage: Warum willst du denn den Baum mit der Richtung vergleichen? Für isPath ist es doch nur wichtig, ob Dir nun L oder R ist. Ob links oder rechts von dem aktuellen Knoten dann wirklich auch noch ein Knoten ist, kann man ja mit Pattern abfangen.

Ausgehend von meiner Überlegung hab ich den Typ so definiert:

Code: Alles auswählen

isPath :: Eq Dir => [Dir] -> Tree a -> Bool

theoretisch sollte man ja mit einer einfachen if-bedingung testen können, ob der übergebene Dir == L oder R ist.
dies scheint Hugs aber garnicht zu gefallen, und er beschwert sich folgendermaßen:

Illegal Haskell 98 class constraint in type declaration

google hilft in dem fall auch nicht wirklich weiter. auf den seiten mit typischen fehlern von haskell taucht dieser nämlich nicht auf.

[O.D.]

Code: Alles auswählen

... :: Eq Dir => ...

is ja auch völliger Nonsens. Dir ist entweder schon in Eq oder halt nicht, und außerdem spezifiziert man auf diese Weise nur Typvariablen aber keine Typen selbst.

[Eshmael]

Mag mich mal jemand aufklären was das mit dem Eq auf sich hat?
Ich kann Tree und Dir nciht vergleichen weil sie neue Typkonstruktoren sind, die Haskell nicht kennt?! Soweit richtig?

Mal eine ganz andere Frage: Warum willst du denn den Baum mit der Richtung vergleichen? Für isPath ist es doch nur wichtig, ob Dir nun L oder R ist. Ob links oder rechts von dem aktuellen Knoten dann wirklich auch noch ein Knoten ist, kann man ja mit Pattern abfangen.

Ausgehend von meiner Überlegung hab ich den Typ so definiert:

Code: Alles auswählen

isPath :: Eq Dir => [Dir] -> Tree a -> Bool

theoretisch sollte man ja mit einer einfachen if-bedingung testen können, ob der übergebene Dir == L oder R ist.
dies scheint Hugs aber garnicht zu gefallen, und er beschwert sich folgendermaßen:

Illegal Haskell 98 class constraint in type declaration

google hilft in dem fall auch nicht wirklich weiter. auf den seiten mit typischen fehlern von haskell taucht dieser nämlich nicht auf.

Ja aus diesem GEdankengang ist letztlich dieser Thread hier entstanden. =)

Aber ich wollte ja nix verraten... =)

[davidM]

Code: Alles auswählen

... :: Eq Dir => ...

is ja auch völliger Nonsens. Dir ist entweder schon in Eq oder halt nicht, und außerdem spezifiziert man auf diese Weise nur Typvariablen aber keine Typen selbst.

Das erklärt zumindest, warum es damit nicht ging. Wieder was gelernt.

Eshmael:
Falls du noch nicht selber drauf gekommen bist: das Ganze funktioniert, wenn man wie in den anderen Übungen den Datentyp einfach schon beim pattern-matching abfragt (na hoffentlich sage ich damit nicht zu viel .)

[Eshmael]

Ich habe per PN mal meine ganze Lösung versandt.
Ich verstehe nämlich nicht warum es nicht funktioniert.

So wie ichs programmiert habe brauchte ich letzte Woche kein Eq... und es funktionierte.. aber da passten die Typen natürlich zusammen...

[NeX]

Eshmael:
Falls du noch nicht selber drauf gekommen bist: das Ganze funktioniert, wenn man wie in den anderen Übungen den Datentyp einfach schon beim pattern-matching abfragt (na hoffentlich sage ich damit nicht zu viel .)

ich hatte haargenau das selbe Problem....und dieser tipp bringt einen da doch deutlich weiter ...hatte ich vorher überhaupt nicht drüber nachgedacht...

[proxylittle]

mal am Rande gefragt:

Beispiel -> [L,R,R,R,L,R,L] Ablauf
Angenommen Path stimmt...

gibt es eine Möglichkeit dann mit sowas wie (x : xs) zu arbeiten? Weil der spuckt mir dauernd Typdeklarationsfehler. [Dir] =/ Dir ... und wenn ich das dann korrigiere sagt der Dir =/ [a]... also watn nu?

EDIT: sry erledigt! -> (x;xs) geschrieben... lappi größe suckt
problem mit Typ Eq Dir herrscht bei mir auch... ich weiß auch keinen Rat. Man sollte das doch lösen können auch mit dem gegebenen Programmierwissen, anstatt neue Instancen zu erstellen.

[Coolcat]

problem mit Typ Eq Dir herrscht bei mir auch... ich weiß auch keinen Rat.

Wie oben schon geschrieben wurde: Einfach weglassen! Hier wird kein Eq benötigt.

[NeX]

problem mit Typ Eq Dir herrscht bei mir auch... ich weiß auch keinen Rat.

Wie oben schon geschrieben wurde: Einfach weglassen! Hier wird kein Eq benötigt.

wie gesagt....PATTERN MATCHING!

[proxylittle]

so und was mach ich nun wenn er mir in aufgabenteil e) die ganze zeit sagt, egal wieviele pattern ich mache das er eine instanz num (int->int->int) braucht??? Irgendwie wird mir haskell immer unsympatischer. Bitte klärt mich auf was ich da machen muss... denn mein Code ist zu 100% richtig!!! und muss einfach funktionieren!