Journal Nosica

Posté par  .
Étiquettes : aucune
0
15
nov.
2002
Salut a tous,

je connaissais pas le journal, je viens de le decouvrir, et j'en profite pour faire un peu de pub a un projet que je développe : Nosica.

Nosica est un langage et un compilateur.
Nosica se veut un langage objet largement inspire de la syntaxe de Java, mais avec des rajouts : la genericite, la surcharge d'opérateur, les propriétes, les tableaux multi dimensionels et j'en passe.

En fait, j'aimerai savoir s'il y a des gens parmi vous qui seraient intérrésseé par aider au developpement de Nosica : il y a plein de chose a faire : du code, de la doc, des tests, le site oueb, des suggestions, des conseils, ...

Nosica est développé en Java (j'en vois rincer le nez d'ici, mais il y a gcj) ...
Actuellement j'ai laissé tomber le projet initial pour développer une version plus light (certaines fontionnalités ont été laissés tombé).

Etat d'avancement :
parsing OK
analyse semantique OK (type checking)
transformation de l'AST en IR OK (transformation du code source en représentation intermédiaire)

Il reste :
implémentation des exceptions (en cours)
analyse globale (a refaire)
prodution C (à réintégrer et à modifier)

Pas mal de bout de code du projet initial sont récupérables, L'architecture est pas trop mal foutu je pense, et même si les docs en ligne sont vieilles et plus du tout au goût du jour, elles permettent de rentrer un peu dans le code.

Pour finir, voici l'adresse : http://nosica.ng-market.net

En attendant votre retour, bon vent !!

David

  • # Re: Nosica

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

    Super interrescant !

    Il fut un temps au je suivais un projet appeler D :) Mais il était trop avancé pour discuter des features.

    Je crois que tu as tord d'ajouter la surcharge d'opérateur, c'est une des grandes raisons de code bloat de C++.

    Il serait plus sympa par contre de créer ses propres opérateurs. Genre le ".+" de mathlab ou n'importe quoi d'autre. Tu définit un paquet de symbol autour desquels tu peux mettre 2 objets, l'expression en retournant un 3ième.

    Cela serait génial de pouvoir préciser la transitiviter de l'opérateur (a T (b T c) == (a T b) T c), si a T b == b T a,... Définir si une fonction est pure ou impure (l'execution de la fonction n'a pas d'effet de bord donc, l'ordre d'execution n'a pas d'importance, genre une fonction avec des IO(est impure) un opérateur devrait toujours être pure).

    Cela deviendra super important pour les optimisations de compilation futures (vectorisation de code et compilation multithread). Et la compilation lève un grand nombre d'erreur.

    Sinon, inclure des opérateurs sur tableau est indispensable pour des raisons de perf. Mais fait une méthode ou la taille peut être fixe car à la compilation les performances ne seront pas les mêmes qu'avec des tailles variables.

    Il faudrait aussi que le compilo est 2 modes debug et release, voire un troisieme de profiling (code release + instrumentation).

    Le release doit avoir le maximum de perf.

    Le code debug devrait implémenter le maximum de running check possible : genre forbiden access in array tartenpion file ??? line ??? column ???, variable titi == N but N should be <N et plus ce stupide "Seg fault !".

    Bon, j'en ai plein des idées pour un nouveau langages... genre :
    les transactions (copy-on-write sur les donné, et rollback en cas d'exception),...
    les méthode d'objet par default (comme objectif C ? genre save() et load() pour chaque objet en xml),...
    utilisation des ensembles plutot que des types,...
    donner des intervalles de valeur pour les entiers (vérification possible à la compilation, et en run time, et finis les grosses merde dû à l'utilisation de int qui était 16 bits, qui est 32 bits et qui passe à 64 !)

    Je regarde le site promis !

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

    • [^] # Re: Nosica

      Posté par  . Évalué à 1.

      Je crois que tu as tord d'ajouter la surcharge d'opérateur, c'est une des grandes raisons de code bloat de C++.


      Oui, sauf que pour limiter la casse, la surcharge d'operateur est limite aux types primitifs, et pas aux types references, justement a cause des prob du c++. De plus, il y a un tas de restrictions sur leur declaration ... On a essaye de faire un langage safe, mais il nous a semble que pour faire un type "complex" par exemple, il fallait pouvoir redefinir les operateurs +, *, ...

      Il serait plus sympa par contre de créer ses propres opérateurs. Genre le ".+" de mathlab ou n'importe quoi d'autre. Tu définit un paquet de symbol autour desquels tu peux mettre 2 objets, 'expression en retournant un 3ième.


      Oui, mais ca compliquerait enormement la facon de faire le parsing, sans parler des problemes de lookahead ...
      On a garde a peu pres les operateurs classiques que tout le monde connais et dont tout le monde connait la signification. Je pense que pour des operateurs un peu plus bizarre, il vaut mieux un nom de methode bien explicite qu'un operateur obscur ...

      Cela serait génial de pouvoir préciser la transitiviter de l'opérateur (a T (b T c) == (a T b) T c), si a T b == b T a,...


      On a pas ca, mais on utilise la notation infix / postfix, pour dire sur quelle instance s'effectue l'operation.

      Définir si une fonction est pure ou impure (l'execution de la fonction n'a pas d'effet de bord donc, l'ordre d'execution n'a pas d'importance, genre une fonction avec des IO(est impure) un opérateur devrait toujours être pure).


      C'est une tres bonne idee, mais je sais pas si c'est adapte a un langage de haut niveau : a priori un langage de haut niveau ne devrait pas permettre ce genre de chose : ca fait une chose de plus a faire au programmeur ...
      Sinon, en pratique, ca permet d'optimiser quoi ?

      Cela deviendra super important pour les optimisations de compilation futures (vectorisation de code et compilation multithread). Et la compilation lève un grand nombre d'erreur.

      Sinon, inclure des opérateurs sur tableau est indispensable pour des raisons de perf. Mais fait une méthode ou la taille peut être fixe car à la compilation les performances ne seront pas les mêmes qu'avec des tailles variables.


      Heuh je comprend pas tres bien. Il y a plusieurs operateurs sur les tableaux. Il y a meme un operateur qui permet de traiter un tableaux multidimensionnels comme un tableau monodimensionnel. Les tableaux sont forcement de taille fixe, a moins de les reallouer, sinon il faut utiliser les vecteurs ...

      Il faudrait aussi que le compilo est 2 modes debug et release, voire un troisieme de profiling (code release + instrumentation).


      On a prevu ca effectivement.

      Le release doit avoir le maximum de perf.
      oui

      Le code debug devrait implémenter le maximum de running check possible : genre forbiden access in array tartenpion file ??? line ??? column ???, variable titi == N but N should be <N et plus ce stupide "Seg fault !".


      Deja fait.


      Bon, j'en ai plein des idées pour un nouveau langages... genre :
      les transactions (copy-on-write sur les donné, et rollback en cas d'exception),...
      les méthode d'objet par default (comme objectif C ? genre save () et load() pour chaque objet en xml),...
      utilisation des ensembles plutot que des types,...
      donner des intervalles de valeur pour les entiers (vérification possible à la compilation, et en run time, et finis les grosses merde dû à l'utilisation de int qui était 16 bits, qui est 32 bits et qui passe à 64 !)


      Transactions sur les donnees ? Tres interressant, qu'est ce que tu proposes comme syntaxe ? En fait, je dois dire que nous aussi on fourmille pas mal d'idees, mais souvent le seul fait de ne pas trouver de syntaxe objet propre nous a fait jeter l'eponge ... :-)

      Je connais pas Objective C ... Tu peux t'expliquer ?
      Il n'y a pas d'ensemble de valeur pour les entier, ca pourrait etre une feature interressante, mais toujours pareil : quelle syntaxe ?
      On s'est debrouiller pour faire un langage relativement sur, par exemple un int16 * int16 ne loge pas forvement dans un int16, et ca provoque une erreur de compil. Si on veut le forcer il faut le dire explicitement par un narrow ... Ca evite les erreurs, et dans ce cas, ca fait un check au runtime ...

      Je regarde le site promis !

      Cool !! merci !! :-)

      Si tu as des idees, je te propose de les mettre en ligne sur le forum dedie ... Ca pourra donner des idees a d'autres personnes et c'est en discutant comme ca que ca peut faire avancer les choses ...

      David

  • # Pourquoi faire ?

    Posté par  . Évalué à 1.

    Je me doute bien que c'est éducatif et amusant mais je ne vois pas l'intérêt alors que d'autres langages font déjà ça très bien ?

    • [^] # Re: Pourquoi faire ?

      Posté par  . Évalué à 1.

      Comme tu dis, c'est educatif et amusant avant tout.
      De plus non, je ne connais aucun langage qui propose ce que propose Nosica.

      Disons que chaque langage a ses specificites.
      Tu code, tu prend de l'experience, et tu apprecie tel specificite de tel langage, tel specificite de tel autre, mais au final, il n'y a pas un seul langage qui possede l'ensemble des specificites qui t'interresse.

      C'est pour tout ca qu'on a cree Nosica.
      Une syntaxe clair
      compile
      object
      modelisation par interface
      genericite
      surcharge d'operateur, mais pas comme le c++ qui permet tout et n'importe quoi
      les contraintes
      les tableaux multi dimensionnels (je connais que Pascal)
      les proprietes (je connais que VB)
      differenciation infix/postfix/prefix comme en eiffel (le c++ le fait pas)

      Tu comprend son interet maintenant ?

      • [^] # Re: Pourquoi faire ?

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

        contraintes ?

        C'est un genre d'assert() ?

        genericite ? contraintes ? differenciation ?

        C'est quoi tout ça ?

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

        • [^] # Re: Pourquoi faire ?

          Posté par  . Évalué à 1.

          les containtes d'eiffel : de petits statements qui permettent de verifier des contraintes sur le fonctionnement d'une methode.

          3 types de contraintes :
          invariant : verifiee a chaque modification des donnees d'une classe
          requires : verification avant execution d'une methode
          ensures : verification apres execution d'une methode

          ex :

          
class T
          
{
          
  private int i;
          
  invariant
          
  {
          
     i inferieur a 10;  // pas pu utiliser l'operateur de math : bug dans templeet ?
          
     i superieur ou egal a 0;
          
  }
          

          
  public int inc(int incValue)
          
  {
          
     i += incValue;
          
     return i;
          
  }
          
  requires
          
  {
          
    incValue + i inferieur a 10;
          
    incValue + i superieur ou egal a 0;
          
  }
          
  ensures
          
  {
          
    result inferieur a 10;
          
    result superieur ou egal a 0;
          
  }
          
}


          Bon c'est pas un exemple top interressant, mais ca te donne une idee de ce que ca peut faire.

          En cas de contraintes non verifie, le programme s'arrete en precisant ce qui a merde.

          genericite : les templates en C++ :
          class Vector<T> implements Collection
          {
          }

          differenciation infix/postfix/prefix
          Il s'agit des differents types d'operateurs existant dans Nosica.
          En c++ :
          int operator +(int i) {}
          utilisation : int i = 1 + 2; // equivalent a 'int i = 1.operator +(2);'

          Tu remarqueras qu'on a pas le choix : l'operateur s'applique sur le terme de gauche.

          En Nosica :
          int infix +(int i) {}
          meme utilisation, mais la notation indique que c'est le membre de gauche qui est utilise comme instance.

          int postfix(OStream os) {}
          utilisation :
          OStream os = new OStream(System.out);
          os << 1; // equivalent a 1.postfix(os);

          Ici, on a permute l'instance qui fait l'operation : il s'agit du membre de droite.

          Les operateurs prefix permettent de definir les operateurs ++ par exemple :
          int prefix++();
          utilisation :
          ++i; // equivalent a i.prefix++();

          A+

Suivre le flux des commentaires

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