Un petit langage ZdS

Hé hé ! J’aurais justement préféré un langage fonctionnel aussi minimaliste que possible, façon Lisp, mais avec un typage statique puissant.

Hé hé ! J’aurais justement préféré un langage fonctionnel aussi minimaliste que possible, façon Lisp, mais avec un typage statique puissant.

Je m'en doutais un petit peu.

Perso, je préfère partir sur un langage impératif. Par contre, pour ce qui est de l'implémentation, je pense qu'il pourrait être intéressant d'utiliser un langage fonctionnel (typiquement, Haskell ou OCaml).

Pour ce qui est de ma volonté d'un typage dynamique, ça vient certainement de Perl. Quand on a l'habitude, c'est un sacré confort.

Un langage impératif est plus simple pour les débutants, non ?

Salut,

Je vote pour une implémentation en Haskell, étant à l'aise dans ce langage. Cependant je ne suis pas contre essayer un autre langage fonctionnel. Après je pense que Haskell sera un peu une barrière pour les débutants, vu que c'est un langage assez difficile à apprendre.

Pour ce qui est de la philosophie du langage, j'opterai pour un typage statique et inféré (ça peut être intéressant à implémenter) et un paradigme purement fonctionnel avec des semblants d'OO. Je ne parle pas d'OO au strict du terme, mais j'aimerais essayer d'implémenter un système d'héritage.

Edit: Tout ça c'est assez chaud à implémenter, surtout cette histoire d'OO, c'est quelque chose qu'on verra à la fin je pense

Franchement, impératif avec typage statique, ça me parait bien. C'est assez fatiguant des fois en Python par exemple quand on a une variable et qu'on ne sait pas quel est son type.

Edit: Évidemment, si je dis ça, c'est car je n'y connais rien en fonctionnel. Créer un langage fonctionnel peut aussi être une occasion pour beaucoup d'apprendre, pis beaucoup de personnes intelligentes codent en fonctionnel.

Je suis plutot pour partir sur un typage statique fort. Je pense qu il serait interessant de partir sur un langage impératif, mais avec le paradigme fonctionnel fortement integre.

Qu en pensez vous ?

Par contre, je ne pense pas que l implementer e Haskell soit une bonne idee. Loin de moi l idee de critiquer ce langage, son apprentissage est d ailleurs dans mes priorites, mais je pense que trop peu de gens le maitrisent assez pour participer au projet.

Sinon, integrer la PPC me parait etre une bonne idee.

Un peu d'originalité que diable !

Je propose un langage orienté évènements. Quand vous avez une interface graphique, cliquer sur un bouton provoque l'exécution d'une partie spécifique du code. Si vous avez déjà codé avec une bibliothèque graphique, on a un truc comme

1
2
3
4

liste_évènements = récupérer_évènements()
pour chaque élément 'évènement' de liste_évènements:
    si évènement est touche_Échap:
        quitter()

Je propose d'ajouter un système de ce type automatiquement géré au sein même du langage (sans considérations d'interface graphique). On pourrait faire

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

a = 1
quand a vaut 3:
    afficher "effet de bord !"
    stopper programme
b = 0
quand b modulo 2 vaut 0:
    a = a+1

pour b allant de 0 à l'infini:
    afficher a, b
# renvoie:
# 1, 0
# 1, 1
# 2, 2
# 2, 3
# effet de bord !

Si vous voulez, je peux vous trouver plusieurs autres idées bien bizarres.

Plus sérieusement, si on implémente un langage fonctionnelle dans un langage fonctionnelle, on va perdre beaucoup de débutants. Je suis plus de l'avis d'Emeric.

Pour le typage, je suis partisan du typage fort mais inféré, ainsi que du duck typing.

On est d'accord qu'il faut aussi prévoir un compilateur vers le brainfuck ?

Bien sûr, on ne va tout de même pas compiler vers de l’assembleur, voyons !

Comme j'avais pu le deviner, vous semblez tous être pour un typage statique fort. Je ne suis pas contre cette option, loin de la. Alors si tout le monde est d'accord, partons la dessus.

1
2
3
4
5
6

> my Int $x = 12;
> my Str $y = '7';
> say ($x + $y).WHAT;
(Int)
> say $x + $y
19

1
2
3
4
5
6

> my Int $x = 12;
> my Str $y = '7';
> say ($x ~ $y).WHAT;
(Str)
> say $x ~ $y;
127

Plus sérieusement, si on implémente un langage fonctionnelle dans un langage fonctionnelle, on va perdre beaucoup de débutants. Je suis plus de l'avis d'Emeric.

Je ne peux qu'approuver. Et puis, un langage impératif implémenté en langage fonctionnel, tout le monde est content.

+1 pour le duck typing. Et c'est vrai que l'orienté événements, ça a l'air rigolo.

EDIT : @Gabbro : J'attends avec impatience tes autres idées.

+1 I'm in

Ne serait-ce pas une bonne idée de mettre ce sujet en une ?

Pour proposer des sujets à mettre en Une à l'équipe com', tu peux faire un signalement en débutant ton message par @com ou utiliser ce topic.

Je ne veux pas faire mon rabat-joie, mais typage statique et duck typing, c’est incompatible, hein… Alors mettez-vous d’accord.

C'est pas ce que fait OCaml en utilisant le polymorphisme ?

Ou je mélange tout (je ne connais rien en théorie de langages de programmation) ?

Du coup, même si le duck typing a l'air plutôt sympa, je préfère le typage statique.

Non.

Si un langage fonctionne uniquement avec des types statiques, il ne peut pas avoir de duck typing. Point. Ce qu’ils font eux, c’est un langage ayant à la fois des types statiques et des types dynamiques, mais je suis pas persuadé que ça réponde aux exigences de simplicité préalablement imposées…

C'est fait

c’est un langage ayant à la fois des types statiques et des types dynamiques

Ok, donc le duck-typing n'est pas incompatible avec le typage statique. C'est tout ce que je voulais relever.