funktionale Sprachen (Re: [linux-l] RS-232 oder USB lesen mit (Schauder...) Java Os-unabhaengig)

Oliver Bandel oliver at first.in-berlin.de
Di Sep 20 14:21:56 CEST 2005


On Tue, Sep 20, 2005 at 11:14:16AM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2005-09-20 01:31:26 +0200, Oliver Bandel <oliver at first.in-berlin.de> wrote:
> > On Mon, Sep 19, 2005 at 05:03:32PM +0200, Jan-Benedict Glaw wrote:
> > > On Mon, 2005-09-19 11:46:21 +0200, Oliver Bandel <oliver at first.in-berlin.de> wrote:
> > > > > weil durch die Sprache Randbedingungen
> > > > > meist nicht so gut beschrieben werden können
> > > > 
> > > > Was meinst Du denn damit?
> > > > Randbedingungen?
> > > 
> > > Die Lösung eines Problemes wird in funktionalen Sprachen normalerweise
> > > sehr allgemein beschrieben. Der Compiler weiß aber ggf. nicht, daß von
> > > allen möglichen Eingabe-Werten vielleicht nur ein sehr simpler,
> > > übersichtlicher Sonderfall vorkommen kann. Ein C-Programmieren würde
> > > das berücksichtigen.
> > 
> > Verstehe ich noch immer nicht, was Du meinst.
> > 
> > Wie wäre es mit einem Beispiel?
> 
> Aufgabe: Zahlen sortieren.
> Nebenwissen: bei einer gewissen Art, es zu implementieren, fallen
> immer nur exakt zwei Zahlen an.
> 
> Funktionale Implementierung: Siehe Beispiel von das GNU Haskell Seite

GNU Haskell? Das gibts auch schon?



> 
> Minimalistische Implementierung: Man betrachte exakt die beiden Werte
> und drehe sie ggf um.
> 
> Die Compiler funktionaler Sprachen sind einfach noch nicht so weit,
> vorauszuahnen, daß man bei vielleicht nicht eine allgemeingültige
> Lösung zu den Anforderungen, die die Programmierer beschrieben hat,
> sondern eine vereinfachte Version schon reicht.

Verstehe das zwar immer noch nicht, was Du mit allgemeingültig usw.
meinst, aber das qsort-Beispiel ist sicherlich nicht tail-recursive.
Und deswegen bläht sich der Speicher auf.

Man müsste das Programm umformulieren, dann gehts auch flotter und
mit weniger Speicherfresserei.


> 
> So kommen dann auch die netten memory footprints zustande, die z.B.
> Darcs so verursacht.

Darcs?

Wer nicht tail-recursive programmiert hat meist deswegen
ausgeblähten Speicherbedarf (jedenfalls, wenn es sehr
tiefe Rekursion ist).


> 
> > > In C suchst Du Dir
> > > zuerst einen passenden Datentypen und schiebst (zum Speichersparen)
> > > lieber die Daten ein paar mal hin- und her.
> > 
> > Müsste ich mir nochmal den Haskell-Code anschauen.
> > Oder hast Du den gerade mal da?
> 
> google://"haskell example qsort"/AufGutGlück

Ja, gefunden.

Ciao,
   Oliver




Mehr Informationen über die Mailingliste linux-l