11
votes

Les compréhensions de la liste sont-elles une partie majeure de HASKELL?

J'ai regardé diverses ressources Haskell sur le Web avant d'acheter le livre, le monde réel haskell. Être aussi excellent, il ne semble qu'il ne semble pas contenir quoi que ce soit sur les compréhensions de la liste que j'ai vues mentionnées dans les différents sites Web que j'ai examinés. Cela pourrait-il simplement être parce qu'ils sont généralement inutilisés dans Haskell bien écrit pour une raison quelconque, ou est-ce quelque chose de plus complexe? Par exemple, la syntaxe impair peut être éventuellement simplement une fustion d'amalgamation des opérateurs que je n'ai pas encore vus.


1 commentaires

Les compréhensions de la liste sont discutées (brièvement) au chapitre 12 dans le livre en ligne: Book.realworldhakell .org / lecture / barcode-reconnaître.html # x_if 1


5 Réponses :


22
votes

Les compréhensions de liste sont mentionnées brièvement dans Chapitre 12 .

Je me trouve à l'aide de combinaisons de carte et filtrer beaucoup plus souvent que des compréhensions de liste dans Haskell, mais à Python, j'utiliserais plus souvent une compréhension de la liste. Donc, je pense qu'une partie de cela est un style personnel.

Une fois que vous avez compris comment utiliser chaque partie d'une compréhension de la liste, à quoi sert de plus pour vous d'apprendre en ce qui concerne les compréhensions de la liste? Vous avez vos entrées, vos conditions / Guards et vos applications de fonction pour la liste renvoyée. Je ne vois pas vraiment un besoin de garantie pour une grande section sur les compréhensions de la liste dans un livre.


3 commentaires

Je suis d'accord ici, je m'embête rarement avec le sucre de compréhension de la liste.


+1) Les compréhensions de la liste ne sont que du sucre ... bien qu'elles auraient pu être vraiment cool si elles étaient définies pour tout monadplus et non seulement [a] ...;)


@Dario - Demandez-vous et vous recevrez: Hackage.hakell.org/trac/ghc/wiki / Monadcomprewensions



5
votes

Les compréhensions de la liste sont du sucre syntaxique pour la liaison (comme dans la liaison de la monade).

L'autre sucre syntaxique pour cela est la notation. IMHO C'est plus agréable, et le grand plus est que cela fonctionne pour toutes les monades.

Si la liste des compréhensions n'existait pas, je pense qu'il y aurait une chose de moins à apprendre, et rien n'a été perdu (vous pouvez utiliser la notation de do-notation).

L'argument en faveur des compréhensions de la liste est qu'il serait plus clair pour l'utilisateur qu'il s'agit d'une liste. IMHO Une signature de type fonctionnerait mieux pour cela.


0 commentaires

16
votes

Haskell est défini en ayant un petit ensemble de fonctionnalités de langues principales entourées d'un ensemble riche de choix syntaxiques. Les compréhensions de la liste sont un choix, mais ils ne fournissent rien que le sucre monad que RWH dépense l'intégralité de l'intuition de l'intuition pour ne pas fournir également. Il existe de nombreux cas où Haskell fournit deux syntaxes pour la même chose, que le style de programmation orienté sur le boîtier et le combinateur et la liste des compréhensions et le sucre monad.

Les compréhensions de la liste ont été initialement mises en œuvre comme des compréhensions monad, un fait qui a changé dans la "grande révolution de monomorphisme de" 98 "(aka Haskell '98). En fait, la conception de Linq dans les langues .NET dérive fortement de la conception de la plus ancienne compréhension monade. Les compréhensions de la liste pourraient être beaucoup plus générales qu'elles ne le sont, mais ont été délibérément criblés pour les rendre plus faciles à comprendre les messages d'erreur.

Compte tenu d'une quantité finie de papier, vous devez choisir quel matériau à souligner et RWH évite de parler d'eux pour la plupart de sorte que vous ne tombez pas dans le piège de la pensée des listes comme quelque chose de spécial.

Cela dit, il y en a une brève mention dans le chapitre 12. À ce stade, une intuition suffisante a été construite pour les concepts sous-jacents qu'ils ne sont pas vraiment un danger.

À la fin, le nom du livre est réel World Haskell. Il veut vous apprendre de bonnes techniques de programmation du monde réel. Un certain nombre de haskellers (pas tous) Évitez les compréhensions de la liste car la notation ne s'améliore pas bien, et parce que, finalement, vous voudrez peut-être revenir dans un transformateur monad ou quelque chose et finirait de réécrire des bandes entières de code de compréhension dans Monadic style quand même.

[Mise à jour: Maintenant que GHC a retrouvé monad compréhensions cette objection isn ' t assez aussi fort que cela était. Vous pouvez obtenir une nouvelle fonctionnalité intéressante d'entre eux.]


0 commentaires

2
votes

Je vois Trois mentions de la compréhension de la liste en RWH.


0 commentaires

7
votes

La liste des compréhensions apparaissent principalement dans de petits exemples de traitement de la liste, dont beaucoup sont destinés à être ouvertement mathématiques dans la saveur. Lorsque vous commencez à entrer dans les plus grandes applications, telles que les Real World Haskell , la liste des processus est proportionnellement une partie beaucoup plus petite du code. Et comme indiqué, il est souvent aussi pratique d'utiliser mappe , filtre , pli , zip , et ainsi de suite , comme il s'agit d'utiliser une compréhension de la liste.

SO

  • dans le programme de Haskell réel, seule une petite fraction des listes de processus de code.

  • Seule une petite fraction du code HASKELL de traitement de liste est significativement plus agréable lorsqu'il est écrit à l'aide d'une compréhension de la liste.

    La quasi-totalité des compréhensions de la liste J'écris activement pour produire des listes de paires. Je ne suis pas sûr que quelque chose soit lu dans cela, cependant.


0 commentaires