Discussion :

[Laurent Dardenne]

Bonjour,
je ne suis pas certain de poster dans le bon forum mais vu ma question je commence ici.

J'aimerais savoir si l'implémentation de closure dans un langage dynamique (PowerShell) fonctionne à l'identique des langages tels que le C, C#...
Enfin plus particuliérement "la capture de l'environnement lexical" est-elle différente ? C'est à dire est-ce qu'on doit capturer les variables de la portée courante ou toutes les variables accessible dans la portée ou bien seulement celles utilisées dans la closure et celles du code l'englobant?

L'objectif étant de simuler le principe des closures. J'ai aujourd'hui un script qui permet de réaliser une closure mais son inconvénient est qu'il capture de nombreuses variables qui me semblent superflues, notamment les variables globales:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
function NewDecorator
{
    param ([string]$decoration)
    return closure {
        param ([string]$text)
        return $decoration + $text + $decoration;
    };
}
$sharpDecorator = NewDecorator '#';
$sharpDecorator
&$sharpDecorator "hoge"; # renvoie #hoge#

J'ai trouvé une possibilité de réduire le nombre de variables capturées mais j'ai un doute sur la pertinence de ma démarche par rapport au script d'origine.

[pseudocode]

je vote pour "seulement celles utilisées dans la closure et celles du code l'englobant".

[Alp]

je vote pour "seulement celles utilisées dans la closure et celles du code l'englobant".

Je dirais pareil que pseudocode.
Car la closure peut comme dans ton exemple utiliser des variables du code qui l'englobe... mais ça ne servirait à rien du tout de capter des variables du code qui est totalement à l'extérieur.

[SpiceGuid]

Il existe des propositions de langage qui répondent à ta question d'une manière assez satisfaisante:
http://citeseerx.ist.psu.edu/viewdoc...10.1.1.47.1578

Autrement, avec une implémentation naïve, tu es obligé de faire un compromis entre expressivité et encapsulation.

[Laurent Dardenne]

Merci pour vos réponses.

Il existe des propositions de langage qui répondent à ta question d'une manière assez satisfaisante:
http://citeseerx.ist.psu.edu/viewdoc...10.1.1.47.1578

Merci, il me reste à trouver le bon document en espérant qu'il me soit accessible.

[Garulfo]

Pourquoi avoir fait atterir ce sujet en Scheme ?
Le but n'est pas de faire une implémentation en Scheme si ?

Ou alors j'ai rien compris au sujet

[Laurent Dardenne]

Pourquoi avoir fait atterir ce sujet en Scheme ?

A l'origine j'ai posté dans Algo.

Le but n'est pas de faire une implémentation en Scheme si ?

Non mais on a jugé que le forum Scheme était peut être plus approprié, car c'est un langage dynamique si je ne me trompe, comme PowerShell qui est un shell basé objet et dynamique. C'est peut être le seul lien.

Il est parfois des cas où on ne sait pas trop quel forum choisir pour poster le sujet

Ce genre de post devient donc itinérant malgré lui.
Ah la bohême

[SpiceGuid]

Je dois bien avouer n'avoir rien compris à ta question à la 1ière lecture

J'aimerais savoir si l'implémentation de closure dans un langage dynamique (PowerShell) fonctionne à l'identique des langages tels que le C, C#...
Enfin plus particuliérement "la capture de l'environnement lexical" est-elle différente ? C'est à dire est-ce qu'on doit capturer les variables de la portée courante ou toutes les variables accessible dans la portée ou bien seulement celles utilisées dans la closure et celles du code l'englobant?

Statiquement: tu peux définir des lambda-fonctions (ou fonctions anonymes), à la volée.
Dynamiquement: en appliquant un argument (ou plus) à une fonction anonyme tu obtiens une fermeture (ou closure).
Cette fermeture n'est qu'un objet dont les champs sont les arguments réels de l'application de fonction.
La fermeture est à une lambda ce que l'objet est à sa classe.

La portée lexicale d'une variable est la même dans un langage dynamique que dans un langage statique.
La relation qui lie une lambda à sa fonction englobante est transitive (la fonction englobante est éventuellement une lambda).
Par conséquent tu dois remonter la chaîne des imbrications de fonctions, et toute variable ou paramètre local qui apparaît dans le code de ta fonction anonyme est un champ pour la fermeture crée par cette fonction.
La durée de vie de la fermeture crée peut éventuellement exéder celle de son code englobant (et d'ailleurs, dans le cas contraire, il n'y a tout simplement pas besoin de créer de fermeture, tout se passe localement, dans la fenêtre de pile), c'est-à-dire que ta fermeture conserve tout son sens même au-delà de la durée de vie des variables de sa fonction englobante.
Et ça n'est possible que si, lors de la création de cette fermeture, tu as fait une copie de tout l'environnement parent utilisé par ta lambda.

il capture de nombreuses variables qui me semblent superflues, notamment les variables globales

Concrètement il suffit de conserver un pointeur sur l'environnement "global", pas besoin de copier l'environnement global dans (toutes!) les fermetures.
Edit:
Sauf, bien sûr, si tu peux par exemple échanger des fermetures entre plusieurs processus, dans ce cas la durée de vie d'une fermeture pourrait excéder celle de tes variables globale.

[Laurent Dardenne]

La portée lexicale d'une variable est la même dans un langage dynamique que dans un langage statique.

Ok, cela répond à ma question.

Par conséquent tu dois remonter la chaîne des imbrications de fonctions, et toute variable ou paramètre local qui apparaît dans le code de ta fonction anonyme est un champ pour la fermeture crée par cette fonction.

Sous powerShell il est possible de récupérer les variables des portées parente, jusqu'a 100 niveau je crois. Je procéde ainsi :

Code :

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

1
2
3
4
5
6
7
8
     #Recherche des variables de la portée parente
     #Au sein du code parent le contenu des portées "local" et "private" sont identiques en PS v1.0, sauf erreur de ma part.
     #On ne récupére que les variables, automatiques ou non, dont la portée est "none"
$private:ParentPrivateVariables=Get-Variable -scope 1|? {$_.options -notmatch "AllScope"}
 
 #Ensuite on filtre les variable automatique créées par PowerShell
 ...

La durée de vie de la fermeture crée peut éventuellement exéder celle de son code englobant

Effectivement je l'ai testé et cela fonctionne.

Concrètement il suffit de conserver un pointeur sur l'environnement "global", pas besoin de copier l'environnement global dans (toutes!) les fermetures.

Sous PowerSehll une directive de portée permet cela :

Code :

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

$global:maVariable

Sauf, bien sûr, si tu peux par exemple échanger des fermetures entre plusieurs processus,

PowerShell v1 ne gére pas très bien les processus et ce n'est pas vraiment un langage de programmation mais du scripting.
Et il ne faut pas être trop gourmand non plus.

Encore merci pour tes explications

Le code d'origine : http://csharper.blog57.fc2.com/blog-entry-218.html
Les commentaires sont en japonais...

[Garulfo]

Je vois toujours pas le rapport direct avec Scheme.
Le forum langage m'aurait paru mieux...

Menfinbon