Règles du topic:
 
1] Ce topci n'est pas un topci sur le cyclimse.
2] Toutes les questions générales, l'actu, même la branlette intellectuelle sont les bienvenues tant que ça concerne les langages fonctionnels.
3] Pour troller, utiliser les catégories approriées du forum comme Seti ou OSA.
4] Pour les questions plus spécifiques, créez un topic.
 
Pour les liens intéressants et autres ressources, me MP je mettrai ça dans le topic.
Des sondages intéressants pourront apparaître aléatoirement, comme ça, suivant si j'ai envie ou pas, si j'ai chié mou la veille, etc.
 

J'ai voté multi de stiffler \o/

c'est quoi un langage fonctionnel

une sorte de langage qui marche donc pas lingo ni actionscript

Masklinn n'a pas d'amis

Un langage dans lequel l'unité de calcul est la fonction au sens mathématique du terme, avec une emphase sur le principe d'application de fonction plutôt que celui de changement d'état
 
Dans les concepts fonctionnels importants on trouve

• First-class function: les fonctions sont des objets de première classe, elles peuvent être envoyées en arguments à d'autres fonctions ou renvoyées (en valeurs de retours)
• Pure functions: une fonction "pure" est une fonction sans effet de bord, la sortie ne dépend que de l'entrée et pas d'un état externe, et la fonction ne modifie pas l'état d'une quelconque ressource (interne ou externe)
• Recursion: la majorité des langages fonctionnels n'ont pas de mécanismes itératifs (pas de boucles for/while/do/...), les processus d'itération sont générés par récursion
• Pattern-matching: s't'un peu compliqué à expliquer comme ça, voir la wikipedia

Naturellement des langages non fonctionnels peuvent avoir des caractéristiques fonctionnelles (e.g. Python et Ruby ont des first-class functions)

mais c'est fini oui ?
edit: je réouvre, ménage fait, mais ce topic peut éventuellement servir à ceux qui ne connaissent pas le paradigme fonctionnel et qui auraient des questions

C'est quelque chose de sain, une forme de dépucelage. La cat ADA est morte dans d'atroces souffrances, c'est ça que tu veux Harko ?

Elle est encore là la cat Ada, il y a même des questions sur Ada dedans, de temps en temps

Aaaah, enfin une cat pour ceux qui aiment programmer

Je suis curieux de voir à quoi ça ressemble cette fonctionnalité... A tout hasard, en aurais-tu un exemple (si possible en ruby, questioin de s'y retrouver un peu dans la syntaxe ) stp?

en ruby ça correspond aux blocks: les blocks sont simplement le nom des first-class functions en Ruby (ça lui vient de Smalltalk) e.g.
 

# je définis une fonction "square"
square = lambda {|x| x*x }
# c'est bien une fonction:
puts square.call 3
# => 9
def foo f # prend une fonction en argument
    puts f.call(5)
    puts f.call(10)
end
foo square
# => 25
# => 100
 
# mais tu connais probablement mieux la syntaxe magique suivante
# qui est simplement un raccourci pour ce qu'on voit au dessus
# (et est limitée à un block unique par appel en ruby, contrairement à Smalltalk)
def foo &block 
    puts block.call(5)
end
foo {|x| "Pouet #{x}" }
# => "Pouet 5"
 
# ou celle là, encore plus magique (mais que je n'aime pas trop perso)
def bar
    puts yield 5
end
 
bar {|x| "Plop #{x}" }
# => "Plop 5"

En se rappelant qu'il y a deux syntaxes différentes pour les blocks en Ruby (donnant globalement des résultats identiques, mais pas exactement):

# v1, à utiliser de préférence quand on a peu de code, pour les blocks "inline"
blk = lambda {|var| op(var)}
# v2, pour les blocks plus complexes (sur plusieurs lignes)
blk = lambda do |var|
    op(var)
end

 
Erlang : http://fr.wikipedia.org/wiki/Erlang_%28langage%29
 
La syntaxe de Erlang me fait un peu penser à Prolog...

J'ai pas compris pourquoi tu l'avais quoté

Les premières implémentations d'Erlang étaient en Prolog, et la syntaxe d'Erlang est effectivement tirée directement de celle de Prolog (avec quelques additions pour les processus par exemple)

\o/

 
Je me demandais, en erlang, comment on pouvait passer des objets via les messages entre processus? Un message peut contenir autre chose que du texte ou des nombres?
 
ps : je connais erlang que de nom et de principe (évoqué en cours d'architecture de systèmes distribués)  

Si on cause de Nemerle, je tacherais de participer.
A+,

Normalement on peut passer n'importe quoi d'un processus à l'autre.
 
Le seul truc dont je suis pas sûr et certain c'est pour passer directement des fonctions d'un processus à un autre (je testerais ça ce soir, même si c'est pas d'un intérêt terrible), mais tout le reste (listes, tuples, symboles, strings, nombres, records) peut servir de message (un message est un objet Erlang quelconque, il n'y a pas fondamentalement d'objet message).
 
Pour envoyer un message à un processus tiers c'est trivial: en considérant qu'on a son pid (son adresse, si tu veux) on fait comme ça:

%% On considère qu'on est à l'intérieur de notre process 
%% le pid du process auquel on veut envoyer un message est socké dans la variable Pid 
%% On veut lui envoyer un tuple {message, "Ceci est un test", ["arg1","arg2","arg3]} 
Pid ! {message, "Ceci est un test", ["arg1","arg2","arg3]} 
%% Voilà, c'est fait

Sympa hein?
 
De l'autre côté, le processus destinataire a une "boite aux lettres" dans lequel notre message est stocké, et il utilise "receive" pour récupérer des messages dans sa boite (receive fait du pattern-matching btw).
 
Par exemple dans ce cas si il veut aller voir sa boite et qu'il cherche uniquement un message:

%% On est à l'intérieur du processus recevant le message 
receive 
    {message, MessageText, MessageArgs} -> 
                    %% ici, MessageText contient le corps du message 
                    %% et MessageArgs est une liste contenant nos 3 arguments 
    %% et on peut naturellement avoir d'autres patterns de réception de messages :o 
end

On notera que sans la coloration syntaxique il est un peu dur de différencier les commentaires et le code

le coup de l'envoi/réception des messages, j'avais compris : j'avais vu ça en cours (le principe) et la mise en application pour erlang (lien wikipedia que j'ai donné plus haut).
C'est vrai que pour le distribué, ça a l'air assez sympa En +, j'ai vu qu'on pouvait attendre des messages pendant un temps donné et si rien ne se passe, déclencher une action...

%% est un commentaire. Ca se comprend assez facilement.

Oui, la dernière clause du receive peut commencer par "after" (suivi d'un int, genre "after 3000" ) et ça timeout proprement (les receive étant bloquants)

Oui mais ça rend pas le truc beaucoup plus lisible

question sans doute bête : on peut coder une appli entière avec erlang? (logique métier + IHM)

oui

Merci pour tes exemples détaillés (et du coup, j'ai appris plusieurs trucs sur ruby aussi genre comment créer une fonction utilisant les blocks ).

Ouaip (il y a un GTK/Erlang et un wxErlang pour la GUI même si c'est pas non plus pour ça qu'il a été créé).
 
Néamoins, Erlang est habituellement utilisé pour des trucs qui n'ont pas tellement besoin de GUI. La manière dont c'est fréquement fait est qu'Erlang gère toute la logique applicative, la distribution tout ça et si il y a besoin d'accéder au hardware c'est fait en C/C++ (ce qu'on appelle des "drivers" en Erlang), qui est ensuite appelé via des FFI.
 
Le recours au C/C++ n'étant que rarement nécessaire à moins de créer le software e.g. d'un switch telecom

Obtenir une référence sur un block  
(transformer un block en proc en fait)

Très juste, désolé
Quelque part, c'est fort semblable aux foncteurs en C++ à la (grosse) différence qu'on peut localiser le code de la fonction fournie en paramètre à l'endroit précis de son utilisation?

Mouais...
 
En beaucoup plus flexible puisque les blocks sont scopés (comme n'importe quel autre objet du langage), n'ont pas besoin d'être nommés (fonctions anonymes) et peuvent être déclarés n'importe où (et le fait que ce soient des objets classiques signifie qu'on peut non seulement les ballader entre les fonctions, mais on peut aussi les stocker dans un Array ou un Hash, ou comme variable membre d'un objet, ou ...)

Ah ouais, j'ai pas pensé à tout ça (vi, je débute en Ruby et j'ai jamais touché python).
Merci pour les détails

C'est pas fondamentalement une tare de pas savoir ça, les langages "mainstream" n'offrant pas tellement cette possibilité
(elle pue en C et C++, elle superpue en Java [classes anonymes], elle a commencé à apparaître en C# 2.0 mais c'est encore assez bof par rapport à ce qu'on peut trouver ailleurs)

je suis pour \o/

pour quoi?

Voila, donc je viens de tester avec le script suivant:

-module(test_send).
 
-export([start/0, sauce/0, torrent/0]).
 
start() ->
        spawn(test_send, sauce, []),
        "".
 
sauce() ->
        Torrent = spawn(test_send, torrent, []),
        Torrent ! {func, fun() -> "This was a function" end},
        Torrent ! {string, "This is a string"},
        Torrent ! {num, 42},
        Torrent ! {exit, self()},
        receive
                Msg ->
                        io:format("~n~w~n", [Msg])
        end.
 
torrent() ->
        receive
                {func, Fun} ->
                        io:format("~s~n", [Fun()]),
                        torrent();
                {string, Str} ->
                        io:format("~s~n", [Str]),
                        torrent();
                {num, Num} ->
                        io:format("~b~n", [Num]),
                        torrent();
                {exit, Pid} ->
                        Pid ! {this, "is", 97, fun() -> "Message" end},
                        ok
        end.

Et je confirme que ça ne pose effectivement strictement aucun problème de balancer des fonctions d'un process à l'autre:

Ici je balance tout d'abord 3 messages de "sauce" à "torrent": une fonction, un string et un int "torrent" appelle les fonctions (et imprime leur valeur de retour) et imprime les strings et ints.
Puis "sauce" envoie un message de terminaison à "torrent" qui répond en envoyant un tuple composé d'un symbol, d'un string, d'un int et d'une fonction, et "sauce" imprime le tout avant de se terminer

c'est illisible ces langages

C'est pas colorisé et codé à la porc pour aller vite surtout

Colorisé c'est déjà largement moins pire e.g.

Après c'est sûr que pour quelqu'un qui ne fait que du C# et du SQL ça peut choquer

Ça à l'air facile de faire une environnement visuel ou semi-visuel genre boiboites à relier pour un truc pareil en fait ...

Je rappelle que quand on code en erlang il faut réfléchir hein

 
Et ? la seule manière de réfléchir c'est en regardant une grille de caractères colorés ?
 
Death to the TextBox

C'est pas en reliant des boiboites dans visio en tout cas

 
J'ai pas parlé de "développer" en UML heing Je parle qu'on s'astique devant des intelli-bidule et de la coloration syntaxique sur des patés de texte alors que ça fait un moment qu'on a quand même un peu plus de trucs qu'avant dans les toolkits graphiques et que y'a ptêtre moyen de faire un poil plus communicant.