Je regarde dans Linq et que le langage de requête apparaît (au moins à la surface) pour ne rien être plus qu'une implémentation de la carte et / ou des compréhensions de la carte, comme le conçu dans HASKELLL et d'autres langues FP (en particulier la généralisation de la carte. 'et' pour 'à Scala). Est-ce correct? Y a-t-il plus à la syntaxe que cela? Du ton bout à bout de souffle du livre, je lis ("Essential Linq"), il semblerait qu'il y ait quelque chose de nouveau ou d'innovation ici.
Il y a tout le dos, pipeline, arbres et types d'expression de premier ordre, etc. pour implémenter LINQ, mais ma question concerne la langue de la requête elle-même.
acclamations
JOE
5 Réponses :
En plus de lire un livre à ce sujet, avez-vous déjà utilisé Linq? J'ai trouvé que c'était une énorme orthographe dans mon travail quotidien de programmation. Pour moi, c'est la prochaine étape d'abstraction, qui peut être utilisée pour combiner différentes données de données telles que XML ou SQL et travailler avec eux dans la même "langue".
En outre, je recommande ce Entretien avec Anders Hejlsberg sur la programmation fonctionnelle et Linq.
Merci pour la réponse et le lien, je le lirai. Oui, je l'ai utilisé un peu (et je le trouve très utile), mais j'ai utilisé de la même manière que j'utilise de la carte et à Scala. J'ai posé la question à cause des similitudes et je me demandais à quel point ils vont profondément.
L'essoufflement est probablement destiné à toutes ces choses "évidentes", dont certaines (comme des arbres d'expression) sont vraiment excellentes. La langue est juste un moyen d'accès; Êtes-vous excité par rapport au mot-clé ou sur la fonctionnalité qu'il expose?
Je ne voulais pas dire que les «choses» évidentes »étaient évidentes, simplement que c'était reconnu mais pas le centre de ma question! Peut-être que je l'ai mal formulé un peu mal.
D'autres s'il vous plaît lire le commentaire de Ben M à la lumière de mon édition à la question.
Parlé fonctionnellement, Linq n'est rien d'autre qu'une simplification syntaxique d'expression de monads. Linq aux objets (liste-compréhensions - même ceci serait déjà extrêmement utile), que vous avez parlé, est juste ce n'est rien d'autre que p> in haskell. p> Le béton la chose qui est faite dépend des em> fournisseurs em> (méthodes d'extension) définis par l'utilisateur, dont En fournissant un, vous pouvez créer une nouvelle sémantique Linq-Sémantics pour vos types. P> Exemple: Compte tenu d'une option code> type code> pour des calculs pouvant échouer ( valeurs nullables), on pourrait définir un fournisseur de Linq pour interroger sur eux. p> Cela nous permettrait maintenant d'écrire ce code: P> linq.enumerable code> est une seule implication impliquant ienumerable code> s . P> monad {
let! x = expr1
let! y = expr2
return x + y
}
Merci pour l'info. Je vais regarder dans ces prospects.
Vraiment, vraiment bon résumé avec un exemple agréable et facile à saisir. +1
En continuant sur le lien Raytracer, voici le même raytracer mis en œuvre entièrement dans une seule relève LINQ: Tirania.org/blog/archive/2007/nov-16.html
Linq a été inspiré par haskelldb, comme Erik Meijer a beaucoup énoncé, par exemple dans Confessions d'un vendeur de langue de programmation d'occasion (obtenir Les masses accrochées sur Haskell) , donc ce n'est pas en soi un nouveau concept. En utilisant la même langue pour interroger différentes sources, c'est dans une certaine mesure novatrice, bien que le fait que le modèle nié couvre XML, les objets et les bases de données relationnelles a été montré par des chercheurs avant. Pour moi, ce qui est extrêmement cool, c'est qu'elle a été intégrée à une langue populaire, à usage général et principalement orientée objet, qui n'a pas été faite auparavant.
Scala IMHO a les capacités d'intégrer quelque chose de similaire. Jusqu'à présent, pour Scala, nous avons Scalaquery Stefan Zeiger et Daniel Spiewak 'S scalaql , qui suivent les traces de linq.
Merci pour les liens, ils ont l'air très intéressant.
Le noyau de Linq, la syntaxe de la requête, n'est pas une portée énorme. C'est simplement des traductions très littérales , des méthodes et des lambdas - donc est littéralement : Il ne connaît rien sur les méthodes d'extension (bien qu'ils soient les plus courants (mais pas seulement ) implémentation), et rien sur Peut-être la partie la plus impressionnante de LINQ est l'arborescence expression etc. Le nombre des mots-clés (et donc le nombre d'implémentations de méthodes requises) n'est pas énorme. Jon une fois tenté de les implémenter toutes en 1 heure (dans une présentation en direct). Il n'a pas fait trop mal ;-p
Une perspective très utile. Merci de clarifier.