1/Le compilateur Lisaac effectue une analyse de flot de ton code, c'est à dire qu'il l'analyse afin de
- recenser le code vivant
- supprimer toutes les instructions inutiles
- résoudre la liaison dynamique -> plus de VFT
L'intérêt du compilateur tient en son minimalisme : la conditionnelle étant défini dans la lib, elle se trouve n'estre qu'une simple résolution de lien dynamique objet.
En effet, le message if est défini comme suit :
dans Boolean.li
- if true_block then false_block <- defered
defered est l'équiv de virtual en Java
Dans true.li
- if true_block then false_block <- (
true_block.value;
);
dans false.li
- if true_block then false_block <- (
false_block.value;
);
Evaluer une condition fausse ou vrai pour le if revient à résoudre un message.
Cela implique que le compilateur ne sait pas faire la différence entre un if, et un héritage dynamique par exemple, il ne connait que la résolution dynamique.
Cela permet d'avoir un langage extrêmement minimaliste en interne et d'optimiser à mort.
2/ Le compilateur peut mettre en place des optimisations qui rendent le code trop vite illisible pour un être humain.
Citons par exemple la gestion de la mémoire qui peut être géré à la main : tu fait un malloc de départ et tu gère l'emplacement de tes données à la main pour en optimiser l'emplacement, pour le cache par exemple.
Tu peux aussi supprimer l'ensemble des appels inutile, c'est à dire inliner ton code, ce qui le rend illisible pour un être humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
1/Le compilateur Lisaac effectue une analyse de flot de ton code, c'est à dire qu'il l'analyse afin de
- recenser le code vivant
- supprimer toutes les instructions inutiles
- résoudre la liaison dynamique -> plus de VFT
L'intérêt du compilateur tient en son minimalisme : la conditionnelle étant défini dans la lib, elle se trouve n'estre qu'une simple résolution de lien dynamique objet.
En effet, le message if est défini comme suit :
dans Boolean.li
- if true_block then false_block <- defered
defered est l'équiv de virtual en Java
Dans true.li
- if true_block then false_block <- (
true_block.value;
);
dans false.li
- if true_block then false_block <- (
false_block.value;
);
Evaluer une condition fausse ou vrai pour le if revient à résoudre un message.
Cela implique que le compilateur ne sait pas faire la différence entre un if, et un héritage dynamique par exemple, il ne connait que la résolution dynamique.
Cela permet d'avoir un langage extrêmement minimaliste en interne et d'optimiser à mort.
2/ Le compilateur peut mettre en place des optimisations qui rendent le code trop vite illisible pour un être humain.
Citons par exemple la gestion de la mémoire qui peut être géré à la main : tu fait un malloc de départ et tu gère l'emplacement de tes données à la main pour en optimiser l'emplacement, pour le cache par exemple.
Tu peux aussi supprimer l'ensemble des appels inutile, c'est à dire inliner ton code, ce qui le rend illisible pour un être humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker