J'explique pourquoi un frontend GCC m'intéresse tellement:

Un frontend GCC ETP permettrait de distribuer ETP avec TIGCC comme une solution intégrée. Enfin bon, il faudrait aussi rajouter le syntax highlighting ETP BASIC à KTIGCC 2, mais ce n'est pas un travail immense. Donc on pourrait écrire en C ou ETP BASIC au choix, et même mélanger les deux.

Enfin, il restera(it?) probablement quelques tensions parce que Onur veut imposer la portabilité dans le langage (accès aux fonctions natives uniquement à travers son runtime), alors que pour ce que je compte faire, il faut pouvoir interfacer avec du code C arbitraire. AMHA, la meilleure solution serait d'implémenter le runtime ETP en termes de l'interface avec le code C/ASM. Genre avoir un header automatiquement inclus, par exemple system.inc, qui contient quelque chose comme:
Declare Sub Locate Alias "_ROM_CALL_1A9" (x As Integer, y As Integer, str As Const String, Attr As Integer)
(le compilateur pourra éventuellement traîter _ROM_CALL_* de manière particulière, mais s'il ne le fait pas, ce serait quand-même suffisant au moins pour les ROM_CALLS F-Line) et de même pour les fonctions de la lib runtime. Comme ça, la lib runtime sera utilisable en C facilement (il suffit de faire un .h équivalent au .inc), donc on pourrait écrire du code tout aussi portable en C aussi si on préfère le C, et dans l'autre sens les fonctions C (ROM_CALLs, librairies etc.) seraient utilisables en ETP, ce qui augmenterait de beaucoup l'expressivité du langage.