Un petit langage ZdS

À un moment il faudra choisir dans quelle direction aller et je sais pas comment organiser un tel choix. Je sais même pas si c'est possible de gérer toutes les divergences d'opinion des gens.

Pourtant, la solution a été donnée quelques messages plus haut par Lz36GQfANCkOchnWu2yv :

Je comprends pas votre discussion. Pourquoi est-ce que vous n'organisez pas plutôt un ensemble d'ateliers, de cours, de défis ou ce que vous voulez, où chacun implémente un langage respectant le paradigme/les idées qu'il préfère, dans le langage de son choix, avec la syntaxe de son choix, etc. bref, pourquoi est-ce que vous essayez de poser des contraintes aussi rigides ?

Concevoir et implémenter un langage de programmation c'est à la fois long et amusant, facile et fastidieux, il y a beaucoup de choses à lire et tout le monde ne sera pas intéressé par les mêmes aspects. Laissez les gens faire ce qu'ils ont envie de faire ? Faites plusieurs posts sur le forum avec le tag "zlang" ou ce que vous voulez, et éventuellement des petits articles comme celui de Dinosaure (dont j'espère qu'il sera retravaillé pour être posté ailleurs que sur ce topic) ?

Arrêtez de vous prendre la tête, en somme ?

Ceci étant dit, pour l'analyse syntaxique, je suis assez d'accord : on aura beau venir clamer que « ça dépend de chacun » et qu'il ne faut pas généraliser, ce qui est certes techniquement correct, ça n'est d'une part vraiment pas la partie qui présente le plus d'intérêt, et d'autre part, à part pour des langages comme lisp où c'est trivial (mais encore plus avec un votrelangagepréféréyacc), c'est pénible et difficile de faire un parser correct et robuste à la main. Maintenant, si certains veulent se concentrer sur l'analyse syntaxique plutôt que sur l'exécution ou la compilation, pourquoi pas ?

Je suis d'accord pour dire que dans le cadre de la réalisation d'un compilateur, il est préférable de s'appuyer sur les outils existant pour réaliser les phases d'analyses lexicale et syntaxique (parce que ces outils existent et sont réutilisables, et qu'il y a déjà pas mal de boulot à réaliser).

Mais je me répète, l'intérêt porté à chacune des parties dépendra des gens : je ne vois pas en quoi ce serait objectivement moins intéressant que le typage, l'optimisation d'AST ou la génération de code par exemple.

J'ai essayer de suivre la discussion en entière, mais certains termes techniques m'ont rendu la tâche difficile mais pédagogique tout de même. C'est d'ailleurs pour ce dernier point que je suis très intéressé par cette idée.

Pour le moment il manque juste un peu de structuration pour bien comprendra la démarche.
Sommes-nous encore en train de parler du projet et comment le faire, ou avons nous déjà passé cette première étape pour parler des spécifications du langage ?

Je pense que pour que le projet soit très instructif pour ceux qui y participent, mais aussi pour ceux qui le suivent uniquement, maintenant ou dans le futur (lorsque celui-ci sera terminé par exemple), il faudrait qu'il soit bien organisé et rangé. De sorte qu'on puisse assez aisément retrouvé les tenants et les aboutissants de chaque action faite pour le projet et ainsi le suivre à notre rythme (vous l'avez bien dit, chacun son niveau, mais aussi chacun son temps libre etc).
Je ne sais pas quelle forme cela peut prendre, un tutoriel/article sur ZDS, l'utilisation d'outils de développement et de communication, etc…

Je reste très heureux de pouvoir suivre cette démarche et j'espère pouvoir y participer ou au moins m'en instruire, que se soit pendant ou après

Puisque l'on parle de débutants, est-ce que quelqu'un connait ce cours : http://www.nand2tetris.org/ ?

C'est assez adapté aux débutants, et la seconde partie (chap.7 a 12) traite de la chaîne de compilation. Les exercices consistent a créer une mini machine virtuelle depuis le début, pour un processeur fictif.

Il ne faudrait pas non plus que les plus avancés (surtout si on part sur du fonctionnel) fassent tout. Mais je suppose qu'ils voudront tout de même participer. Je ne sais pas si il y a suffisamment de travail à faire pour que cela ne se produise pas, mais c'est pour cela que je maintiens l'idée de groupes fonction du niveau. Les groupes plus « avancés » pourraient d'autre part aider les groupes de débutants à faire leur langage.

Je n'aime vraiment pas trop l'idée d'un seul langage ZdS. En plus, cela fait six pages qu'on débat sans trouver de compromis.

Ce qui pourrait être amusant/plus constructif, ce serait créer un groupe par "fonctionnalité" à la rigueur. On se met d'accord sur une toute petite base de langage et après chacun fait son sandwich avec ce qu'il veut y mettre en se joignant aux divers groupes.

Histoire de contribuer pour de vrai, j'ai pensé à un bout de syntaxe pour ceux qui n'ont pas peur de l'analyse syntaxique (les débutants devraient rester sur du S-expression du coup) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// pour ceux qui veulent du typage on peut mettre des types
type Point = { x: Float, y: Float }

// Des fonctions pour le peuple
def distance(a: Point, b: Point) -> Float {
  let x = (b.x + a.x) / 2.0
  let y = (b.y + a.y) / 2.0
  return sqrt(x*x + y*y)
}

// Si on ne met pas de types (ce qui serait bien mieux dans un premier temps)
// On utilisera les entiers comme unique type ou les strings, plus polyvalentes
def add(a, b) {
  return a + b
}

// Puis histoire de faire un programme principal
def main(args: [String]) -> Int {
  let a = new Point { x = 4.0, y = 8.0 } // le new sert à contruire une valeur, pas d'allocation dynamique
  let b = new Point { x = 8.0, y = 3.0 }
  print(distance(a, b))
  return 0
}

Avec ce bout de langage, on peut "aisément" (= ça se marierait bien) introduire typage, GC, fonctions (+ d'ordre supérieur, pourquoi pas). La syntaxe se prête naturellement au paradigme impératif et n'empêche en rien de bifurquer vers du fonctionnel :

1
2
3
4
5
6

def map(f: a -> b, l: [a]) -> [b] {
  case(l) {
    [] -> []
    [h:t] -> f(h) ++ map(f, t)
  }
}

Rien n'empêche d'étendre les structures de données pour avoir un système d'objet basique :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

type Point = {
  private x: Float
  private y: Float

  public def distance(a: Point, b: Point) -> Float {
    // bref
  }

  public def Point(x: Float, y: Float) {
    self.x = x
    self.y = y
  }
}

Je précise bien qu'il s'agit là de pistes, d'essayer de faire avancer le schmillblick. Mais je n'ai absolument aucune prétention concernant ce qui sera fait au final. Je précise aussi que je tiens particulièrement compte des remarques de Dinosaure, ayant moi-même commencé à m'intéresser à la compilation grâce à l'atelier P'tit Langage. Je veux juste proposer un bout de syntaxe histoire de tous nous mettre d'accord et montrer qu'elle se veut assez extensible et qu'on pourra passer d'un langage très simple sans fonction ni type ni pas grand chose à une bonne grosse usine à gaz sans trop de gros problèmes.

Bouuuh la syntaxe que je taperais jamais à cause de toute ces flèches x) (avis personnel bien sûr)

L'idée des groupes me semble excellente ! Chacun voit midi à sa porte, les productions sont plus nombreuses et ça permet de faire participer tout le monde , vraiment bonne idée

Pourquoi ne pas créer un language de script avec une syntax proche de python ou ruby mais avec des mot-clés en français.
Par exemple if=si, else=sinon etc…
Un mini langage créer pour initier des novice à la programmation et à l'orienter objet

Mettre les mots clé en français ne fera pas baisser la difficulté d'apprentissage du langage. Face à la complexité de la plupart des concepts de la programmation, ce n'est pas une quinzaine de mots-clés qui feront la différence.

Cela dit, créer un langage qui s'exécute dans la VM Python, c'est assez facile à faire puisqu'il suffit de générer un AST standard Python (avec PLY par exemple) et laisser la builtin compile() s'occuper du reste.

Cela dit, créer un langage qui s'exécute dans la VM Python, c'est assez facile à faire puisqu'il suffit de générer un AST standard Python (avec PLY par exemple)Source:nohar

Oui c'est vrai ply est plutôt bien adapter pour ce genre de projet. J'ai déjà créer plusieurs mini-langages de script facilement.
De plus une partie des personnes pourront se concentrer sur la rédaction d'une mini bibliothèque standard rédigé en zlang pour zlang.

De nombreuses personnes on proposés un Lisp-like interprété, cela peut devenir poussé et ça reste simple, pourquoi ne pas commencer par ça ?

Ca me fait penser à ceci pour ceux qui connaissent : http://buildyourownlisp.com/

Cela peut être une bonne base de départ effectivement, même si je plussoie tout à fait l'idée des différents groupes qui me semble être très adaptée face aux problèmes rencontrés dans les 6 pages de débats.

@Lalla : Une question peut-être bête, mais pourquoi mettre le typage après le nom de variable (et pas devant comme python, C, …)?

Il n'y a pas de typage en python.

Pas de typage explicite tu veux dire ?

Pardon ?

Python possède un système de typage dynamique donc on à pas besoin d'indiquer le type avant une variable (je pensais que vous le saviez)

On le sait, mais il y a un typage en python. Il est juste facultatif.

Plus directement :

Ne pas avoir besoin d'indiquer le type != typage dynamique != pas de typage.

D'abord un langage sans typage n'existe pas, ou alors il manipule toujours strictement le même type de données, ce qui le rend plutôt inutile.

Ensuite, dans certains langages typés statiquement et même très fortement typés, on peut se passer d'indiquer les types (comme en Haskell) grâce à un mécanisme d'inférence de types.

Enfin, le typage dynamique dit juste que le type d'une variable peut changer au cours du temps, mais les entités manipulées sont quand même typées.

Et pour répondre à Joseph et à Grimur, on peut préciser le type des arguments et de retour d'une fonction en Python depuis Python 3.3, et ces annotations de types ont été complémentées en Python 3.5 par un module standard de description générique des types de données (la PEP en lien de mon précédent message), et quand on précise le type, ce n'est pas devant l'objet typé mais bien derrière, donc à l'opposé du C.

Bref, tout le monde a plus ou moins faux.

A moins de travailler sur une version étendue, Prolog est non-typé.