L'utilisation de TOM est pertinente dès qu'il s'agit de manipuler des données arborescentes (termes, arbres syntaxiques, arbres XML...), ce qui est très courant en programmation.
En plus de proposer un mécanisme de pattern matching puissant (associatif) sur les types Java/C, TOM est fourni avec un langage permettant de définir des types inductifs (comme en Caml) reposant sur une bibliothèque garantissant le partage maximal de la mémoire. Enfin le langage fournit un système de définition de stratégies de parcours des arbres par combinaison de stratégies de base.
Le compilateur est une application stable, bien documentée et réellement utilisable (tâche Ant, plugin Vim...). De nombreux exemples sont fournis. Le premier exemple du tutoriel illustre bien l'intégration de TOM au langage Java :
import main.peano.types.*;
public class Main {
%gom {
module Peano
abstract syntax
Nat = zero()
| suc(pred:Nat)
| plus(x1:Nat, x2:Nat)
}
public final static void main(String[] args) {
Nat z = `zero();
Nat one = `suc(z);
System.out.println(z);
System.out.println(one);
}
}
Les types inductifs définis dans le bloc %gom peuvent être directement utilisés dans le programme java, et peuvent ensuite être filtrés grâce à l'opérateur %match :
public static Nat evaluate(Nat n) {
%match(Nat n) {
plus(x, zero()) -> { return `x; }
plus(x, suc(y)) -> { return `suc(plus(x,y)); }
}
return n;
}
Il est également possible de définir des mappings vers des types Java prédéfinis (arbre XML DOM par exemple) pour ensuite profiter du pattern matching et des stratégies de parcours sur ceux-ci.
TOM fournit un mécanisme de pattern matching associatif, i.e. permet de filtrer des listes avec des expressions du type : (X*, a, Y* , b, Z*) plutôt qu'avec des expressions du type tête::queue comme c'est le cas en Caml.
Le langage est actuellement utilisé dans plusieurs projets de recherche mais aussi dans l'industrie.
Aller plus loin
- Le site de TOM (4 clics)
- La page du projet sur GForge INRIA (2 clics)
- La documentation (comprenant un tutoriel) (2 clics)
- La page de l'équipe Protheo (2 clics)
# typo
Posté par _ . Évalué à 4.
# Et beh...
Posté par Anonyme . Évalué à -10.
Enfin si ça les amuse de bouffer les budgets pour des langages à chier utilisés par eux et c'est tout...
OUI, c'est un troll, OUI c'est méchant, OUI je ne suis qu'un morveux qui connait rien et compagnie, mais OUI je me suis bouffé 1 an de Caml, et j'ai des envies de meurtre....
[^] # Re: Et beh...
Posté par Gabriel . Évalué à 3.
[^] # Re: Et beh...
Posté par Youx . Évalué à 3.
Le top, ça a été les listes, avec des cons(a,cons(b,cons(c ... ))))))) pour faire une liste, les 50 parentheses fermantes à la fin, fallait bien les compter ...
Quand au magnifique IDE (camlight?), où l'historique insérait dans n'importe quel ordre (on a fini par comprends au bout d'un certain temps que l'IDE insérait les commandes à l'endroit ou était l'ascenseur de l'historique plutôt qu'à la fin de celui ci ... trop logique)
J'en garde donc un souvenir particulièrement pénible (voire meme écoeurant).
Pour ce qui est d'ocaml, j'ai entendu quelques personnes dire que c'était bien.
Cela dit, la seule application réelle que j'en ai vu étant mldonkey (avec des performances dignes d'un escargot de course), je me permet de poser quelques doutes sur la légitimité de son utilisation (quand au programme mldonkey lui même, la derniere fois que je l'ai lancé, il m'a pondu tous les fichiers de config dans le repertoire courant ... ça m'a permis d'etre rapidement fixé sur son sort ;) )
[^] # Re: Et beh...
Posté par _ . Évalué à 5.
- Caml light n'est plus maintenu depuis 2002 et n'existe quà des fins éducatiives dans les prépas. Je ne connais pas bien cette version de Caml, mais une liste s'écrit [1;2;3...] chez moi. Un ide c'est un ide...utilise le mode tuareg d'emacs :)
- ocaml a énormément d'applications dans la recherche (en fait là où je bosse les gens qui n'utilisent pas TOM utilisent ça :) ). Il a aussi des applications industrielles mais elles sont moindres. Quand aux performances (http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) , le compilo est plutôt réputé pour celles-ci.
- mldonkey est un peu tout pourri mais si on évalue la qualité d'un llangage à ses applications, alors le C, C++ et java sont très très loins derrière :)
[^] # l'INRIA ne soutient pas suffisamment OCaml
Posté par V . Évalué à 2.
Bref le nombre de parenthèses c'est un peu juste pour juger un langage. Il existe des critères un peu plus objectifs... OCaml permet de programmer de manière très concise (donc rapide) des applications qui plantent très peu.
Et OCaml met à la disposition du programmeur des tonnes de concepts qui ne sont quasiment jamais réunis dans le même langage. C'est le langage le plus riche que je connaisse. (variants, Pattern-matching, Garbage Collector, objets, inférence de types, polymorphisme paramétrique, prog fonctionnelle et impérative, exceptions, préprocesseur, etc) et il a été conçu par des gens qui sont parmi les meilleurs spécialistes du domaine au monde.
Le revers de tout ça c'est qu'il devient un peu plus difficile à apprendre et maîtriser qu'un langage moins riche en concepts. Et souvent les gens qui critiquent OCaml n'ont juste pas pris le temps de le découvrir à fond.
L'IDE dont tu parles est sûrement une vieille IDE de camllight pour windows toute pourrie. Cela dit tu as raison, l'INRIA ne met pas les moyens nécessaires pour développer les outils autour du langage. S'ils veulent que leur recherche passe dans le monde des entreprise il faudrait payer des développeurs (ce n'est pas le boulot des chercheurs)... Et OCaml est vraiment une réussite de l'INRIA qui mériterait d'être utilisée à plus grande échelle. Mais on dirait que l'INRIA n'a pas envie...
C'est pour cette raison qu'OCaml est encore peu utilisé dans l'industrie mais à mon avis il manquerait juste un petit effort de l'INRIA et les entreprises se rendraient compte qu'OCaml leur permet de gagner du temps de programmation et de débogage donc de l'argent.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par reno . Évalué à 5.
Oui enfin on peut le voir aussi dans l'autre sens: pourquoi les gens ne prennent pas le temps de découvrir à fond OCaml?
Dans mon cas, c'est la syntaxe pas terrible qui m'a découragé (pas la "richesse des concepts"), bon il faut dire que depuis que j'ai découvert Ruby je suis devenu assez exigeant coté syntaxe.
Et, à l'opposé, ceux qui maîtrisent un langage ont tendance à oublier ses défauts..
Par exemple (pour ne pas taper que sur Ocaml) qui se souvient des problèmes qu'il a eu pour la déclaration de variable en C?
Pas grand monde.. et pourtant une syntaxe comme celle de Limbo http://www.vitanuova.com/inferno/limbo.html est plus simple..
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par _ . Évalué à 4.
Je pense que la plupart des gens se disant rebutés par la syntaxe d'ocaml sont en fait déroutés par leur premier contact avec un langage fonctionnel.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Yusei (Mastodon) . Évalué à 6.
Dans le même style, le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles. C'est justifié par l'inférence de types, mais c'est pénible de devoir se souvenir quel est l'opérateur à utiliser pour le type que l'on a.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par djrom . Évalué à 5.
Dans le cas d'Ocaml, je crois que c'est plutôt un choix. D'autres langages avec inférence de type ont fait un choix différent, comme Haskell par exemple.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Vivi (site web personnel) . Évalué à 2.
exemples ? Je ne vois pas trop de quoi tu veux parler ...
le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles.
Ouais enfin il ne s'agit que des opérateurs numériques et il suffit de rajouter un point pour la version flottantes, c'est quand même pas trés dur à comprendre et à retenir.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Yusei (Mastodon) . Évalué à 6.
Non, c'est pour tous les opérateurs, sauf ceux de comparaison qui sont polymorphiques. Le langage et la lib de base fournissent peu d'opérateurs, justement parce que l'absence de polymorphisme rendrait pénible d'avoir 27 variantes de "+". Du coup, tu as +, +. et +/ pour additionner les entiers, les flottants et les Nums, et pour les autres types il faut utiliser les fonction du style Type.add.
Dans le même style, et même si ce ne sont pas strictement des opérateurs, tu dois mémoriser que pour décrire une liste c'est [ ... ], pour décrire un vecteur c'est [| ... |]. Pour accéder à un élément d'un vecteur, on utilise .(indice), et pour accéder à un élément d'une chaîne, .[indice], etc.
Chaque point pris individuellement n'est pas dur à mémoriser, c'est la somme des détails qui est lourde. En Ruby, pour additionner deux objets on utilise "+", et pour accéder à un élément dans un truc qui en possède plusieurs, on utilise [indice]. Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.
Difficile de faire une liste précise, je ne mémorise pas les exceptions, c'est bien pour ça qu'elles me posent problème :)
Il me vient, à froid:
- tous les exemples ci-dessus.
- le produit cartésien, pour lequel on peut omettre les parenthèses lorsque ce n'est pas ambigu pour le compilateur, mais j'ai rencontré des cas où c'était ambigu pour mon cerveau limité.
- il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité. Je l'ai dit, j'aime bien le Lisp :)
- Il y a plusieurs manières de déclarer une fonction. Je n'en ai retenu qu'une, mais pour débugguer le code des autres il faut toutes les connaîtres.
- Si on veut faire de l'impératif, on peut délimiter les instructions qui renvoient unit par des points virgule, ou bien on peut écrire let () = expression in ... (il y a peut-être une différence entre les deux, mais je ne la connais pas).
J'ai la flemme d'en chercher d'autre, je n'ai pas pour but de démolir OCaml. Puisque je m'en sers, c'est que je trouve les obstacles surmontables, mais quand même pénibles ;)
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Vivi (site web personnel) . Évalué à 1.
OK mais tout ceci n'est pas à strictement parler un problème de syntaxe. Cela tient plutôt à la manière dont ces deux langages gèrent le polymorphisme, le typage, etc. Ce n'est pas quelque chose qui peut s'améliorer en changeant uniquement la syntaxe (ie. la représentation en chaîne de caractères du programme), ça a aussi à voir avec toute la sémantique du langage.
Effectivement, si OCaml avait des type classes comme Haskell, cela permettrait une syntaxe plus légère. Mais il ne faut pas se focaliser sur la syntaxe actuelle comme si les concepteurs l'avait voulue exactement ainsi, qu'ils se fichent des aspects pratiques, etc. Les aspects problèmatiques de la syntaxe sont surtout des conséquences d'autres limitations du langage plutôt que erreurs de conception. (AMHA)
mais ... c'est comme ça dans tous les langages. C'est comme si tu nous faisait un vélo parce qu'en C, pour parser les expression arithmétiques genre 2 + 4 * 5 parfois il faut des parenthèses et parfois on peut les omettre. Les différentes règles de la grammaire ont des priorités, si ça ne correspond pas à ce que tu veux, il faut rajouter les parenthèses ... c'est tout.
Par exemple, l'opérateur produit pour les types * à une priorité plus faible que l'application, du coup string * string list est parsé comme string * (string list) ; si tu veux une liste de paires de string, il faut l'écrire (string * string) list. C'est le même principe que pour les expressions arithmétiques : tu retiens les priorités des opérateurs les plus courants et sinon tu mets des parenthèses. Je vois pas trop ce qu'on peut reprocher à OCaml sur ce point.
Autre exemple: l'expression if/then/else. Quand on écrit if e1 then e2 ; e3, l'expression e3 n'est pas dans la branche then, elle est au même niveau que le if ; il faut mettre des parenthèses (ou un begin/end) si on veut obtenir la séquence e2 ; e3 dans le then. Mais c'est à peu près le même comportement qu'en C avec if (cond) i1; i2;: il faut des {} pour regrouper i1 et i2.
... et je ne prétends pas que OCaml soit sans défaut. Comme souvent c'est une question de compromis : la syntaxe n'est sans doute pas la meilleure qui soit mais les autres atouts du langage en valent largement la peine.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Yusei (Mastodon) . Évalué à 2.
(Pas en Lisp.)
Il y a une différence fondamentale entre ton exemple d'additions/multiplications et mon exemple de produit cartésien: tout le monde sait comment 5+3*6 est évalué. La priorité des opérateurs est là pour refléter l'écriture normale des opérations. Dans la vraie vie, un n-uplet s'écrit (a, b, c), rarement a, b, c, donc je ne vois pas pourquoi rendre les parenthèses facultatives. Si on le fait, on autorise à écrire [ 1 , 2 ; 1 , 3 ; 2 , 4 ; 3 , 1 ] au lieu de [ (1, 2) ; (1, 3) ; (2, 4) ; (3, 1) ]. Ce n'est pas ambigu, mais c'est difficile à lire. Si on n'a pas l'habitude du langage, certaines expressions non ambigues peuvent être trompeuses... en tout cas je me suis déjà fait avoir par cette règle.
Je prend un autre exemple tiré par les cheveux, en créant un opérateur qui additionne des couples:
# let (++) x y = fst x + fst y, snd x + snd y;;
# 1,1 ++ 1,2;;
This expression has type int but is here used with type int * int
# (1,1)++(1,2);;
- : int * int = (2, 3)
Là aussi, le code n'est pas ambigu. On aurait tort d'essayer 1,1 ++ 1,2 parce que l'opérateur s'appliquerait à deux entiers, pas à deux couples. Mais à mon avis c'est un piège inutile, et si le parenthèsage n'était pas facultatif on n'aurait jamais pu se tromper.
Tout à fait, mais malgré tout je déplore les exceptions ou les variantes de sa syntaxe. La syntaxe du Lisp est plus abordable pour les débutants, parce qu'elle ne possède pas d'exceptions. Quand tu connais la règle (fonction arg1 ... argN) et les quelques formes spéciales, tu connais tout. En contrepartie, c'est un peu plus lourd à écrire.
Personnellement, je me satisfais assez d'un OCaml très parenthèsé, qui n'utilise qu'une seule manière de déclarer les fonctions, etc. Tant que je ne relis pas le codes des autres, bien sûr :)
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par reno . Évalué à 3.
Ce n'était pas mon premier langage fonctionnel (mais je n'apprécie pas particulièrement les langages fonctionnels à part Scala) et Ocaml est "vendu" comme un langage multi-paradigme pas fonctionnel.
Cependant dans le livre l'accent est mis sur le coté fonctionnel ce qui est pénible..
En fait, j'ai ressenti exactement la même chose que Yusei ce qui est amusant..
Sinon je suis d'accord que l'inférence de type épure le code mais Ocaml n'est pas le seul langage ou l'inférence de type existe: Limbo, Scala, D, bientôt C# v3 etc ont l'inférence de type locale ce qui est suffisant.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Antoine . Évalué à 1.
Et Boo : http://boo.codehaus.org/Home
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Alex G. . Évalué à 4.
Bref il ne manque peut-être pas tant des développeurs à OCaml mais du marketing (et ce n'est certes pas le travail des chercheur). Ce travail devrait être mené (en mon sens) par un tandem commercial-ingénieur (ou une personne qui réunit les deux) qui, profitant de la licence, pourrait faire un consorsium type ObjectWeb (JBOSS).
Mais c'est beaucoup plus facile à dire qu'à faire ! De plus il faudrait effectivement la coopération des chercheurs qui sans savoir forcément l'exprimer connaissent la valeur du produit. La manière la plus naturelle serait surement un étudiant de master ou de thése qui se sente suffisament hardi et intéressé pour se lancer dans une startup (en lien avec le labo) ! Je connais quelqu'un qui a fait un truc dans le genre avec les lasers (me faire un message perso si tu veux en savoir plus).
[^] # Re: Et beh...
Posté par Christian-Cyril CORDAT (site web personnel) . Évalué à 0.
- j'ai appris à programmer avec caml en prépa, en utilisant caml light, enfin pas vraiment, on utilisait un éditeur tout bête http://www.crimsoneditor.com qui nous permettait d'interpréter et d'avoir la sortie dans un "ide" potable, caml light n'est qu'un petit utilitaire fait à la va-vite pour des tests rapides.
- ensuite, après 3 ans d'école informatique, et bien je peux dire que je préfère encore caml au reste, parce qu'il n'y a rien de tel que le pattern matching, les inférences de type, et les déclarations fonctionnelles.
- mldonkey tourne très bien, je l'ai compilé et installé sur un serveur où nous étions plusieurs à l'administrer, il propose une interface web avec toutes les fonctions utiles au téléchargement, il tourne de façon bien plus légère que emule amule et autres, etc
et si tes fichiers se sont retrouvés n'importe où c que t'as encore pas mal de choses à apprendre petit (genre savoir faire un make install)
- ocaml permet de faire des appli complètes, pour le réseau, les jeux, etc
PS : waoh polux, 69 commentaires sur ta dépèche, c chaud TOM !
d'ailleurs pour revenir au sujet, j'attends tom pour C# et c partiiii !
[^] # Re: Et beh...
Posté par pemo . Évalué à 1.
c'est quelque chose de tout à fait envisageable. Comme Tom ne parse pas la syntaxe du langage hote, il est assez facile de l'etendre à d'autres langages : il suffit de faire un nouveau backend.
Si C# supporte le if-the-else, l'affectation, la sequence d'instructions et la notion de block, cela de devrait prendre que quelques heures pour avoir un prototype. J'imagine qu'en 1 ou 2 jours on doit pouvoir faire un backend pour C# qui tienne la route.
Surtout, ne pas hésiter à contribuer, le projet est ouvert.
[^] # Re: Et beh...
Posté par _ . Évalué à 3.
[^] # Re: Et beh...
Posté par Christian-Cyril CORDAT (site web personnel) . Évalué à -2.
ce qui serait bien, ça serait de faire connaître tom dans les communautés java et C, en entreprise, j'ai pas entendu parler de TOM, alors que des choses genre JML ou JUnit pour java oui.
[^] # Re: Et beh...
Posté par Antoine Reilles (site web personnel) . Évalué à 1.
Ensuite, un backend Gom pour ca sera probablement assez direct à ecrire
[^] # Re: Et beh...
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 9.
Je ne suis pas franchement convaincu par l'idée d'enseigner aux étudiants à programmer en commençant par OCaml, comme ça a été fait dans certaines facs. Un langage de programmation, c'est un outil pour résoudre les problèmes. Si on n'a pas encore eu de problèmes, on ne peut pas correctement apprendre à les résoudre. Donc je pense qu'il vaut mieux commencer par un langage simplissime et pas trop abstrait, commencer à programmer, et quand on rencontre des obstacles, trouver des langages qui aident à les surmonter.
Par exemple quand on se met à programmer à plusieurs et que la modularisation avec des .h atteint ses limites, on commence à mieux apprécier la programmation objet. Ou bien quand on se met à manipuler des structures de données abstraites et récursives, on se met à sérieusement apprécier la programmation fonctionnelle... du moins en ce qui me concerne.
D'un autre côté, il y a des inconvénient à apprendre d'abord un langage comme le C et ensuite un langage comme OCaml. On commence en ayant peu de contraintes, et ensuite on se trouve face à quelque chose de beaucoup plus formel, qui demande un peu de discipline, et il est difficile de se débarrasser de ses mauvaises habitudes.
Finalement, je ne sais pas ce qui est le mieux, comme ordre d'apprentissage, mais je comprend qu'on pense qu'OCaml est un langage sans applications quand on n'a pas encore souffert en essayant de faire quelque chose de vraiment compliqué dans ces langages préhistoriques que sont le C et ses dérivés (ce qui inclut Java, hein).
[^] # Re: Et beh...
Posté par Philip Marlowe . Évalué à 3.
[^] # Re: Et beh...
Posté par Guillaume Vauvert (site web personnel) . Évalué à 7.
En tant qu'enseignant, j'avais essayé de suivre cette démarche : je pose un problème, les étudiants essaient de le résoudre avec ce qu'ils connaissent, ils construisent alors souvent quelque chose qui ressemble à la nouveauté que je voulais leur enseigner, puis j'amène la nouveauté : joie, soulagement, satisfaction, plaisir, c'est super ! Les étudiants comprennent mieux l'intérêt, apprécient la beauté de la nouveauté, mais :
- c'est un processus un peu lent
- ça demande que les étudiants s'investissent dans la recherche sinon on perd du temps; d'après moi, c'est toujours là que réside la difficulté : motiver chaque étudiant, en tenant compte de ses goûts, de sa personalité, de sa forme du moment, des ses propres motivations, ... Difficile à faire avec 35 étudiants différents !
[^] # Re: Et beh...
Posté par Sylvain Sauvage . Évalué à 7.
Le problème, c'est que les étudiants sont habitués à l'ordre CM (où on dort à moitié en grattant) - TD (on dort en attendant que le prof. donne la solution) - TP (quand il y en a) et que monter un cours dans cet ordre demande du temps (pour la préparation et pour le cours) et on a déjà pas forcément le temps de tout caser...
[^] # Re: Et beh...
Posté par pierthi . Évalué à 7.
Sérieux, c'est quoi l'intérêt d'un langage surdoué, quand le framework de base est à peine plus évolué que la libc ? Ok, c'est un langage Türing complete, tu peux tout faire avec, mais en combien de temps ? Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans. Parce que bon, on a franchement autre chose à faire que de recoder tout une tétrachié de wrappers pour des libs existantes (avec tous les emmerdes que ça présuppose : doc, tests, mise à jour, intégration plus ou moins bancale dans le langage, etc ...).
Tant qu'on y est, quid de l'intégration avec le système hôte ? Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ? Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ? Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche) ? Quid des capacités cross-plateformes (dont les différences subtiles ont bien-sûr été documentées et à peu près testées) ? C'est l'exemple typique de sales boulots que personne ne veut faire.
Si on ajoute à ça que Caml n'est absolument pas en position de force, et que l'Inria n'a de toute façon pas les moyens de concurencer un Java ou un C#, ben faut pas s'étonner que ce langage se cantonne depuis des lustres aux cercles académiques ou à quelques niches ultra-pointues.
En tous les cas, l'approche utilisé par TOM me semble nettement plus pragmatique et réaliste.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 4.
Mouais, alors si tu compares la lib de base d'OCaml et celle du C, je ne sais pas vraiment qui gagne, mais je penche très fort pour OCaml, puisque la notion de "lib de base" pour le C est quasi inexistante. Pour Java, par contre, d'accord.
Ceci dit, s'il n'y a pas de parser XML, d'interface ODBC, etc. dans la lib de base, tout ça existe quand même. Il manque peut être un repository, je ne sais pas trop, chez moi c'est bien proprement intégré par Debian. Quand j'ai besoin de quelque chose, ça se limite souvent à une recherche dans la base des paquets.
Ho ho. Je t'accorde que le seul intérêt de Java, c'est son framework, parce que le langage n'est vraiment pas terrible.
Mais si on se basait sur l'existence de bibliothèques et d'IDE pour juger les langages, Java n'aurait jamais été créé. Du côté des IDE, j'ai commencé à faire du Java avec le bloc note de Windows, et c'était pas joyeux.
open Unix
Là, j'avoue que je n'en connais pas de mieux foutu qu'Emacs.
C'est triste ce que tu penses de GTK2.
Il y a un livre publié par OReilly et diffusé sur le net, qui est très bien foutu, bien qu'un peu dense à mon goût.
Je ne sais pas sur quelles plateformes le compilateur d'OCaml tourne, mais tu peux compiler un programme OCaml en bytecode pour JVM, si tu veux.
[^] # Re: Et beh...
Posté par pierthi . Évalué à -1.
[^] # Re: Et beh...
Posté par outs . Évalué à 6.
Je sais qu'ils ont déjà quelques utilisateurs dans l'industrie principalement pour manipuler du XML avec le back-end Java.
[^] # Re: Et beh...
Posté par Anonyme . Évalué à 0.
Personnellement j'ai pas envie d'apprendre un language où il faut sans cesse appuyer sur deux touches pour faire un caractère et là ils ont mis des % et | à gogo on dirait.
Sur les claviers QWERTY ces caractères sont accessibles directement non ? c'est peut être plus pratique pour programmer.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 4.
- Ils ne pouvaient pas modifier le langage d'origine, et ajouter les mots clés directement à Java ou C, parce que ça serait revenu à créer un nouveau langage, avec tous les défauts que ça implique.
- Du coup ils ont opté pour un préprocesseur. Or, si les mots du langage du préprocesseur sont des mots possibles du langage de destination, ça pose des problèmes. Dans le cas présent, un programme Java dans lequel une variable serait nommée "match" n'aurait pas été une entrée valide pour Tom, s'il avait utilisé le mot clé "march" au lieu de "%match".
[^] # Re: Et beh...
Posté par _ . Évalué à 2.
Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:
def pred(n):
match Nat n:
suc(x):
return x
zero():
return zero()
par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.
Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.
[^] # Re: Et beh...
Posté par _ . Évalué à 2.
[^] # Re: Et beh...
Posté par dinomasque . Évalué à 6.
Et ce nouveau language m'a l'air tout à fait désopilant.
Ils ont donc bien rempli leur mission !
BeOS le faisait il y a 20 ans !
[^] # Re: Et beh...
Posté par reno . Évalué à 1.
Apparemment il y a beaucoup d'utilisation de ` dans le language, un opérateur difficilement visible, je ne pense pas que ce soit une bonne idée.
Les langages qui mélangent fonctionnel et objet sur JVM, il y en a beaucoup, par exemple Scala qui est pas mal. Y-a t'il un comparatif entre Scala et TOM par exemple?
Il y a franchement abondance de langage, c'est difficile de s'interresser à un nouveau langage alors que certains comme Limbo auraient mérités beaucoup mieux..
[^] # Re: Et beh...
Posté par _ . Évalué à 2.
Scala est sympa mais pour l'instant ça part un peu dans tous les sens, ce qu'on propose avec tom est centré sur la réécriture mais on le fait (déjà :)), on le fait bien (résultats certifiés par coq et zenon, donc il y a une vraie sémantique) et on fournit tout un framework qui va avec :
signatures algébriques, partage maximal de la mémoire, définition de stratégies, possibilité d'ajouter des backends, etc.
[^] # Re: Et beh...
Posté par reno . Évalué à 3.
La syntaxe d'un language pour un programmeur, c'est comme l'interface graphique d'une application: très important..
Il n'y a pas que les preuves formelles qui sont importantes..
[^] # Re: Et beh...
Posté par _ . Évalué à 2.
[^] # Re: Et beh...
Posté par outs . Évalué à -1.
De toute manière c'est 100% subjectif. Et c'est aux programmeurs a s'adapter aux nouvelles syntaxes, et oui on ne peut pas faire de nouvelles choses avec des vieilles syntaxes ...
Les preuves formelles, la puissance et l'expressivité du langage sont bien plus importante. Tu fais quoi avec ton langage ? De la poésie ?
Perso je fait des programmes avec, je les affiche pas dans ma chambre.
[^] # Re: Et beh...
Posté par reno . Évalué à 5.
Il n'y a qu'a essayer de maintenir un programme écrit par un autre en Perl pour s'en rendre compte..
[^] # Re: Et beh...
Posté par outs . Évalué à 2.
[^] # Re: Et beh...
Posté par reno . Évalué à 4.
Mais certains langages ont une syntaxe qui facilite l'écriture de code propre et la maintenance..
S'il faut faire attention en écrivant en Perl, c'est bien parce que le langage encourage a faire du code peu lisible..
Peu de gens préférent la syntaxe de Perl à celle de Ruby (je parle de la syntaxe hein pas du reste, on peut préférer Perl parce qu'on y est plus habitué, à cause de CPAN..). Donc Ruby doit faire quelque-chose de bien..
Pour exagérer les différences, tu préfère maintenir un programme en Ruby ou en APL?
Les préférences individuelles n'ont que peu d'intérét, le succes d'un langage c'est par définition quelque-chose de collectif: ce sont les préférences d'un grand nombre de programmeurs qui comptent..
Et la majorité des programmeurs se fichent des preuves de Coq mais pas de savoir si c'est facile à lire|maintenir/écrire, les deux ne sont bien sûr pas incompatible, mais apparemment c'est dur à retenir..
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 5.
Même si je sais que tous les langages Turing-complets permettent la même chose, je ne peux pas penser que la syntaxe n'a pas d'importance. Il n'y a qu'à voir la différence dans les programmes de résolution d'un problème, si l'un a été codé en impératif et l'autre en fonctionnel. De la même manière, on peut souvent voir lorsqu'un type qui code en C est un programmeur qui a fait du fonctionnel avant, ou de l'objet, ou autre. Le paradigme favorise certains choix, et la syntaxe également.
[1] http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis
[2] http://en.wikipedia.org/wiki/Currying
[^] # Re: Et beh...
Posté par outs . Évalué à 5.
La syntaxe n'a qu'un impact mineur sur la lisibilité des programmes. C'est d'abord les conventions collectives et les effort de chacun qui détermine le résultat. Tout ce que peut faire le langage c'est proposer une bonne expressivitée pour coller naturelement à ce que veux faire le programmeur, c'est donc la sémantique qui est déterminante (a ne pas confondre avec la syntaxe).
Et les seuls arguments que j'ai vu ici (à part les ouin-ouin pasque c'est pas comme l'habitude de chacun) c'est :
* "`" est difficiliement lisible mais cela tombe bien car c'était justement le but dans ce choix de lexeme.
* % nécessite deux touches pour être saisie : oh mon dieu c'est la fin du monde...
[^] # Re: Et beh...
Posté par pemo . Évalué à 4.
Le "`" est bien connu dans la communauté Lisp et symbolise un echappement. Il manque encore la "," qui permet de revenir dans le contexte de départ.
Quant au "%", il est aussi difficile à saisir que "{", "(" ou "*". On va dire que Tom n'est pas fait pour les programmeurs qui ont des difficultés à appuyer sur 2 touches en meme temps :-)
[^] # Re: Et beh...
Posté par Mildred (site web personnel) . Évalué à 4.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 3.
Si tu as une référence, ça m'intéresse. Je ne suis même pas sûr que ce soit réfutable, comme hypothèse.
Tiens, amusant, il y a aussi une page sur wikipedia concernant les langages et l'hypothèse Sapir Whorf: http://en.wikipedia.org/wiki/Sapir-Whorf_and_programming_lan(...)
C'est tellement peu conforme à mon intuition et à mon expérience personnelle que je ne sais pas vraiment comment y répondre.
On pourrait prendre un cas extrême inspiré du langage Whitespace. Avec un alphabet comportant uniquement deux caractères, l'espace et le retour à la ligne, on peut tout à fait construire un langage qui permet d'exprimer des concepts de haut niveau. Faut être cinglé pour vouloir faire ça, mais on peut.
D'un autre côté, comme c'est un exemple extrême, ce n'est pas très satisfaisant. Et comme la plupart des langages ont été conçus pour être utilisables par des humains, on ne trouvera pas dans la nature d'exemples flagrants de syntaxe qui rend le code illisible, car la sélection naturelle des programmeurs l'aurait éliminée.
(note, au passage, que je n'ai rien contre la syntaxe de Tom, hein :)
[^] # Re: Et beh...
Posté par outs . Évalué à 3.
La forme forte est réfuté car les humains sont capables de se représenter des concepts et de faire des raisonnements quand bien même ils ne possèdent pas de vocabulaire ou de langues adaptées. Ce qui indiquerait que le cerveau n'utilise pas forcement le langage pour manipuler les concepts.
La forme faible de l'hypothèse dit que le langage facilite le raisonnement, alors la on peut rentrer dans des polémiques sans fin (comme tu l'a dis c'est pas forcement réfutable). Forcement si on dispose d'une langue qui colle exactement a ce que l'on veux exprimer cela facilite les choses, d'un autre coté les êtres humains sont capable de créer de toutes pièces les représentation qui leurs manque ...
Je suis très probablement d'accord avec toi mais il faut absolument faire la distinction entre :
- le choix des lexèmes
- la syntaxe
- la sémantique
Le witespace n'a pas uniquement un choix lexical particulierement peu lisible mais aussi une sémantique très peu expressive. Si tu remplace les 3 lexemes (et non pas deux) qui sont " ", "\t" et "\n" par A,B et C en prenant bien soin de choisir A,B et C de telle manière que cela soit le plus lisible possible. Et bien cela restera illisible. Parceque la sémantique, c'est à dire le sens, que possède les mots clés ne permet pas de représenter facilement les choses.
Inversement si tu prend un langage très expressif et que tu lui colle des lexèmes et une syntaxe la moins claire possible cela restera facile à lire, car le cerveau est suffisament plastique par s'adapter a beaucoup de situation. Regarde par exemple le lambda-calcul, avec juste lambda, des parenthèses et des variables on peut réaliser des programmes très lisibles sont on indente les choses correctement.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 2.
Ça ressemble plus à un indice contre l'hypothèse qu'à une réfutation formelle. Il est possible que notre langage influe sur la manière dont on pense et qu'on soit quand même capable de penser des choses difficiles à formuler dans notre langage.
Je n'y ai pas réfléchi en détails, mais je prend un exemple de ce qui me reste de mes souvenirs de Lojban. Il y a dans le langage une manière naturelle d'exprimer "à droite de X, qui me fait face", ou bien "à gauche de X, qui fait face à Y". Évidemment, on est capable de concevoir "à gauche de X qui fait face à Y" et de le traduire en position, mais ça demande toujours un temps de réflexion, et de nombreuses personnes ont du mal à imaginer les rotations d'objets ou de point de vue[1]. Il me semble que si ces gens parlaient une langue qui utilise ce genre d'indicateurs de position aussi naturellement que "à ma gauche", leur capacité de faire des rotations mentales serait plus développée. (Ou alors c'est une limite biologique et ils auraient du mal à comprendre les phrases, mais ça me semble moins probable.)
[1]: il me semble qu'on se sert d'ailleurs de ça dans certains tests psychologiques ou tests de QI: on montre une image de main et on demande si c'est une main gauche ou une main droite. Ou bien on demande "parmis ces images, laquelle est une rotation de cet objet ?".
[^] # Re: Et beh...
Posté par Alex G. . Évalué à 3.
Je pense que le probleme principale d'une syntaxe compliquée est que cette syntaxe te pompe une bonne partie de tes facultées (mémoire immédiate etc...) ce qui peut se dépasser par l'apprentissage (mais c'est bien du temps perdu).
Perso si j'aime Python par dessus tout c'est bien pour ça. De plus un langage de bas niveau te prendra plus de ligne qu'un langage de haut nivaue pour exprimer la même choses ce qui est là encore une mobilisation importante de tes facultés sur l'outil plutôt que sur le problème.
[^] # Re: Et beh...
Posté par Antoine . Évalué à 2.
Justement la syntaxe est la convention collective de base, intangible.
C'est pour cela qu'une syntaxe compliquée ou ambigüe entraînera du code moins lisible, même avec tous les efforts du monde.
[^] # Re: Et beh...
Posté par pemo . Évalué à 4.
Si vous avez une idee de meilleure syntaxe, qui permette de parser les instructions introduites sans avoir a parser le langage hote (C ou Java) et qui soit compatible avec les differents modes de vim ou d'emacs, je suis sur qu'elle sera retenue et qu'elle remplacera rapidement la syntaxe actuelle.
[^] # Re: Et beh...
Posté par Brice Goglin . Évalué à 10.
Apparemment, tu t'es bouffé plus de Caml que de grammaire...
[^] # Re: Et beh...
Posté par Paul Balança . Évalué à 2.
J en bouffe egalement plein cette année, et ca me lourde egalement la syntaxe vraiment merdique (rien qu un if / else est mal foutu a la base vu que tu sais pas vraiment ou il se termine).
Sans parler bien sur de l interface CamlWin. C est mal foutu.
Pour dire, je m etais rapidement amusé a reprogrammer une interface en C, et j en ai pas eu pour longtemps pour faire qqchose de mieux foutue. Rien que de colorer la sortie en rouge pour une erreur apporte bcp en clarté.
Enfin, voila, pour le peu que j ai vu des projets de l INRIA, ca reste assez decevant. A par en prepa / université, je vois pas ou ils sont utilisés tous ces langages.
Pourtant, je vous assure que je cracherais pas sur un projet francais informatique bien foutu, par ex Lisaac pourrait me sembler sympa comme concept (j ai pas assez de connaissances en info pour reellement en juger), malheureusement, la syntaxe est encore loin de m attirer.
[^] # Re: Et beh...
Posté par Anonyme . Évalué à 4.
Je ne sais pas, mais quand je vois:
if (blabla) {
foo();
} else {
bar();
}
Je ne vois pas comment on pourait se tromper...
Et l'Isaac, c'est marrant, mais on en entend pas beaucoup parler....
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Et beh...
Posté par _ . Évalué à 2.
Je ne pense pas que le but de l'INRIA soit de fournir le nouveau langage utilisé en prépa... et d'ailleurs c'est déjà fait puisqu'ils utilisent caml.
Les langages qui sortent de l'INRIA sont souvents enseignés au départ dans l'université à laquelle le langage est rattaché, puis dans d'autres au gré de l'utilisation de ses langages par les équipes/thésards qui l'utilisent. SmartEiffel est enseignés dans bon nombre d'universités, et même à l'étranger par exemple.
Mais je crois que le but d'un labo de recherche dans le domaine des langages informatiques, c'est de mettre le doigt sur un nouveau paradigme de programmation, même si ce n'est pas la première implantation de la chose qui sera retenue. De ce point de vue, TOM sort un peu des chemins battus puisqu'il propose un langage dont on pense qu'il peut vraiment apporter un plus tout de suite à l'industrie. Ca ne l'empêche pas d'introduire des notions intéressantes en recherche comme les ilôts formels, ou la combinsaison de stratégies... d'ailleurs puisqu'on en parle la sortie de TOM peut être certifiée à chaque compilation à l'aide des prouveurs coq et zenon.
[^] # Re: Et beh...
Posté par gc (site web personnel) . Évalué à 4.
Rien qu'en se limitant au monde linuxien mainstream, les logiciels suivants sont programmés en ocaml: advi, bibtex2html, camlgrenouille, coq, drgeocaml, findlib,
freetennis, gmetadom, hevea, htmlc, ledit, mathplot, mldonkey, monotone-viz, omake, spamoracle, unison, et v6.
D'autre part, la qualité d'un langage ne se mesure pas uniquement au nombre de ses utilisations (sinon C voire C++ seraient des très bons langages, affirmations avec laquelle de plus en plus de gens de tous horizons se distancient). On pourrait citer le fait que l'ICFP[1] a été gagné par un programme en ocaml (plusieurs fois je crois, mais je ne trouve pas les podiums facilement). On peut citer de nombreuses choses. Mais si on juge l'utilisation, on se retrouve noyé dans les obligations industrielles et on obtient des langages comme Cobol, Fortran, C, C++ ou Java en premier, alors que les programmeurs passionnés préfèrent (et utilisent) souvent des langages plus à la pointe.
[1] http://www.cs.luc.edu/icfp/
[^] # Re: Et beh...
Posté par salvaire . Évalué à 3.
Le système éducatif Français est en partie basé sur la sélection ...
Enseigner Ocaml en prépa ou en première année universitaire est à mon avis une erreur. Critiquer quelque chose qu'on comprend pas aussi!
# Inutile
Posté par imalip . Évalué à 1.
[^] # Re: Inutile
Posté par neologix . Évalué à 1.
http://linuxfr.org/2006/03/09/20473.html
J'avais raté le fil a l'époque.
J'ai une question, parce que ce n'est pas très clair dans ma tête.
C'est une sorte de méta-langage, qui effectue des optimisations avant de transformer le code en C.
Donc (je ne connais quasiment rien en compilateurs), on ne pourrait pas considérer qu'il empiète sur le boulot du compilateur?
En gros, avec un compilateur qui va bien, on doit pouvoir se ramener avec un programme écrit en C au même niveau de performance/taille d'exécutable que ce qu'on arrive à faire avec Lisaac?
[^] # Re: Inutile
Posté par _ . Évalué à 4.
si je veux faire une liste chaînée "générique" en C par exemple j'écris :
struct linked_list {
void* value;
struct linked_list* next;
};
c'est le choix notemment de la glib.
Maintenant en eiffel/c++ j'écrirai une liste chaînée réellement générique:
template class linked_list ...
et je l'instancie avec linked_list par exemple. (dans le cas de caml, le type est inféré, caractéristique qui semble avoir été mise de côté dans les débats ci-dessus mais peut-être que les personnes qui ont un peu vite vomi sur le langage n'en ont même pas pris conscience). Et là, même si du code C est généré par le compilo eiffel/c++/caml, il sera plus efficace parce que le compilo aura un vrai type à la place de void* et poura faire des optimisations sachant par exemple que le champ value ne pourra pas pointer sur linked_list.
Le typage (qui comme par hasard est fort en caml) apporte donc des infos nécessaires à l'optimisation en plus de fournir une abstraction du programme assez proche du langage pour qu'une bonne partie des erreurs de programmation soit détectées à la compil.
[^] # Re: Inutile
Posté par _ . Évalué à 1.
il fallait lire
linked_list< T >
et
linked_list< toto >
[^] # Re: Inutile
Posté par outs . Évalué à 8.
Beaucoup de compilo performant sortent du C, c'est le cas de OCaml, et SmartEiffel par exemple.
La raison à cela est que les optimisations réalisé par le compilateur C et Lisaac sont totalement indépendantes. Du coté C on s'occupe des spécificité des processeurs, utilisation correcte des registres etc Du coté du compilo Lisaac (ou n'importe quel autre langage au niveau comme eiffel ou caml) on fait des optimisations du style traitement du la récursion terminale, gestion du polymorphisme. Ce n'est pas du tout le même travail.
L'autre chose a comprendre est que les compilateurs C ne peuvent pas faire ce genre de choses haut niveau car le langage n'est pas prévu pour. En C ou en C++ on est sensé gérer à la main les optimisations de haut niveau comme l'inlining en C++ ou décider de ne pas mettre un méthode virtual en C++ ou l'utilisation fine de pointeurs en C. A cause de ca le compilateur n'a pas la lattitude de faire des optimisation il doit suivre exactement les instructions du programmeur sinon le programme ne réalisera pas les choses de la façon exacte qui a été demandé et cela le fera planter.
[^] # Re: Inutile
Posté par neologix . Évalué à 1.
Touché ;-)
Mais je suis tenté de répondre que le C est un langage de haut niveau, on ne peut donc pas placer C->asm sur le même plan que Lisaac->C
Sinon, merci pour ces explications, je comprends mieux l'idée.
[^] # Re: Inutile
Posté par Vivi (site web personnel) . Évalué à 2.
si tu veux dire par là que le compilateur OCaml génére du C qui est ensuite compilé par gcc, c'est complètement faux, le compilateur ocaml génère de l'assembleur directement.
[^] # Re: Inutile
Posté par outs . Évalué à 2.
Ca a toujours été le cas ou au debut ils utilisaient le C ?
[^] # Re: Inutile
Posté par Vivi (site web personnel) . Évalué à 3.
[^] # Re: Inutile
Posté par Yusei (Mastodon) . Évalué à 6.
Probablement pas, parce qu'il est plus facile de descendre que de remonter.
Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.
Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?
- Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.
- L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.
- L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.
[^] # Re: Inutile
Posté par Philip Marlowe . Évalué à 1.
Moins tous ceux qui seront passés à Sather...
[^] # Re: Inutile
Posté par Ontologia (site web personnel) . Évalué à 2.
On vient de monter un embryon de wiki.
Tout est là, j'ai mis un section par numéro de version de la spec.
Bref, Lisaac n'est pas un langage figée, masi un langage évolutif à conditions que les idées soient bonnes et restent cohérentes avec le reste.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Inutile
Posté par outs . Évalué à 3.
[^] # Re: Inutile
Posté par Ontologia (site web personnel) . Évalué à 2.
http://wiki.loria.fr/wiki/ProjetIsaac
Je crois qu'il va falloir que je fasse un petit journal...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Inutile
Posté par reno . Évalué à 2.
Je sais je suis lourd avec Scala, je -->[]
[^] # Re: Inutile
Posté par Philip Marlowe . Évalué à 2.
Ben pas du tout. C'était juste pour dire une blague, je connais à peine Sather. Et quitte à apprendre un nouveau langage, je me mettrais plutôt à Lisaac qui me semble avoir plus d'avenir.
[^] # Re: Inutile
Posté par golum . Évalué à 6.
Son nom à lui c'est
Lisaac et ce n'est pas un concurrent de Jacob
[^] # Re: Inutile
Posté par imalip . Évalué à 1.
# Hem
Posté par Pierre Tramonson . Évalué à 5.
Ca risque pas d'avoir un grand succès si personne ne sait à quoi ça sert et comment ça marche.
[^] # Re: Hem
Posté par _ . Évalué à 3.
Pour faire le lien avec une technologie connue, c'est comme du XSLT sauf qu'au lieu de réécrire des arbres XML on réécrit n'importe quelle structure de donnée, y compris les structures du langage hôte (par exemple, on peut réaliser un mapping de java XML dom vers tom et réécrire des arbres DOM).
Un exemple d'utilisation réaliste est la section 3 du tutoriel ou on réécrit toutes les occurences de "if not a then b else c" en "if a then c else b" partout dans l'arbre abstrait d'un programme : on voit donc les applications pour les compilateurs.
[^] # Re: Hem
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Hem
Posté par Paul Balança . Évalué à 3.
[^] # Re: Hem
Posté par _ . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.