Yo
J'aimerais créer un petit "language" de programmation, bon pas vraiment un language de programmation m'enfin ça fait plus classe m'voyez, je veux dire un truc proche du XML/JSON/YAML mais avec une ou deux spécificitées qui sont plus ou moins inédites qui font toute la différence !

Donc j'aimerais savoir ce que vous aimeriez voir dans un language comme celui la, et aussi sa syntaxe, j'ai pensé à me baser sur un des trois languages cités ci dessus mais j'arrive à rien de propre, soit c'est pas asser détaillé, soit trop chargé, etc.

J'aimerais qu'il soit maniable, facile à apprendre, puissant, qui pardonne (en gros pas un typage "strict" qui ne s'interprete pas à la moindre erreur) et open source, je pense avoir disons 70/80% des compétences nécéssaires pour réaliser cela, apres y'a la motivation qui doit suivre mais je pense si je m'y mets à fond en une ou deux semaine avoir déja une alpha stable.

Donc citez moi les qualité et défaut que vous aimez dans un "markup language" au choix et ce que vous aimeriez qu'il y ai dedans,c'est a dire
XML (Html par extension)
CSS
JSON
YAML
etc..
Et par exemple
"J'aime bien les balises qu'utilise le XML"
"J'aimerais qu'il soit personnalisable (si oui précisez dans quel domaine)"
..
J'aimerais au final me constituer une "wishlist" et arriver à la finir.
Go

"J'aime bien les balises qu'utilise le XML"

...said no one ever (bon OK, à part chez IBM, c.f. JSONx ).

Sinon, le YAML est parfait pour moi (et AMHA, il répond à tous tes critères).

Je n'ai pas de criteres réel, je ne veux pas utiliser un language déja connu, juste car je veux en faire un, c'est un défis que je veux me fixer
Ce que je veux, c'est que de gens qui ont déja du utiliser des languages comme ceux la me disent ce qu'ils y aiment et ce qu'ils y détestent + ce qu'ils aimeraient y voir.

Nan j'ai envis d'un défis, ce que tu me dis on me l'as déjà beaucoup dit. Je n’espère vraiment pas révolutionner le domaine, je veux juste me faire plaisir, voir jusqu’où je peux aller.
Pour te donner une idée je me base sur une structure en noeuds (nodes) en gros c'est un arbre le fichier, ce qui me permet de faire une structure efficace et flexible. (Et me casser la tête avec les pointeurs mais chuut )

Donc personne ne sait me citer une seule qualité ou un seul défaut/voeux de son language de stockage de données favoris ? Bah ça alors

Le seul problème que j'ai eu avec YAML pour l'instant, c'est que c'est pas évident de modifier un fichier YAML "en place" en conservant les sauts de lignes et commentaires.

Je verrais bien un genre de json :
Pourquoi pas remplacer les { par de l'indentation ?
Ajouter des annotations @type pour faciliter le parsing ?

J'ai pas trop d'idée

Sinon tu pourrais améliorer le markup language, j'ai toujours aimé le concept mais ça manque d'un petit quelque chose je trouve

Pourquoi pas remplacer les { par de l'indentation ?

Mauvaise idée, tu ne peux plus le minifier si tu fais ça.

Pour avoir déjà eu a gérer du XML un peu lourd avec des multi-fichiers et multi-référence, le casse-tête a plutôt été de conceptualiser le machin, ainsi qu'à apprendre aux gens ayant pondus la DTD (et le schéma) de se cantonner à UN UNIQUE moyen de décrire une information, et pas 56 différents.

J'aime bien le XML, je le trouve généralement très simple et flexible, mais complexe à parser (les multi-références en fichier, youhou, la teuf).
J'aime bien le JSON pour sa lisibilité et sa grande facilité de parsing (une annot' et c'est terminé).
Le YAML, je n'ai pas assez joué avec. Je ne l'ai croisé que durant mes études, et jamais entendu parlé depuis (sauf de manière très anecdotique pour du Ruby).

Je vois mal ce que tu pourrais rajouter au XML, ce machin permettant de tout décrire déjà, avec plus ou moins de facilité.

ça peut être autre chose que le XML
+Alpha v0.1+ <*Root ~ Document 1> <Recette de la pâte à crêpes @recipe> <Ingrédients @recipe ~ "Les ingrédients !">[sucre,beurre,farine,oeufs,lait],prix=34.33,currency=dollar</> </>
Ligne par ligne, ce que je veux dire
+ Alpha v0.1 + = Commentaire signalant la version + nom du logiciel
<*Root ~ Document 1> *Root indique à l'interpréteur de créer un nouveau sous ensemble sous Root avec le nom Document 1.
<Recette de la pâte à crêpes @recipe> sous le curseur actuel (root) créer le sous ensemble avec pour diminutif "recipe" et les caractéristiques mentionnées
etc..
</> Remonter au parent du curseur actuel, Dans ce cas ci peut être omis vu que c'est la fin du fichier. (pas nécéssaire de remonter vu qu'on fini le fichier)
Au niveau du *, je pense l'utiliser comme soit un indicateur de macro soit une déclaration, genre <*Root> déclare que ce node est la racine. Mais si je fais par exemple "acceptedValue:*int" et que je demande à ma librairie de me donner la valeur de lib elle me renverra "integer" et l'utilisateur pourrait définir ses types, ce serait des macros .
Par exemple je pourrais modifier mon fichier comme ça.
+Alpha v0.1+ <define Dollar as $> <*Root ~ Document 1> <Recette de la pâte à crêpes @recipe> <Ingrédients @recipe ~ "Les ingrédients !">[sucre,beurre,farine,oeufs,lait],prix=34.33,currency=*$</> </>
(utf8 obligé tmtc)
et ducoup pas besoin de réécrire dollar J'aurai pu le faire avec autre chose genre les ingrédients de base de la pate à crepe pour les variantes, etc, ça marcherait avec tout les types (array entre autre)

Ce qui serait supporté : les array à dimensions multiples. Car la facon du programme de gérer les valeurs données serait un enfant du node mais d'un autre type du style "contentNode" qui pourrait avoir comme enfant un node normal. Ducoup je pourrais avoir un arbre super compliqué voir un gros fichier qui aurait une array contenant d'autres fichier, fichinception En gros je pourrais écrire cela :
+Alpha v0.1+ <define Dollar as $> <define baseRecipe as [sucre,beurre,farine,oeufs,lait] > <*Root ~ Document 1> <Recette de la pâte à crêpes @recipe> <Ingrédients @recipe ~ "Les ingrédients et leur préparation!">[*baseRecipe, {<Sous noeud ~ ssNoeud> "Lol":"mdr" </> }]prix=34.33,currency=*$</> </>
Mais je trouve que ça ressemble trop au XML pour certaines choses, j'aimerais trouver un autre indicateur que <>

Et oui, je ne compte pas utiliser l'indentation pour un indicateur car j'aimerais que mes fichiers soit minifiable pour les buils release :p

Sinon je prévois cette maniere de travailler pour les fichiers, ici dans le cas lecture/modification/réécriture

-> Lecture du fichier
-> Construction de l'arbre
-> Navigation dans l'arbre et modifications de l'arbre
-> Effacement du fichier et réécriture de l'arbre dans ce dernier (Minifié ou non, au choix);

La sauvegarde du fichier se fera automatiquement dans le destructeur si elle n'as pas déja été faite, comme ça si on oublie le "fichier.rewrite()" par exemple on n'aura pas de soucis.

PS: Les idées que j'énonce ici me sont venues en écrivant, donc ça peut être fouillis, très fouilli voir irréalisable

Alaur