Syntaxe langage simple

Hello,
comme vous le savez surement, onidev tout comme GM aura son propre langage.
Le but est de faire un langage OO fortement typé, simple mais tout de même relativement efficace.

Je demanderait donc l'avis des experts ici, au cas ou vous remarqueriez des incohérences dans ce langage, ou des moyens de simplifier sa syntaxe sans le rendre trop lite.

Je commence par le plus général. Le langage ressemblera a un C++ simplifié et épuré:
-pas de templates
-probablement pas d'héritage multiple (****** a gérer au niveau de la conception de l’interpréteur)
-des pointeurs plus soft pour ceux qui sont pas a l'aise avec les pointeurs du C++


Donc y auras quelques différences avec le C++, tout d'abord pour la déclaration des fonctions, il n'y auras pas besoin de réécrire le type des paramètres s'ils sont les mêmes:

Code:

double length(double x1, y1, x2, y2)
// sera l'équivalent de
double length(double x1, double y1, double x2, double y2)

Ensuite, par défaut toute variable sera initialisée.
Pour empêcher une variable d'être initialisée, un opérateur '~' sera disponible.
Par ex:

Code:

int t[1000]~;

Tout comme la nouvelle norme C++11, on pourra modifier le contenu d'une structure avec {}:

Code:

struct Point { int x, y; }
Point pt;
pt { 16, 32 }; // <=> pt.x=16; pt.y=32;

Contrairement au C++, il n'y auras pas de headers, pas de prototypes.
Tout sera dans des modules, et par défaut tout sera caché dans les espaces de noms qui leur sont associés.

Par exemple vous voulez utiliser toutes les fonctions de la lib standard d'onidev? Vous faites:

Code:

using od;

Vous voulez toutes les fonctions pour la gestion de la souris?

Code:

using od.io.mouse;

Vous voulez utiliser uniquement la fonction keyCheck?

Code:

using od.io.keyboard.keyCheck;

Vous voulez utiliser les fonctions de couleurs mais vous ne voulez pas des constantes prédéfinies?

Code:

using od.graphics.colors;
unuse od.graphics.colors.constants; // bon par contre j'ai pas trouvé mieux que le mot clé unuse... donc si vous avez mieux je prend

Pour terminer avec la syntaxe: le truc qui a été le plus ****** a penser, la gestion des 'pointeurs'.
Car déjà, un langage simple ne peut pas avoir de pointeurs a proprement parler, ce serait trop prise de tête.
Par contre, je voulais absolument pas un système a la Java ou tout est dynamique.
A la limite je verrais peut être pour inclure un garbage collector activable, mais je n'aime pas vraiment la façon dont ça oblige a programmer quand on doit toujours passer par ça.

Donc dans l'idée, voici les règles que j'ai définis pour les 'pointeurs', qui finalement ressemblent plus a des espèces de références...

Code:

Syntaxe
:
Fonctionnement

T = T
const T = T
T = const T
const T = const T
:
Copie valeur.
Copie valeur si initialisation, sinon erreur.
Copie valeur.
Copie valeur si initialisation, sinon erreur.


T & = T
const T & = T
T & = const T
const & T = const T
:
Copie adresse.
?
Copie valeur.
?


T = T &
const T = T &
T = const T &
const T = const T &
:
Copie valeur.
Copie valeur si initialisation, sinon erreur.
?
?


T & = T &
const T & = T &
T & = const T &
const T & = const T &
:
Copie adresse.
?
?
?

Les '?' c'est ce qui n'a pas encore été définis, car pour l'instant ce n'est pas vraiment important.

Donc déjà, avec le T & = T, on peut se retrouver dans le cas ou on fait pointer une variable sur une variable d'un autre scope, dans le genre:

Code:

T & t;
{ T myStaticIns; t = myStaticIns; }

Après le bloc, on aurait donc t qui pointe sur quelque chose qui n'existe plus.
Le compilateur assignera donc automatiquement l'instruction t=null; avant la fin du bloc...

Sinon pour cette syntaxe elle permettra de facilement passer des objets par référence aux fonctions, et permettra de facilement gérer les allocations dynamiques.
Reste a voir si y a moyen de faire un système d'itérateurs correct avec ça.
Dans tous les cas j'ai pas vu de boulette, pour l'instant



Pour ce qui est de l'intégration du langage a onidev, ça ressemblera pas mal a GM, sauf qu'on ne sera pas obligé de créer que des objets (qui seront en fait des classes dont la plupart du code aura été pré-écrit, et structuré en parties a la GM), mais on pourra aussi ajouter des modules contenant fonctions, structures et classes.
Rien n’empêchera donc d'élaborer un drag&drop like pour permettre aux non codeurs d'utiliser le soft.

L’exécution pourra se faire théoriquement de plusieurs façons:

• Interprétation a la volée
  L'IDE d'onidev analysera le code en temps réel, de cette façon quand vous lancerez le code l'arbre de syntaxe abstraite sera déjà complet, ce qui permettra d’exécuter directement le contenu de l'arbre sans aucun temps d'attente.
  En revanche, le code ainsi exécuté sera très lent, et prendra beaucoup de mémoire. Cela sera tout de même très utile pour le debug
  
• Interprétation/Compilation opcodes
  Pas mal plus lent cette fois, tout l'arbre est convertis en opcodes, qui seront exécutés par une espèce de machine virtuelle.
  L'avantage des opcodes, est qu'ils sont totalement portables, tant qu'un runner existe sur la plateforme visée.
  
• Compilation JIT
  (pas sur que cette option soit rapidement dispo, ça a l'air assez complexe a mettre en place)
  Compilation a la volée pour de très bonne performances, et des temps de compilations plutôt courts.
  
• Compilation native
  Transformation de l'arbre en IR LLVM, qui sera ensuite compilé en assembleur et transformé en binaires.
  Lent, mais efficace, avec possibilité d'optimiser l'assembleur généré grâce a LLVM.
  
• Conversion C++
  Convertis tout le projet en c++, cela permettra de faire des modifs directement dans ce langage très puissant.
  

Pour ceux qui se demandent ou le projet en est, bah ça avance lentement, mais surement.
J'ai pas mal avancé la lib standard, je commence a bien maîtriser la création d’interpréteurs et je réussi petit a petit a utiliser LLVM pour la compilation.
Dans tous les cas, je suis toujours sur la grammaire du langage et ce n'est pas une mince affaire
Donc bon, n'attendez pas de version utilisable prochainement, mais le projet n'est pas du tout mort :b

Pour ceux qui se demandent les possibilités théoriques au niveau des exports, eh bien grâce a LLVM, une compilation en javascript très rapide devrait être possible (pour les interessés allez voir Asm.js + emscripten).
Dans tous les cas les plateformes visées qui se feront sans soucis: Windows/Linux/Mac
Grâce au NDK, l'export Android devrait pas être trop dur a mettre en place.
Grâce a l'export C++, il ne devrait pas y avoir de soucis pour faire un export sur les consoles récentes.

Pour finir si vous voyez des incohérences, boulettes, ou si vous avez juste des conseils ou suggestions n'hésitez pas a m'en faire part.
Merci d'avoir lu, et désolé pour le pavé

Je trouve ça pas mal. Une seule chose bizarre pour moi est la syntaxe des variables non initialisées. Je verrais mieux un mot-clef du genre :

Code:

 raw int t[1000];

Ah effectivement c'est pas mal comme ça. Je pense que je vais garder cette syntaxe, ou l'idée du raw, merci :b

Citation :

Donc y auras quelques différences avec le C++, tout d'abord pour la déclaration des fonctions, il n'y auras pas besoin de réécrire le type des paramètres s'ils sont les mêmes:

Code:

double length(double x1, y1, x2, y2)
// sera l'équivalent de
double length(double x1, double y1, double x2, double y2)

Hmmm... pourquoi pas, mais je continuerai perso à déclarer le type de toutes mes variables, je trouve ça trop brouillon si on fait pas de notation "Hongroise"

Citation :

Ensuite, par défaut toute variable sera initialisée.
Pour empêcher une variable d'être initialisée, un opérateur '~' sera disponible.
Par ex:

Code:

int t[1000]~;

L'idée est franchement bonne!

Citation :

Contrairement au C++, il n'y auras pas de headers, pas de prototypes.
Tout sera dans des modules, et par défaut tout sera caché dans les espaces de noms qui leur sont associés.

Par exemple vous voulez utiliser toutes les fonctions de la lib standard d'onidev? Vous faites:

Code:

using od;

Vous voulez toutes les fonctions pour la gestion de la souris?

Code:

using od.io.mouse;

Vous voulez utiliser uniquement la fonction keyCheck?

Code:

using od.io.keyboard.keyCheck;

Vous voulez utiliser les fonctions de couleurs mais vous ne voulez pas des constantes prédéfinies?

Code:

using od.graphics.colors;
unuse od.graphics.colors.constants; // bon par contre j'ai pas trouvé mieux que le mot clé unuse... donc si vous avez mieux je prend

Idée intéressante! J'ai beau chercher, je ne trouve pas de meilleure mot clé... peut être 'drop', pour 'laisser tomber' une partie de la lib? (drop out). J'ai aussi pensé à dump, mais c'est autre chose dans la tête des devs normalement



Pour les pointeurs, résumons:
Un pointeur (bref, une variable contenant une adresse) s'écris foo &;
Une variable s'écris bar;

Du coup, lors d'une assignation, le contenant défini ce que l'on prend. Si l'on assigne une variable à un pointeur (foo & = bar; ), ce dernier prendra l'adresse de la variable bar.
Inversement, si on assigne un pointeur à une variable (bar = foo&, on assigne à bar la valeur de la variable se trouvant à foo&.

J'ai juste?

foo & = 0x001215a2;

Ca fait quoi? C'est le cas "T & = const T" ? Tu dis que ça fait une copie de valeur... dans le sens ou ça fout le pointeur au bon endroit?

En tout cas, j'ai hâte de tester tout ça!

Merci :b
Et yep tu as juste.
Pour le cas foo & = 0x001215a2; c'est un peu plus compliqué effectivement.
En fait ça donne la valeur 0x001215a2 a l'objet pointé par foo.

Du coup si j'ai:
int i = 123;
int & p; // p pointe sur null
p = i; // p pointe sur i (soit en C/C++: p = &i; )
p = 1234; // 1234 est de type const int, alors i prend 1234 (soit en C/C++: *p=1234;)

Je n'ai pas trouvé mieux pour régler le soucis suivant quand on a pas de vrais pointeurs, illustré par l'exemple:
void assign(int & x)
{
x = 123;
}
int v = 0;
assign(v); // regle x& = x
// ici v vaux donc 123

Ce qui m'obligera par la suite a définir les opérations avec const T &, si on veux passer un objet constant a une fonction par exemple.

Du coup, c'est parfaitement clair pour moi

Ca a l'air vraiment cool
Par contre, juste une question conne : quand tu dis qu'il n'y aura pas d'héritage multiple, on peut quand même faire plusieurs 'couches' d'héritage, comme en java (ou il n'y a pas non plus d'héritage multiple) ? Genre ca :
public class Object
public class Item extends Object
public class Weapon extends Item
public class Gun extends Weapon

C'est pas de l'héritage multiple à proprement parler, donc je suppose que ca marche sans problème, nan ?

Yep pas de soucis pour ça, sinon aucun intérêt d'avoir de l'orienté objet

Ok, ca me rassure, parce qu'effectivement c'est plus que limité autrement... ^^

J'ai profité d'un peu de temps pour modifier certaines choses et commencer a structurer la lib standard du langage, qui s'appellera surement Eol (easy orientend langage/easy onidev langage).

Nouveau système de pointeurs bien moins casse ******* que le précédent:

Code:

int x, y; // x et y valent 0
int& ptr = @x; // ptr pointe sur x
ptr = 3; // x vaux 3
ptr = @y;
ptr = x; // y vaux 3
ptr = null; // pointe sur rien

Bref c'est un peu des 'sous' pointeurs du C, qui au lieu de fonctionner par adresse fonctionnent par valeur (un mix pointeur/reference).
Ils permettent de faire moins de choses mais la syntaxe est beaucoup plus simple et il sera rare d'avoir des erreurs avec.
Pour ce qui est de manipuler les données a l'octet près, il faudra passer par une classe spéciale StreamData.

J'ai aussi prévu un nouveau système d'espaces de noms, pour faire du code plus structuré:
http://pastebin.com/7FTBDx3j

Et voici un début de ma lib standard:

Code:

.io
 .keyboard
 .mouse
 .file

.container
 .algorithm
 Vector<>
 List<>
 Stack<>
 Queue<>
 Dequeue<>
 Map<>
 Set<>
 Matrix<>

.system
 .directory
 .time
  Clock
  Timer
 .parallelism
  Thread
  Mutex
  Lock

.math
 .random

.graphics
 Texture
 Font
 Shader
 Surface
 Framebuffer

.network
 .sockets
  SocketListener
  SocketTcp
  SocketUdp
  SocketSelector
 .http
 .ftp
 .irc
 IpAdress


A trier:
assets, collision
color, image
fcurve, fcurveColor
png, jpeg, bmp, tga
base64
zip, zlib
lz77, huffman, deflate
csv
dom, json, xml
object, particles, path
ressourceManager, room
sprite, streamData
texturePacker
view
mat4, vec2, vec3
masques
hash

Les '.' indiquent les scopes.
Ainsi pour utiliser les fonctions network il faudra faire using od.network;

Je travaille aussi sur les façons de faire un compiler JIT afin d'avoir des temps de compilation instantané, et ça c'est pas de tout repos...

J'aime beaucoup tes nouveaux pointeurs.
Déja le @ pour signifier "adresse de", sa sonne bien.
Juste quelques question pour être sùr que rien loupé.

Si on fait:

Code:

int x,y;
int& xx = @x
int& yy = @y
yy=@xx

Possible ou pas ? yy référence x ?


Sinon, je vois que tu inclus toutes les structure de la lib C++ standard..
Du genre : Stack<>
Or tu disais ne pas inclure de template dans ton langage.
Je me demande syntaxiquement comment tu va instancier un de ces objets là ?

Alors pour les nouveaux pointeurs j'y avais pensé, il suffira de faire
yy=xx
qui sera bien plus souvent utilisé.

Et si tu veux récupérer la valeur de xx, il faudra faire un cast vers int.
Donc pour synthétiser:
T <- T : valeur
T <- @T : aleur
@T <- T : valeur
@T <- @T : adresse

J'ai pas finis de réfléchir a toutes les conséquences possible donc ça risque peut être d'un peu changer.
Par exemple avec un tel système il est impossible de modifier l'adresse d'une référence passée a une fonction dans la fonction :/


Sinon finalement oui, je compte implémenter un système de généricité, car après avoir bien réfléchis, ce serait vraiment galère de faire des conteneurs corrects sans.
En revanche ce sera bien moins puissant que les templates C++, mais ça permettra de faire de la généricité sans soucis.
En fait le parser va juste se charger de faire des conversions de 'types templates' et 'dupliquer' la source du module avec le nouveau type spécifié.
Simple a implémenter et fonctionnel. La libstd aura les classes génériques pour les types de base déjà précompilés afin d'éviter une perte de temps inutile pour la compilation.

D'ailleurs je suis aussi en train de bosser sur des optimisations de precompilation afin d'améliorer au maximum les possibilités au niveau des temps de compilation. Le but étant d'avoir une compilation la plus rapide possible quelque soit la taille du projet...

Ca a l'air cool tout ca :b J'ai compris l'utilité des pointeurs ia pas très longtemps, j'en aurais eu besoin, mais avec java pas moyen   

Sinon j'en profite pour te poser une question onilink : t'avais parlé ia un certain moment d'une méthode pour traiter du code, donc justement compilation, etc... mais aussi pour la colorisation syntaxique de façon plus simple et plus rapide que les regex ; donc c'est moi qui m'invente des trucs ou tu te rappelle du nom de la méthode ? ^^'
Merci !

Bah faut parser le code quoi, y a plusieurs méthodes mais ma préférée est la descente récursive: http://en.wikipedia.org/wiki/Recursive_descent_parser
Simple a implémenter, et efficace.

Pour la coloration syntaxique par contre je pense qu'il faut coupler ça a la création d'un arbre de syntaxe abstraite, ainsi tu peux connaitre la vrai nature de chaque token et coloriser en fonction de ça.

Ouaip, c'est ca, je vais regarder ca de plus près, merci

Dans tous les cas pour avoir la meilleur façon de faire je pense qu'il faut aller voir le code source de Qt qui a un très bon éditeur de code (ou Eclipse qui est quand même très balèze).

Ouaip, je regarderais aussi de ce côté ! En tous cas merci ^^