Seventh, le micro langage impératif de ZDS !

Parce que les lisp-like, c'est cool, mais on aime aussi l'impératif nous !

a marqué ce sujet comme résolu.

Je continue de porter Seventh (version n°C - #laPrivateJoke), et les opérations du style (10 + (14 - ((147.852 % 79.654) / 42))) * (my-var - (142 + 47)) fonctionnent :)

Sinon j'ai mon tokenizer et un début de parser pour Eleventh (pas totalement fonctionnel le parser, ok)

+1 -0

Tu fais comme tu veux mais je pense que tu devrais vraiment pas te prendre la tête a court terme. Selon moi pour commencer tu devrais juste définir :

  • Comme définir une fonction,
  • L'affectation,
  • Les opérations arithmétiques de bases,
  • une fonction print,
  • Eventuellement un if/else

Pour le reste, tu verra plus tard, ça se rajoutera.

Le pascal que je te propose a l'avantage de rester simple a parser (car il y a pas mal de délimiteurs). Il y a effectivement une difficulté, c'est que les opérateurs ne sont plus infix mais vu que tu nous a dis déjà avoir fais un parseur de lisp, ça fait un petit challenge! Je pense que c'est largement faisable.

Kje

Les conditions et les boucles c'est un peu important quand même pour un langage impératif :D 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.

+1 -0

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 ?

Non, voilà exactement le genre de point de syntaxe lequel il ne faut pas discuter : on s'en fiche complètement. Prenez l'un ou l'autre, mais ne perdez pas de temps à savoir lequel, c'est vraiment sans intérêt.

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

Oui, pour commencer c'est une bonne idée. Vous pourrez toujours rajouter d'autres choses après, mais avec un peu d'ambition vous avez déjà de quoi vous occuper pendant quelques mois avec des entiers.

+3 -0

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 ?

Non, voilà exactement le genre de point de syntaxe lequel il ne faut pas discuter : on s'en fiche complètement. Prenez l'un ou l'autre, mais ne perdez pas de temps à savoir lequel, c'est vraiment sans intérêt.

Eusèbe

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).

+1 -0

Perso, peu importe la syntaxe. Le plus important, c'est comment on va définir des "idées". autrement dit :

exemple

  • définition de fonction: keyword name arguments bloc_de_code

edit: post principal édité !

edit 2 : j'ai ajouté la possibilité d'avoir des alias (codés par l'utilisateur) dans seventh-C (concrètement je l'ai fait juste pour le fun). 'fin bref, ça se complète petit à petit !

+0 -0

Petit message pour indiquer que j'évolue la manière d'écrire du code Seventh-C : le monoligne est maintenant supporté ! A la manière du C quand on fait un #define ;)

exemple :

1
2
3
4
5
6
7
8
9
print << "hello world" $10 \
         "on another line"
print << "fucking test ?"

if (3 < 4) \
   (print << "crap, 3 < 4 !!")

my-var = [0 1 2 3 4 5]
my-var

Ici vous voyez également que j'ai une variable drôlement nommée : $10. Il faut savoir qu'il y en a d'autres, préfixées ainsi par un $ : $8, $9, et $13. Ce sont des constantes, et le numéro qui les suffixe est un ordinal. Vous comprenez donc que $10 $13 représente ceci : \n\r (on peut mettre un espace entre $10 et $13, peu importe, quand je join mes chars, ça changera rien !). Ces constantes permettent donc de pouvoir contourner le petit problème avec les caractères spéciaux préfixés de \. Dans l'autre croissant, ça nous donne : backspace, tab, new line, carriage return

+0 -0

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 :

Vous pourrez toujours rajouter d'autres choses après, mais avec un peu d'ambition vous avez déjà de quoi vous occuper pendant quelques mois avec des entiers.

Eusèbe

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

+0 -0

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 :)

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 :)

AlphaZeta

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' " ? ^^

+0 -0

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 :euh:

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 :lol:

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 :euh:

AlphaZeta

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. ;)

+0 -0

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. :p

+0 -0

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.

+0 -0

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 ?

AlphaZeta

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 :

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.

Eusèbe

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

+0 -2

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.

Kje

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.

mehdidou99

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 :

Dans le contexte des langages de programmation fonctionnels et impératifs, un système de gestion d'exceptions ou SGE permet de gérer les conditions exceptionnelles pendant l'exécution du programme. Lorsqu'une exception se produit, l'exécution normale du programme est interrompue et l'exception est traitée.

Wikipédia

+0 -0

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. ;) Source: Wikipédia

mehdidou99

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

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte