Je précise que ce que j'ai proposé plus haut est pas une "bidouille" conçu sur un coin de table par un ingénieur pour générer du code.
C'est une tentative de repenser intégralement la façon de programmer en introduisant des notions de reconnaissances de forme, de manipulation ensembliste des données, de métaprogrammation, etc...
Cela dit, tu soulèves des points intéressants, bien que je pense qu'il est possible de faire un langage de spec très haut niveau sufiseament léché au niveau théorique pour cracher quelque chose de propre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Why génère une preuve pour COQ qui se charge dé montrer que l'algo est valide.
Le problème est que COQ n'est pas incrémental.
Il y a plusieurs défis :
1/ Concevoir un générateur de preuve à partir des contrats
2/ Concevoir un système qui vérifie la cohérence des contrats, ie. qu'il n'y ait pas incomplétude.
3/ Prouver le compilateur ou au moins une bonne partie
donc
4/Prouver le langage (sa grammaire)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'en ai parlé à Benoit, et il m'a répondu que cela ne l'intéressait pas, que ça limite Lisaac à Gcc et qu'on serait tributaire des changements de langage de Gcc.
Plus précisément ça le gonfle, il estime (et je suis d'accord) qu'il y a des choses plus intéressantes à faire.
Je te rappel qu'il est chercheur et t'informes qu'il est plus intéressé par des problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
C'est pas une mauvaise idée en soit du moment qu'elle soit optionnelle.
Cela dit, on ferait beaucoup mieux de travailler sur l'optimisation de la sémantique que de pinailler sur des optimisation en assembleur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bonne question.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
T'es lourd.
C'est la dernière fois que te répond parce que t'es vraiment bouché, et c'est pas la première fois que je me fait cette réflexions. Tu as une aptitude pour donner l'impression d'argumenter d'une façon qui se révèle en fait bancale qui me laisse rêveur.
J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications.
Question : T'as au moins fait l'effort de jeter un oeil sur la doc ?
Elle est là : http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Va falloir que je la cite pour t'expliquer.
Page 47.
3.2.3 The mapping section The mapping section purpose is to format data slots description according to some o/xed hard-ware data structure.
In such a section, the compiler follows exactly the order and the description of slots as they arewritten to map exactly the
corresponding hardware data structure. Thus, one is able to write data slots description according to the hardware to handl
e.You can only deo/ne slots with the + symbol, and only datas (not code). Otherwise, these attributes are used exactly as th
e others not in the mapping section (readingor writting).
These prototype match exactly a 16 byte physical structure.
Slots inside some mapping section are considered private for any other objects. Slotscan only be deo/ned with the + property
. No slot outside this section can be deo/ned with the + property.
La section INTERRUPT
Page 48
3.2.4 The interrupt section
The goal of the interrupt section is to handle hardware interruptions.In this section you can deo/ne methods (code slots) that will be executed only while there is an interrupt associated.Each slot is associated with one of the processor's interruptions [Hum90]. These slots dioeer from others in their generated code. For example, their entry and exit codesare related to the interrupt processing. Their invocations are asynchronous and borrow the quantum of the current process.Generally, these slots are little time consumers and they don't require specio/c process' context for their executions.It is thus necessary to be careful while programming such slots to ensure the consistency of the interrupted process.
Deo/ne your method (without return value, because you don't explicitly call it) as any otherclassical method. Then associate the adress of your method with the eoeective interrupt jump adress (it dependsof your architecture). This can be done using a system mapped object. When your interrupt physically happends, there is the call of your associated method, whichreturns a pointer on the code. The compiler will not optimize local variables of your interrupt method because of its particu-larity : the call depends of the context and cannot be anticipated during compilation.
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
L'intérêt de Lisaac est de permettre de gérer des interruptions ainsi que des sections Mapping permettant de poser le code sur une structure binaire.
Ceci permet donc d'écrire des drivers. IsaacOS, que certains qui se sont exprimés ont comme moi vu tourner sur une machine est un OS entièrement écrit en Lisaac qui utilise ces fonctionalitées pour écrire un OS from scratch.
Il te faut quoi comme preuve ?
Pour le reste, c'est une affaire de goût (pointeurs, langages, etc...) mais ces fonctionalitées permettent d'écrire des drivers.
mais il y a de gros problème de performance du compilateur.
Un langage qui sur une application "critique", un décodeur Mpeg2, 9852 lignes de code en C, 6176 lignes de code après traduction en Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
T'es con ou t'es con ?
Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
C'est vrai... mon logiciel de GPAO ou mon gros client mail, je le compile tout les matins en arrivant au boulot. Mon FireFox aussi..
Qu'est-ce qu'on en a à foutre que la compilation est "lente" (parce qu'en passant, "lente", Lisaac met 30 secondes pour compiler 60 000 lignes, je crois pas que Gcc puisse soutenir la comparaison, désolé).
Est-ce que tu pourrais me démontrer en quoi dans l'industrie, à part pour ces conneries de JIT (nous c'est pas notre problème, c'est compilé), on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non.
C'est de ma faute à moi ?? C'est de la faute à l'auteur de la news ???
Non, c'est une question qui concerne celui qui a le pouvoir de libérer le code, soit la direction de l'INRIA.
T'es prié d'apprendre à te plaindre à la personne responsable, pas ceux qui n'y peuvent rien.
Quand on te colle une amande parce que tu t'es mal garé, tu gueule contre le flic ?
Moi non. Il fait son boulot, et c'est normal qu'il le fasse.
J'aimerai que ça soit pareil vis à vis de moi, merci.
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
De plus, tu as toute la doc disponible sur le site pour apprendre ce qu'est l'objet à prototype. C'est un concept vieux de 20 ans, et cela ferai du bien à ta culture.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Apprend que tout est lié.
Il faut vraiment que tu apprennes à raisonner, TImaniac, ça devient grave.
Boubou te l'a déjà dit, lui qui est normalien et docteur en maths, il est bien placé pour le savoir.
Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Il est très loin d'être parfait, vu tout ce que je veux mettre dedans, et de toutes façon le modèle des langages à grammaire classique m'emmerdent, je trouve ça beaucoup trop restrictif.
Donc non. Je défend Lisaac parce que je pense que ce langage apporte ce qui n'existait pas jusqu'alors : un langage de haut niveau avec des performances proches du C (et bientôt meilleurs je pense) avec des fonctionalitées bas niveau.
La preuve, un OS a été écrit avec.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Je te l'ai déjà dit p****, c'est pas de notre ressort.
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
va falloir être fort pour vendre ça aux types qui comme moi continuent à faire du C aujourd'hui, après avoir essayé C++ et Java, et en être revenu.
Oui bien sûr, ça va prendre du temps.
Lisaac aura ses utilisateurs, C sera encore utilisé encore longtemps... Et alors.
Certains projets utiliseront C, d'autres Lisaac, ce sera en fonction de la situation de chacun.
Personnelement, à la différence de nicO, qui en tant qu'ingé microélectronique s'intéresse au bas niveau, je suis plus attiré par les fonctionnalités haut niveau, le (bon) design de la lib, etc...
Après... Lisaac possède en natif des fonctionnalités système, personellement je ne les utiliserai pas et de toutes façons, elles sont là et les utilisera qui veut.
Seulement, quand on aura un code qui pour un algo similaire fera 30 % de lignes code en moins pour 10 % de perf en mieux (pour le moment on est à 2% moins bien), pas mal de projet faisable qu'en C à l'heure actuel pourront être fait en Lisaac.
Pour le très bas niveau, ok, le C, c'est très bien.
Pour des applications critiques comme un player mpeg2 ou autres choses du même style, j'en vois par contre un gros intérêt : réduire les coûs, de dev, mais aussi de debugging.
Le leimotiv de Benoit (je l'ai entendu 15 fois) c'est "un gros projet en C, ça devient ingérable. C'est vrai qu'on se sent puissant à jouer avecles pointeurs, mais à un moment ça devient trop lourd". Et il sait de quoi il parle !
Effectivement, les langages de scripts ont des avantages (introspection), mais je pense qu'en bidouillant, on peut se débrouiller pour les compiler.
Lisaac est une aventure qui ne fait que commencer.... ;-)
En ce qui me concerne, le travail à fournir est plus dans les fonctionnalités du langage (fonctionnalités agent créant des threads automatiquement, type MATCH permettant de choisir son type au dernier moment, SQL intégré, etc..) mais aussi dans le designe de la lib.
Regarde la librairie graphique, pour gérer des fenêtre, elle est super bien faites, avec son système de boite au lettre qui te permet de gérer les éveènements clavier souris comme du courrier.
L'avenir du langage passe aussi par là...
- Faire gaffe à l'inflation de types, comme Java. --> minimum de type pour le maximum de choses. Merci l'héritage dynamique, ça va servir à ça.
- Faire des fonctions avec des noms et mot clés intuitifs.
Pour la question des licences, je suis totalement d'accord avec toi, comme je l'ai expliqué plus haut.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
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
[^] # 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.
C'est une tentative de repenser intégralement la façon de programmer en introduisant des notions de reconnaissances de forme, de manipulation ensembliste des données, de métaprogrammation, etc...
Cela dit, tu soulèves des points intéressants, bien que je pense qu'il est possible de faire un langage de spec très haut niveau sufiseament léché au niveau théorique pour cracher quelque chose de propre.
« 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é à 4.
C'est dans la lignée des travaux de Jean-Christophe Filliatre
http://why.lri.fr/index.fr.html
Exemple : http://why.lri.fr/examples/sqrt/sqrt.mlw.html
Why génère une preuve pour COQ qui se charge dé montrer que l'algo est valide.
Le problème est que COQ n'est pas incrémental.
Il y a plusieurs défis :
1/ Concevoir un générateur de preuve à partir des contrats
2/ Concevoir un système qui vérifie la cohérence des contrats, ie. qu'il n'y ait pas incomplétude.
3/ Prouver le compilateur ou au moins une bonne partie
donc
4/Prouver le langage (sa grammaire)
« 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.
Plus précisément ça le gonfle, il estime (et je suis d'accord) qu'il y a des choses plus intéressantes à faire.
Je te rappel qu'il est chercheur et t'informes qu'il est plus intéressé par des problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
C'est pas une mauvaise idée en soit du moment qu'elle soit optionnelle.
Cela dit, on ferait beaucoup mieux de travailler sur l'optimisation de la sémantique que de pinailler sur des optimisation en assembleur.
« 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.
C'est vrai que c'est une optimisation de très bas niveau.
On est en train de réfléchir à des optimisations plsu haut niveau, comme le déroulement et la paraléllisation de grosses boucles. Du genre transformer
http://www.haypocalc.com/wiki/Image:Graphe_s%C3%A9quentiel.j(...)
en
http://www.haypocalc.com/wiki/Image:Graphe_paral.jpg
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« 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.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« 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.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est la dernière fois que te répond parce que t'es vraiment bouché, et c'est pas la première fois que je me fait cette réflexions. Tu as une aptitude pour donner l'impression d'argumenter d'une façon qui se révèle en fait bancale qui me laisse rêveur.
J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications.
Question : T'as au moins fait l'effort de jeter un oeil sur la doc ?
Elle est là : http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Va falloir que je la cite pour t'expliquer.
Page 47.
3.2.3 The mapping section The mapping section purpose is to format data slots description according to some o/xed hard-ware data structure.
In such a section, the compiler follows exactly the order and the description of slots as they arewritten to map exactly the
corresponding hardware data structure. Thus, one is able to write data slots description according to the hardware to handl
e.You can only deo/ne slots with the + symbol, and only datas (not code). Otherwise, these attributes are used exactly as th
e others not in the mapping section (readingor writting).
Section MAPPING
+ x1:uinteger; // 4 bytes, unsigned
+ x2:usmallint; // 1 byte, unsigned
+ x3:smallint; // 1 byte, signed
+ x4:ushortint; // 2 bytes, unsigned
+ x5:uinteger; // 4 bytes, unsigned
+ x6:shortint; // 2 bytes, signed
+ x7:ushortint; // 2 bytes, unsigned
These prototype match exactly a 16 byte physical structure.
Slots inside some mapping section are considered private for any other objects. Slotscan only be deo/ned with the + property
. No slot outside this section can be deo/ned with the + property.
La section INTERRUPT
Page 48
3.2.4 The interrupt section
The goal of the interrupt section is to handle hardware interruptions.In this section you can deo/ne methods (code slots) that will be executed only while there is an interrupt associated.Each slot is associated with one of the processor's interruptions [Hum90]. These slots dioeer from others in their generated code. For example, their entry and exit codesare related to the interrupt processing. Their invocations are asynchronous and borrow the quantum of the current process.Generally, these slots are little time consumers and they don't require specio/c process' context for their executions.It is thus necessary to be careful while programming such slots to ensure the consistency of the interrupted process.
Deo/ne your method (without return value, because you don't explicitly call it) as any otherclassical method. Then associate the adress of your method with the eoeective interrupt jump adress (it dependsof your architecture). This can be done using a system mapped object. When your interrupt physically happends, there is the call of your associated method, whichreturns a pointer on the code. The compiler will not optimize local variables of your interrupt method because of its particu-larity : the call depends of the context and cannot be anticipated during compilation.
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
L'intérêt de Lisaac est de permettre de gérer des interruptions ainsi que des sections Mapping permettant de poser le code sur une structure binaire.
Ceci permet donc d'écrire des drivers. IsaacOS, que certains qui se sont exprimés ont comme moi vu tourner sur une machine est un OS entièrement écrit en Lisaac qui utilise ces fonctionalitées pour écrire un OS from scratch.
Il te faut quoi comme preuve ?
Pour le reste, c'est une affaire de goût (pointeurs, langages, etc...) mais ces fonctionalitées permettent d'écrire des drivers.
mais il y a de gros problème de performance du compilateur.
Un langage qui sur une application "critique", un décodeur Mpeg2, 9852 lignes de code en C, 6176 lignes de code après traduction en Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
T'es con ou t'es con ?
Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
C'est vrai... mon logiciel de GPAO ou mon gros client mail, je le compile tout les matins en arrivant au boulot. Mon FireFox aussi..
Qu'est-ce qu'on en a à foutre que la compilation est "lente" (parce qu'en passant, "lente", Lisaac met 30 secondes pour compiler 60 000 lignes, je crois pas que Gcc puisse soutenir la comparaison, désolé).
Est-ce que tu pourrais me démontrer en quoi dans l'industrie, à part pour ces conneries de JIT (nous c'est pas notre problème, c'est compilé), on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non.
C'est de ma faute à moi ?? C'est de la faute à l'auteur de la news ???
Non, c'est une question qui concerne celui qui a le pouvoir de libérer le code, soit la direction de l'INRIA.
T'es prié d'apprendre à te plaindre à la personne responsable, pas ceux qui n'y peuvent rien.
Quand on te colle une amande parce que tu t'es mal garé, tu gueule contre le flic ?
Moi non. Il fait son boulot, et c'est normal qu'il le fasse.
J'aimerai que ça soit pareil vis à vis de moi, merci.
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
De plus, tu as toute la doc disponible sur le site pour apprendre ce qu'est l'objet à prototype. C'est un concept vieux de 20 ans, et cela ferai du bien à ta culture.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Apprend que tout est lié.
Il faut vraiment que tu apprennes à raisonner, TImaniac, ça devient grave.
Boubou te l'a déjà dit, lui qui est normalien et docteur en maths, il est bien placé pour le savoir.
Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Il est très loin d'être parfait, vu tout ce que je veux mettre dedans, et de toutes façon le modèle des langages à grammaire classique m'emmerdent, je trouve ça beaucoup trop restrictif.
Donc non. Je défend Lisaac parce que je pense que ce langage apporte ce qui n'existait pas jusqu'alors : un langage de haut niveau avec des performances proches du C (et bientôt meilleurs je pense) avec des fonctionalitées bas niveau.
La preuve, un OS a été écrit avec.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Je te l'ai déjà dit p****, c'est pas de notre ressort.
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
« 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é à 3.
Oui bien sûr, ça va prendre du temps.
Lisaac aura ses utilisateurs, C sera encore utilisé encore longtemps... Et alors.
Certains projets utiliseront C, d'autres Lisaac, ce sera en fonction de la situation de chacun.
Personnelement, à la différence de nicO, qui en tant qu'ingé microélectronique s'intéresse au bas niveau, je suis plus attiré par les fonctionnalités haut niveau, le (bon) design de la lib, etc...
Après... Lisaac possède en natif des fonctionnalités système, personellement je ne les utiliserai pas et de toutes façons, elles sont là et les utilisera qui veut.
Seulement, quand on aura un code qui pour un algo similaire fera 30 % de lignes code en moins pour 10 % de perf en mieux (pour le moment on est à 2% moins bien), pas mal de projet faisable qu'en C à l'heure actuel pourront être fait en Lisaac.
Pour le très bas niveau, ok, le C, c'est très bien.
Pour des applications critiques comme un player mpeg2 ou autres choses du même style, j'en vois par contre un gros intérêt : réduire les coûs, de dev, mais aussi de debugging.
Le leimotiv de Benoit (je l'ai entendu 15 fois) c'est "un gros projet en C, ça devient ingérable. C'est vrai qu'on se sent puissant à jouer avecles pointeurs, mais à un moment ça devient trop lourd". Et il sait de quoi il parle !
Effectivement, les langages de scripts ont des avantages (introspection), mais je pense qu'en bidouillant, on peut se débrouiller pour les compiler.
Lisaac est une aventure qui ne fait que commencer.... ;-)
En ce qui me concerne, le travail à fournir est plus dans les fonctionnalités du langage (fonctionnalités agent créant des threads automatiquement, type MATCH permettant de choisir son type au dernier moment, SQL intégré, etc..) mais aussi dans le designe de la lib.
Regarde la librairie graphique, pour gérer des fenêtre, elle est super bien faites, avec son système de boite au lettre qui te permet de gérer les éveènements clavier souris comme du courrier.
L'avenir du langage passe aussi par là...
- Faire gaffe à l'inflation de types, comme Java. --> minimum de type pour le maximum de choses. Merci l'héritage dynamique, ça va servir à ça.
- Faire des fonctions avec des noms et mot clés intuitifs.
Pour la question des licences, je suis totalement d'accord avec toi, comme je l'ai expliqué plus haut.
« 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