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

[Oliver Bandel]

On Sun, Oct 02, 2005 at 09:31:08PM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> > > Ich meine natürlich das einfache Abtesten von case-Zweigen bei eine
> > > switch(enum_var). Nichts anderes wurde hier beschrieben. Ich kann
> > > mir durchaus vorstellen, dass OCaml da weiter geht -- aber das geht
> > > aus dem Beispiel in keiner Weise hervor.
> > 
> > Oliver hat aber dazu gesagt, dass fehlende Fälle bei Patterns gesucht
> > und gemeldet werden.
> 
> Also nach meinem Verständnis -- und die Beispiele scheinen das zu
> bestägiten -- handelt es sich bei diesem Pattern-Matching um nichts
> anderes, als die funktionale Variante der case-Anweisung (die ich auch
> von anderen funktionalen Sprache kenne, einschließlich SQL und sogar
> VHDL); und das überprüfen fehlender cases scheint hier nichts
> prinzipiell anderes zu sein als beim gcc...


Wie die Beispiele bestätigen, handelt es sich beim Space Shuttle um nichts
weiteres als ein Flugzeug, beim Flugzeug um nichts weiteres als ein
Drachen und dieser ist quasi ein Vogel.
Der fehlender Flügelschlag scheint jedenfalls nichts dagegen
einzuwenden, daß dies alles Vögel sind.

(Die Biologie muß nun also umgeschrieben werden. ;-))


Die Pattern Matches sind wesentlich leistungsfähiger als die
switch/case-Anweisung.
Erstens mal ist die switch-/case-Anweisung rein auf Integers
festgelegt, die Pattern Matches sind flexibler.
Ausserdem kann man die Pattern matches auf komplexe Typen anwenden.


Pattern match auf Liste (Trennen von head/tail und match auf empty-list):

============================================
# let rec sum liste = match liste with
     [] -> 0
   | head::tail -> head + sum tail;;
val sum : int list -> int = <fun>
# sum [1;4;6;7;10];;
- : int = 28
# 
============================================



Matching auf komplexe Muster (softes Beispiel):

====================================================================
let flipdir_transv (direction: direction_t) = match direction with
     | (trans, sag, front) when trans = High -> (Deep, sag, front)
     | (trans, sag, front) when trans = Deep -> (High, sag, front)
     | _ as direction                        -> direction
====================================================================


Sowas ist besonders prima, wenn man Trees programmiert.
Wenn meine Muße mich nicht verläßt, mache ich demnächst
endlich mal meine RTree-Implementation fertig.

Wenn man einen Baum/Tree ausbalancieren soll, dann
ist das ja mit Pattern-Matches schon ein gewusel.
Mit Pointern an sowas heran zu gehen ist quasi
Selbstmord oder Beschäftigungstherapie.

Mit Pattern Matches kann man das inhaltlich nachvollziehen,
direkt aus dem Quelltext.

Mit Pointergeraffel aus C oder vermutl. auch mit
OO-Ansatz wird das alles unübersichtlich und dadurch
Bug-anfällig.



Normaler, sortierender Binärbaum, Insert-Funktion, unbalanciert:

====================================================================
(* sorted insert, unbalanced *)
(* ------------------------- *)
type 'a tree_t = Empty | Tree of ('a tree_t *  'a *  'a tree_t)

let rec insert ins tree = match tree with
         Empty -> Tree(Empty, ins, Empty)
       | Tree(left, found, right) as current -> if ins < found
                                                then
                                                  Tree((insert ins left) ,found, right)
                                                else
                                                  if ins > found
                                                then
                                                  Tree(left, found, (insert ins right))
                                                else current
====================================================================

...naja, das geht ja noch... und ist sicherlich wesentlich besser als das
Pointer-Geraffel! :)


(btw: man könnte das if/then/else-Zeuegs mit nem Pattern match auch noch mal etwas
 schicker lösen :))




[...]
> Wie auch aus meinen anderen Mails hervorgehen sollte, bin ich den
> konsequent funktionalen Sprachen nicht abgeneigt...

Und gegenüber Sprachen, die imperativ + funktional + OO sind?

Gefallen die Dir nicht so?


> Ist das erste
> Konzept, was mir wie ein echter Fortschritt gegenüber dem guten alten C
> scheint, nicht nur problematische dynamische Sprachfeatures,
> schwachsinnige VMs, aufgebohrte Standardbibliotheken, oder syntaktische
> Spielerei.


Naja, Lisp war zwar IMHO nicht purely functional, aber doch eben funktional.

C kam später, oder? ;-)

Ciao,
   Oliver