Les API Edison et les modules de base sont la mise en œuvre Haskell de Purely Functional Data StructuresY at-il un avantage à porter l'API Haskell Edison et Core à F #?
Faites le # F et structures de données natives .Net couvrir les cas d'utilisation de l'API Edison et Core suffisamment? Y aura-t-il un avantage à essayer de porter les modules API et CORE Haskell sur F #?
Je n'ai pas lu the paper on edison, mais si elle est rien de plus que la mise en œuvre Haskell des structures de données purement fonctionnel, ne pas faire plus de sens au port le code SML qui est dans le livre/thèse? Cela devrait être plus facile que le portage du code Haskell, qui doit être annoté pour la rigueur, alors que F # devra être annoté pour la paresse.
Le langage utilisé par le livre est SML avec des extensions de syntaxe pour l'évaluation paresseuse. F # fournit la moitié de ces extensions en mode natif:
> let x = lazy 12;;
val x : Lazy<int> = <unevaluated>
> match x with
| Lazy(n) -> n;;
val it : int = 12
> x;;
val it : Lazy<int> = 12
Pour convertir la notation fun lazy, changer de ce livre:
fun lazy plus ($m, $n) = $m + n
à ceci:
let plus (m',n') = lazy (
match (m',n') with
| (Lazy(m), Lazy(n)) -> (lazy (m + n)).Force())
(Voir page 33 dans le livre) . Les différences entre SML et F # sont une syntaxe mineure, donc la traduction devrait être facile. Quant à savoir si cela en vaut la peine, la plupart des structures de données du livre d'Okasaki sont très spécialisées, il est donc peu probable qu'elles existent déjà dans .NET, même si Set et Map immuables de F #. Cela vaudrait la peine pour les personnes qui ont besoin de ces structures de données.
Je n'ai pas suivi le lien, même si j'ai au moins une familiarty minuscule avec le travail ou Okasaki. Donc, toute cette réponse est follement spéculative (je suis peut-être hors de mes hypothèses sur ce qui est dans l'API Edison). Je pense qu'il y a un «avantage» dans le sens où les gens aiment «implémenter des implémentations de structures de données FP communes» dans de «nouvelles langues» pour aider à apprendre de nouvelles langues. En ce qui concerne l'utilisation en pratique (plutôt que la pédagogie), je pense que certains d'entre eux sont utiles, bien qu'il existe des API F # et .Net qui peuvent être aussi utiles ou plus utiles dans de nombreux scénarios. Les principaux «groupes» de fonctionnalités chevauchantes que je suppose sont les collections immuables F # (Set et Map), ainsi que le .Net 4.0 concurrent collections (comme ConcurrentQueue).
Bien sûr, vous trouverez également des extraits sur le Web, comme immutable queue de Jomo.
Revisiter ce mois question plus tard, je constate que
quelqu'un http://lepensemoi.free.fr/index.php/tag/purely-functional-data-structures
a mis en place un bon nombre d'entre eux sur ce blog.
Vous voudrez peut-être aller plus en détail sur les avantages de ces structures de données, car la lecture d'un papier de 168 pages n'est pas quelque chose que beaucoup voudront faire pour y répondre. Quels sont les avantages de ces structures de données dans Haskell et quelles structures de données ne sont pas en F # qu'il pourrait être utile d'ajouter? –
Pour ce que cela vaut, j'ai essayé de traduire certaines des structures de données d'Okasaki en F # (http://en.wikibooks.org/wiki/F_Sharp_Programming/Advanced_Data_Structures). Les plus intéressants sont les implémentations en tas et en arbre rouge-noir. C'est un wiki, donc si vous voyez quelque chose de mal ou juste bizarre, n'hésitez pas à le réparer :) – Juliet