Journal Le langage L

Posté par  .
Étiquettes : aucune
0
13
jan.
2007
Bonjour à tous,

Je suis en train d'écrire un langage de programmation sympathique, et j'aimerai avoir des opinions dessus.

Mon langage pourrait être décrit comme un mélange entre Lisp et C:

-Il hérite de la syntaxe de C, permet l'utilisation de pointeurs et de constructions bas niveau, il est type statiquement comme C. En fait, il s'interface extrêmement bien avec le C, ce qui est bien pratique.

- Il est extensible comme en Lisp, avec la définition de nouvelles macros permettant l'extension du langage, on peut le compiler interactivement, et il est plus base sur les expressions que les statements.

Il y a aussi des différences avec ces deux langages:

- il est typé fortement
- les macros peuvent utiliser les informations de typage
- La syntaxe aussi est extensible

Il existe des langages implémentant ces fonctionnalités independamment (quoique les deux dernières sont assez rarement rencontrées), mais leur combinaison en fait quelque chose de sympa.

Au niveau de l'avancement, tout ce qui est raconte dans la page web est vrai, mais le langage est pour le moins loin d'être fini: j'ai toujours pas de flottants par exemple (ce n'était pas l'important pour le moment), et bon il y a quasiment encore aucune librairie.

Voila, l'adresse de la page web du langage est http://www.nongnu.org/l-lang, la mailing liste est l-lang-devel at nongnu dot org, et si vous êtes interessés, n'hésitez pas à contribuer!
  • # Evidemment

    Posté par  . Évalué à 3.

    Je me suis fait avoir par le bug de l'URL.

    C'est donc: http://www.nongnu.org/l-lang
  • # Le L est déjà pris

    Posté par  . Évalué à 2.

  • # Comme XP^WPerl6 ?

    Posté par  (site web personnel) . Évalué à 2.

    - il est typé fortement
    - les macros peuvent utiliser les informations de typage
    - La syntaxe aussi est extensible

    Il existe des langages implémentant ces fonctionnalités independamment (quoique les deux dernières sont assez rarement rencontrées)
    Dylan ? Perl6 ? Template Haskell ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Comme XP^WPerl6 ?

      Posté par  . Évalué à 2.

      OCaml (avec camlp4) \o/
      • [^] # Re: Comme XP^WPerl6 ?

        Posté par  . Évalué à 2.

        J'ai dit rarement, pas jamais!

        Pour Perl, je connaissais juste un module pour Perl5 qui reanalysais son code source, est-ce plus elabore sur Perl6?

        Je ne connaissais pas Template Haskell ni savait que Dylan savait etendre sa syntaxe; en fait je n'etait au courant que de Camlp4. Je jetterai un oeil a tout ca, merci.
        • [^] # Re: Comme XP^WPerl6 ?

          Posté par  (site web personnel) . Évalué à 1.

          Ou surtout, Scheme lui même; notement par le biais de Gambit et de la « Scheme infix syntax extension ».
          Les gens qui n'utilisent pas Scheme sont condamnés à l'instancier... Respect ceci dit : j'en serais incapable.
          • [^] # Re: Comme XP^WPerl6 ?

            Posté par  . Évalué à 2.

            Je ne suis pas d'accord: le SIX syntax extension est bien une extension a la syntaxe de Scheme, mais cette extension me semble predefinie. Il me semble impossible de rajouter des nouvelles grammaires dynamiquement, comme je le fais en L dans l'exemple du XML.

            Et puis l'interet de L n'est pas que dans sa syntaxe extensible: l'usage de macros a la common Lisp dans un language type statiquement n'est pas si courant (pour reprendre l'exemple donne plus haut, il faudrait utiliser Ocaml + Camlp4 + MetaOCaml pour reproduire mon exemple de compilateur d'automates a partir d'expressions rationnelles), surtout dans un langage pas uniquement fonctionnel .
            • [^] # Re: Comme XP^WPerl6 ?

              Posté par  (site web personnel) . Évalué à 1.

              Scheme est loin d'être uniquement fonctionel, et on peut bel et bien y définir des syntaxes nouvelles par les macros.
              • [^] # Re: Comme XP^WPerl6 ?

                Posté par  . Évalué à 3.

                Exact, mais scheme n'est pas type statiquement (OK, il y a des extensions qui le font).

                Et quand je parle de modification de syntaxe, je parle de syntaxe concrete, pas de syntaxe abstraite. Les macros lisp/scheme permettent de changer de syntaxe concrete, les modifications du reader lisp permettent de changer (dans une certaine mesure) de syntaxe concrete.

                L permet de changer completement la syntaxe concrete ET la syntaxe abstraite.
  • # Le monde a-t-il besoin d'un nouveau langage de programmation ?

    Posté par  . Évalué à 4.

    Je me suis posé cette question un jour et je me suis répondu non. Et j'ai trouver mieux a faire qu'un nouveau langage. Si tu veut que ton langage devienne polulaire je te souhaite bonne chance, la concurence est plutot rude.
    • [^] # Re: Le monde a-t-il besoin d'un nouveau langage de programmation ?

      Posté par  (Mastodon) . Évalué à 5.

      À la même question, je répondrais "oui", pour ma part. Tout simplement parce que je n'ai pas encore trouvé de langage qui me satisfasse pleinement. J'aimerais bien un truc ressemblant à Ruby mais permettant d'imposer facilement plus de rigueur au niveau du typage. Le duck typing c'est souvent bien, mais des fois on aimerait bien avoir quelques garanties.

      Eiffel est proche de la perfection (selon moi bien sûr), mais il lui manque un petit côté fonctionnel comme possède Ruby. J'accueillerais avec plaisir un mélange entre les deux.
  • # Expliquer...

    Posté par  . Évalué à 2.

    Ce que je trouverais intéressant, pour les moins informaticiens d'entre-nous (comme moi par exemple ^_-), serait d'expliquer l'approche d'un tel developpement.

    Pour ma part, j'aimerais réellement connaître les tenants et aboutissants
    Bref, le "comment c'est k'on fait?" :)
    Je connais quelques langages de script (python, ruby) mais je n'ai absolument aucune idée de comment cela a été rendu possible.

    Je suis tjrs étonné de voir des personnes se lancer dans un tel projet.

    Ceci étant, bonne chance à toi
    • [^] # Re: Expliquer...

      Posté par  . Évalué à 3.

      En fait, tu voudrais connaître la théorie derrière tout ça ? Savoir comment un code source peut-être compilé en binaire exécutable (ou interprété, le cas échéant) ?

      Eh bien ça n'a rien de trivial. Inventer un langage et les outils pour le lire demande de sérieuses bases théoriques et de longues heures de pratique (allez, en référence universitaire, je dirais un bon niveau M1 en info).
      En fait je vois mal comment expliquer l'essentiel en quelques lignes... mais c'est peut-être parce qu'il est tard aussi ;-)

      Cela dit, quelque pointeurs :
      * http://fr.wikipedia.org/wiki/Langage_de_programmation
      * http://fr.wikipedia.org/wiki/Interprète_(informatique)
      * http://fr.wikipedia.org/wiki/Compilateur
      * http://fr.wikipedia.org/wiki/Analyse_syntaxique
      * http://fr.wikipedia.org/wiki/Sémantique_des_langages_de_programmation
      * les manuels de lex et yacc pour la pratique et l'apprentissage par la bidouille
    • [^] # Re: Expliquer...

      Posté par  . Évalué à 3.

      Je comprend pas exactement ce que tu veut savoir mais je vais essayer de répondre.

      l'ordi il ne peut faire que des opérations vraiment simplissime genre des operation mathématiques + - * mais une par une, des tests egalité superiorité tout ça (mais un par un) des sauts et des déplacement de mémoire.

      donc quand tu fait
      x=(a+b)*(c+d)
      le pross il fait en gros ( rX c'est des registres)
      r0=a
      r1=b
      r0=r0+r1
      r2=c
      r3=d
      r2=r2+r3
      r0=r0*r2
      x=r0

      enfin pour le pross c'est pas du texte c'est des code en binaire qui veulent dire ça.

      et donc toute la subtilité d'un compilateur c'est de transformé des operations compliqués en plein d'operations unitaires. genre quand t'appelle une methode d'un objet, il s'en passe plein des choses.

      j'espere que c'est ce que tu voulait savoir.
    • [^] # Re: Expliquer...

      Posté par  (Mastodon) . Évalué à 4.

      Il y a deux aspects, je ne sais pas auquel tu penses en demandant "comment c'est k'on fait", mais je vais tenter de résumer les deux:

      1- Créer le langage

      il faut qu'il soit analysable par un programme, donc contrairement aux langages naturels, il va devoir avoir une grammaire plus stricte et non ambiguë.

      Il faut essayer de faire entrer les fonctionnalités que l'on veut dans la syntaxe sans la rendre trop lourde ou ambiguë.

      Il faut choisir parmis les différentes manières de programmer celle(s) que l'on veut introduire dans le langage, par exemple:

      - est-ce que les variables ont un type défini lors de leur création, ou bien est-ce que ce type peut changer ?

      - peut-on redéfinir les opérateurs ? Par exemple si on crée un "objet" Matrice, peut on redéfinir l'opérateur "+" pour écrire "m1 + m2" ou bien doit-on définir une nouvelle fonction "addition_matrice" ?

      - indique-t-on les opérations que l'ordinateur doit effectuer, dans l'ordre, ou bien indique-t-on les calculs qu'il doit faire, en le laissant décider comment il les fait ?

      etc.

      2- Créer un compilateur ou interpréteur

      Il y a plusieurs étapes:

      - Créer la fonction qui transforme le texte du programme en quelque chose de plus facilement exploitable, une représentation intermédiaire. Pour prendre l'exemple des opérations arithmétiques:
      a = 1+2*6+3
      va être découpé pour indiquer comment on fait les opérations:
      2*6
      +3
      +1
      affecté à a

      Pour les grammaires courrament utilisées, l'écriture de cette fonction est à peu près automatique, car il y a des outils qui le font automatiquement. Lex (flex chez GNU) se charge de découper le texte en tokens, puis Yacc (Bison chez GNU) prend une grammaire et permet simplement de construire la représentation intermédiaire.

      - Si possible, on essaye d'optimiser cette représentation intermédiaire (surtout si on fait un compilateur). Par exemple si on voit qu'à plusieurs reprises on additionne deux variables sans que leurs valeurs changent, on va essayer d'éviter de refaire l'addition à chaque fois. L'optimisation de la représentation intermédiaire, c'est difficile.

      - Ensuite, si on fait un interpréteur, on doit "lire" la représentation et effectuer les opérations demandées, pour calculer le résultat. Si on fait un compilateur, c'est pareil, sauf qu'au lieu d'exécuter les instructions on les traduit dans un autre langage. On les traduit en langage machine si on veut directement faire un programme, mais on peut aussi les traduire en C puis compiler le tout avec gcc, c'est plus simple.
      • [^] # Re: Expliquer...

        Posté par  . Évalué à 3.

        Juste pour preciser: L ne depend ni de flex ni de yacc.

        Pour l'analyse lexicale (equivalent de flex), j'ai ecris une librairie qui analyse un ensemble d'expressions rationnelles, en construit un automate deterministe, et le compile en assembleur. Il n'a pas besoin de dependences exterieures comme la libflex.

        La difference avec flex, c'est que flex construit une table pour l'analyse lexicale, qu'il "interprete". Tandis que mes automates sont compiles.

        L'interet de ma technique est essentiellement la rapidite, le fait qu'on peut generer des scanners sans dependance exterieure, et le fait que je vais pouvoir directement utiliser ca pour creer ma librairie de regexp. Le desavantage c'est la place prise en memoire (par exemple, on ne peut pas utiliser des tables compressees).

        Je n'ai pas fait de tests comparatifs de rapidite avec flex, mais j'en avais fait avec la libpcre (pour une seule expression rationnelle "matchee" en meme temps), et le resultat etait 10x plus rapide que la PCRE. Par contre, on ne gere pas tout ce qui n'est pas vraiment des expressions rationnelles (les trucs comme "<(\w+)>.*<\1>" par exemple), parce que ca ne peut pas etre compile en automate deterministe. Et puis, les extensions necessaires pour recuperer les resultats d'un match ne sont pas encore ecrites.

        De meme, je n'utilise pas bison : j'ai ecrit un parser en descente recursive. Ca me permet justement de pouvoir etendre ma syntaxe en rajoutant des parsers au run-time. Pour faciliter l'ecriture de nouveaux parseurs, je prevois l'ecriture d'un "parse language", qui permet d'ecrire la regle de grammaire directement, et qui sera compilee en une fonction de parsing.

        Ah, et au final, mon programme genere du code x86 directement en memoire
        (ce qui permet un processus de developpement interactif), mais je suis en train de rajouter la possibilite de sortir du C.
        • [^] # Re: Expliquer...

          Posté par  (Mastodon) . Évalué à 2.

          D'ailleurs il y a un paquet d'interpreteurs/compilateurs qui utilisent des parseurs faits à la main pour des raisons de rapidité. Si j'ai parlé de lex/yacc c'était surtout pour souligner qu'on peut s'amuser à faire son propre langage sans apprendre tous les détails de l'analyse lexicale et syntaxique.
      • [^] # Re: Expliquer...

        Posté par  . Évalué à 2.

        C'est plus l'introduction de ces subtilités "sémantiques" qui m'échappent.
        Comment arrive t-il a traduire ses idées?

        J'ai également du mal à déterminer "l'oeuf et la poule" dans cette histoire :)
        Là le langage "L" part de quoi? tout comme le langage avant celui-ci...
        En gros, qu'est-ce qui vient juste après le rien, qui permette à Matthieu de s'amuser?

        Vous remarquerez, que c'est très naïf comme question héhé
        Je ne cherche aucunement à me lancer dans ce genre d'entreprise, mais ma curiosité sur le sujet ne veut pas me lâcher.

        bye et merci pour vos interventions

        ps: evidemment, si vous avez un bouquin sous la main, pourquoi pas
        • [^] # Re: Expliquer...

          Posté par  . Évalué à 3.

          Pour ma part, j'ai teste beaucoup de langages de programmations, parmi lesquels C, Common Lisp/Scheme, Ruby, Caml, Perl, PHP, Java, et de l'assembleur.

          J'ai beaucoup apprecie le style de programmation de Lisp, dans lequel on peut etendre son language completement en ajoutant de nouveaux operateurs.

          Il se trouve que je programme beaucoup en C que j'aime beaucoup, et j'aime bien appliquer cette pratique en C, mais le preprocesseur C ne permet pas tout. Ce qu'il faut, c'est que l'outil de metaprogrammation soit integre au langage. D'ou l'idee de L.

          Par ailleurs, le style de developpement de Ruby est aussi interessant. Je ne suis pas forcement un afficionado du concept "tout est objet", mais l'integration entre
          les cotes fonctionnels et imperatifs de Ruby est remarquable.

          J'aime aussi les langages fortement types statiquement a la Caml; je trouve que definir des nouveaux types permet de clarifier fortement un programme.

          J'ai eu la chance de suivre des cours de compilation lors de mon cursus, et j'ai donc tente de creer un langage qui combinait toutes les fonctionnalites que j'aime bien : extensible, bas-niveau, type fortement, multi paradigme, plus quelques idees auxquelles j'avait deja pense, mais jamais pu realiser faut de support du langage.

Suivre le flux des commentaires

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