Le langage Arc, issu de Common Lisp et Scheme, a un mois

Posté par . Modéré par Mouns.
Tags :
1
1
mar.
2008
Science
Le langage Arc est disponible depuis un mois sous la licence Libre Artistic 2 de la perl foundation. Pour info, Arc est un nouveau dialecte Lisp conçu par Paul Graham, un "gourou" de Lisp, qui a écrit 2 ouvrages très réputés sur ce langage et qui s'est fortement enrichi en vendant à Yahoo son application Viaweb, elle-même écrite en Lisp.

P. Graham a conçu Arc car il considérait que le langage Lisp, qui fête cette années ses 50 ans, avait perdu de sa fraîcheur et de sa pureté originelle, celle qu'il avait lorsqu'il a été conçu par John McCarthy à la fin des années 50, lui-même se basant entre autres sur le lambda-calcul élaboré par A. Church quelques années auparavant.

Arc est un langage à la fois minimaliste, comme Scheme, mais voué à être réellement utilisé, Graham étant un programmeur, pas un théoricien. Avant d'être publié, il a d'ailleurs été utilisé pour réaliser une application web : le forum Hacker News, dont le code source est disponible depuis quelques jours.

Le noyau du langage a été écrit en quelques centaines de lignes de Scheme et peut être très facilement étudié. Le reste du langage, c'est une de ses caractéristiques, a été écrit en Arc lui-même.

NdM : pour ceux qui voudraient retracer l'évolution de l'intelligence artificielle côté États-Unis principalement, n'hésitez pas à (re-)lire Crevier et son livre À la recherche de l'intelligence artificielle.
Peu après la publication des premières versions de Lisp au début des années 60, celui-ci a intéressé nombre de développeurs, plus intéressés cependant par les aspects pratiques que par le côté théorique et conceptuel du langage. Et ainsi, les années suivantes, Lisp a été principalement "patché", voyant des ajouts et modifications apportées surtout pour des raisons pragmatiques ou de performance. Et plusieurs versions concurrentes et incompatibles ont alors foisonné.

Des nombreuses versions publiées aux cours des années par les divers vendeurs d'interpréteurs / compilateurs Lisp, il est sorti une norme, Common Lisp. Ce langage est très complet, trop d'après certains. Il en existe diverses implémentations, dont certaines, libres, offrent d'excellentes performances.

Puis Scheme est paru, suite à un désir de certains de"purifier" ce qui était devenu à leurs yeux une véritable "usine à gaz". Scheme est devenu de fait l'un des langages les plus minimalistes qui soient. Il corrigeait aussi certaines "atrocités" de Common Lisp, tel le symbole NIL, représentant à la fois le booléen faux, la liste vide, l'absence de valeur... Désormais, le booléen #f et la liste vide seraient des concepts différents. Les macros ensuite, une des spécifités de Lisp, très puissantes puisqu'elles permettent de générer du code à la volée, très dangereuses aussi. Scheme propose alors des macros, dites "hygyéniques", plus propres mais aussi moins puissantes.

Paul Graham a alors conçu son Lisp idéal, prenant des idées à Common Lisp comme à Scheme. Il voulait un langage à la fois très pragmatique (son objectif est d'obtenir un outil permettant de développer rapidement des applications) et ayant en même temps un noyau aussi minimaliste que possible. L'objectif est que, hormis les axiomes de base, toutes les fonctionnalités du langage soient écrites dans le langage lui-même. Ainsi, le langage est lui-même sa propre spécification et peut être étendu, voire modifié, par le développeur lui-même, au gré de ses besoins.

Le langage est encore en cours de conception et évolue donc régulièrement, mais il est tout à fait utilisable en l'état. Il propose à l'heure actuelle peu de bibliothèques, hormis une librairie web très intéressant (contenant un serveur web et des fonctionnalités permettant de concevoir des applications web basées sur l'utilisation de continuations).

Une petite communauté d'utilisateurs s'est formée, et elle propose certains patchs, améliorations et extensions (expérimentales) au langage. Enfin, P. Graham publie régulièrement de nouvelles versions de l'interpréteur (3 en un mois !), corrigeant certains bugs ou apportant de nouvelles fonctionnalités. À ce sujet, une polémique avait éclaté lors de la sortie du langage : P.G se vantait que Arc ne gérait que l'ASCII et qu'il ne voulait pas passer de temps à gérer Unicode. Au bout de quelques jours, un patch est paru et Arc est maintenant l'un des langages gérant le mieux UTF-8.
  • # Le théoricien rêveur et le programmeur pragmatique, quelle blague !

    Posté par . Évalué à 4.

    | Arc est un langage à la fois minimaliste, comme Scheme, mais voué à
    | être réellement utilisé, Graham étant un programmeur, pas un
    | théoricien.

    Cette phrase a certainement été écrite alors que tu n'étais pas bien réveillé. Il n'y a aucune opposition entre être un programmeur et un théoricien.

    Oui, le théoricien est plein de rêves, mais, parmi eux, on trouve aussi celui de voir ses idées "réellement utilisées". Cependant, pas n'importe lesquelles et pas n'importe comment. Le théoricien a le goût pour les choses bien faites et quand il programme, ces productions sont des oeuvres d'art. Comme tout art, pour l'apprécier, il faut se faire les yeux : se délecter de Knuth, s'irradier de Leroy, se perfuser de Turing.

    De plus, compte tenu du nombre de pisseurs de C que j'ai rencontrés qui pensent qu'en tunant leur assembleur, ils pourront résoudre un problème NP-complet ou bien encore, que, eux, ils programment sans bug, j'ai du mal à dire qui est le plus proche de la réalité.

    Ceci dit, je n'ai rien contre Paul Graham que j'ai pu écouter lors d'une conférence sur les langages fonctionnels (tu sais les langages pour théoricien ;-) ).
    • [^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague

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

      Je trouve que tu es dur, le rédacteur de cette news a au moins partiellement raison : il y a un sens à opposer Graham le "programmeur" à un "théoricien pur" comme Church.
      • [^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague

        Posté par . Évalué à 10.

        Church n'est pas un théoricien, c'est un mathématicien. Il s'est attaqué avec quelques succès à la question de la définition de l'algorithmique et de la calculabilité quelques années avant l'apparition des ordinateurs.

        Son lambda calcul est extrêmement pragmatique, pour résoudre la question à laquelle il s'est attaqué. Et ce n'était pas de concevoir un langage de programmation.
    • [^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague

      Posté par . Évalué à 10.

      "Cette phrase a certainement été écrite alors que tu n'étais pas bien réveillé. Il n'y a aucune opposition entre être un programmeur et un théoricien."

      Oui, enfin il y a quand même quelques divergences dans les objectifs visés. Dans le monde Lisp, il y a traditionnellement de véritables scissions entre les adpetes de Common Lisp, qui ont bidouillé leur langage pour l'optimiser à mort, au détriment de la pureté conceptuelle, et ceux de Scheme, qui sont au contraire plus intéressés par la pureté et le minimalisme conceptuel afin d'avoir le langage le plus simple possible, au détriment de l'efficacité. Je n'invente rien : cherche des Schemeurs dans le monde industriel, tu en trouveras peu. Cherche des Common Lispers parmi les théoriciens des langages, tu en verras aussi peu. Le but de Graham est en quelque sorte de trouver un compromis entre ces deux tendances.

      Et puis, il n'y avait rien de péjoratif là-derrière, j'ai passé plus de temps dans ma vie à utiliser Scheme ou Smalltalk qu'avec C ou C++. J'ai juste voulu préciser ce point en voyant venir de très loin les commentaires du genre "Ouais, mais d'abord, c'est nul Lisp, encore un délire de chercheur dans sa tour d'ivoire qui fait des langages fonctionnels alors que ça sert à rien dans la réalité". Ce genre de choses.
      • [^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague

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

        Euh, les schemeurs sont des gens tres interesses par la conception de langages *et* par l'efficacite'....

        Gambit-C Scheme, Larceny, Stalin, Bigloo... autant d'implantations de Scheme qui sont rudement efficaces, rapides (et qui ne font pas qu'interpreter, mais aussi qui compilent aussi).

        Scheme est le langage ideal pour toutes les demarches de conception de langage, car il y est on ne peut plus simple de creer un langage par dessus, et le monde academique ne s'en prive pas, et l'industrie vient alors utiliser ces produits (je pense a Termite pour Gambit-C, un langage "a la Erlang" sur Scheme). (enfin, la, je crois qu'on est d'accord, mais je suis pas sur d'avoir bien lu ton paragraphe).

        Je persiste et je signe: la simplicite' de Scheme ne s'est pas faite au detriment de l'efficacite'.
  • # bootstrapping myself

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

    > Le reste du langage, c'est une de ses caractéristiques, a été écrit en Arc lui-même.

    Je dirais que c'est une caractéristique minimale pour un langage...

    Le C ça puxor, gcc est écrit en brainfuck, c'est bien connu


    mes 2 cents
    • [^] # Re: bootstrapping myself

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

      Il y a plein de langages qui ne bootstrappent pas (encore). Exemple: les interpreteurs officiels de python, perl et ruby sont écrits en C (a mettant a part le projet Pypy qui est encore assez experimental).

      La VM java n'est pas ecrite en java non plus il me semble.
      • [^] # Re: bootstrapping myself

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

        > ...interpreteurs...
        voilà le problème

        Mais la vrai question est : "Comment puis-je faire, moi aussi, pour faire un programme voué à être réellement utilisé" ???

        Celui qui a la réponse me permettra peut-être de gagner aussi 445000 yahoo shares !

        mes 45M $
      • [^] # Re: bootstrapping myself

        Posté par . Évalué à 5.

        A part pour faire du développement système c'est quoi le gros intérêt d'avoir un langage qui bootstrape ? C'est une preuve de maturité du langage OK mais "pragmatiquement" ca à quel utilité ?
        • [^] # Re: bootstrapping myself

          Posté par . Évalué à 5.

          Avoir une grosse application trés tot pour faire de la validation...

          "La première sécurité est la liberté"

        • [^] # Re: bootstrapping myself

          Posté par . Évalué à 6.

          Dans le cas d'Arc, c'est un peu particulier. Ce n'est pas le compilateur/interpréteur qui est "bootstrappé", c'est le langage lui-même. À partir de quelques axiomes de base (if, cons, car, cdr, eval, quote, fn, les opérations mathématiques de bases, l'affection et quelques autres), tout le reste du langage est défini (le langage est lui-même sa propre spécification) : la définition de fonction, les opérateurs and et or, les divers systèmes d'itération, le système de macro, etc.

          L'intérêt, c'est de permettre d'adapter le langage aux problèmes auxquels on se trouve confronté, de A à Z : selon la devise Lispienne, c'est "un langage de programmation programmable".
        • [^] # Re: bootstrapping myself

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

          Avoir un langage qui bootstrap, cela permet notament :
          - à ne pas dépendre d'un autre langage
          - de tester le langage lui-même
          - de faciliter le X-compiling. Tu n'as qu'à modifier ton compilateur pour ajouter une nouvelle archituecture cible (Sinon, il est problable que tu doivent aussi modifier le compilateur du langage que tu utilises).
          - d'optimiser de ton propre compilateur et améliorant sa production de code (suffit de le recompiler avec lui-même 2x de suite)
          • [^] # Re: bootstrapping myself

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

            Oula pas bien réveillé ce matin, je vous conseille de supprimer des "de" et ajouter des "de", changer des "et" en "en", etc.
        • [^] # Re: bootstrapping myself

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

          Bien souvent, dans le monde Scheme/Lisp, on etudie en profondeur les interpretes dits "meta-circulaires" ou` les primitives du langages interprete' sont interpretees par les primitives correspondantes du langage hote. Pour peu qu'une semantique (souvent denotationelles) du langage hote soit connue, le bootstrap permet alors d'obtenir "a peu de frais" une semantique du nouveau langage. Et donc un support mathematique pour l'etude des proprietes de ce langage, de sa robustesse, de sa validite' conceptuelle.

          Et bien souvent, le but de la creation d'un langage est d'apporter de nouveaux concepts. Avec le bootstrap, une fois le concept cree, t'as plus qu'a l'utiliser ! Avoue qu'il serait dommage de creer un truc uber cool et de pas pouvoir en profiter dans l'application que tu developpes...
  • # Différences notables avec scheme ?

    Posté par . Évalué à 7.

    Je connais très bien scheme, et j'ai parcouru un peu le tutorial. Pour l'instant les seules différences notables que j'ai vu sont syntaxiques :

    (set! x 12) => (= x 12)

    (set-car! '(1 2) 11) => (= (car '(1 2)) 11)

    (let ((x 1) (y 2)) (cons 1 2)) => (with (x 1 y 2) (cons x y))

    Ca commence mal ! En scheme le symbole "!" est utilisé pour représenter l'affectation, l'effet de bord, le mal pour celui qui aime les langages fonctionnels, le compromis pour celui qui aime l'efficacité. Une convention veut que toute fonction qui utilise effet de bord se termine pas un point d'exclamation, c'est facile à voir

    Utiliser "=" pour l'affectation fait déjà perdre cette convention tellement utile.

    En bref, quels sont les principales différences avec scheme, quels sont les avantages de arc par rapport à scheme, quels sont les inconvénients ?
    • [^] # Re: Différences notables avec scheme ?

      Posté par . Évalué à 3.

      En fait, l'affectation avec =, au début j'étais un peu sceptique, mais finalement je suis assez fan. L'argumentaire de Graham à ce sujet, c'est que le signe =, c'est deux bandes, ce qui attire l'attention (et signale un danger).

      Pour ce qui est des principales différences :

      - Pas de différence entre le symbole nil, la liste vide et le booléen faux : le mal absolu pour les schemeurs (et même pour McCarthy lui-même) ; on aime ou on n'aime pas, il y a des avantages et des inconvénients, l'avantage étant la concision, l'inconvénient étant de prendre une liste vide pour un booléen faux dans un cas où ça n'a rien à voir.

      - Macros non hygiéniques : en scheme, les variables définies dans une macro ne peuvent pas entrer en conflit avec celles qui sont définies par l'utilisateur (la capture de variable). C'est une source de bug fréquente et assez difficile à repérer. Mais la capture de variable peut parfois être voulue. Par exemple, arc définit une macro "aif" (anaphoric if) qui affecte à la variable "it" le résultat du test :

      (aif (max une-liste-très-longue) (prn it) (prn "vide !"))

      équivalent de :

      (let it (max une-liste-très-longue) (if it) (prn it) (prn "vide !"))

      - Des divergences dans la façon de concevoir les programmes. Par exemple, là où Scheme incite fortement le programmeur à suivre le paradigme fonctionnel, Arc est assez "agnostique" : il y a tout ce qu'il faut pour écrire des algos fonctionnels (map, filter, reduce, tail-recursion, ...) comme des algos procéduraux (notamment beaucoup de types d'itérateurs) ; ce qui explique en partie l'absence de "!" dans les noms des fonctions.

      Toutes ces divergences, c'est ce que Graham a retenu de Common Lisp. Mais globalement, je trouve Arc plus proche de Scheme.

      Enfin, Arc contient un peu de syntaxe :

      (~f x) <=> (not (f x))

      (f:g x) <=> (f (g x))

      a.b <=> (a b)

      a!b <=> (a 'b)
      • [^] # Re: Différences notables avec scheme ?

        Posté par . Évalué à 3.

        En fait, on perds le côté fonctionnel de scheme pour une programmation plus impérative (boucles, itérateurs, etc.).

        Les macros ne sont plus hygiéniques, ce qui permet quelques bidouilles (liées elles aussi aux effets de bord) et fait perdre la sûreté des macros (on ne peut plus utiliser une macro dans n'importe quel contexte, l'environnement lexical peut interférer avec elle).

        Alors, quel est l'avantage de Arc sur Scheme ? Un peu de sucre syntaxique ? Moi je ne suis pas convaincu du tout du tout

        ps : à lire : la vision de l'auteur de l'objet et de l'héritage, et pourquoi Arx n'intègre pas ses notions : http://paulgraham.com/noop.html

Suivre le flux des commentaires

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