Suivi de JulienCharles

Du 7 au 10 mai

Réunion du 7 mai

Alors voici un résumé de ce que nous avons fait avec Pierre le 7mai: on a principalement mis au clair des éléments syntaxiques afin de faire la sémantique (au moins une partie) aujourd'hui. Un résumé plus détaillé se trouve sur la page de Pierre.

Réunion du 10 mai (avec pierre)

L'enjeu était principalement de mieux définir la génération de code. Après quelques réflexions; nous avons décidé la manière de générer les entêtes des fonctions et comment gérer les mécanismes de surcharges et redéfinitions. La conclusion du 7 mai avait été de rassembler les clauses d'une même fonction afin de permettre les redéfinitions comme en Scheme. Nous avons suggéré d'utiliser un mécanisme de surcharge s'appuyant sur le nombre d'arguments et non sur les types d'arguments.

La question qui restait en suspens était la suivante: Comment gérer la surcharge dans le code SpecialK généré?

Pierre a suggéré d'utiliser un système de définition lié. L'idée est de générer des redéfinitions des fonctions stockant dans une variable l'ancienne fonction; si la nouvelle fonction n'arrive pas à utiliser les arguments alors elle appelle l'ancienne fonction qu'elle surcharge. Dans ce mécanisme, la redéfinition est possible pour les fonctions ayant le même nombre d'arguments. Si le nombre d'arguments est le bon; si la fonction ne s'unifie pas avec les arguments on envoie une erreur. On obtiendrait le code suivant (approximatif) pour une fonction foo qui prend 3 arguments:

(let ((old-foo foo))
   (define (foo . L) 
        (if (= (length L) 3)
            (match ....
                ....)
            (apply old-foo L)))

En générant ce genre de code, cela permet la redéfinition en SpecialK; ainsi qu'une certaine forme de surcharge. Un avis différent serait d'abandonner toute forme de redéfinition en exécutant old-foo aussi dans le cas où match échouait. Mais nous pensons que les redéfintions sont un mécanisme intéressant. Donc on optera a priori pour la première solution.

-- JulienCharles - 10 May 2004

Du 11 au 14 mai

Réunion du 11 mai

Une autre réunion avec Pierre. Nous avons essayé encore une fois de normaliser un peu plus la syntaxe de SpecialK.

Réunion du 12 mai

Réunion avec Jean-Paul Roy pour savoir où on en est. Il nous a suggéré une 'optimisation' qui empèche la redéfinition dynamique de code. Enfin. Elle est très rapide à mettre en oeuvre.

Du 13 au 14 mai

A partir de la base donnée par Pierre je me suis mis à coder le traducteur. Cyril n'a toujours pas fini de coder les tableaux a priori. J'arrive à traduire l'arbre décoré. Mon code n'est qu'une première version; je ne gère pas les tableaux (Cyril!!!!!); je ne gère pas la complétude; et il n'y a pas encore l'optimisation au niveau des gardes. Sinon ça produit du code Scheme exécutable.

Dans une des réunions qui précédait on avait décider de faire des fonctions de la forme

(let ((old-foo foo))
   (define (foo . L) 
        (if (= (length L) 3)
            (match ....
                ....)
            (apply old-foo L)))

maintenant c devenu:

(define the-thing-that-shouldnt-be-in-special-k-funs '?)
 (let ((g148
        (with-handlers ((exn:variable? (lambda (ex) (lambda l (raise ex))))) (eval 'foo))))
   (set! the-thing-that-shouldnt-be-in-special-k-funs
     (lambda g150
       (define g149
         (match-lambda
           ((args) (=> g151) (if #t (+ 5 (g149 (list 5))) (g151)))
           (((9 . a)) (=> g152) (if (eq? (and (not (foo 5 a)) #t) b) (+ a b) (g152)))))
       (if (= (length g150) 1) (g149 g150) (apply g148 g150)))))
 (define foo the-thing-that-shouldnt-be-in-special-k-funs)

Le nom de la variable pompeuse est juste pour tester. Si elle ne convient pas on la remplacera par un vrai nom: par exemple specialk-fun ce qui serait sympa.

-- JulienCharles - 14 May 2004

Du 15 au 19 mai

Du 15 au 17 mai

J'ai principalement avancé la génération de code. Pas grand choses à dire. Je génère du code à peu près correct (les tableaux ne sont pas encore codés).

Réunion du 18 mai

Sylvain m'a orienté vers une solution pour le problème précédent (celui de la variable en trop). La solution est donc la suivante:

(define fac
   (with-handlers ((exn:variable? (lambda (ex) (lambda l (raise ex))))) (eval 'fac)))
 (let ((g1163 fac))
   (set! fac
     (lambda g1165
       (define g1164
         (match-lambda ((n) (=> g1166) (if (not (eq? n 0)) (* n (g1164 (list (- n 1)))) 1))))
       (if (= (length g1165) 1) (g1164 g1165) (apply g1163 g1165)))))

Maintenant la grammaire de Cyril fonctionne; j'ai pu faire des testes de traductions SpecialK vers Scheme. Mon gros travail a été d'adapter les deux; et modifier certains aspects de la traduction de la structure intermédiaire qui n'étaient pas clairement définis. J'ai traduit les tableaux.

Avec Pierre on a discuter de sémantique; et notamment au niveau de la sémantique des fonctions en SpecialK.

Réunion du 19 mai

J'ai commencé à faire quelques optimisations; notamment celle du 'not'. J'ai essayé de faire l'optimisation de la complétude des clauses. J'hésite à la faire réellement; le code produit par la traduction devient gros et rapidement illisible. Je mets la dernière version du traducteur sur ma page...

Pendant la réunion on a réglé 2 3 trucs sur la sémantique de Pierre; Cyril devrait finir sa grammaire pour le week-end. J'ai décider de m'arréter de faire les optimisations de la traduction pour le moment. Je commence l'inclusion dans DrScheme ce soir; pour ensuite effectuer la gestion des exceptions.

-- JulienCharles - 19 May 2004

Du 20 au 25 mai

Du 20 au 21 mai

J'ai effectué l'inclusion... bon maintenant ça marche à peu près; il reste à voir les exceptions; terminer la syntaxe de la fonction produite en SpecialK (le call/cc n'y figure pas encore).

Du 22 au 23 mai

Week-end... j'ai pas fait des tonnes de choses.

Du 24 au 25 mai

Pierre m'a donné son optimisation que je lui avait demandé; nouveau module special-k-opt.ss. J'ai fignolé un peu tout ça. C'est stable. Reste à trouver les comportements non voulus (surtout les mauvais reports d'exceptions). En incluant la nouvelle version de Cyril; j'ai modifié ses expressions réguliaires pour les commentaires (...); j'arrive toujours pas à bien inclure ses exceptions . Sinon c'est stable; on peut programmer etc. ...
-on s'approche de la fin-

-- JulienCharles - 25 May 2004

Du 26 au 28 mai

Le 26 mai

Finalement je suis arrivé à inclure les exceptions hier soir....

Aujourd'hui j'ai fait le syntax highlighting; la vérification ne fonctionne pas bien encore; et j'ai perdu le tabbing au passage. Mais c'est pas mal sinon....

-- JulienCharles - 26 May 2004

Le 27, 28 mai

J'ai corrigé les bugs que Cyril m'avait indiqué... j'ai trouvé le moyen d'ajouter le tabbing. Et ça marche. Il reste à faire la distribution sic.

- JulienCharles - 28 May 2004

Du 29 mai au 1 juin

J'ai enfin terminé le tabbing; j'ai ajouté des trucs au top level; j'ai réécris plusieurs regexp pour que la coloration se fasse mieux; j'ai commencé à réorganisé/commenter le code; maintenant je fignole tout ça; et la partie sera terminée d'ici à demain matin.

J'ai mis plus de temps que prévu parce que la fonction pregexp-replace* est buggée. Et le temps de s'en apercevoir...

Il reste l'inclusion des bibliothèque de Pierre (faut que je vois ça avec lui).

-- JulienCharles - 01 Jun 2004

Du 2 au 3 juin

Le langage normal était vraiment trop lent (sur un exemple réel). J'ai inclus la partie de Pierre. Maintenant on a 2 niveaux de langages. J'ai inclus mod et div; affectation d'une variable renvoie une valeur. J'ai changé la fun. d'affichage.

-- JulienCharles - 03 Jun 2004
to top