Liens connexes

Dépêche modérée par

Dépêche éditée par

: Lisaac 0.12 en GPL v3

Posté par Ontologia (page perso, ). Modéré le 24 septembre 2007.
0
Après un an de travail intensif, Benoit Sonntag nous livre une version stable et intégralement réécrite de Lisaac, un langage ayant une productivité proche des langages de script avec les performances du C. Lisaac est un langage objet à prototype avec une bibliothèque et un compilateur sous licence GPLv3.

Les benchs effectués sur des traductions fidèles de programmes C donnent des résultats différents en fonction de l'architecture cible : on obtient, grossièrement, un code de 20 % plus rapide à 30 % plus lent.

La spécification 0.2 apporte de nombreuses nouveautés au langage : un système de types amélioré, une syntaxe où la casse permet de séparer clairement mot-clé, prototype/type et variables, un système de contrats amélioré et gérant l'héritage, une gestion automatique des micro/macro objets, l'héritage alimentaire, une gestion des blocks très puissante. L'innovation la plus visible est l'apparition des résultats multiples : une méthode peut retourner plusieurs valeurs, de même qu'elle peut en accepter plusieurs en argument.

Le compilateur est en outre capable de produire des statistiques sur les appels potentiels sur NULL et de prédire l'endroit où ils risquent d'arriver. Les temps d'exécution, la consommation mémoire et surtout la stabilité du compilateur ont été considérablement améliorés.

L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code. Cette technique de compilation, qui analyse et prédit les chemins potentiellement empruntés par le code à l'exécution permet une optimisation très poussée de celui-ci afin se rapprocher des performances du C (voir les benchs).

Dominique Colnet (auteur de SmartEiffel) et Benoit Sonntag ont quasiment terminé un traducteur Eiffel vers Lisaac. Ce traducteur permettra à Lisaac de bénéficier d'une bibliothèque Eiffel rigoureusement traduite de l'originale, et donc de disposer d'une bibliothèque testée et sûre. Cette bibliothèque devra ensuite être retravaillée afin d'utiliser au mieux la puissance d'un langage objet à prototype.

La version 0.3 de Lisaac, implémentera la gestion de la concurrence avec le modèle COP, qui automatisera celle-ci. La version 0.4 apportera la stabilisation syntaxique, sémantique et fonctionnelle du langage, ce qui permettra le lancement du projet Isaac OS, le système d'exploitation objet à prototype. Le projet Isaac sera ainsi réellement lancé.

Espérons que la communauté répondra présent à ce formidable défi.

NdM : l'"héritage alimentaire" est appelé comme cela car c'est un héritage qui possède toutes les propriétés de l'héritage classique, mais "secrètement". C'est à dire que vu de l'extérieur de l'objet qui utilise ledit héritage alimentaire, on ne sait pas qu'il hérite.

> Lire la suite (345 commentaires, moyenne: 2,3).   [dépêche : 9904 caractères]

Lisaac est un langage objet à prototype conçu au LORIA (INRIA Lorraine) en 2001. Il a été conçu afin d'écrire le système d'exploitation objet IsaacOS. Lisaac s'inspire de SmallTalk pour sa syntaxe à mot clé et sa logique exclusivement objet, de Self pour l'objet à prototype et d'Eiffel pour le typage statique ainsi que la programmation par contrat. La philosophie qui l'inspire se veut la plus minimaliste possible, de sorte à proposer un langage simple à apprendre, sans une multitude de mots clés et subtilités.

La principale difficulté fut de réussir à compiler un tel langage afin d'obtenir des performances permettant d'écrire un système d'exploitation autonome. En effet, la plupart des langages orientés objet compilés (C++, Eiffel...) utilisent soit des techniques de tables virtuelles (C++) pour résoudre la liaison dynamique (choix de l'objet sur lequel appeler une méthode, en fonction de l'arbre d'héritage) ou de résolution syntaxique grossière (Eiffel). Le compilateur Lisaac utilise une technique d'analyse de flot, certes très consommatrice en mémoire (algorithme exponentiel), afin d'analyser les possibilités d'exécution, prédire les appels, les spécialisations de type et optimiser le code en conséquence. Le langage étant très minimaliste (le compilateur ne connait pas la conditionnelle qui est défini dans la bibliothèque, à la manière de Smalltalk), le compilateur travaille sur une sémantique très bas niveau, ce qui lui permet de généraliser toutes sortes d'optimisations, en analysant la géométrie du graphe du code.

Adhérant largement aux principes de génie logiciel définis par Bertrand Meyer, le concepteur d'Eiffel, Benoit Sonntag a conçu un langage fortement typé et doté de contrats.
Le compilateur embarque aussi la possibilité de définir des contrats qui permettront de s'assurer de la validité de chaque unité de code et de s'arrêter à l'endroit où se trouve le problème, puis de l'afficher. Un système permettant de vérifier statiquement une partie des contrats a été implémenté dans cette version.

Lisaac, un peu à la manière de Smalltalk, possède le prototype BLOCK comme fondement. BLOCK est une liste d'instructions à évaluation retardée jusqu'à l'appel de la méthode .value. On peut ainsi écrire toutes les structures de contrôle que l'on désire, écrire des fonctions que l'on ne retrouve généralement que dans les langages fonctionnels (comme map/fold/filter).

La fonction fold_left de collection, est définie par :
- fold_left function:BLOCK with element:E :E <-
( + result:E;

result := element;
lower.to upper do { j:INTEGER;
result := function.value (result,item j);
};
result
);


s'utilise

maliste.fold_left { i,j : INTEGER;
i.max j
} with 0;

maliste étant un tableau d'entier.

La bibliothèque, directement issue de celle d'Eiffel, n'utilise que très peu ces possibilités. Les évolutions de celle-ci vont donc entre autre chercher à en tirer plus souvent partie.

En Lisaac, il n'existe pas de différence entre slots et données, ainsi la syntaxe est la même entre une propriété et une méthode. De même une méthode peut devenir une donnée :
- code_vers_donnee : INTEGER <- (
+ un_entier_quelconque : INTEGER;
// code
// ...
code_vers_donnee := un_entier_quelconque
);

code_vers_donnee va devenir et rester une propriété. Bien évidemment, il pourra redevenir plus tard une fonction.

On peut jouer de la même façon avec le slot définissant le parent. En effet, héritage dynamique oblige, le parent est défini dans la section Inherit :
Section Inherit
+ parent : Expanded FATHER := FATHER;

// Code...
Section Public
- set_parent p_parent : FATHER <- (
parent := p_parent;
);

On peut définir parent où l'on veut dans le reste du code du prototype.


Apport de la spécification 0.2

La spécification 0.2 apporte des innovations importantes
Le gestionnaire mémoire est entre autre issu d'une réflexion initiée en lisant un article de LinuxFR et suite à ce journal. Il s'agissait d'essayer de voisiner les données utilisées en même temps afin de s'assurer qu'elles se trouvent en cache L1 à l'exécution. Nicolas Boulay a ensuite rapidement embrayé une discussion avec Benoit Sonntag afin de mettre au point diverses optimisations. En effet, Lisaac n'utilise que très peu le système d'allocation mémoire du système d'exploitation. Il s'alloue un quantum de mémoire (virtuelle) et la gère ensuite à sa façon. Cela permet d'obtenir des optimisations très sensibles et poussées du code.

Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY (prototype de base pour les collections, qu'il est déconseillé d'utiliser).

Des contrats sur des données et du code
Non content de permettre de poser des contrats sur des slots de code, il est aussi possible d'en poser sur des slots de données. Par exemple, je veux qu'un entier soit strictement supérieur à 50 et soit un multiple de 11.
Autrement dit que
[i in |N | i>50 | i mod 11 = 0 ]

Rien de plus facile en Lisaac. À la déclaration de la variable, on écrit :
- i : INTEGER := 110 [ ? {(Result > 50) && {(Result % 11) = 0}}; ];

Le mode debug activé, le compilateur compilera le programme de façon à ce que chaque accès à la variable i vérifie ce contrat. Si celui-ci n'est pas respecté, le programme s'arrête avec un message d'erreur indiquant une valeur non autorisé pour la variable i.

Cette fonctionnalité appartenant à la spécification 0.2 est désactivée dans cette version 0.12 et sera activée dans la version suivante.


Éditeurs et coloration syntaxique
Des templates de coloration syntaxique sont disponibles pour les principaux éditeurs, notamment emacs, Vim, récemment proposé par Xavier Oswald, mais aussi Kate/KDevelop, développé par Anthony Pajot, qui, outre la coloration syntaxique, permet même la complétion sous KDevelop.


Projets
Les prochaines évolutions de la bibliothèque, pour une bonne partie d'entre elles, serviront de base à IsaacOS, qui sera libéré dans quelques mois, lorsque la version de Lisaac implémentant la spécification 0.3 proposant COP (Concurent Object Programming), sera prête.

Lorsque le traducteur Eiffel vers Lisaac sera disponible, on synthétisera une bonne partie de la bibliothèque avec celle de SmartEiffel, qui est testée et certifiée depuis 15 ans. Il sera alors temps d'amender celle-ci d'un point de vue cosmétique, afin de lui faire épouser les réelles possibilités du langage (en particulier les possibilités offertes par le type BLOCK).

Un effort de documentation est à fournir, en effet la bibliothèque donne lieu à deux version de la doc : la version "référence" qui se veut complète mais succincte, et une version plus détaillée qui renseigne chaque méthode des principaux prototypes de la bibliothèque, en détaillant chaque paramètre. Les deux documentations sont incomplètes pour le moment, mais suffisantes pour démarrer. En outre, à la suite de la contribution de Jérome Hilbert, Simon Fuhlhaber et Grégoire Jacquemin produisant un schéma UML (en svg) d'un ensemble de source Lisaac, nous aimerions améliorer celui-ci afin de le rendre plus configurable (position, couleurs des items)

Des rapports de bugs sont attendus pour la bibliothèque et le compilateur, n'hésitez pas à compiler vos programmes avec, cela vous (et nous) permettra de savoir où cela plante exactement.

Nous envisageons, dans les mois qui viennent, de mettre en place une sorte de CPAN pour le langage Lisaac.

À noter que la bibliothèque étant GPLv3, tout logiciel écrit avec cette bibliothèque est elle-même GPLv3 (vaccination oblige).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Sather

Posté par Sytoka Modon (page perso, ) le 24/09/2007 à 15:50. (lien). Évalué à 3.

Etant un admirateur de Sather, je ne peux qu'être enchanté par cette annonce parfaitement rédigée.

Merci.

[+] Pertinence de cette dépeche ?

Posté par Lucas (page perso, ) le 24/09/2007 à 16:41. (lien). Évalué à -6.

A chaque fois qu'une dépeche sur Lissac passe sur DLFP, je me demande ce qu'elle fait là. Alors cette fois-ci, j'exprime mes doutes.

Il me semble que Lissac est juste un language de recherche parmi énormément d'autres. Je ne remets pas en doute son côté innovant, mais pourquoi publier cette dépêche sur DLFP ? Surtout en première page ? Est-ce que ça veut dire que tous les projets de recherche publiés sous licence libre vont avoir droit à une dépêche de premiere page sur DLFP ?

De plus, qui est cet "Ontologia", dont la page perso est celle du projet Isaac ? Quelle est sa relation avec Benjamin Sonntag et avec les modérateurs de DLFP ? A noter que la page Wikipédia de Lisaac[1] est également écrite par lui, et qu'elle provoque également des interrogations[2,3].

[1] http://fr.wikipedia.org/wiki/Lisaac
[2] http://fr.wikipedia.org/wiki/Discuter:Lisaac
[3] http://fr.wikipedia.org/wiki/Utilisateur:Ontologiae

seul compilateur objet au monde à réaliser une analyse de flot ?

Posté par Antoine () le 24/09/2007 à 17:09. (lien). Évalué à 4.

L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code.

Je ne sais pas quels sont les critères pour toi d'un "compilateur objet", mais pypy fait aussi ce genre d'analyse.
http://codespeak.net/pypy/