Exemple: lorsque vous utilisez l'API Windows pour obtenir des messages Windows, il est généralement implémenté dans une boucle.
Je sais qu'il est possible de faire une fonction qui va continuer à récupérer indéfiniment. Je m'attends à ce que cela entraînerait un débordement de pile.
est une boucle infinie le mauvais état d'esprit pour la programmation fonctionnelle?
est l'interface du système d'exploitation ou du matériel du problème?
Cela ne me semble pas comme un programme fonctionnel / O.S. pourrait continuer à courir seul
J'ai un petit peu d'expérience en train d'écrire des programmes fonctionnels, mais cela m'a toujours dérangé. Veuillez partager vos pensées / idées sur ces problèmes
4 Réponses :
Vous pouvez avoir infini Récursion queue si votre compilateur le reconnaît. Quelques langues, par exemple schéma, exiger que les compilateurs reconnaissent la récupération de la queue et allouez aucun espace de pile pour cela.
EDIT STRUT> Je ne veux pas être en désaccord avec les autres réponses, mais "infinie" boucles récursifs avec une idiome courante. pour traiter avec le monde extérieur. L'exemple suivant est tiré de Real World Haskell et est représentatif de l'idiome. mainloop :: Handle -> Handle -> IO ()
mainloop inh outh =
do ineof <- hIsEOF inh
if ineof
then return ()
else do inpStr <- hGetLine inh
hPutStrLn outh (map toUpper inpStr)
mainloop inh outh
Si vous utilisez Récuissation queue , vous avez efficacement une itération, comme un pour / pendant boucle. Par conséquent, je suppose que vous pouvez avoir une boucle infinie sans obtenir le débordement de la pile.
à votre question: "est une boucle infinie le mauvais état de l'esprit pour la programmation fonctionnelle?" peut-être que cela aidera peut-être: - tandis que ou à la récursivité de la queue dans F #, quoi utiliser quand ?
intéressant. Je n'ai pas pensé que la programmation fonctionnelle pourrait vous échapper avec des récursions infinies (bien de savoir). Merci pour l'information et vos idées. J'aime l'idée de la programmation réactive.
À titre d'exemple de la raison pour laquelle vous le feriez: le cœur d'un programme est souvent mieux représenté comme une séquence potentiellement infinie de transformations dans l'État mondial (par exemple, Pac-Man est sur le point de manger la pilule, Pac-Man est un pas en avant. et a mangé la pilule, etc.). C'est aussi le cas le plus courant pour les boucles infinies de mon expérience.
La plupart des utilisations des "boucles infinies" dans la programmation fonctionnelle peuvent être modélisées par Récursion . D'autres réponses ont jusqu'à présent souligné la récursion générale, mais une utilisation sans restriction de la récursion est sans doute une mauvaise approche, car elle peut entraîner un code mal structuré.
La grande majorité du code dans un programme purement fonctionnel doit être écrit dans le sous-ensemble total, c'est-à-dire des schémas d'utilisation telles que la récursion structurelle ou la co-récursion (qui garantissent la résiliation et les progrès) plutôt que de revenir à la récursivité générale. Espérons que les futures versions de GHC incluront un soutien direct pour détecter un sous-ensemble total de HASKELL et émettre des avertissements pour le code qui ne peuvent être prouvés pour résilier ou progresser.
Essayez Googling 'Tail Resursion'.
merci pour votre contribution à tous