Seventh, le micro langage impératif de ZDS !

Les conditions et les boucles c'est un peu important quand même pour un langage impératif Par contre, pas la peine d'avoir des fonctions récursives par exemple. À part ça oui, c'est une liste très raisonnable.

Du coup, repartons sur la syntaxe. Je trouve que les blocs begin/end sont un peu trop verbeux, pourquoi ne pas les remplacer par des accolades comme en C ?

Autre point : vous voulez vraiment vous limiter à des entiers ?

EDIT : Une fois qu'on aura une syntaxe, faudra qu'on lui trouve un nom.

Pas faux. ;-° Mais il faut quand même que l'on se mtte rapidement d'accord sur le même, pour avoir la même chose dans toutes les implémentations.

Faisons simple : +1 sur ce message pour mettre des accolades, -1 pour garder begin/end (étant donné que je peux voter, il faudra ajouter 1 au compteur positif).

Oui, évidemment.

Salut, je me posais une petite question : est-ce que cela se fait de remonter les erreurs de compilation à coup d'exceptions ? Sinon, avez-vous une meilleure alternative à me proposer ?

EDIT : Toucher un peu aux outils que je vais utiliser pour m'attaquer au projet (flex/bison + llvm) m'a permis de comprendre cette phrase :

C'est vrai que finalement, avec un peu d'imagination, il y a largement de quoi s'amuser avec des entiers.

est-ce que cela se fait de remonter les erreurs de compilation à coup d'exceptions ? Sinon, avez-vous une meilleure alternative à me proposer ?

Normalement non: une exception est une erreur dans TON programme, pas dans celui que tu compiles/interprète.

Juste fais les remonter et attrapes-les quelque part en les affichant joliment

Je ne voulais pas dire laisser les exceptions remonter sans les gérer : je voulais justement demander si la méthode que tu proposes est acceptable, ou s'il y a mieux. Tu croyais que j'avais l'intention de laisser l'utilisateur du compilo en face d'un message "terminate called after throwing an instance of 'ParseError' " ?

Je ne voulais pas dire laisser les exceptions remonter sans les gérer : je voulais justement demander si la méthode que tu proposes est acceptable, ou s'il y a mieux

En fait je vois pas tellement d'autre méthode

Tu croyais que j'avais l'intention de laisser l'utilisateur du compilo en face d'un message "terminate called after throwing an instance of 'ParseError' " ?

On sait jamais, j'ai déjà vu des gens faire ça

Moi non plus, mais vu que ce n'est pas un cas d'utilisation des exceptions dont j'ai l'habitude, je préfère demander.

La question n'est pas de savoir quoi faire avec mon exception, mais juste si une exception est adaptée pour faire remonter ce type d'information. Spontanément, je dirais que c'est la "moins pire" des solutions, mais si quelqu'un à quelque chose à proposer, qu'il se manifeste.

A moins que tu voulais dire "abandonner la compilation à la première erreur et terminer le programme avec une fonction exit ou équivalent" ? Si c'est ça, c'est hors de question.

La question n'est pas de savoir quoi faire avec mon exception, mais juste si une exception est adaptée pour faire remonter ce type d'information. Spontanément, je dirais que c'est la "moins pire" des solutions, mais si quelqu'un à quelque chose à proposer, qu'il se manifeste.

Si je ne m'abuse le concept même d'exception a été inventé pour résoudre ces problèmes. Qu'est-ce qui te fait hésiter ?

Ce que tu veux, c'est un programme qui, étant donnée une source, produit un de ces deux résultats :

• le résultat du programme pour un interpréteur ou le résultat de la compilation pour un compilateur, si le programme source ne comporte pas d'erreur
• un échec, avec des informations plus ou moins précises sur cet échec (à quel endroit, de quel type…) si une erreur a été détectée dans le programme source

Les exceptions sont un moyen de faire ça qui vaut ce qu'il vaut : la valeur de retour de toutes tes fonctions est celle du premier cas (où ça se passe bien), et si un traitement échoue, il lève une exception pour l'indiquer. Tout en haut du code, il y a effectivement un gros try qui récupère les échecs de compilation possible pour les afficher proprement.

Dans un langage comme Python, c'est une solution pas trop mal. Dans des langages un peu expressifs avec des vrais types, on pourrait faire autrement en ayant des fonctions sur un type qui contient à la fois les résultats corrects et les erreurs possibles, et le typeur s'assurerait que tu prends bien en compte les différentes erreurs dans les fonctions qui prennent en paramètre le résultat d'une autre fonction. En Python, comme le compilateur ne vérifie rien du tout, ça n'a de toute façon aucun intérêt.

Tu t'abuses.

Les exceptions sont faites pour s'exécuter lorsqu'il se produit un événement exceptionnel dans l'exécution du programme, c'est-à-dire un événement qui ne fait pas partie de l'exécution normale de ton programme. Autrement dit, et c'est ce que tu as dit, elles sont faites pour rapporter les erreurs de ton programme, et plus précisément les erreurs qui ne sont pas dues à une erreur de programmation (PPC, post-conditions, toussa), par exemple une allocation qui échoue.

Après, il est possible que ça soit la "moins pire" des solutions en Python, et c'est le cas selon Eusèbe, mais ce qui est sûr, c'est que ce n'est pas pour résoudre ce genre de problèmes que l'on a inventé les exceptions.

Sinon, pour en revenir à nos moutons :

J'avoue ne pas vraiment comprendre ce que tu veux dire. Tu aurais un petit exemple ?

Mouais je ne sais pas pourquoi elles ont été inventé mais dans pleins de langages, dont Python, c'est utilisé bien plus souvent que ça.

Je comprends que l'on puisse les utiliser pour d'autres choses. Je voulais juste revenir sur le fait qu'il dise que ce soit pour ce genre de problèmes que c'est fait à la base. Je t'avoue que je chipote un peu.

Sinon, au passage, comme citer une source ne fait jamais de mal :

Et une erreur de compilation, tu ne considères pas ça comme un cas exceptionnel, qui mérite donc son exception ?