janvier
2009
Ce billet inaugure une série que je voudrais consacrer à la spécification et à l’implantation d’un (nouveau) langage de bas niveau.
Syntaxiquement, ce langage est inspiré de BASIC ou de MODULA, sémantiquement il se veut une modernisation du C c’est-à-dire avec les mêmes objectifs de libre performance, avec toutefois une attention particulière accordée à la sûreté de l’ensemble sans toutefois rien renier des opérations de bas niveau.
La motivation principale de cette nouvelle conception c’était le constat que les langages principaux dans la famille des langages natifs (à savoir Pascal et C) sont aujourd’hui d’une conception qu’on pourrait qualifier de datée. Entre-temps le paradigme dominant a changé, des extensions ont été ajoutées, et avec le nouvel engouement pour les caractéristiques inspirées des langages fonctionnels on peut se demander si leur conception d’origine est encore d’actualité. Bien sûr leur utilisation est encore d’actualité, cela je n’en doute pas un instant, toutefois il m’a paru intéressant d’imaginer ce que pourrait être aujourd’hui le coeur d’un langage de bas niveau, conçu aujourd’hui avec en tête le style des programmeurs d’aujourd’hui tout en préservant les possibilités d’hier.
Et j’insiste particulièrement sur ce dernier point: ce que je ne cherche pas c’est à remplacer les idées d’hier par des idées d’aujourd’hui, je me demande au contraire comment on pourrait (ou comment on aurait du) réconcilier au mieux la puissance du bas niveau avec la productivité du haut niveau. Par réconcilier j’entends minimiser au mieux les allers-retours du style procédural vers le style POO, d’un côté rogner le moins possible sur la liberté et la performance, d’un autre côté rogner le moins possible sur la sécurité et l’expressivité.
Il y a quelques temps j’avais mis en ligne une ébauche de spécification, surnommée Lombric pour bien rappeler que mon objectif restait un langage de bas niveau (au niveau des pissenlits et même en dessous).
Qu’est-ce qu’un langage de bas niveau aujourd’hui ?
Lombric m’avait paru, et me paraît toujours, un bon début de réponse.
À partir de là il y avait deux directions possibles :
- poursuivre la spécification, notamment la partie orienté-objet
- commencer une implantation de la partie procédurale, sans me soucier de la POO
Après un temps de réflexion il s’est avéré que seule la deuxième option faisait sens.
D’abord parce que je ne crois pas au modèle Waterfall, dans mon cas je crois que la bonne spécification est nourrie par la bonne implantation. Il a mille façons de faire une extension POO et seule l’expérience du style procédural peut me guider vers le choix le plus respectueux du style traditionnel. Car je ne veux pas que l’un supplante l’autre, je veux qu’ils se renforcent mutuellement.
Ensuite, et c’est sans doute la véritable raison, même en se limitant au style procédural un compilateur reste quelque chose de difficile à implanter, c’est donc dans un soucis de maîtrise de la complexité que j’ai décidé de commencer par la partie « facile ».
Laquelle partie facile réserve tout de même son lot de problèmes et de questions, mais j’aurai sans doute l’occasion de revenir là-dessus dans mes prochains billets.
Pour l’instant je vous invite à vous familiariser avec la conception de base du langage, en gardant ces quelques points à l’esprit :
- la syntaxe ne fait pas partie de la conception, c’est juste une notation pour parler d’une conception, en particulier la syntaxe n’est pas la partie difficile dans la réalisation d’un compilateur
- il ne faut pas voir les primitives proposées comme étant complètes ou suffisantes mais seulement comme une proposition de ce qui pourrait consistuer le coeur d’un langage autour duquel viendrait se greffer des extensions et/ou des services complémentaires, d’une façon qu’on souhaite harmonieuse, sans le passif de 30 années de compatibilité
- il est prématuré de parler d’outils, de caractéristiques ou de fonctionnalités modernes alors que le document ne parle pas de choses aussi basiques que par exemple les nombres flottants
Pour finir je n’oublie pas l’exemple fondamental, que pour l’occasion je précipite dans l’ère moderne (et néanmoins déjà désuète) de la programmation modulaire :
IMPORT
Console
INITIATE
Console.Print("Hello World!\n")
ENDMODULE
Bonsoir millie,
Est-ce un choix délibéré d’utiliser des majuscules pour les mots-clefs ?
Le langage est, entre autres, inspiré de MODULA/OBERON pour la syntaxe, ça explique les majuscules.
Mais ça ne veux rien dire pour l’instant.
La décision ultime en matière de lexeur et de parseur ne se fera que très tard dans le développement, pour l’instant ce qui m’intéresse c’est le système de typage.
Si tu fais un prototype, tu vas compiler ton programme vers quel langage intermédiaire ?
Aucun qui soit susceptible de t’intéresser.
Pour l’instant je cherche à tester une conception, pas une implantation.
Salut,
J’ai une question :
Si tu fais un prototype, tu vas compiler ton programme vers quel langage intermédiaire ?
Est-ce un choix délibéré d’utiliser des majuscules pour les mots-clefs ?
Bonne continuation