Alors c’est pas pour dire, mais si quelqu’un implémentait un parseur json en lisp (notamment en scheme, où ce dont je parle est rendu obligatoire par le standard, mais ça vaut aussi pour toute implémentation décente de (common) lisp, et si ça vaut pas pour emacs lisp, ça serait facile de faire en sorte que si), bah yaurait aucun problème, læ programmeuseur n’aurait jamais aucune question à se poser, ça marcherait juste, tant qu’ya assez de ram, au pire ce serait un peu plus lent par rapport à ce qui serait possiblement optimisable, au bout d’un certain niveau...
Le fait est qu’assez généralement en lisp, obligatoirement en scheme, les entiers overflowent naturellement sur des bignum (càd en précision arbitraire, le programme devient juste plus lent, mais toujours fonctionnel, tant qu’ya assez de ram, les nombres peuvent être aussi gros qu’ya de place en ram pour les représenter), et ya de la « tail call recursion » que tout le monde systémise : ie tout appel récursif en fin de fonction (et c’est une bonne pratique de toujours faire ça) revient à faire un goto, et ne grossit en rien la pile (pas moins performant qu’une boucle).
Rappelons que la seule (à part le nouveau « do », un peu compliqué et trop générique, que tout le monde déteste) forme de boucle en scheme est la récursion, on l’utilise pour tout, naturellement elle a été optimisée en conséquence. Et dans les autres lisps c’est un peu pareil, juste pas nécessairement systémique (le bon usage reste à la récursion, mais ya aussi bcp de formes de boucles plus expressives que dans les autres langages, incluant toutes les formes de boucles des autres langages).
Donc voilà, j’dis ça j’dis rien... c’pas comme si en lisp on avait des structures de données plus simples qu’xml/json, plus efficaces, performantes, et qu’on avait l’habitude d’imbriquer par delà la raison depuis... fortran en fait (lisp est le deuxième vrai gros langage de prog de l’Histoire, le premier interprété, et le premier-pas-mal-de-trucs en fait).
# En Lisp tout marche toujours sans se poser de questions
Posté par galex-713 . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 0. Dernière modification le 12 novembre 2017 à 16:15.
Alors c’est pas pour dire, mais si quelqu’un implémentait un parseur json en lisp (notamment en scheme, où ce dont je parle est rendu obligatoire par le standard, mais ça vaut aussi pour toute implémentation décente de (common) lisp, et si ça vaut pas pour emacs lisp, ça serait facile de faire en sorte que si), bah yaurait aucun problème, læ programmeuseur n’aurait jamais aucune question à se poser, ça marcherait juste, tant qu’ya assez de ram, au pire ce serait un peu plus lent par rapport à ce qui serait possiblement optimisable, au bout d’un certain niveau...
Le fait est qu’assez généralement en lisp, obligatoirement en scheme, les entiers overflowent naturellement sur des bignum (càd en précision arbitraire, le programme devient juste plus lent, mais toujours fonctionnel, tant qu’ya assez de ram, les nombres peuvent être aussi gros qu’ya de place en ram pour les représenter), et ya de la « tail call recursion » que tout le monde systémise : ie tout appel récursif en fin de fonction (et c’est une bonne pratique de toujours faire ça) revient à faire un goto, et ne grossit en rien la pile (pas moins performant qu’une boucle).
Rappelons que la seule (à part le nouveau « do », un peu compliqué et trop générique, que tout le monde déteste) forme de boucle en scheme est la récursion, on l’utilise pour tout, naturellement elle a été optimisée en conséquence. Et dans les autres lisps c’est un peu pareil, juste pas nécessairement systémique (le bon usage reste à la récursion, mais ya aussi bcp de formes de boucles plus expressives que dans les autres langages, incluant toutes les formes de boucles des autres langages).
Donc voilà, j’dis ça j’dis rien... c’pas comme si en lisp on avait des structures de données plus simples qu’xml/json, plus efficaces, performantes, et qu’on avait l’habitude d’imbriquer par delà la raison depuis... fortran en fait (lisp est le deuxième vrai gros langage de prog de l’Histoire, le premier interprété, et le premier-pas-mal-de-trucs en fait).