Si la seule chose qui te gêne est le caractère %, tu peux toujours modifier le lexer du compilo et le recompiler, ça marche.
Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:
def pred(n):
match Nat n:
suc(x):
return x
zero():
return zero()
par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.
Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:
def pred(n):
match Nat n:
suc(x):
return x
zero():
return zero()
par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.
Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.