Tu peux facilement utiliser un FFI pour aller appeler n'importe quelle fonction d'un autre langage. Haskell est même "premier de sa classe" dans ce domaine avec de superbes libraires de FFI pour s'interfacer avec du C, du C++ (là j'ai des doutes), du java, du python, du fortran, du R, et j'en passe. L'interface avec du C est aussi trivial que de taper ton code C au milieu de ton code Haskell avec le module inline-C (regarde les exemples).
J'ai vu un tutoriel où, dans le cas d'un main en C, la procédure écrite en GHC doit au préalable être initialisée (ce qui me faisait pencher pour un interpréteur embarqué).
Il faut initialiser entre autre le ramasse miette pour que ton code Haskell puisse allouer / désallouer de la mémoire. Après ce serait un interpréteur cela ne me choquerais pas tant que cela quand on vois les performances dingues qu'un interpréteur JIT peut donner (il n'y a qu'à voir Java ou PyPy). Bref, je pense qu'en dehors de certains contextes limités en mémoire, il ne faut pas cracher sur les interpréteurs. (Mais bon, GHC fait tout de même du code natif).
Il en découle qu'il ne semble pas avoir d'avenir pour GHC pour jouer avec des interfaces graphiques (GTK ou QT) qui sont le plus souvent écrites en C/C++ .
Il y a des bindings Haskell pour GTK, Qt, wxwidget, fltk, OpenGL, ... et j'en passe. J'ai peu de retour à faire, (je n'aime pas faire des interfaces graphiques, alors le peu que je fais je le garde pour le boulot et là c'est en LUA ;), mais le code gtk en Haskell que j'ai vu avait l'air plutôt acceptable.
Bien que les librairies d'interface graphique soient souvent écrites en C ou C++, c'est souvent un autre langage qui tape dedans, python, lua, ...
Concernant GHC en tant que substitut au C++ dans le domaine du calcul intensif, je m'interroge : quitte à s'investir intellectuellement dans l'apprentissage d'un nouveau langage, pourquoi ne pas préférer Fortran (version F2015, pas F77 !) ?
Du peu que je connais de Fortran, j'ai l'impression que Haskell à une syntaxe et un système de type bien plus agréable à utiliser, mais je peu me tromper ;)
[^] # Re: Haskell pour les nuls
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 6.
Tu peux facilement utiliser un FFI pour aller appeler n'importe quelle fonction d'un autre langage. Haskell est même "premier de sa classe" dans ce domaine avec de superbes libraires de FFI pour s'interfacer avec du C, du C++ (là j'ai des doutes), du java, du python, du fortran, du R, et j'en passe. L'interface avec du C est aussi trivial que de taper ton code C au milieu de ton code Haskell avec le module inline-C (regarde les exemples).
Il faut initialiser entre autre le ramasse miette pour que ton code Haskell puisse allouer / désallouer de la mémoire. Après ce serait un interpréteur cela ne me choquerais pas tant que cela quand on vois les performances dingues qu'un interpréteur JIT peut donner (il n'y a qu'à voir Java ou PyPy). Bref, je pense qu'en dehors de certains contextes limités en mémoire, il ne faut pas cracher sur les interpréteurs. (Mais bon, GHC fait tout de même du code natif).
Il y a des bindings Haskell pour GTK, Qt, wxwidget, fltk, OpenGL, ... et j'en passe. J'ai peu de retour à faire, (je n'aime pas faire des interfaces graphiques, alors le peu que je fais je le garde pour le boulot et là c'est en LUA ;), mais le code gtk en Haskell que j'ai vu avait l'air plutôt acceptable.
Bien que les librairies d'interface graphique soient souvent écrites en C ou C++, c'est souvent un autre langage qui tape dedans, python, lua, ...
Du peu que je connais de Fortran, j'ai l'impression que Haskell à une syntaxe et un système de type bien plus agréable à utiliser, mais je peu me tromper ;)