Sortie du langage de programmation Tom 2.4

Posté par . Modéré par Mouns.
Tags :
0
5
oct.
2006
Technologie
Six mois après la dernière version, la version 2.4 du langage TOM vient de sortir, apportant son lot d'innovations.

TOM est un langage de programmation développé au sein de l' INRIA et qui marie le meilleur des mondes des langages fonctionnels et impératifs en ajoutant du filtrage de motifs («pattern matching») et de la programmation par statégies à Java, C ou OCaml.

TOM permet de manipuler des arbres (termes, AST, XML, ...) grâce à un mécanisme de filtrage puissant (travaillant aussi sur des listes) sur les types Java/C. De plus, il fournit un outil permettant de générer des arbres non-mutables en Java avec partage maximal de la mémoire et invariants (listes triées, sans doublons, arbres balancés, ...).

Combiné avec un langage de stratégies réflexives, il est utilisé entre autres pour :
  • développer des compilateurs (comme le compilateur Tom) ;
  • transformer à la volée du bytecode Java ;
  • le développement d'un assistant à la démonstration ;
  • générer des sites web (transformations de XML plus puissantes que XSLT grâce aux stratégies)

Le compilateur est stable et mature, et la documentation est fournie et à jour. De plus, l'environnement de programmation est multi-plate-forme et convivial : greffon vim, tâches ant, greffon pour l'IDE Eclipe.

Le tout est publié sous des licences libres (GPL et BSD). Cette version s'inscrit dans la continuité de notre travail d'intégration de capacités de filtrage de motif et programmation par règles dans les langages C et Java. Sa conception fait suite aux recherches de l'équipe en matière de compilation efficiente des langages à base de règles (cf ELAN, développé au Loria).

Tom est un compilateur qui ajoute de puissantes constructions aux langages C, Java et OCaml; filtrage de motifs non-linéaire, filtrage de motifs associatif avec élément neutre (càd filtrage de listes), filtrage de motifs XML, filtrage de chaînes de caractères, et réécriture équationelle. Il permet d'analyser et de transformer n'importe quel type de structure de données.

Pour avoir un aperçu de sa syntaxe, se référer à la dépêche précédente ou au tutoriel.

Cette nouvelle version contient de nombreuses améliorations et nouvelles fonctionnalités :
  • Anti-motifs (anti-patterns) :
    Tom supporte à présent le filtrage d'anti-motifs. Par exemple, le motif (_*,!a(),_*) représente une liste qui contient au moins un élément différent de a(). De manière similaire, !(_*,a(),_*) représente une liste qui ne contient aucun a().
  • Stratégies réflexives :
    Les stratégies sont à présent des termes contre lesquels on peut filtrer comme n'importe quel autre terme. Cela permet la construction et la modification des stratégies à l'exécution.
  • Stratégies de congruence :
    Gom génère à présent de nouvelles stratégies élémentaires de congruence et de construction. Cela permet par exemple la définition aisée de la stratégie "map" : map(s) = _cons(s)
  • Bytecode Java :
    Le support de l'analyse et la transformation de bytecode java est disponible dans la bibliothèque standard. Il permet le chargement de classes, la transformation de bytecode et son analyse dans cadriciel algébrique. Le graphe de flot de contrôle du bytecode peut être exploré à l'aide langage de stratégies et visualisé avec dot.
  • Greffon Eclipse :
    De retour pour Eclipse 3.2. Il supporte Gom et les nouvelles fonctionnalités de Tom.
  • # La dépêche précédente

    Posté par (page perso) . Évalué à 2.

    L'adresse de la dépêche précédente : http://linuxfr.org/2006/04/28/20738.html
    • [^] # Re: La dépêche précédente

      Posté par . Évalué à 6.

      Tu parles du premier lien de la dépêche ?

      ;-)

      ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

      • [^] # Re: La dépêche précédente

        Posté par . Évalué à 5.

        Bah, si le 'se referer a la depeche precedente' avait un lien au lieu de le planquer au début de la dépèche, il n'aurait pas posté ce message!

        Elle est quand même un peu mal fichu cette depeche par certain coté:
        -lien mal placé pour le coup de la derniere dépèche
        -'stratégie "map" : map(s) = _cons(s)' quel bel exemple immédiatement compréhensible.
        -programmation par stratégie terme mystèrieux avec un un lien a un texte peu informatif (et en Anglais) qui fait référence a un texte tout aussi peu informatif qui fait référence a un bouquin, super!

        Promis quand le language D sort en version 1.0, j'essaye de faire une depeche mieux tournée.
        • [^] # Re: La dépêche précédente

          Posté par (page perso) . Évalué à 5.

          Ce qui m'étonne le plus dans cette dépêche, c'est qu'elle passe en seconde page (qui contient 80% d'infos locales), c'est d'ailleurs aussi le cas de la sortie de bzr (bon c'est vrai que pour bzr, ils sortent des versions souvent...) alors que la dernière gueulante de Theo de Raadt passe en première page.

          <mauvaise foi>
          La ligne éditoriale de ce canard ferait dans le sensationnalisme que ça ne m'étonnerait pas
          </mauvaise foi>
        • [^] # Re: La dépêche précédente

          Posté par . Évalué à 3.

          L'article (et non le livre) auquel le texte peu informatif en anglais fait référence se trouve en ligne et le texte en question contient un lien http (en haut à droite) qui pointe dessus: http://www.cs.uu.nl/~visser/ftp/eosp.ps

          Désolé pour le lien en anglais mais personne n'a encore écrit en français sur la question à première vue. Quant à ne pas pointer l'article directement mais une entrée dans "program-transformation.org", on a pensé qu'une courte description du pattern repousserait moins de gens que la lecture d'un long article, disponible pour les plus intéressés.
  • # Programmation par stratégies

    Posté par (page perso) . Évalué à 6.

    Je comprend pas trop les concepts de la "programmation stratégique". J'ai jeté un oeil sur le papier Ralf Lämmel là http://homepages.cwi.nl/~ralf/eosp/ et ce que j'en comprend en lisant http://tom.loria.fr/soft/release-2.4/manual-2.4/manual004.ht(...) (parce que la publi est pas très claire), il s'agirait de définir des primitives ensemblistes sur des transformations d'éléments.

    En gros on a des primitives

    opérateur (fonction, liste élément)

    Par exemple

    All(Fonction, liste élément) signifie "Vrai si qqsoit x ¤ liste_élément fonction(x) est possible en terme de typage"

    On a des espèce de fonction il_existe, repeat (qui farfouille l'abre), etc...

    J'ai rien compris ou c'est bien ça ?

    Mais à part proposer quelques primitives sympas proposant un espèce de langage axiomatique, ça apporte quoi le paradigme stratégique ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Programmation par stratégies

      Posté par (page perso) . Évalué à 6.

      En gros, une stratégie, c'est un moyen de spécifier, en composant des opérateurs élémentaires (All, One, Sequence...) et un opérateur de récursion, des traversées d'arbre.

      On peut voir ça comme une version étendue du patron de conception "visiteur".
      L'intéret ici est que contrairement au visiteur, qui impose soit de choisir une fois pour toutes la stratégie de parcours (des feuilles à la racine, de la racine aux feuilles), soit de coder dans chaque visiteur une stratégie de parcours, la méthode de parcours est séparée des actions à effectuer sur les noeuds.
      De plus, Tom te donne une interface typée pour spécifier les transformations à appliquer aux noeuds, ce qui est moins évident dans le cas des visiteurs.

      Les expressions de stratégie peuvent être bien plus compliquées que "des feuiiles à la racine" ou l'inverse. Par exemple, on peut coder facilement des points fixes poru les transformations. En plus, les stratégies étant réflexives, on peut changer le comportement de la stratégie en cours de route, pour "réagir" à une certaine configuration de l'arbre.

      Tout ça mis bout à bouts donne des outils plutôt efficaces (en terme de temps passé à écrire du code, ainsi qu'a l'exécution), pour écrire par ex. des compilateurs, qui sont assez consmmateurs de transformations d'arbres, en général.
      • [^] # Re: Programmation par stratégies

        Posté par (page perso) . Évalué à 3.

        En gros c'est de la programmation axiomatique contextualisée à des problèmes de traitement d'arbre.

        Mais pourquoi ne pas généraliser la programmation axiomatique à toute sorte de traitement de données ?

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Programmation par stratégies

          Posté par . Évalué à 3.

          Apparemment les arbres en question semblent satisfaire toutes les problématiques (un arbre de niveau 1 pouvant être vu comme un type scalaire, un arbre de niveau 2 pouvant être vu comme un vecteur ou une hash...).

          Enfin si j'ai bien compris... Merci de me corriger si je me trompe. Je dois admettre que le ton de la dépêche et même de certains commentaires est un peu dur à suivre même pour le codeur que je suis :-) Sans doute le deuxième effet Ralgan...
          • [^] # Putain, les mecs...

            Posté par . Évalué à 2.

            Salut,
            juste pour vous dire que je viens de relire vos 3 posts... (antoine,Ontologia, カリメロ) et je dis dire que je suis impressionné (et que j'ai rien compris apres plusieurs lectures) dire que vous avez l'aire de vous comprendre (bien que je sache ce qu'est un arbre, et que je connaisse vaguement... tres vaguement... les design paterns).

            C'est pas possible, vous devez bosser sur des trucs de fou!...

            surtout ne me dites pas que vous codez un site web, je serait juste dégouté (quel gachis)...

            au plaisir de vous retrouver dans le changelog de gcc, kernel, xorg.... :)

            (ce post est inutile)
            • [^] # Re: Putain, les mecs...

              Posté par . Évalué à 1.

              Antoine est un des pricipaux contributeurs de TOM, bien plus que moi :)
              Ontologia est un contributeur important de Lissac : http://linuxfr.org/2005/11/29/19970.html si je ne me trompe pas.
            • [^] # Re: Putain, les mecs...

              Posté par (page perso) . Évalué à 6.

              Un arbre est une structure de données que l'on retourve très souvent en entreprises, dans toute sorte de logiciel, en entreprise comme dans la recherche.
              A tel enseigne que l'importance du format XML qui permet de représenter des arbres n'est plus à démontrer.

              La programmation par stratégies permet donc de manipuler des données à l'intérieur des arbres.
              Une arborescence de répertoire est par exemple un arbre.

              Voir http://fr.wikipedia.org/wiki/Arbre_%28informatique%29

              (ps : la théorie et la technique c'est pas la même chose, je suis incapable de comprendre une ligne du code source de Kernel ou xorg)

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

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