Discussion :

[Alp]

Je doute que l'impact soit assez important pour que tu ais à t'en préoccuper.
Pense plutôt à la clarté et l'élégance du code. Les langages fonctionnels sont pour la plupart assez expressifs, dans 2 sens :
- lorsque tu lis du code fonctionnel, pour peu que les fonctions soient bien nommées, les lignes de code sont presque des phrases, donc très facile de savoir ce que fait telle ligne par exemple
- lorsque tu écris du code fonctionnel, après un petit temps d'adaptation, tu écriras les fonctions comme tu les penses dans ta tête, cela devient très vite naturel

Si une fonction ne va servir qu'à l'intérieur d'une autre fonction, dans ce cas tu peux la déclarer à l'intérieur, comme on te l'a montré plus tôt dans ce sujet. Si elle doit servir à plusieurs endroits ou doit être mise à disposition d'autres développeurs, alors définis-là en dehors de l'autre fonction.

[alex_pi]

Une fonction définie à l'intérieur d'une autre est une fonction qui va aider la première en factorisant une partie des opérations dans la seconde.

Allez, histoire de perdre le PO, notons que parfois on défini une fonction en interne pour la retourner ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
type compteur = 
  {bump : unit -> unit;
   get : unit -> int};;
 
let new_compteur = 
  let r = ref 0 in
  {bump = (fun () -> incr r);
   get = (fun () -> !r)};;

[InOCamlWeTrust]

Salut !

Une réponse un peu plus centrée sur le « raisonnement » (un bien grand mot pour peu de choses ici) : dans les langages fonctionnels, les fonctions sont des éléments de première classe. Elles peuvent donc être manipulées comme n'importe quel type de base. Bref, aucune limitation théorique au contenu et aux imbrications.

Cordialement,
Cacophrène

En C aussi... puis on peut même faire la différence entre fonction et adresse de fonction dans le système de types.

[alex_pi]

En C aussi... puis on peut même faire la différence entre fonction et adresse de fonction dans le système de types.

Tu fais comment en C pour créer une fonction dans le corps d'une autre ?

[gorgonite]

Tu fais comment en C pour créer une fonction dans le corps d'une autre ?

tout dépend de ce que l'on appelle "créer"... c'est le principe de base des basic blocks, ou de l'export asm du back-end du compilo

mais clairement, je suis d'accord avec l'idée que je me fais de ta question

[Garulfo]

Désolé de réécrire dans le même sujet, mais j'aimerais savoir comment on ferme l'effet d'une condition :

si [condition] alors [action1] fin
[action2]

Mais pourquoi le fais-tu si tu sais que c'est pas bien ?
Je comprends pas. Ouvre un autre sujet plutôt.

[LLB]

Après test, je viens de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
int add(int x, int y) {
  return x + y;
}
 
typedef int(*Func1)(int);
typedef int(*Func2)(int,int);
 
Func1 partial(Func2 f, int x)
{
  int p(int y)
  {
    return f(x, y);
  }
  return &p;
}
 
int main(){
  Func1 f = partial(add, 2);
  return f(5);
}

Mais bon, c'est en utilisant une extension non-standard de gcc (fonctions imbriquées). Et puis, on n'a pas non plus les fonctions anonymes.

Donc non, les fonctions ne sont pas des éléments de premier ordre en C.

[alex_pi]

Mais bon, c'est en utilisant une extension non-standard de gcc (fonctions imbriquées). Et puis, on n'a pas non plus les fonctions anonymes.

Et puis quand on lit la page de manuel correspondant : http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html , on se rend compte que c'est un peu dangereux quand même...

If you try to call the nested function through its address after the containing function has exited, all hell will break loose.

Donc créer une fonction localement et la retourner n'est pas une très bonne idée...

Tout ça confirme qu'on est bien loin d'un "objet de première classe"

[InOCamlWeTrust]

Tu fais comment en C pour créer une fonction dans le corps d'une autre ?

En C GCC, tu peux sans problèmes.

[alex_pi]

En C GCC, tu peux sans problèmes.

Donc déjà, on est d'accord, ce n'est pas possible "en C".

Et sincèrement, je trouve que dire "on peut faire pareil en C", ça relève du "tout les langages sont équivalents, c'est turing complet". Un objet de première classe, c'est un objet qu'on peut créer *dynamiquement* dans une fonction et retourner.

Par exemple en Caml, on peut facilement écrire une fonction qui attend une chaîne de caractère représentant une fonction du lambda calcul simplement typé des entier dans les entier, et retourner la fonction de int dans int équivalente.

En C c'est impossible puisque toutes les fonctions sont définies statiquement.

Et qu'on en me réponde pas "il suffit d'encoder la fermeture à la main", parce que ça relève du "pour faire une première projection en lambda calcul, il suffit de faire '\p.(p \x.\y.x)'".

Donc je persiste et signe, les capacités du C dans le domaine n'ont *rien* à voir.

[InOCamlWeTrust]

On va pas refaire le monde, mais je trouve, que, même si tu as raison dans le fond, ta position est dogmatique. C'est comme les gens qui ne jurent que par la POO, ceux qui croient que GNU c'est le logiciel libre, ou encore ceux qui croient encore que le style fonctionnel a triomphé de l'infâme impérativité.

Enfin, c'est bon, quoi...

Pour ce qui est de ceci...

Par exemple en Caml, on peut facilement écrire une fonction qui attend une chaîne de caractère représentant une fonction du lambda calcul simplement typé des entier dans les entier, et retourner la fonction de int dans int équivalente.

... j'aimerais bien que tu m'expliques ton raisonnemment... car je quasiment sûr, même si je ne l'ai pas codé, qu'en C ANSI, c'est aussi possible. Tu ne le feras peut-être pas de la même façon, mais je pense que la solution existe également.

[InOCamlWeTrust]

Je viens de réfléchir, et certes, on ne peut pas faire en C ce que tu dis. Par contre, il est possible de produire une fonction de type string -> int -> int faisant exactement la même chose. Pour en faire une fonction, il faudrait le faire au niveau supérieur.

Tu vois bien qu'au niveau de la sémantique, ça se rejoint !

[alex_pi]

Je viens de réfléchir, et certes, on ne peut pas faire en C ce que tu dis. Par contre, il est possible de produire une fonction de type string -> int -> int faisant exactement la même chose. Pour en faire une fonction, il faudrait le faire au niveau supérieur.

Mais l'ordre supérieur, ça bloque en C...

Tu vois bien qu'au niveau de la sémantique, ça se rejoint !

C'est ce que je disais... Les deux sont turing complet, donc on peut évidement écrire les mêmes "programmes" à top-level. Mais ça ne veut pas dire qu'on peut "faire pareil en C" quand on parle des fonctions.

[alex_pi]

On va pas refaire le monde, mais je trouve, que, même si tu as raison dans le fond, ta position est dogmatique.

Je n'ai pas dit (dans cette discussion :p) "hors fonctionnel point de salut", juste que le C ne peux pas être considéré comme étant un langage fonctionnel, même s'il y a des pointeurs de fonctions.

Mais vu qu'on semble d'accord, fin de la discussion au fond