Idee: Sprachintegration von Tuple

29/12/2009 - 14:07 von Immo Landwerth | Report spam
Servus,

erst einmal frohe Weihnachten nachtràglich an alle!

Miguel Icaza, der Gründer des Mono Projekts, hat vorgeschlagen C# um
eine spezielle Syntax für Tupel zu bereichern:

http://tirania.org/blog/archive/2009/Dec-23.html

Nachdem .NET 4.0 ja nun etliche Tupel Datentypen enthàlt (mangels
variadic generics sind es tatsàchlich mehrere) fànde ich die Idee in der
Tat nicht schlecht. Zumal die Syntax zum verwenden der Tupels IMHO nicht
besonders intuitiv ist:

var t = new Tuple<string, int>("Hello", 4);

Da generische Typinferenz bei Konstruktoren nicht unterstütz wird,
wurden Factory Methoden hinzugefügt, damit das ganze nicht zu
geschwàtzig wird:

var t = Tuple.Create("Hello", 4);

Allerdings wirkt das ganze immer noch ein wenig zu schwerfàllig. Schöner
wàre freilich:

var t = new Tuple("Hello", 4);

Oder eine Variante von:

var t = ("Hello", 4);
var t = {"Hello", 4};
var t = <"Hello", 4>;
var t = ["Hello", 4];

(was immer die Grammtik noch zulàsst).

Miguels Ideen sind da ziemlich interessant:

Tuple creation syntax:
ParseUri ()
{
...
return (user, password, host, port, path);
}

Initializing multiple variables from a tuple:

(user, password, host, port, path) = ParseUri (url);

Obwohl ich im allgemeinen sehr vorsichtig mit Vorschlàgen zu
Spracherweiterung bin, finde ich die grundlegende Richtung sehr gelungen.

1. Tupel sind eine sehr allgemeine Datenstrukutur. Das .NET Framework
hat sie an einigen Stellen selbst neu erfunden, z.B. KeyValuePair<K,V>
oder auch out Parameter wie bei TryParse().

2. Gerade in der funktionalen Welt spielen Tupel eine sehr große Rolle.
C# hat bereits so viele funktionale Spracherweiterungen bekommen, sodass
klar ist, dass C# in dieser Welt mitspielen will und kann.

3. Linq und anonymous types sind großartig, allerdings kann man diese
nicht ohne weiteres an Methoden übergeben. Das wàre mitunter allerdings
praktisch. Natürlich kann man sich einen eigenen Typen basteln, ein
Tupel würde aber in vielen Fàllen ausreichend und würde sogar
interessante Standardeigenschaften liefern (Equals, GetHashCode, etc).

Dagegen spricht natürlich die Komplexitàt und Orthogonalitàt der
Sprache. Irgendjemand sagte mir einmal: "Features sind leicht. Das
Problem ist das Zusammenspiel zwischen Features".

Und das sehe ich bei Tupels ganz genauso. Miguel schlàgt z.B. auch vor
Tupels, in using Statements verwenden zu können:

using (var (image, audio, badge) = iphoneApp.GetNotifications ()){
// use IDisposable image
// use IDisposable audio
// use trivial int badge
}

Miguel hat bereits ein paar Patches hochgeladen, mit deren Hilfe man
Tupel Support in seinem Mono C# Compiler aktivieren kann. Ich habe
allerdings ein wenig Angst vor so einem Schnellschuss. [1]

Ich finde Linq z.B. recht gelungen, die Sprachintegration wirkt
allerdings bestenfalls unvollstàndig. Viele Dinge, kann man in Linq nur
durch Methodenaufrufe und Lambdas ausdrücken. Im Endergebnis ergeben
sich dann oft Abfragen die ein buntes Feuerwerk aus Schlüsselnwörtern
und Linq Methodenaufrufen sind -- wobei die leidliche Frage der
Formatierung noch das kleinste Problem darstellt...

Desweiteren werden durch die Syntax nicht vollstàndig neue Szenarien
ermöglicht. Alles, was man mit der vorgeschlagenen Syntax erreichen
kann, kann man auch ohne sie erreichen -- den Datentypen Tuple<> gibt es
ja auch ohne diese Syntax.

Soviel zu meiner Meinung: was haltet ihr davon, eine spezielle Syntax
für Tupel hinzuzufügen?

[1] Damit möchte ich freilich nicht andeuten, Miguel würde damit einen
Schnellschuss liefern. Soweit wie ich es verstanden habe, möchte Miguel
mit dem Patch in erster Linie Feedback von anderen Entwicklern bekommen.

Immo Landwerth
 

Lesen sie die antworten

#1 Nicolas Pavlidis
29/12/2009 - 19:53 | Warnen spam
Hi!

Immo Landwerth wrote:
erst einmal frohe Weihnachten nachtràglich an alle!



Ebenso und rutsch gut :-).

Miguel Icaza, der Gründer des Mono Projekts, hat vorgeschlagen C# um
eine spezielle Syntax für Tupel zu bereichern:

http://tirania.org/blog/archive/2009/Dec-23.html

Nachdem .NET 4.0 ja nun etliche Tupel Datentypen enthàlt (mangels
variadic generics sind es tatsàchlich mehrere) fànde ich die Idee in der
Tat nicht schlecht. Zumal die Syntax zum verwenden der Tupels IMHO nicht
besonders intuitiv ist:

var t = new Tuple<string, int>("Hello", 4);

Da generische Typinferenz bei Konstruktoren nicht unterstütz wird,
wurden Factory Methoden hinzugefügt, damit das ganze nicht zu
geschwàtzig wird:

var t = Tuple.Create("Hello", 4);



Bin grad überracht das das geht, oder ist das Creat einfach mit
verschiedenen Anzahlen von Typparametern überladen?

Allerdings wirkt das ganze immer noch ein wenig zu schwerfàllig. Schöner
wàre freilich:

var t = new Tuple("Hello", 4);



Jep das wàr das schönste.

Oder eine Variante von:

var t = ("Hello", 4);
var t = {"Hello", 4};
var t = <"Hello", 4>;
var t = ["Hello", 4];



Für meine Begriffe ließt und schreibt sich das alles seltsam, aber ich
musss zugeben ich war nie ein großer Freund von Syntaxen funktionaler
Programmiersprachen :-).

Miguels Ideen sind da ziemlich interessant:

Tuple creation syntax:
ParseUri ()
{
...
return (user, password, host, port, path);
}

Initializing multiple variables from a tuple:

(user, password, host, port, path) = ParseUri (url);



Das ist ein Punkt der mich mit schaudern erfüllt diese Multiple -
returntypes.

Mir ist klar, dass man nicht für alles einen Typ basteln will, aber für
meine Begriffe ist es immer noch schöner wenn bei einer Methode steht:

Tuple<String, String, String, uint, String> ParseUri(...), und ich das
draußen auch entsprechend zuweise, keine Ahnung vielleicht bin ich zu
altmodisch. Muss zugeben, dass ich auch Lambdas immer ein wenig kritisch
gesehen habe, oder das was mir mit denen passiert ist passiert nur mir :-).

Wobei mir hier auch nicht ganz klar ist wie die Zuweisung der Werte
funktionieren soll, muss aber zugeben dass ich mir die Tupels die in
.NEt 4.0 kommen noch nicht im Detail angeschaut habe.

Obwohl ich im allgemeinen sehr vorsichtig mit Vorschlàgen zu
Spracherweiterung bin, finde ich die grundlegende Richtung sehr gelungen.

1. Tupel sind eine sehr allgemeine Datenstrukutur. Das .NET Framework
hat sie an einigen Stellen selbst neu erfunden, z.B. KeyValuePair<K,V>
oder auch out Parameter wie bei TryParse().



Stimmt, da gebe ich Dir Recht, zu mal das mit dem out - Parameter auch
recht umstàndlich zu bedienen ist und das Problem dass sie vorher wohl
hatte (auf was initialisiere ich das Zeug wenns nicht zu parsen ist)
seit nullable value types auch gelöst ist.

Dennoch würde ich von multiplen Returnvalues dennoch Abstand nehmen :-).


2. Gerade in der funktionalen Welt spielen Tupel eine sehr große Rolle.
C# hat bereits so viele funktionale Spracherweiterungen bekommen, sodass
klar ist, dass C# in dieser Welt mitspielen will und kann.



Um richtig funktional zu sein gibts jetzt eh F#, sollen die sich quàlen
mit ihren Listen usw. Dort macht es ja auch Sinn, da in der funktionalen
Welt sowieso alles eine Liste ist, die Welt wohl selber auch :-).


3. Linq und anonymous types sind großartig, allerdings kann man diese
nicht ohne weiteres an Methoden übergeben. Das wàre mitunter allerdings
praktisch. Natürlich kann man sich einen eigenen Typen basteln, ein
Tupel würde aber in vielen Fàllen ausreichend und würde sogar
interessante Standardeigenschaften liefern (Equals, GetHashCode, etc).



Aber bitte nich tannonym, ich mein hier und da wirklich praktisch, aber
mir liegt halt auch die Codequalitàt am Herzen, und diese vielen
annonymen Sachen erinnern mich einfach zu sehr an Java und seine
ActionListeners in Swing :-).

Dagegen spricht natürlich die Komplexitàt und Orthogonalitàt der
Sprache. Irgendjemand sagte mir einmal: "Features sind leicht. Das
Problem ist das Zusammenspiel zwischen Features".

Und das sehe ich bei Tupels ganz genauso. Miguel schlàgt z.B. auch vor
Tupels, in using Statements verwenden zu können:

using (var (image, audio, badge) = iphoneApp.GetNotifications ()){
// use IDisposable image
// use IDisposable audio
// use trivial int badge
}



Was eine logische Konsiquenz wàre.

Miguel hat bereits ein paar Patches hochgeladen, mit deren Hilfe man
Tupel Support in seinem Mono C# Compiler aktivieren kann. Ich habe
allerdings ein wenig Angst vor so einem Schnellschuss. [1]


Desweiteren werden durch die Syntax nicht vollstàndig neue Szenarien
ermöglicht. Alles, was man mit der vorgeschlagenen Syntax erreichen
kann, kann man auch ohne sie erreichen -- den Datentypen Tuple<> gibt es
ja auch ohne diese Syntax.



Natürlich, wobei ich hier doch ein Freund von sytactic shugar bin, weil
z.B ein foreach bràuchte man auch net :-).

Soviel zu meiner Meinung: was haltet ihr davon, eine spezielle Syntax
für Tupel hinzuzufügen?



wie bereits erwàhnt, gefallt mir die Version mit den mehrfachen
Returnwerten irgendwie nicht, vielleicht zu viele böse Erfahrungen mit
Matlab. Ansich wàre es für mich schon schön, wenn man die generischen
Typargumente nicht explizit angeben müsste.

Die Syntax an sich würde sich mE nach gut in C# einfügen.

Wobei man sich mit (wie mit allem funktionalem IMHO) mit solch einer
Syntax Dinge eintritt die Code einfach schwerer lesbar machen, ich
erinnere mich hier nur grad daran was Alexandrescu uns und den Templates
von C++ angetan hat :-).

LG
Nicolas

| Nicolas Pavlidis | Elvis Presly: |
| Student of SE & KM | "Into the goto" |
| http://pavnics-thoughts.blogspot.com |
| University of Technology, Graz|

Ähnliche fragen