les fonctions;

Question

Je sais que C # reçoit beaucoup d'assistance en programmation parallèle, mais autant que je sache, il n'y a toujours pas de construction pour la vérification des effets secondaires, non?

Je suppose que c'est plus compliqué maintenant que C # est déjà défini. Mais y a-t-il des plans pour y parvenir? Ou bien F # est-il le seul langage .NET à disposer de constructions pour la vérification des effets secondaires?

Answer 1

C# la langue n'est pas le cas, mais .NET le cadre peut être.

Les Contrats de bibliothèque + les outils d'analyse statique introduit dans .NET 4 peut introduire de ces:

Microsoft est à l'aide de [Immuable] et [Pur] à l'intérieur .NET framework 3.5 droite maintenant.

Par exemple, voir [Microsoft.Des contrats.Immuable] et [Microsoft.Des contrats.Pure] à l'intérieur .NET 3.5, System.Core.dll. Malheureusement, ils sont internes. Toutefois, Microsoft.Des contrats.* est surtout né de Spec# recherche, et Spec# a été intégrée dans les Contrats d'Api qui va être de la partie .NET 4.0.

Nous allons voir ce qui vient de. Je n'ai pas vérifié pour voir si la pré-version .NET 4.0 bits contiennent toutes les Api comme [Pur] ou [Immuable] dans les Contrats d'Api. S'ils le font, j'imagine que l'outil d'analyse statique sera le seul à faire respecter la règle, plutôt que de le compilateur.

edit je viens de charger jusqu'Microsoft.Contracts.dll à partir de la dernière pré-version goutte de MS Contrats de Code de cette semaine. Bonne nouvelle: [Pur] et [Mutabilité(Mutabilité.Immuable)] attributs existent dans la bibliothèque, ce qui suggère qu'ils seront dans .NET 4.0. Woohoo!

edit 2 Maintenant que .NET 4 a été libéré, j'ai regardé ces types. [Pur] est toujours là dans le Système.Diagnostics.Les contrats d'espace de noms. Il n'est pas conçue pour un usage général, mais plutôt, pour une utilisation avec le Contrat de l'API de pré - et post-condition de la vérification. Je ne crois pas que c'est le compilateur appliquée. [Mutant] est allé. Il est intéressant de noter, où Microsoft a été l'aide de la Mutabilité et de la Pure attributs .NET 3.5 (interne BigInteger classe System.Core.dll), .NET 4 a déménagé BigInteger dans le Système.Numériques, et a dépouillé la [Pur] et [Mutant] les attributs de désactiver ce type. Bottom line: il s'affiche .NET 4 ne fait rien pour les effets secondaires de vérification.

edit 3 Avec le récemment (fin 2011) aperçu de Microsoft Rosyln compilateur-comme-un-service-outils -- croyait être prévue pour le RTM dans Visual Studio 2015, regardez comme ils ' ll être en mesure de soutenir des trucs comme ça; vous pouvez écrire des extensions pour le compilateur pour vérifier la pureté et de l'immutabilité, et d'émettre des avertissements du compilateur si quelque chose décorées avec ces attributs ne suivez pas les règles. De même, nous sommes à la recherche à quelques années, à l'appui de cette.

Answer 2

Non seulement il n'y a rien pour les effets secondaires de la vérification: - il n'y a rien, même pour vérifier qu'un type est immuable, qui est une petite étape le long de la même route de l'OMI.

Je ne crois pas qu'il y ait quelque chose à venir sur la pipe en C# 4.0 (bien que je pourrais facilement être mal). J'ai vraiment l'espoir que l'immutabilité fait un impact dans C# 5.0, qui, assurément, Eric Lippert a blogué un peu à ce sujet, et les gens de chez MS ont été de penser à propos de parallélisme d'un montant équitable.

Désolé ce n'est pas une image plus encourageante.

Edit: Juda, la réponse est beaucoup plus lumineux... serait-prise en charge du framework être assez bon pour vous? :) (Je ne serais pas surpris si certains aspects du Code des Contrats n'étaient pas prêts pour .NET 4.0, vous l'esprit - si peut-être ils ont gardé la version initiale relativement petite et renforcé plus tard.)

Answer 3

En principe, vérifier si quelque chose est immuable et que le code dépourvue d'effets secondaires, c'est facile. Tous les champs de la classe/structure de données doit être en lecture seule et de leur type doit être un autre objet immuable. Nous avions également besoin d'un moyen pour le marquage d'un délégué comme "pur" (sans effets secondaires), mais ce serait sans doute tous les possibles.

Cependant, le problème est que c'est souvent trop restrictives. En F#, vous souhaitez généralement de l'écriture du code dans un effet secondaire libre et immuable de style, mais il est souvent avantageux d'utiliser certains de mutation à l'échelle locale. Cela ne veut pas casser l'ensemble de la pureté (dans un certain sens) et le rend beaucoup plus facile d'écrire le code. Cependant, en vérifiant automatiquement, cela est difficile (meanin que c'est un intéressant problème théorique..)

Par exemple, il est parfaitement bien de travailler avec des tableaux dans un "pur". Vous pouvez avoir des méthodes comme le Tableau.map qui applique une fonction à tous les éléments et de retour d'un nouveau tableau sans modifier l'original. La fonction mute (nouvellement créé) tableau avant de le retourner, mais le tableau n'est pas muté ailleurs, donc c'est en principe pur, mais difficile à vérifier, et c'est tout à fait utile de programmation de modèle en F#).

Donc, je pense qu'il y a un lot qui pourrait être fait, mais simplement l'interdiction de tous les effets secondaires peuvent ne pas être aussi bon comme il semble être. La bonne chose à propos des contrats est qu'ils pourraient être probablement utilisés dans ce scénario.