Haskell

otze

Als ob das ein Argument wäre. Die Haskelleute behaupte auch, dass sie perfektes OOP in Haskell machen können. Und nu?

Bashar

Das kann man nicht vergleichen. Das Block-Konzept in Smalltalk ist ja nicht ein objektorientiertes, mit dem man funktionale Programmierung simuliert. Das *ist* funktional.

Zeus

Lasst den Kreuzzug beginnen! - Männer an die Waffen! - Vollstreck die Ungläubigen mit aller Macht!

freakC++

Lieber Seitenbesucher, schrieb:

Mich keiner. Den freakC++ wahrscheinlich sein Lehrer/Prof.

Nö! In der Schule läuft gerade nichts, weshalb ich mich zu einem Vorsemster an der Goethe Uni Frankfurt eingeschrieben. Dort lerne ich das. Ich finds interessant. Nach dem Vorsemester habe ich damit nichts mehr am Hut

Wir hatten heute eine rekursive Funktion ohne Abbruchbedingung und ich hatte plötzlich "Stack overflow" im Kopf. Mich hat es schon sehr gewundert, dass das Haskell wenig krazt. Das Programm terminiert zwar nicht, aber es stürzt auch nicht ab! Das kann C++ nicht.

SideWinder

Muss ja nicht 1:1 so in Maschinencode umgesetzt werden wie man es hinschreibt. Ich glaube du hängst noch zu sehr am Konzept Programmiersprache als etwas absolut Einordbares. Viel eher gilt es aber die richtige Sprache, zum richtigen Zeitpunkt, für den richtigen Zweck zu wählen.

Es herrscht inzwischen doch ein gewisser Konsens (und das sieht man auch an dem erhöhten Aufkommen der eigenen Techniken in der jeweils anderen Ecke), dass Konzepte von funktionalen als auch imperativen Sprachen nötig sind - wiederum, je nach Einsatzzweck (inwiefern hier überhaupt funktional mit objektorientiert verglichen wird ist nicht zu verstehen, können doch auch funktionale Sprachen objektorientiert sein, oder?).

MfG SideWinder

Es herrscht inzwischen doch ein gewisser Konsens (und das sieht man auch an dem erhöhten Aufkommen der eigenen Techniken in der jeweils anderen Ecke), dass Konzepte von funktionalen als auch imperativen Sprachen nötig sind

Kleine Ergänzung: Man kann auch in Haskell wunderbar imperativ programmieren.

Nach dem Vorsemester habe ich damit nichts mehr am Hut

Na, vielleicht möchtest du ja selber weitermachen. Wie schonmal geschrieben, empfehle ich dir wärmstens das Buch Programming in Haskell, es ist wirklich sein Geld wert.

knivil

Das kann C++ nicht.

Doch, while (true) {} !

freakC++

was ist daran rekursiv?

SideWinder

freakC++ schrieb:

was ist daran rekursiv?

Ich möchte fast wetten, dass der Haskell-Code in nicht-rekursiven Maschinencode übersetzt wurde. Verwendet ihr ghc oder hugs?

MfG SideWinder

SideWinder schrieb:

freakC++ schrieb:

was ist daran rekursiv?

Ich möchte fast wetten, dass der Haskell-Code in nicht-rekursiven Maschinencode übersetzt wurde. Verwendet ihr ghc oder hugs?

MfG SideWinder

Wieso fast? Wenn tatsächlich rekursiv immer wieder ein Call auftauchen würde, dann gäbe es zu 100% einen Überlauf. Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

otze

Stak schrieb:

Wieso fast? Wenn tatsächlich rekursiv immer wieder ein Call auftauchen würde, dann gäbe es zu 100% einen Überlauf. Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

klar, tail recursion kannste primitiv in ne Schleife umfrickeln. Und sobald du ne Schleife hast, kannst du analysieren ob du wirklich jedes mal Dinge auf den Stack/Heap pushen musst, oder ob du die alten Variablen nicht verwenden kannst.

volkard

freakC++ schrieb:

Wir hatten heute eine rekursive Funktion ohne Abbruchbedingung und ich hatte plötzlich "Stack overflow" im Kopf. Mich hat es schon sehr gewundert, dass das Haskell wenig krazt. Das Programm terminiert zwar nicht, aber es stürzt auch nicht ab! Das kann C++ nicht.

Das ist einfach falsch.
Ich habe im Kopf, daß C++-Compiler das seit Jahren können.
Ich teste das doch mal.

#include <iostream>

void test(){
   std::cout<<"hallo\n";
   test();
}

int main(){
   test();
}

Und der Compiler macht daraus

.L5:
	movl	$6, %edx
	movl	$.LC0, %esi
	movl	$_ZSt4cout, %edi
	call	_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
	jmp	.L5   # <-- hier, unbedingte Schleife

Oder mal etwas, was nicht ganz so trivial ist:

#include <iostream>

int gcd(int a,int b){
   if(b!=0)
      return gcd(b,a%b);
   else
      return a;
}

int main(){
   std::cout<<gcd(1024,768)<<'\n';
}

wird zu

_Z3gcdii:
.LFB1003:
	.cfi_startproc
	testl	%esi, %esi
	movl	%edi, %eax
	jne	.L5
	jmp	.L8
	.p2align 4,,7
	.p2align 3
.L4:
	movl	%esi, %eax
	movl	%edx, %esi
.L5:
	cltd
	idivl	%esi
	testl	%edx, %edx
	jne	.L4        # <-- Bedinter Sprung nach .L4, eine Schleife!
	movl	%esi, %eax
	ret
.L8:
	rep
	ret
	.cfi_endproc

knivil

Stak schrieb:

Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

Das nicht, es kann aber das Programm verwandeln. Stichwort: Endrekursion. Das kann gcc im uebrigen auch und ich habe es auch hier im Forum oft genug mit Beispielen belegt.

klar, tail recursion kannste primitiv in ne Schleife umfrickeln.

Das hat nichts mit frickeln zu tun und man benoetigt auch keine Schleifen. Es ist ein bestens verstandenes Konzept in Theorie und Praxis. Waehrend volkards Beispiel eine tatsaechliche endrekursive Funktion ist, kann der Kompiler auch in bestimmten Faellen aus einer rekursiven in eine endrekursive verwandeln. Das Beispiel der Fakultaetsfunktion findest hier auch im Forum irgendwo.

maximAL

Stak schrieb:

Wieso fast? Wenn tatsächlich rekursiv immer wieder ein Call auftauchen würde, dann gäbe es zu 100% einen Überlauf. Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

Stichwort: Tail-Rekursion.

edit: nächste Seite übersehen

knivil

Ach uebrigens: Ich mag den Bergiff Tail-Rekursion nicht!

Wenn man Haskel mal für was anderes als Rechnen nimmt, ist es garnicht mehr toll.

otze

knivil schrieb:

klar, tail recursion kannste primitiv in ne Schleife umfrickeln.

Das hat nichts mit frickeln zu tun und man benoetigt auch keine Schleifen. Es ist ein bestens verstandenes Konzept in Theorie und Praxis.

Sogar Volkard schreibt in seinem Kommentar, dass der Compiler daraus ne unbedingte Schleife macht. Keine Ahnung was du mal wieder hast

Zeus

knivil

Du kannst schon vorher analysieren, was alles auf den Heap landet, ohne eine Schleife draus zu machen.

mit welchem switch wandelt g++ tail-recursions nochmal in loops? Bei meinen Tests war kurz vor Tiefe 262000 Schicht im Schacht.