Super, je vais pas te donner tout le code généré par le compilateur.
Je sais bien, c'etait une question rethorique.
Tu sais tres bien qu'il faut embarquer un compilateur pour ca, c'etait juste une facon (certes qq peu trollesque) de le faire remarquer.
Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.
Oui, je suis pas idiot et je me doute bien que c'est comme ca qu'il fonctionne, MS a une VM plutot bien gaulee, ca serait dommage de pas l'utiliser.
Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).
Oui, j'ai fait la meme remarque (et pour eval, c'est meme tres tres tard, puisque semantiquement tu ne peux pas compiler avant d'arriver sur l'appel. Mais c'est pas ce qui est important aussi).
On pourrait aussi dire la meme chose pour un langage interprete: au final, ca va tourner sur le processeur, ya donc du code machine qui est genere d'une facon ou d'une autre.
Tu n'oserais pas pretendre pour autant qu'un langage interprete est compile?
Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence, et tu te retrouves donc avec une generation de code, aka compilation.
Ce que je veux dire c'est que l'argument: au final, on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.
2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.
Oui, je me doute bien, j'ai pas precise dans mon commentaire, mais je n'ai jamais doute un instant que MS ne supportait pas ca, donc pas de raison que mono ne puisse le faire.
Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.
Certes, mais eval fait partie de javascript. Supporter tout javascript sauf eval, c'est supporter un subset de javascript. Si tu peux pas supporter eval en natif, tu ne supportes pas JavaScript en natif, juste un subset.
Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.
Bref, au final, tout ce long thread vient, je pense d'un probleme tout con: vous avez l'air de considerer qu'il n'y a que 2 type de langages: compile ou pas.
Tu vois mono comme compile, vu qu'il y a une phase de compilation. On peut pas dire que t'as tord, mais on peut pas dire que t'as raison non plus.
Il voit mono comme non compile, vu qu'il target une archi qui n'existe pas, et que le bytecode est de trop haut niveau pour etre considere comme du code machine. On peut pas dire qu'il a tord, mais on peut pas dire qu'il a raison non plus.
Bref, le probleme c'est peut etre qu'il faut introduire une troisieme categorie, ce qui nous laisse avec:
- interprete
- langage a VM
- langage compile.
Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.
[^] # Re: Surprise
Posté par thedude . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
Je sais bien, c'etait une question rethorique.
Tu sais tres bien qu'il faut embarquer un compilateur pour ca, c'etait juste une facon (certes qq peu trollesque) de le faire remarquer.
Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.
Oui, je suis pas idiot et je me doute bien que c'est comme ca qu'il fonctionne, MS a une VM plutot bien gaulee, ca serait dommage de pas l'utiliser.
Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).
Oui, j'ai fait la meme remarque (et pour eval, c'est meme tres tres tard, puisque semantiquement tu ne peux pas compiler avant d'arriver sur l'appel. Mais c'est pas ce qui est important aussi).
On pourrait aussi dire la meme chose pour un langage interprete: au final, ca va tourner sur le processeur, ya donc du code machine qui est genere d'une facon ou d'une autre.
Tu n'oserais pas pretendre pour autant qu'un langage interprete est compile?
Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence, et tu te retrouves donc avec une generation de code, aka compilation.
Ce que je veux dire c'est que l'argument: au final, on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.
2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.
Oui, je me doute bien, j'ai pas precise dans mon commentaire, mais je n'ai jamais doute un instant que MS ne supportait pas ca, donc pas de raison que mono ne puisse le faire.
Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.
Certes, mais eval fait partie de javascript. Supporter tout javascript sauf eval, c'est supporter un subset de javascript. Si tu peux pas supporter eval en natif, tu ne supportes pas JavaScript en natif, juste un subset.
Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.
Bref, au final, tout ce long thread vient, je pense d'un probleme tout con: vous avez l'air de considerer qu'il n'y a que 2 type de langages: compile ou pas.
Tu vois mono comme compile, vu qu'il y a une phase de compilation. On peut pas dire que t'as tord, mais on peut pas dire que t'as raison non plus.
Il voit mono comme non compile, vu qu'il target une archi qui n'existe pas, et que le bytecode est de trop haut niveau pour etre considere comme du code machine. On peut pas dire qu'il a tord, mais on peut pas dire qu'il a raison non plus.
Bref, le probleme c'est peut etre qu'il faut introduire une troisieme categorie, ce qui nous laisse avec:
- interprete
- langage a VM
- langage compile.
Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.