Je travaille sur un concept déclaratif s'inspirant de la méta-programmation.
Ca va plus loin que la définition d'un mini langage : c'est de la reconnaissance de forme.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ta contribution est très bien argumentée, mais je ne suis pas d'accord.
Lisaac a été pensé pour ne plus avoir besoin de faire du C.
D'ailleurs, un Système d'exploitation entier a été écrit avec. Il tient en 30 000 lignes, interfaces graphique comprise. Il est intégralement objet et fonctionnel. Tu trouveras sur le site une démo tournant sous linux ou tu pourras évaluer l'empreinte mémoire.
Lisaac est doté de mécanismes permettant de se passer de C. Tu trouveras la doc sur le site, mais j'évocquerai ici :
- La section INTERUPT qui permet de définir des interuptions, le code étant compilé en conséquence.
- La section MAPPING qui permet de définir une structure de données ordonné, se posant sur le binaire
- Des perfs et une consommation mémoire similaire au C.
Benoit Sonntag, le concepteur de Lisaac a 400 000 lignes de C à son actif, et un peu plus en assembleur x86.
C'est dire s'il a fait le tour de la question.
Décidé d'en finir une bonne fois pour toute avec l'obligation de passer par ce langage pour le bas niveau, il a fait Lisaac.
Il a la prétention de penser que Lisaac est fait pour rendre (théoriquement parlant) le C comme un langage dépassé, bien qu'exceptionnel.
J'ai la flemme de répondre sur tes idées sur le framework qui sont très intéressantes et que j'irai relire de temps en temps, mais ça fait quasiment une semaine que je ma bat ici, je fatigue :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
...et Lissac a une syntaxe destiné à simplifier la vie au compilateur.
Non là tu ne peux pas dire ça.
La grammaire est certes minimaliste. Connaissant benoit, je dirai que c'est une approche philosophique qu'il affectionne (et moi qui ne le suis pas du tout, je me rend compte qu'en fait c'est mieux : les axiomatiques trop grosses, c'est jamais bon).
La grammaire de Lisaac a été très pensée, et on s'y habitue assez vite. De fait on l'apprend très vite (quelques heures), c'est quelques choses que j'apprécie beaucoup.
Moi aussi au début, j'ai gueulé contre les types en majuscules, parce que Shift à chaque fois, c'est lourd.
Je crois que la solution, c'est un emcas ou autre qui te le met automatiquement en majuscule.
Moi aussi au début j'ai gueulé contre l'interdiction de majuscules dans les variables, qui me permettaient de faire des phrases dans mes variables (je fais souvent des variables avec des noms interminables).
J'ai reprogrammé en Java, et j'ai passé un temps fou zsur des erreurs du type "ah erde, là ya un majuscule pour la 2ème lettre" et je me suis rendu compte que c'est galère.
Par contre j'adore les mots clés. Ca fait des phrases.
Comme il parait que j'aime spéculer ;o)) L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
(1) A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
Est-ce que qqu'un a comparé ces deux langages ?
Pas à ma connaissance. Personnelement, je ne connais rien à ce langage.
Serait-il possible de mettre en oeuvre les optimisations de Lissac pour d'autres langages ?
Je m'étonne qu'il y ait fallu quasiment une semaine pour que quelqu'un pense enfin à poser la question.
Je pense que, sauf les fonctionalitées comme la réflexivité, etc... on pourrait tout à fait utiliser le compilateur Lisaac pour compiler du Java, du C++ (beuurk), d'autres.
Il faudrai pour cela pas mal retravailler l'objet PARSER pour lui faire bouffer la syntaxe.
J'ai un peu peur duand à la gestion des mots clé, qui sont énormes dans ces langages.
Ca serait un gros parser, mais ça passerai.
Ce qui serait marrant, c'est du Java aussi rapide que du C....
(3) Ruby connait un grand enthousiasme en ce moment via (a) le framework Ruby On Rails pour la programmation web et (b) comme candidat pour fabriquer facilement des DSL (via la métaprogrammation ?).
Si Lissac, via la compilation, enfonce Ruby (dont le coté dynamique a l'air d'avoir un cout), et supporte des fonctionnalités analogues à celles de Ruby, Lissac pourrait aussi être positionné sur les mêmes créneaux (a) et (b).
Cela a-t-il été envisagé ?
Peut être pas sous cet angle, et que par moi (les délires sur les langages du futur, c'est ma spécialité)
Mais je v étudier la question, le titre "Creating a weblog in 15 minutes" est assez bandant.
Si t'as des idées là dessus, tu es le bienvenu, les discussions sur les spécifications 0.3 et surtout 0.4 de Lisaac sont ouvertes (la 0.2 est en train d'être implémentée).
Fais moi signe ;)
(4) Lissac supporte-il le polymorphisme à la Caml ?
par exemple, en Caml, on peut écrire une fonction telle que (j'écris de mémoire) :
let rec size list = match list with
[] -> 0
| head::tail -> (size tail) + 1
et cette fonction est typé comme ['a] -> int : elle peut opérer sur des listes de n'importe quoi.
Bon là je me rend compte, que j'en ai marre, je veux une fonction tail et une fonction head dans les collections.
- size lst :LINKED_LIST[E] : INTEGER <-
(
+ result : INTEGER;
+ tmp : LINKED_LIST[E];
(lst.count <1).if { result :=0;
} else { result := (size lst.tail) +1; };
result
);
C'est mieux
Ya encore du progrès à faire.
La futur version 0.2 qui sort bientôt te permettra de rendre plusieurs valeurs, comme caml, donc de faire du vrai fonctionnel.
public SortedMap<ArrayList<MBeanServerInvocationHandler>> getFoo() {
SortedMap<ArrayList<MBeanServerInvocationHandler>> foo =
new SortedMap<ArrayList<MBeanServerInvocationHandler>>();
foo.doSomething();
return foo;
}
(5) en Caml, on peut aussi faire du pattern matching, une sorte de switch, comme en C, mais amélioré car pouvant porter sur des types de données qui ne sont pas limités au type 'int'.
Est-ce possible via Lissac ?
Merci de vos éclaircissements.
Non, mais moi j'aimerai bien.
Alors comme il se trouve que Xavier Leroy et Benoit Sonntag se connaissent, j'aimerai bien que ce soit implémenté dans le compilo.
Ca va venir, je pense.
Cela dit, je pense qu'il est implémentable dans la lib un truc similaire mais un moins puissant.
Faudrait y réfléchir.
Tu me donnes une idée, merci :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ma phrase: le compilateur transforme une récurcivité terminale en boucle classique.
C'est un pattern matching : dès qu'il en détecte une il la dérécurcive.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est nécessaire pour pouvoir faire des raisonnements éléborés d'abstraire les structures. Plus on se rapproche du niveau sémantique, et plus il est facile de faire de déductions, et donc de faire des déductions efficace. Optimiser au niveau de l'algorithme et non plus de la boucle. Une idée qui m'est venu comme ça : un langage ou le compilo choisit lui même la structure de donnée adaptée pour stocker une collection d'objet, en fonction de ce qu'on en fait : optimisation des accès si il y en a beaucoup, ... Au lieu de préciser 'vecteur', 'liste', 'arbre de recherche', on dit 'collection de' et on laisse le compilo se débrouiller en fonction de l'utilisation qu'on en fait.
Alors ça c'est dingue !!! C'est précisément l'idée qu'on a eu avec Benoit l'autre jour. Je crois que c'est parti d'une remarque de nicO au SL2006 et on est arrivé à la conlusion qu'il fallait faire un type LIST général qui hérite dynamiquement de toutes les collections existantes (FIXED_ARRAY, LINKED_LIST, etc...). On ajoute un mot clé pour que le codeur puisse dire au compilateur de choisir lui même le parent en fonction de ce qu'il y a dans le code.
Par analyse de flot, le compilateur calcule le temps d'exécution dans le pire des cas de chaque branche et choisi la meilleur.
Dans le même genre, niveau langage, certains pensent (genre MS) qu'on va de plus en plus vers des langages spécialisés, dans lequel le spécialiste du domaine (plus forcément un informaticien spécialiste) peut exprimer ce qu'il veut, et laisser faire le boulot à des algos spécialisé, le travail de l'informaticien ce recentrant sur la conception des langages et des algos spécialisés.
Je ne savais pas qu'MS en arrivait là, mais j'en arrive aussi à la même conclusion. Suite à mes réflexions (voir mes articles), j'en arrive qu'il faut (liste non exhaustive):
- Un langage de manipulation de données ensembliste, genre Cduce, mais en plus haut et orienté langage naturel avec des idées de prolog.
- Des fonctionnalitées agent
- Du pattern matching, encore du pattern matching !
- La possibilité de définir une sémantique grammaticalisé avec les règles associées facilement.
C'est encore très flou, mais le concept "un paradigme pour tout faire", j'y crois plus.
Il faut que les langages ne se contentent plus de définir des graphes de code et il faut arrêter avec les grammaires dures (genre il manque un ';' donc ça compile pas).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ben j'en sais les benchs que vous donnez...
Ce n'est pas parce que l'implémentation d'un concept à un instant T est moins performante, que ce concept est invalide. Ce n'est pas une condition nécessaire, tu n'as rien prouvé là.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
La librairie est en libre (Cecill), si quelqu'un a une primitive intéressante, on l'intègre.
Pour le reste, s'il y a au moins 1% de codeur qui toucheront à Boolean.li, je serai très étonné.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
C'est hors de question. Le compilateur restera hyper minimaliste, comme je l'ai expliqué en bas, ça permet de se concentrer sur la sémantique du code. de plus, comme on te l'a expliqué ailleurs, cela permet de faire un compilo plus propre, donc moins de bug, etc...
Seront rajoutées des primitives lorsqu'on tombera sur du très haut niveau, genre le SQL intégré ou des primitives très haut niveau comme "qqsoit x de l'ensemble".
>Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il >manque quelque confort pour la chose c'est un détail qui se règle en quelques heures >au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
Il y a une ML pour le projet, tu as le droit de contribuer.
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" : http://www.artima.com/intv/nonvirtual.html
Envoi un mail à Benoit, je ne me sens pas assez qualifié pour répondre à ça.
[héritage dynamique, prototype]Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
C'est à toi de répodnre à cette question lorsque tu designe une application.
Premièrement, cela apporte que la structure objet que tu codes, restera la même à l'exécution, ce qui n'est pas le cas avec l'objet à classe. Une classe n'est qu'un moule, il faut l'instancier pour qu'elle devienne vivante, tandis qu'un prototype est vivant dès le début.
Deuxièmement, l'héritage dynamique te permet de simplifier considérablement l'arbre d'héritage.
On met beaucoup de temps à comprendre l'intérêt de ces possibilités. Même son auteur a mis beaucoup de temps à utiliser l'héritage dynamique dans son langage. Le compilo actuel n'en n'utilise pas, le futur qui sortira bientôt, l'utilise massivement.
C'est en designant ton appli que tu en vois l'intérêt.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
Pour résoudre les bugs, ya pas de debugger mais ça viendra.
intégrer le code à l'existant, c'est dors et déjà possible, on va travailler à améliorer la cosmétique.
Pour la doc, un générateur de Doc, un peu dans le style de Javadoc sera intégré dans la prochaine version du compilateur.
Pour concevoir des API friendly, le haut niveau du langage et son expressivité sont là pour ça. Observe la lib de la GUI par exemple, elle est à mon sens beaucoup mieux pensée que ce qu'on peut trouver ailleurs.
Pour les tests, tu as les contrats.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je ne peu qu'encourager Benoit de parler à Alain Frish, mais il n'y a pas de volonté concertée à ma connaissance.
C'est simplement qu'on sans doute arrivé au bout des techniques de compilation syntaxiques.
De plus on a maintenant des machines sufisament pourvue en mémoire pour faire de l'analyse de flot.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bon, tu me gonfles :-)
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
Qu'en sais-tu ? Pour le moment, le compilateur crache du code légèrement mois rapide que du C, mais peut être que celui-ci sera plus rapide bientôt ?
Je crois beaucoup aux optimisations de gestion de la mémoire, à la réécriture de boucle, etc...
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Ce langage date de deux ans, et depuis deux ans son auteur a pas eu le temps de faire grand chose (post-doc, cours à la fac, etc...).
On débute ! On est pas SUN ni Microsoft ! Laisse nous le temps de lister, réfléchir à tout le travail qui doit être effectué à ce propos et de l'implémenter !
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
foreach est dans la lib à ma demande, de toutes façon, c'est une fonction qui prend 15 secondes à s'écrire. dans collection.
- foreach_do blk : BLOCK <-
(
1.to self.count do blc.value self;
);
Terminé.
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Je suis totalement d'accord avec toi, mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Je te signale que tu as un exemple de code plus haut bourré d'Inline en C...
Tu inline ton C dans le code tout simplement, et le compilateur le pose dans le fichier généré.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
C'est un de ses intérêts, mais pas le seul.
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
Chaque chose en son temps.
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
C'est vrai que les centres d'intérêts prioritaire de nicO transparaissent dans cette news.
Pour le reste on t'a expliqué ce que ça apporte (voire mon dernier post de tout à l'heure, tout en bas).
Pour l'objet à prototypes, je te renvoi en aux transparents sur le site, ainsi qu'au manuel d'utilisateur.
La différence entre le proto et la classe,c'est que le prototype est vivant à l'exécution et se clone, tandis que la classe s'instancie.
Cela signifie que lorsque tu dit B hérite de A. L'instance de B est objet unique, un mix de A et B. Tandis qu'en prototypes A et B restent deux objets indépendants, ils peuvent avoir une existance physique séparée en mémoire (Pagination, voir segmentation par objet avec pour chacun leur zones de code, de donnée et leur pile à eux).
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
De plus Lisaac permet de jouer avec les opérateurs '-','+','*' que tu met avant chaque slot, cela permet des subtilités très poussées dans le partage des variables entre enfants d'un parent, la possibilité d'embarquer des méthodes, comme en Java/C++/etc.. et plein de choses qui sont expliquées pas très clairement dans le manuel.
Un des gros challenge futur, c'est de faire ue doc pour expliquer tout ça, parce que c'est très puissant.
Je répond ici à plusieurs posts, de TImaniac en particulier, argumentant qu'un compilateur se doit de posséder des constructions lourdes (des if, des while, builtin la grammaire) pour bien optimiser.
J'ai demandé au maîître de m'expliquer pourquoi ce point de vue est plutôt faux.
Elle est fausse pour des primitives de bas niveau du genre if, while, traitement des nombres, etc...
Elle peut être vrai pour des primitives très haut niveau du genre "quel que soit x dans l'ensemble".
C'est faux pour les if, while car il arrive souvent que dans le code il y ait des if caché, de s while caché, etc...
Une résolution dynamique classique, peut, par envoi de message être un if caché.
Il est donc beaucoup plus intelligent de les rendre équivalent, et de les optimiser de la même façon.
Lorsqu'on optimise le while comme une récurcivité terminale, on optimise toutes les récurcivités terminales, on repère d'autres structures similaires qui n'auraient pas été vu.
Il faut bien voir que le compilateur Lisaac passe un certains temps à inliner tout ce qui est possible d'inliner, de par son algorithme d'analyse de flot, donc on retombe facilement sur des if, des while cachés, etc...
"Les optimisations ne sont plus liées à une syntaxe, mais à la sémantique du code...
C'est justement bien plus profond !"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Il est frai que je reconnais tout de suite le style... C'est émouvant ;-)
La section "ICQ flood" est caractéristiques. C'était l'époque où j'étais encore sous windows(95), que je reboutais à cahque soirée passée sur internet.
C'était l'époque où les comm' téléphonique étaient très cheres, je me suis battu à l'époque, au sein de l'Association Des Internautes Médiateurs, à l'ART, face aux industriels et principalement France Télécom, qui à l'époque (en tout cas leur dirigeants) étaient totalement paumés. Dès qu'on leur posait une question, ils répondaient "On ne sait pas...... (ils se regardaient entre eux), il faut qu'on en discutte en interne". Ils frainaient des quatre fers pour mettre en place l'ADSL, de peur de la VoIP, de peur de la grogne salariale, etc...
A propos de l'hilarant azerty0, je cherche les ex "links to trous", les tout premiers, les originaux, où un hacker listait tous les malheures du monde et pleurai "c'est pas possible, ça peut pas continuer comme ça".
C'était à pleurer de rire.
Cela fait 8 ans que je m'en veux de ne pas avoir aspiré la page à l'époque...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
On se place dans un contexte où l'on compile l'ensemble du code disponible. Le compilateur peut analyser l'ensemble de celui-ci et donc transformer ce code objet en un code procédural, c'est ce que fait Lisaac.
Tu peux aussi, avec le compilateur compiler des "macro-objets", c'est à dire que tu as un code procédural (un fichier C avec plein de fonctions dedans et un .h associé), et tu utiliseras (c'est le cas d'IsaacOS) de la liaison dynamique pour communiquer entre objet.
(Bien qu'on ai imaginé Benoit et moi un mécanisme tordu de table dichotomique à trou qui se rempliraient une fois les objets installés en mémoire...)
Prenons un exemple.
Soit une classe/prototype IMAGE et ses descendants BMP et JPG. Soit une méthode affiche_toi() définie comme virtuelle dans IMAGE, mais contenant du code dans BMP et IMG.
Soit image une variable de type BMP ou JPG.
1/Dans le monde à classe (Eiffel, donc), on effectue une analyse syntaxique (ou une analyse de flot) du code pour créer des procédure contextualisant le polymorphisme.
C'est à dire que le compilateur SmartEiffel va produire en C
BMP_affiche_toi()
JPG_affiche_toi()
et il colle un test du genre si besoin :
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Tandis qu'avec une VFT, image est un pointeur sur la structure :
(là imagine que C++ produise du C)
struct Image_jpg
{
//données
void *affiche_toi();
};
et
struct Image_bmp
{
//données
void *affiche_toi();
};
donc si la variable (l'instance dans le monde objet) image est de type BMP, on a
Image_bmp *image;
Et un appel de la fonction se fait
image->affiche_toi();
La compilation de l'Eiffel est pas trop problématique car c'est un langage à classe, donc ta variable image est soit de type BMP ou soit de type JPG. Il suffit de lire le code et d'appeler la bonne fonction.
Seulement ni C++ qui fait de la VFT, ni Eiffel qui fait du procédural ne produise que la fonction qui va être utilisée.
Même si tu as un code du genre
private BMP image;
image.set_image(mon_bitmap); //on lui balance le tableau d'octets
image.affiche_toi();
C++ va te pondre les deux structures décrites plus haut et va te faire un appel dans la VFT.
Eiffel, il me semble (je ne suis pas sûr) va faire de même, mais en procédural lui, donc sans vider le cache code du processeur, ce qui coute très cher et en pouvant faire des inlines, etc....
2/Dans le monde à prototype, le problème est beaucoup plus ardu parce tu as l'héritage dynamique.
Donc là tu renverse ton arbre d'héritage.
Tu vas avoir IMAGE qui va hériter, soit de JPG ou soit de BMP
Tu auras dans le code :
- name := IMAGE;
Section INHERIT
- parent choix : BOOLEAN : OBJECT <-
(
+ result : OBJECT;
choix.if {result := JPG;}
else
{result := BMP;};
result
);
Il suffit que tu en enchaine qq uns comme ça et ça explose vite...
Donc là on est obligé de faire de l'analyse de flot : il faut recencer le code vivant, autrement dit, calculer quels sont les possibilités que tu vas utiliser pour virer les autres.
Le compilateur recence donc le code vivant, spécialise les appels (s'ils se rend compte que tu n'utilise jamais BMP.affiche_toi; il ne la compile pas) et inline au besoin.
Mais je le répète, ce n'est possible que si le compilateur dispose de l'ensemble du code sous la main.
Sinon, tu es obligé de faire de la VFT ou de la table dichotomique à trou, c'est à dire à du code asm auto-écrit, et là ça part un peu en live.
Les contrats c'est pareil, ils sont compilés, backpropagés, etc...
Pour finir, je cite Benoit, dans un mail qu'il m'a écrit il y a un an et demi pour m'expliquer ça (et dont je me suis largement inspiré) :
"
Le pb est que C++ n' est pas capable d'analyser suffisemment son code pour
savoir si il y a un ou plusieurs type possible pour un site d'appel.
Consequence: Tous les appels sur les objets sont realise' par la technique
decrite en 4)[ie. la VFT]. Alors que, dans la pratique, il n' est pas rare que le type
soit unique et que donc, l'appel peut etre direct (statique).
Dans un langage comme C++, tout n' est pas objet, donc 2+2 n' est pas
un appel du type 2.plus(2) (le message "plus" sur l' objet 2) donc sa technique
reste lente mais viable. En Lisaac, 2+2 est un appel sur objet, si nous
utilisions la technique de C++, les perfs serait tout bonnement catastrophique!
Ici, le compilo detecte sans mal qu'il n'y a qu'un seul type dynamique
possible, l'appel est direct et statique sur la methode "plus" de NUMERIC.
Cette methode sera ensuite inline', et nous retomberons sur un 2+2 aussi
efficace que C.
Meme dans le cas de site reellement polymorphique (plusieurs type dynamique
possible), il est preferable de realiser des branchements avec des appels
statique.
Exemple:
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Les appels statiques ainsi produit peuvent ensuite etre inline', specialise',
... Et les caches du processeurs ne sont pas vide' (meme dans le cas de
multiple branchement, le pipeline execute les differentes branches en meme
temps et choisi les effets de bord de la bonne branche apres evaluation
de la conditionnelle).
Donc, la ou C++ realise un appel indirect (considere' comme liaison dynamique),
le compilo Lisaac produit ou un appel statique (84%) ou plusieurs branches
avec des appels statiques (16%).
Ce score est passe' a 91% en produisant des methodes plus specialise' selon
le contexte courant d'appel. Nous produisons plusieurs exemplaires d'une
methode. Chaque exemplaire etant specialise' a un contexte d'appel et donc
plus rapide (moins de types dynamiques possible dans ce contexte d'appel plus
precis)."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
* Ça fait plusieurs mois qu'on parle de la libération du compilo, qui n'est pas libre (officiellement) par crainte de la copie des algos par MS^Wune grosse entreprise quelconque. En résumé (corrige-moi si je me trompe) : suite à une discussion avec RMS, il a été envisagé de brevetter aux USA. Bon, ça en est où précisément ? Une date est envisagée ? Que pense Benoit Sonntag de l'hypotétique libération ? Quel avenir voit-il pour ce qui doit-être son "bébé" ? Au final, qui décide, lui ou l'INRIA ?
C'est l'INRIA qui décide, je ne me permettrai pas de commenter leur décision, où ce que j'ai cru comprendre qu'ils pensent.
Je crois que Pierre Jarillon s'est exprimé là dessus plus haut.
Benoit pense (et je pense) qu'il faut breveter la techno centrale du compilateur, libérer le compilateur et autoriser tout ceux qui feront du libre avec.
De toutes façon, le fait que la librairie du code soit en Cecill implique qu'on est obligé de faire du libre avec, à moins de réécrire celle-ci (bonne chance).
L'INRIA se financera (je suis pour que la recherche française, quelque fois, essaye de gagner de l'argent à condition qu'on laisse les chercheurs tranquille quand il veulent faire du fondamental) sur la vente de licence propriétaire, et éventuellement sur des droits du brevets.
Mais surtout sur la (les) start-up créé autour de la technologie : il y aura de toutes façons besoin d'une expertise qui se vendra très cher.
* Sur certains PDF, j'ai remarqué que ST Microelectronics est/était assez impliqué dans le projet. Il me semblait même avoir lu dans un document qu'une vente était prévue (mais je ne retrouve plus le pdf en question). Cela concerne uniquement IsaacOS ou Lisaac également ? Est-ce toujours d'actualité ? Que pensent-ils d'une libération ? D'un brevet ?
Benoit a effectué sa post-doc à ST. Il y a développé certains bouts de codes qui ne seront donc pas libérés.
Cependant, cela ne concerne ni l'OS, ni le compilateur.
* La libération de Lisaac est envisagée, et celle d'IsaacOS ? Je pense que serait un plus (mais certes pas le plus important). D'ailleurs d'après http://www.loria.fr/software/tous/logiciel?id=36 Isaac est libre, mais après lecture de la licence, ce n'est pas le cas (usage non commercial only, etc).
La libération du compilateur Lisaac est à la discretion de l'INRIA, tu peux leur poser la question concernant ce point.
Benoit a reçu, jusqu'à nouvel ordre, l'autorisation de libérer IsaacOS.
Il travaille d'arache pied à finir la récriture intégrale du compilateur v0.2
Il s'occupera ensuite de nettoyer IsaacOS afin d'en faire une distribution "propre".
Quand à moi, je vais m'occuper de commenter un peu le code et de rédiger e la doc.
J'espère avoir fini début mai.
Si je pose ces questions, c'est parce que Lisaac me semble plus que prometteur. Mais je doute que dans le paysage actuel , un langage de plus sortant de nulle-part, sans entreprise ni communauté derrière, réussise à s'imposer (aussi révolutionnaire fût-il). AMHA une libération ne serait pas du luxe, avec la création d'un groupe d'utilisateurs motivés pour développer les outils/modules/libs nécessaires, si vous voulez avoir un jour une chance de percer.
Je suis entièrement d'accord avec toi : Seul quelques entreprises ont à l'heure actuelle la capacité de vendre un langage propriétaire : Microsoft, éventuellement Sun, Borland, bien que j'y crois guère pour ces dernier.
Les coûts d'évangélisation sont énormes (il y a un marketeux pour 5 développeur à Microsoft) et le libre constitue un marketing gratuit que l'INRIA ne peut pas payer. De toutes façon cette organisation n'a pas les structures nécessaires.
Espérer diffuser Lisaac en tant que langage et compilateur non libre constitue de l'irréalisme totale et à mon sens une méconnaissance du marché de l'informatique qui n'a plus rien à voir avec ce qu'il était il y a encore 3 ans.
Le marché est dorénavent séparé entre deux acteurs : Microsoft et ses féaux, et le monde du Libre. Tout le monde, chinois compris, suit et subit cette situation.
Si IBM et consort se sont rangés derrière le libre, ce n'est pas par conversion à l'idéal communiste, mais par réalisme stratégique : ils ont compris que c'était leur seul moyen de s'en sortir et que la mutualisation des coûts de développement, les économies énormes en coûts de marketing sont une force très difficile à combattre, on commence à voir les fruits que cela rapporte.
De toutes façons, vendre un compilateur à l'heure actuel n'est plus du tout adapté au marché, ça l'était peut être encore il y a 10 ans, mais aujourd'hui, c'est une stratégie vouée à l'échec.
Par contre, vendre du service autour, du support pour les SSII, du dev de libs, de framework est un modèle qui pourrait être très rémunérateur.
J'espère qu'ils sauront le comprendre. Je pense qu'ils sont clairvoyants, il le comprendront donc, si ce n'est déjà fait.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
Boulot énorme !
Falloir que j'étudie Apache, faire un module, gérer les get/post, faire une grosse API pour générer du html (parce que mettre du HTML dans le source signifie modifier le compilateur, donc il faut que ce soit du Lisaac classique qui génère du HTML), faire un binding pour gérer une BDD (pas encore fait).
C'est une bonne idée parce que le serveur surement très bien la charge, mais j'ai peur du boulot que ça implique...
S'il y a des volontaires...
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
C'est une idée séduisante, mais j'entend d'ici la réponse de Benoit.
"Oui, mais comme le compilateur va chercher tout seul les objets... Je vois pas l'utilité"
Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl ou en Java.
Tu as un fichier path.li qui se trouve dans le répertoire $LISAAC, et celui-ci contient divers infos comme la liste des répertoire contenant les objets de la lib.
Après le compilateur se débrouille : si tu fait - a : OBJET_TOTO;
il ira chercher objet_toto.li tout seul.
Cela dit, c'est une idée intéressante pour une question de rangement et sur le CLAN, il faudra le ranger comme cela.
Réflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
Il faut savoir (voir manuel utiisateur sur le site) qu'en Lisaac tu as la possibilité d'aller un peu plus loin que le "protected" de c++.
Le protected correspond à toutes les méthodes défini dans la Section SELF
Evidemment c'est généralisable :
Tu peux si tu le désir définir du code dans une Section MACHIN, TRUC
qui implique que ton code écrit dans cette section sera accessible uniquement aux prototypes MACHIN, TRUC ainsi qu'à leur descendants.
Evidement avec un espace de nom, on peut imaginer d'aller plus loin, parce qu'espace de nom est différent de l'héritage. NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il y a des chances, mais il faudrait que ce ne soit pas obligatoire).
On pourrait donc imaginer de jouer avec cette histoire de section pour définir l'accessibilité des méthodes.
Mais ça risque de faire doublon.
Qu'en penses-tu ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Vu qu'il est aussi haut niveau que Java, C#, Eiffel, il peut être une alternative, mais là c'est plus une histoire de communauté, de librairie disponible, de framework et d'extensions du langage qu'on compte mettre dedans dans le futur.
La notation de Lisaac est fonction de sa spécification (on passe bientôt à la 0.2), effectivement on pourra mettre plein de features haut niveau dans les spécifs 0.3, 0.4, etc...
Voir https://linuxfr.org/~Montaigne/20582.html pour des exemples.
Mais effectivement, je pense que Lisaac sera un langage en grande partie destiné à l'embarqué, dans l'industrie, là ou ses performances seont vraiment utile. Parce que quand on voit la lenteur de Java et sa grande popularité on comprend que c'est un paramètre totalement secondaire.
Et puis pour faire marcher Lisaac dans l'info de gestion, il faut de la lib, des framework à la J2EE, des serveurs d'applications, etc...
Donc oui l'intérêt, est de remplacer C, pour C++, Java, on verra plus tard, si c'est possible.
Pour en revenir aux optims, je plussoie ce que tu répond à TImaniac et j'ajouterai que ça permet de l'avoir sans se tapper un code illisible puisque c'est le compilateur qui se tappe les réécriture fastidieuse, chiante et illisibles.
La devise qui prévaut à la conception du compilateur est : "Ne laissez jamais un humain faire le travail d'un programme"
;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai effectivement pour projet de monter un CLAN (Comprehensive Lisaac Archive Network). C'est d'ailleurs à toi que je dois cette idée, m'étant rendu compte à te lire que c'est effectivement indispensable.
Je pense l'écrire bientôt, quand j'aurai trouvé le temps (en php je pense).
Par contre je ne comprend pas de quoi tu parle avec ton histoire d' "espace de nom".
Pourrais-tu être plus explicite ?
Merci !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Un débat confus émerge, et nicO a abordé ce point sur la news. C'est un sujet important, en particulier pour lui qui nous bombarde d'excellentes idées pour optimiser le code.
Comment cela peut être possible ?
Premier point : Le minimalisme du code.
Le langage Lisaac est basé sur 7 primitives (elles sont définies dans le manuels, on les trouve aussi dans la librairie sous la forme `1`).
Ce nombre minimaliste permet au compilateur de travailler sur un code intermédiaire extrêment minimaliste et dépouillé.
C'est nécessaire pour réaliser l'ensemble des optimisations.
Second point : La suppression de la liaison dynamique
Je reprend ce que j'ai écrit sur Wikipedia : Les langages objets classiques, jusqu'à SmartEiffel, utilisent des VFTs (de l'anglais Virtual Function Table) pour compiler la liaison dynamique: :
Soient l'objet IMAGE, et ses deux descendants PNG et XCF. Quand on appelle la fonction PNG.affiche_toi() en Java ou en C++, on se retrouve en assembleur avec un appel du type :
L'adresse de PNG (l'objet receveur) pointe sur la base de la VFT, ensuite on ajoute le bon index pour recuperer le champs correspondant à la bonne methode...
Ce qui implique que cela vide le cache du processeur et que l'inlining est bloqué à la compilation.
Le compilateur lisaac supprime la liaison dynamique en analysant finement le type dynamique des objets grâce à un algorithme de prédiction de type. La liaison dynamique supprimée, il devient possible de procéder à des inlining et à des spécialisations de code.
Je devrai y rajouter que le polymorphisme se gère en utilisant une table duchotomique, ce qui implique que la recherche se fait en log de n.
Cela permet surtout d'avoir un code entièrement procédurale, sans dynamicité pour tuer les performances.
Troisième point : L'analyse de flot
Comme vous le savez pour la plupart d'entre vous, l'analyse de flot est une technique qui permet d'analyser le code (son graphe) pour y trouver diverses choses.
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
C'est un algo de complexité exponentielle, ce qui est risqué pour des programme de taille plus ample.
L'analyse de flot va par exemple permettre de détecter que l'on ait par exemple n := n*2+1; quelque part et que dans une autre méthode, "10 km plus loin" on fasse un (n mod 2).if
Dans ce cas le test est supprimé.
Ce n'est pas encore implémenté car trop gourmand en mémoire (4 Go pour 400 lignes hors librairie).
Pour le moment, le compilateur recence le code vivant, supprime toutes les étapes inutiles, supprime le code mort, spécialise les types.
L'analyse de flot permet, par reconnaissance de forme, de transformer des structures lourdes en structures légère.
Par exemple le message if, initialement, est écrit comme suit (en C):
if(id_obj) { /*V*/}
else
if (!id_obj) { /*F*/}
transformé en if (id_obj) { /*V*/} else { /*F*/}
de même les récurcivité terminale sont dérécurcivées.
Dans le futur, on peut pense à des techniques d'optimisation de la mémoire, pour se coller à la structure du cache, ou des techniques permettant de gérer automatiquement les threads, ou encore des techniques permettant de spécialiser des corps de calculs en fonction des données.
Ce dernier point vous sera mieux expliqué par nicO qui développe en ce moment ces idées.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est un point auquel j'ai réfléchi avec Benoit Sonntag, et je pense que l'on se dirige vers un interpréteur.
Pour le moment, il faut faire avec le -d (option du compilo)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est vrai que la norme et le standard est un problème fondamental, et le libre ne simplifie pas les choses...
Concernant la librairie, elle est très proche de Eiffel (elle en est tirée).
Je suis pour le moment un peu inquiet là dessus : quel mécanisme juridique peu permettre de garantir un standard ?
Quel mécanisme pour intégrer les bonnes idées et rejeter les autres. Je pense que ce sera son concepteur qui jouera ici le rôle de Linus.
Cela dit la lib n'est que du texte, ce ne sont pas des binaires, donc enlever, rajouter, interchanger n'est pas trop problématique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je comprend pas ce que tu veux dire.
En lisaac précisément, tu as un type STRING défini dans la librairie (comme les nombres, booléen, etc...) mais pas dans la grammaire et ceux-ci sont très simple à utiliser.
Mais effectivement, un langage sans string c'est galère.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
De même, avec les blocks (je te les mets entière) :
- while_do body:BLOCK <-
( //? {body!=NULL};
value.if {
body.value;
while_do body;
};
);
- do_while test:BLOCK <-
( //? {test!=NULL};
value;
test.value.if {
do_while test;
};
);
- until_do body:BLOCK <-
( // ? {body!=NULL};
(! value).if {
body.value;
until_do body;
};
);
- do_until test:BLOCK <-
( //? {test!=NULL};
value;
(! test.value).if {
do_until test;
};
);
Et si tu veux en inventer d'autres, tu peux. Tu n'est pas obligé de les implémenter dans la grammaire du langage.
Et cela en gardant les performances du C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
de faire un "méta" language qui génere du C "optimisé"
Non de faire un langage qui, au lieu de générer de l'asm, génère du C (très bas niveau le C). ou bien à terme d'avoir un compilo capable de généré du code exécutable pour toutes les archi
Je ne vois pas trop à quoi cela pourrait servir : les types qiu font tourner Gcc sur n architectures font très bien leur boulot. Pourquoi s'emm** à refaire la roue ?
ou bien carrément un langage supplémentaire de GCC (qui signifie rappelons le "GCC, the GNU Compiler Collection" )
Why not ? Il faudrait modifier le compilateur afin qu'il crache du langage intermédiaire. Mais l'intérêt est très moyen, vu qu'on peut utiliser le compilateur C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
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é à 2.
Je travaille sur un concept déclaratif s'inspirant de la méta-programmation.
Ca va plus loin que la définition d'un mini langage : c'est de la reconnaissance de forme.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: One size fits all
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é à 5.
Lisaac a été pensé pour ne plus avoir besoin de faire du C.
D'ailleurs, un Système d'exploitation entier a été écrit avec. Il tient en 30 000 lignes, interfaces graphique comprise. Il est intégralement objet et fonctionnel. Tu trouveras sur le site une démo tournant sous linux ou tu pourras évaluer l'empreinte mémoire.
Lisaac est doté de mécanismes permettant de se passer de C. Tu trouveras la doc sur le site, mais j'évocquerai ici :
- La section INTERUPT qui permet de définir des interuptions, le code étant compilé en conséquence.
- La section MAPPING qui permet de définir une structure de données ordonné, se posant sur le binaire
- Des perfs et une consommation mémoire similaire au C.
Benoit Sonntag, le concepteur de Lisaac a 400 000 lignes de C à son actif, et un peu plus en assembleur x86.
C'est dire s'il a fait le tour de la question.
Décidé d'en finir une bonne fois pour toute avec l'obligation de passer par ce langage pour le bas niveau, il a fait Lisaac.
Il a la prétention de penser que Lisaac est fait pour rendre (théoriquement parlant) le C comme un langage dépassé, bien qu'exceptionnel.
J'ai la flemme de répondre sur tes idées sur le framework qui sont très intéressantes et que j'irai relire de temps en temps, mais ça fait quasiment une semaine que je ma bat ici, je fatigue :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
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é à 2.
Non là tu ne peux pas dire ça.
La grammaire est certes minimaliste. Connaissant benoit, je dirai que c'est une approche philosophique qu'il affectionne (et moi qui ne le suis pas du tout, je me rend compte qu'en fait c'est mieux : les axiomatiques trop grosses, c'est jamais bon).
La grammaire de Lisaac a été très pensée, et on s'y habitue assez vite. De fait on l'apprend très vite (quelques heures), c'est quelques choses que j'apprécie beaucoup.
Moi aussi au début, j'ai gueulé contre les types en majuscules, parce que Shift à chaque fois, c'est lourd.
Je crois que la solution, c'est un emcas ou autre qui te le met automatiquement en majuscule.
Moi aussi au début j'ai gueulé contre l'interdiction de majuscules dans les variables, qui me permettaient de faire des phrases dans mes variables (je fais souvent des variables avec des noms interminables).
J'ai reprogrammé en Java, et j'ai passé un temps fou zsur des erreurs du type "ah erde, là ya un majuscule pour la 2ème lettre" et je me suis rendu compte que c'est galère.
Par contre j'adore les mots clés. Ca fait des phrases.
Comme il parait que j'aime spéculer ;o)) L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
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é à 2.
- size noeud:LINK[E] :INTEGER <-
( + result:INTEGER;
(noeud = NULL).if {
result := 0;
} else {
result := 1 + size (noeud.next);
};
result
);
Mais de toutes façons ça sert à rien, car il y a l'attribut count dans les listes...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
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é à 2.
(1) A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
Est-ce que qqu'un a comparé ces deux langages ?
Pas à ma connaissance. Personnelement, je ne connais rien à ce langage.
Serait-il possible de mettre en oeuvre les optimisations de Lissac pour d'autres langages ?
Je m'étonne qu'il y ait fallu quasiment une semaine pour que quelqu'un pense enfin à poser la question.
Je pense que, sauf les fonctionalitées comme la réflexivité, etc... on pourrait tout à fait utiliser le compilateur Lisaac pour compiler du Java, du C++ (beuurk), d'autres.
Il faudrai pour cela pas mal retravailler l'objet PARSER pour lui faire bouffer la syntaxe.
J'ai un peu peur duand à la gestion des mots clé, qui sont énormes dans ces langages.
Ca serait un gros parser, mais ça passerai.
Ce qui serait marrant, c'est du Java aussi rapide que du C....
(3) Ruby connait un grand enthousiasme en ce moment via (a) le framework Ruby On Rails pour la programmation web et (b) comme candidat pour fabriquer facilement des DSL (via la métaprogrammation ?).
Si Lissac, via la compilation, enfonce Ruby (dont le coté dynamique a l'air d'avoir un cout), et supporte des fonctionnalités analogues à celles de Ruby, Lissac pourrait aussi être positionné sur les mêmes créneaux (a) et (b).
Cela a-t-il été envisagé ?
Peut être pas sous cet angle, et que par moi (les délires sur les langages du futur, c'est ma spécialité)
Mais je v étudier la question, le titre "Creating a weblog in 15 minutes" est assez bandant.
Si t'as des idées là dessus, tu es le bienvenu, les discussions sur les spécifications 0.3 et surtout 0.4 de Lisaac sont ouvertes (la 0.2 est en train d'être implémentée).
Fais moi signe ;)
(4) Lissac supporte-il le polymorphisme à la Caml ?
par exemple, en Caml, on peut écrire une fonction telle que (j'écris de mémoire) :
let rec size list = match list with
[] -> 0
| head::tail -> (size tail) + 1
et cette fonction est typé comme ['a] -> int : elle peut opérer sur des listes de n'importe quoi.
A vue de nez, ça donnerai
- size lst :LINKED_LIST[E] : INTEGER <-
(
+ result : INTEGER;
+ tmp : LINKED_LIST[E];
(lst.count <1).if {result :=0} else
{
lst.remove_first;
result := (size lst) +1;
}
result
);
Bon là je me rend compte, que j'en ai marre, je veux une fonction tail et une fonction head dans les collections.
- size lst :LINKED_LIST[E] : INTEGER <-
(
+ result : INTEGER;
+ tmp : LINKED_LIST[E];
(lst.count <1).if { result :=0;
} else { result := (size lst.tail) +1; };
result
);
C'est mieux
Ya encore du progrès à faire.
La futur version 0.2 qui sort bientôt te permettra de rendre plusieurs valeurs, comme caml, donc de faire du vrai fonctionnel.
public SortedMap<ArrayList<MBeanServerInvocationHandler>> getFoo() {
SortedMap<ArrayList<MBeanServerInvocationHandler>> foo =
new SortedMap<ArrayList<MBeanServerInvocationHandler>>();
foo.doSomething();
return foo;
}
Oui effectivement...
Section PUBLIC
- get_foo lst : SORTED_MAP[ARRAY[MBEAN] <-
(
+ foo : SORTED_MAP[ARRAY[MBEAN] := SORTED_MAP[ARRAY[MBEAN].create;
foo.do_something;
foo
}
(5) en Caml, on peut aussi faire du pattern matching, une sorte de switch, comme en C, mais amélioré car pouvant porter sur des types de données qui ne sont pas limités au type 'int'.
Est-ce possible via Lissac ?
Merci de vos éclaircissements.
Non, mais moi j'aimerai bien.
Alors comme il se trouve que Xavier Leroy et Benoit Sonntag se connaissent, j'aimerai bien que ce soit implémenté dans le compilo.
Ca va venir, je pense.
Cela dit, je pense qu'il est implémentable dans la lib un truc similaire mais un moins puissant.
Faudrait y réfléchir.
Tu me donnes une idée, merci :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
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é à 2.
C'est un pattern matching : dès qu'il en détecte une il la dérécurcive.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
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é à 2.
Alors ça c'est dingue !!! C'est précisément l'idée qu'on a eu avec Benoit l'autre jour. Je crois que c'est parti d'une remarque de nicO au SL2006 et on est arrivé à la conlusion qu'il fallait faire un type LIST général qui hérite dynamiquement de toutes les collections existantes (FIXED_ARRAY, LINKED_LIST, etc...). On ajoute un mot clé pour que le codeur puisse dire au compilateur de choisir lui même le parent en fonction de ce qu'il y a dans le code.
Par analyse de flot, le compilateur calcule le temps d'exécution dans le pire des cas de chaque branche et choisi la meilleur.
Dans le même genre, niveau langage, certains pensent (genre MS) qu'on va de plus en plus vers des langages spécialisés, dans lequel le spécialiste du domaine (plus forcément un informaticien spécialiste) peut exprimer ce qu'il veut, et laisser faire le boulot à des algos spécialisé, le travail de l'informaticien ce recentrant sur la conception des langages et des algos spécialisés.
Je ne savais pas qu'MS en arrivait là, mais j'en arrive aussi à la même conclusion. Suite à mes réflexions (voir mes articles), j'en arrive qu'il faut (liste non exhaustive):
- Un langage de manipulation de données ensembliste, genre Cduce, mais en plus haut et orienté langage naturel avec des idées de prolog.
- Des fonctionnalitées agent
- Du pattern matching, encore du pattern matching !
- La possibilité de définir une sémantique grammaticalisé avec les règles associées facilement.
C'est encore très flou, mais le concept "un paradigme pour tout faire", j'y crois plus.
Il faut que les langages ne se contentent plus de définir des graphes de code et il faut arrêter avec les grammaires dures (genre il manque un ';' donc ça compile pas).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par Ontologia (site web personnel) . En réponse au journal Comment virer quelqu'un quand on veut.. Évalué à 2.
« 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é à 4.
Ce n'est pas parce que l'implémentation d'un concept à un instant T est moins performante, que ce concept est invalide. Ce n'est pas une condition nécessaire, tu n'as rien prouvé là.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
La librairie est en libre (Cecill), si quelqu'un a une primitive intéressante, on l'intègre.
Pour le reste, s'il y a au moins 1% de codeur qui toucheront à Boolean.li, je serai très étonné.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
C'est hors de question. Le compilateur restera hyper minimaliste, comme je l'ai expliqué en bas, ça permet de se concentrer sur la sémantique du code. de plus, comme on te l'a expliqué ailleurs, cela permet de faire un compilo plus propre, donc moins de bug, etc...
Seront rajoutées des primitives lorsqu'on tombera sur du très haut niveau, genre le SQL intégré ou des primitives très haut niveau comme "qqsoit x de l'ensemble".
>Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il >manque quelque confort pour la chose c'est un détail qui se règle en quelques heures >au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
Il y a une ML pour le projet, tu as le droit de contribuer.
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" :
http://www.artima.com/intv/nonvirtual.html
Envoi un mail à Benoit, je ne me sens pas assez qualifié pour répondre à ça.
[héritage dynamique, prototype]Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
C'est à toi de répodnre à cette question lorsque tu designe une application.
Premièrement, cela apporte que la structure objet que tu codes, restera la même à l'exécution, ce qui n'est pas le cas avec l'objet à classe. Une classe n'est qu'un moule, il faut l'instancier pour qu'elle devienne vivante, tandis qu'un prototype est vivant dès le début.
Deuxièmement, l'héritage dynamique te permet de simplifier considérablement l'arbre d'héritage.
On met beaucoup de temps à comprendre l'intérêt de ces possibilités. Même son auteur a mis beaucoup de temps à utiliser l'héritage dynamique dans son langage. Le compilo actuel n'en n'utilise pas, le futur qui sortira bientôt, l'utilise massivement.
C'est en designant ton appli que tu en vois l'intérêt.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
Pour résoudre les bugs, ya pas de debugger mais ça viendra.
intégrer le code à l'existant, c'est dors et déjà possible, on va travailler à améliorer la cosmétique.
Pour la doc, un générateur de Doc, un peu dans le style de Javadoc sera intégré dans la prochaine version du compilateur.
Pour concevoir des API friendly, le haut niveau du langage et son expressivité sont là pour ça. Observe la lib de la GUI par exemple, elle est à mon sens beaucoup mieux pensée que ce qu'on peut trouver ailleurs.
Pour les tests, tu as les contrats.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
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é à 2.
C'est simplement qu'on sans doute arrivé au bout des techniques de compilation syntaxiques.
De plus on a maintenant des machines sufisament pourvue en mémoire pour faire de l'analyse de flot.
« 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é à 4.
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
Qu'en sais-tu ? Pour le moment, le compilateur crache du code légèrement mois rapide que du C, mais peut être que celui-ci sera plus rapide bientôt ?
Je crois beaucoup aux optimisations de gestion de la mémoire, à la réécriture de boucle, etc...
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Ce langage date de deux ans, et depuis deux ans son auteur a pas eu le temps de faire grand chose (post-doc, cours à la fac, etc...).
On débute ! On est pas SUN ni Microsoft ! Laisse nous le temps de lister, réfléchir à tout le travail qui doit être effectué à ce propos et de l'implémenter !
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
foreach est dans la lib à ma demande, de toutes façon, c'est une fonction qui prend 15 secondes à s'écrire. dans collection.
- foreach_do blk : BLOCK <-
(
1.to self.count do blc.value self;
);
Terminé.
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Je suis totalement d'accord avec toi, mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Je te signale que tu as un exemple de code plus haut bourré d'Inline en C...
Tu inline ton C dans le code tout simplement, et le compilateur le pose dans le fichier généré.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
C'est un de ses intérêts, mais pas le seul.
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
Chaque chose en son temps.
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
C'est vrai que les centres d'intérêts prioritaire de nicO transparaissent dans cette news.
Pour le reste on t'a expliqué ce que ça apporte (voire mon dernier post de tout à l'heure, tout en bas).
Pour l'objet à prototypes, je te renvoi en aux transparents sur le site, ainsi qu'au manuel d'utilisateur.
La différence entre le proto et la classe,c'est que le prototype est vivant à l'exécution et se clone, tandis que la classe s'instancie.
Cela signifie que lorsque tu dit B hérite de A. L'instance de B est objet unique, un mix de A et B. Tandis qu'en prototypes A et B restent deux objets indépendants, ils peuvent avoir une existance physique séparée en mémoire (Pagination, voir segmentation par objet avec pour chacun leur zones de code, de donnée et leur pile à eux).
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
De plus Lisaac permet de jouer avec les opérateurs '-','+','*' que tu met avant chaque slot, cela permet des subtilités très poussées dans le partage des variables entre enfants d'un parent, la possibilité d'embarquer des méthodes, comme en Java/C++/etc.. et plein de choses qui sont expliquées pas très clairement dans le manuel.
Un des gros challenge futur, c'est de faire ue doc pour expliquer tout ça, parce que c'est très puissant.
Encore une fois, je te renvoi au manuel http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Tu auras quelques explications ici http://isaacos.loria.fr/download/lisaac_overview.zip
Et la grammaire est là : http://isaacos.loria.fr/li_docs.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Optimiser un langage minimaliste cai mieux..
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é à 2.
J'ai demandé au maîître de m'expliquer pourquoi ce point de vue est plutôt faux.
Elle est fausse pour des primitives de bas niveau du genre if, while, traitement des nombres, etc...
Elle peut être vrai pour des primitives très haut niveau du genre "quel que soit x dans l'ensemble".
C'est faux pour les if, while car il arrive souvent que dans le code il y ait des if caché, de s while caché, etc...
Une résolution dynamique classique, peut, par envoi de message être un if caché.
Il est donc beaucoup plus intelligent de les rendre équivalent, et de les optimiser de la même façon.
Lorsqu'on optimise le while comme une récurcivité terminale, on optimise toutes les récurcivités terminales, on repère d'autres structures similaires qui n'auraient pas été vu.
Il faut bien voir que le compilateur Lisaac passe un certains temps à inliner tout ce qui est possible d'inliner, de par son algorithme d'analyse de flot, donc on retombe facilement sur des if, des while cachés, etc...
"Les optimisations ne sont plus liées à une syntaxe, mais à la sémantique du code...
C'est justement bien plus profond !"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Nostalgie...
Posté par Ontologia (site web personnel) . En réponse au journal (inutile )Souvenir du vieux net. Évalué à 3.
La section "ICQ flood" est caractéristiques. C'était l'époque où j'étais encore sous windows(95), que je reboutais à cahque soirée passée sur internet.
C'était l'époque où les comm' téléphonique étaient très cheres, je me suis battu à l'époque, au sein de l'Association Des Internautes Médiateurs, à l'ART, face aux industriels et principalement France Télécom, qui à l'époque (en tout cas leur dirigeants) étaient totalement paumés. Dès qu'on leur posait une question, ils répondaient "On ne sait pas...... (ils se regardaient entre eux), il faut qu'on en discutte en interne". Ils frainaient des quatre fers pour mettre en place l'ADSL, de peur de la VoIP, de peur de la grogne salariale, etc...
A propos de l'hilarant azerty0, je cherche les ex "links to trous", les tout premiers, les originaux, où un hacker listait tous les malheures du monde et pleurai "c'est pas possible, ça peut pas continuer comme ça".
C'était à pleurer de rire.
Cela fait 8 ans que je m'en veux de ne pas avoir aspiré la page à l'époque...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Supprimer la VFT
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é à 4.
Tu peux aussi, avec le compilateur compiler des "macro-objets", c'est à dire que tu as un code procédural (un fichier C avec plein de fonctions dedans et un .h associé), et tu utiliseras (c'est le cas d'IsaacOS) de la liaison dynamique pour communiquer entre objet.
(Bien qu'on ai imaginé Benoit et moi un mécanisme tordu de table dichotomique à trou qui se rempliraient une fois les objets installés en mémoire...)
Prenons un exemple.
Soit une classe/prototype IMAGE et ses descendants BMP et JPG. Soit une méthode affiche_toi() définie comme virtuelle dans IMAGE, mais contenant du code dans BMP et IMG.
Soit image une variable de type BMP ou JPG.
1/Dans le monde à classe (Eiffel, donc), on effectue une analyse syntaxique (ou une analyse de flot) du code pour créer des procédure contextualisant le polymorphisme.
C'est à dire que le compilateur SmartEiffel va produire en C
BMP_affiche_toi()
JPG_affiche_toi()
et il colle un test du genre si besoin :
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Tandis qu'avec une VFT, image est un pointeur sur la structure :
(là imagine que C++ produise du C)
struct Image_jpg
{
//données
void *affiche_toi();
};
et
struct Image_bmp
{
//données
void *affiche_toi();
};
donc si la variable (l'instance dans le monde objet) image est de type BMP, on a
Image_bmp *image;
Et un appel de la fonction se fait
image->affiche_toi();
La compilation de l'Eiffel est pas trop problématique car c'est un langage à classe, donc ta variable image est soit de type BMP ou soit de type JPG. Il suffit de lire le code et d'appeler la bonne fonction.
Seulement ni C++ qui fait de la VFT, ni Eiffel qui fait du procédural ne produise que la fonction qui va être utilisée.
Même si tu as un code du genre
private BMP image;
image.set_image(mon_bitmap); //on lui balance le tableau d'octets
image.affiche_toi();
C++ va te pondre les deux structures décrites plus haut et va te faire un appel dans la VFT.
Eiffel, il me semble (je ne suis pas sûr) va faire de même, mais en procédural lui, donc sans vider le cache code du processeur, ce qui coute très cher et en pouvant faire des inlines, etc....
2/Dans le monde à prototype, le problème est beaucoup plus ardu parce tu as l'héritage dynamique.
Donc là tu renverse ton arbre d'héritage.
Tu vas avoir IMAGE qui va hériter, soit de JPG ou soit de BMP
Tu auras dans le code :
- name := IMAGE;
Section INHERIT
- parent choix : BOOLEAN : OBJECT <-
(
+ result : OBJECT;
choix.if {result := JPG;}
else
{result := BMP;};
result
);
Il suffit que tu en enchaine qq uns comme ça et ça explose vite...
Donc là on est obligé de faire de l'analyse de flot : il faut recencer le code vivant, autrement dit, calculer quels sont les possibilités que tu vas utiliser pour virer les autres.
Le compilateur recence donc le code vivant, spécialise les appels (s'ils se rend compte que tu n'utilise jamais BMP.affiche_toi; il ne la compile pas) et inline au besoin.
Mais je le répète, ce n'est possible que si le compilateur dispose de l'ensemble du code sous la main.
Sinon, tu es obligé de faire de la VFT ou de la table dichotomique à trou, c'est à dire à du code asm auto-écrit, et là ça part un peu en live.
Les contrats c'est pareil, ils sont compilés, backpropagés, etc...
Pour finir, je cite Benoit, dans un mail qu'il m'a écrit il y a un an et demi pour m'expliquer ça (et dont je me suis largement inspiré) :
"
Le pb est que C++ n' est pas capable d'analyser suffisemment son code pour
savoir si il y a un ou plusieurs type possible pour un site d'appel.
Consequence: Tous les appels sur les objets sont realise' par la technique
decrite en 4)[ie. la VFT]. Alors que, dans la pratique, il n' est pas rare que le type
soit unique et que donc, l'appel peut etre direct (statique).
Dans un langage comme C++, tout n' est pas objet, donc 2+2 n' est pas
un appel du type 2.plus(2) (le message "plus" sur l' objet 2) donc sa technique
reste lente mais viable. En Lisaac, 2+2 est un appel sur objet, si nous
utilisions la technique de C++, les perfs serait tout bonnement catastrophique!
Ici, le compilo detecte sans mal qu'il n'y a qu'un seul type dynamique
possible, l'appel est direct et statique sur la methode "plus" de NUMERIC.
Cette methode sera ensuite inline', et nous retomberons sur un 2+2 aussi
efficace que C.
Meme dans le cas de site reellement polymorphique (plusieurs type dynamique
possible), il est preferable de realiser des branchements avec des appels
statique.
Exemple:
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Les appels statiques ainsi produit peuvent ensuite etre inline', specialise',
... Et les caches du processeurs ne sont pas vide' (meme dans le cas de
multiple branchement, le pipeline execute les differentes branches en meme
temps et choisi les effets de bord de la bonne branche apres evaluation
de la conditionnelle).
Donc, la ou C++ realise un appel indirect (considere' comme liaison dynamique),
le compilo Lisaac produit ou un appel statique (84%) ou plusieurs branches
avec des appels statiques (16%).
Ce score est passe' a 91% en produisant des methodes plus specialise' selon
le contexte courant d'appel. Nous produisons plusieurs exemplaires d'une
methode. Chaque exemplaire etant specialise' a un contexte d'appel et donc
plus rapide (moins de types dynamiques possible dans ce contexte d'appel plus
precis)."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu de transparence
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é à 3.
C'est l'INRIA qui décide, je ne me permettrai pas de commenter leur décision, où ce que j'ai cru comprendre qu'ils pensent.
Je crois que Pierre Jarillon s'est exprimé là dessus plus haut.
Benoit pense (et je pense) qu'il faut breveter la techno centrale du compilateur, libérer le compilateur et autoriser tout ceux qui feront du libre avec.
De toutes façon, le fait que la librairie du code soit en Cecill implique qu'on est obligé de faire du libre avec, à moins de réécrire celle-ci (bonne chance).
L'INRIA se financera (je suis pour que la recherche française, quelque fois, essaye de gagner de l'argent à condition qu'on laisse les chercheurs tranquille quand il veulent faire du fondamental) sur la vente de licence propriétaire, et éventuellement sur des droits du brevets.
Mais surtout sur la (les) start-up créé autour de la technologie : il y aura de toutes façons besoin d'une expertise qui se vendra très cher.
* Sur certains PDF, j'ai remarqué que ST Microelectronics est/était assez impliqué dans le projet. Il me semblait même avoir lu dans un document qu'une vente était prévue (mais je ne retrouve plus le pdf en question). Cela concerne uniquement IsaacOS ou Lisaac également ? Est-ce toujours d'actualité ? Que pensent-ils d'une libération ? D'un brevet ?
Benoit a effectué sa post-doc à ST. Il y a développé certains bouts de codes qui ne seront donc pas libérés.
Cependant, cela ne concerne ni l'OS, ni le compilateur.
* La libération de Lisaac est envisagée, et celle d'IsaacOS ? Je pense que serait un plus (mais certes pas le plus important). D'ailleurs d'après http://www.loria.fr/software/tous/logiciel?id=36 Isaac est libre, mais après lecture de la licence, ce n'est pas le cas (usage non commercial only, etc).
La libération du compilateur Lisaac est à la discretion de l'INRIA, tu peux leur poser la question concernant ce point.
Benoit a reçu, jusqu'à nouvel ordre, l'autorisation de libérer IsaacOS.
Il travaille d'arache pied à finir la récriture intégrale du compilateur v0.2
Il s'occupera ensuite de nettoyer IsaacOS afin d'en faire une distribution "propre".
Quand à moi, je vais m'occuper de commenter un peu le code et de rédiger e la doc.
J'espère avoir fini début mai.
Si je pose ces questions, c'est parce que Lisaac me semble plus que prometteur. Mais je doute que dans le paysage actuel , un langage de plus sortant de nulle-part, sans entreprise ni communauté derrière, réussise à s'imposer (aussi révolutionnaire fût-il). AMHA une libération ne serait pas du luxe, avec la création d'un groupe d'utilisateurs motivés pour développer les outils/modules/libs nécessaires, si vous voulez avoir un jour une chance de percer.
Je suis entièrement d'accord avec toi : Seul quelques entreprises ont à l'heure actuelle la capacité de vendre un langage propriétaire : Microsoft, éventuellement Sun, Borland, bien que j'y crois guère pour ces dernier.
Les coûts d'évangélisation sont énormes (il y a un marketeux pour 5 développeur à Microsoft) et le libre constitue un marketing gratuit que l'INRIA ne peut pas payer. De toutes façon cette organisation n'a pas les structures nécessaires.
Espérer diffuser Lisaac en tant que langage et compilateur non libre constitue de l'irréalisme totale et à mon sens une méconnaissance du marché de l'informatique qui n'a plus rien à voir avec ce qu'il était il y a encore 3 ans.
Le marché est dorénavent séparé entre deux acteurs : Microsoft et ses féaux, et le monde du Libre. Tout le monde, chinois compris, suit et subit cette situation.
Si IBM et consort se sont rangés derrière le libre, ce n'est pas par conversion à l'idéal communiste, mais par réalisme stratégique : ils ont compris que c'était leur seul moyen de s'en sortir et que la mutualisation des coûts de développement, les économies énormes en coûts de marketing sont une force très difficile à combattre, on commence à voir les fruits que cela rapporte.
De toutes façons, vendre un compilateur à l'heure actuel n'est plus du tout adapté au marché, ça l'était peut être encore il y a 10 ans, mais aujourd'hui, c'est une stratégie vouée à l'échec.
Par contre, vendre du service autour, du support pour les SSII, du dev de libs, de framework est un modèle qui pourrait être très rémunérateur.
J'espère qu'ils sauront le comprendre. Je pense qu'ils sont clairvoyants, il le comprendront donc, si ce n'est déjà fait.
« 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.
https://linuxfr.org/comments/673971,1.html
là
https://linuxfr.org/comments/674008,1.html
et un peu partout autour...
« 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é à 2.
Boulot énorme !
Falloir que j'étudie Apache, faire un module, gérer les get/post, faire une grosse API pour générer du html (parce que mettre du HTML dans le source signifie modifier le compilateur, donc il faut que ce soit du Lisaac classique qui génère du HTML), faire un binding pour gérer une BDD (pas encore fait).
C'est une bonne idée parce que le serveur surement très bien la charge, mais j'ai peur du boulot que ça implique...
S'il y a des volontaires...
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
C'est une idée séduisante, mais j'entend d'ici la réponse de Benoit.
"Oui, mais comme le compilateur va chercher tout seul les objets... Je vois pas l'utilité"
Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl ou en Java.
Tu as un fichier path.li qui se trouve dans le répertoire $LISAAC, et celui-ci contient divers infos comme la liste des répertoire contenant les objets de la lib.
Après le compilateur se débrouille : si tu fait - a : OBJET_TOTO;
il ira chercher objet_toto.li tout seul.
Cela dit, c'est une idée intéressante pour une question de rangement et sur le CLAN, il faudra le ranger comme cela.
Réflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
Il faut savoir (voir manuel utiisateur sur le site) qu'en Lisaac tu as la possibilité d'aller un peu plus loin que le "protected" de c++.
Le protected correspond à toutes les méthodes défini dans la
Section SELF
Evidemment c'est généralisable :
Tu peux si tu le désir définir du code dans une
Section MACHIN, TRUC
qui implique que ton code écrit dans cette section sera accessible uniquement aux prototypes MACHIN, TRUC ainsi qu'à leur descendants.
Evidement avec un espace de nom, on peut imaginer d'aller plus loin, parce qu'espace de nom est différent de l'héritage.
NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il y a des chances, mais il faudrait que ce ne soit pas obligatoire).
On pourrait donc imaginer de jouer avec cette histoire de section pour définir l'accessibilité des méthodes.
Mais ça risque de faire doublon.
Qu'en penses-tu ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
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é à 2.
La notation de Lisaac est fonction de sa spécification (on passe bientôt à la 0.2), effectivement on pourra mettre plein de features haut niveau dans les spécifs 0.3, 0.4, etc...
Voir https://linuxfr.org/~Montaigne/20582.html pour des exemples.
Mais effectivement, je pense que Lisaac sera un langage en grande partie destiné à l'embarqué, dans l'industrie, là ou ses performances seont vraiment utile. Parce que quand on voit la lenteur de Java et sa grande popularité on comprend que c'est un paramètre totalement secondaire.
Et puis pour faire marcher Lisaac dans l'info de gestion, il faut de la lib, des framework à la J2EE, des serveurs d'applications, etc...
Donc oui l'intérêt, est de remplacer C, pour C++, Java, on verra plus tard, si c'est possible.
Pour en revenir aux optims, je plussoie ce que tu répond à TImaniac et j'ajouterai que ça permet de l'avoir sans se tapper un code illisible puisque c'est le compilateur qui se tappe les réécriture fastidieuse, chiante et illisibles.
La devise qui prévaut à la conception du compilateur est :
"Ne laissez jamais un humain faire le travail d'un programme"
;-)
« 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é à 4.
Je pense l'écrire bientôt, quand j'aurai trouvé le temps (en php je pense).
Par contre je ne comprend pas de quoi tu parle avec ton histoire d' "espace de nom".
Pourrais-tu être plus explicite ?
Merci !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Comment faire un langage plus rapide que C ?
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é à 6.
Comment cela peut être possible ?
Premier point : Le minimalisme du code.
Le langage Lisaac est basé sur 7 primitives (elles sont définies dans le manuels, on les trouve aussi dans la librairie sous la forme `1`).
Ce nombre minimaliste permet au compilateur de travailler sur un code intermédiaire extrêment minimaliste et dépouillé.
C'est nécessaire pour réaliser l'ensemble des optimisations.
Second point : La suppression de la liaison dynamique
Je reprend ce que j'ai écrit sur Wikipedia :
Les langages objets classiques, jusqu'à SmartEiffel, utilisent des VFTs (de l'anglais Virtual Function Table) pour compiler la liaison dynamique: :
Soient l'objet IMAGE, et ses deux descendants PNG et XCF. Quand on appelle la fonction PNG.affiche_toi() en Java ou en C++, on se retrouve en assembleur avec un appel du type :
Call dword ptr [__adresse_de_PNG + index_dans la_VFT_de_la_fonction_affiche_toi()]
L'adresse de PNG (l'objet receveur) pointe sur la base de la VFT, ensuite on ajoute le bon index pour recuperer le champs correspondant à la bonne methode...
Ce qui implique que cela vide le cache du processeur et que l'inlining est bloqué à la compilation.
Le compilateur lisaac supprime la liaison dynamique en analysant finement le type dynamique des objets grâce à un algorithme de prédiction de type. La liaison dynamique supprimée, il devient possible de procéder à des inlining et à des spécialisations de code.
Je devrai y rajouter que le polymorphisme se gère en utilisant une table duchotomique, ce qui implique que la recherche se fait en log de n.
Cela permet surtout d'avoir un code entièrement procédurale, sans dynamicité pour tuer les performances.
Troisième point : L'analyse de flot
Comme vous le savez pour la plupart d'entre vous, l'analyse de flot est une technique qui permet d'analyser le code (son graphe) pour y trouver diverses choses.
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
C'est un algo de complexité exponentielle, ce qui est risqué pour des programme de taille plus ample.
L'analyse de flot va par exemple permettre de détecter que l'on ait par exemple n := n*2+1; quelque part et que dans une autre méthode, "10 km plus loin" on fasse un (n mod 2).if
Dans ce cas le test est supprimé.
Ce n'est pas encore implémenté car trop gourmand en mémoire (4 Go pour 400 lignes hors librairie).
Pour le moment, le compilateur recence le code vivant, supprime toutes les étapes inutiles, supprime le code mort, spécialise les types.
L'analyse de flot permet, par reconnaissance de forme, de transformer des structures lourdes en structures légère.
Par exemple le message if, initialement, est écrit comme suit (en C):
if(id_obj) { /*V*/}
else
if (!id_obj) { /*F*/}
transformé en if (id_obj) { /*V*/} else { /*F*/}
de même les récurcivité terminale sont dérécurcivées.
Dans le futur, on peut pense à des techniques d'optimisation de la mémoire, pour se coller à la structure du cache, ou des techniques permettant de gérer automatiquement les threads, ou encore des techniques permettant de spécialiser des corps de calculs en fonction des données.
Ce dernier point vous sera mieux expliqué par nicO qui développe en ce moment ces idées.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Portable ?!?
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é à 2.
Pour le moment, il faut faire avec le -d (option du compilo)
« 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é à 2.
Concernant la librairie, elle est très proche de Eiffel (elle en est tirée).
Je suis pour le moment un peu inquiet là dessus : quel mécanisme juridique peu permettre de garantir un standard ?
Quel mécanisme pour intégrer les bonnes idées et rejeter les autres. Je pense que ce sera son concepteur qui jouera ici le rôle de Linus.
Cela dit la lib n'est que du texte, ce ne sont pas des binaires, donc enlever, rajouter, interchanger n'est pas trop problématique.
« 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é à 2.
En lisaac précisément, tu as un type STRING défini dans la librairie (comme les nombres, booléen, etc...) mais pas dans la grammaire et ceux-ci sont très simple à utiliser.
Mais effectivement, un langage sans string c'est galère.
« 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é à 2.
Différents tests :
+ monboolean, monautrebooleen : BOOLEAN;
monboolean.if_true { cond_vrai;};
monboolean.if_false {cond_fausse;};
monboolean.if { cond_vrai;} else {cond_fausse;};
monboolean.if {
/**/
}.elseif monautrebooleen then {
/**/
} else { /**/ }
etc...
Tu peux en créer autant que tu veux de ce style.
De même, avec les blocks (je te les mets entière) :
- while_do body:BLOCK <-
( //? {body!=NULL};
value.if {
body.value;
while_do body;
};
);
- do_while test:BLOCK <-
( //? {test!=NULL};
value;
test.value.if {
do_while test;
};
);
- until_do body:BLOCK <-
( // ? {body!=NULL};
(! value).if {
body.value;
until_do body;
};
);
- do_until test:BLOCK <-
( //? {test!=NULL};
value;
(! test.value).if {
do_until test;
};
);
Et si tu veux en inventer d'autres, tu peux. Tu n'est pas obligé de les implémenter dans la grammaire du langage.
Et cela en gardant les performances du C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: N'y-a-t-il pas antinomye ?
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é à 2.
Non de faire un langage qui, au lieu de générer de l'asm, génère du C (très bas niveau le C).
ou bien à terme d'avoir un compilo capable de généré du code exécutable pour toutes les archi
Je ne vois pas trop à quoi cela pourrait servir : les types qiu font tourner Gcc sur n architectures font très bien leur boulot. Pourquoi s'emm** à refaire la roue ?
ou bien carrément un langage supplémentaire de GCC (qui signifie rappelons le "GCC, the GNU Compiler Collection" )
Why not ? Il faudrait modifier le compilateur afin qu'il crache du langage intermédiaire. Mais l'intérêt est très moyen, vu qu'on peut utiliser le compilateur C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker