Fonction path

[Sandra Naboulet]

Bonjour, 

est-il possible d'obtenir un objet à partir d'un value_identifier ?

Par exemple, le path "a.x",  "a" est construit avec 

Sub(   Path(Member(ValueIdentifier("x"))  ,  ValueIdentifier("a") )  mais comment pourrait-on obtenir concrètement l'objet ?

Une fonction existe-t-elle?

Sinon, est-il possible de la créer ? 

Merci

[Jerome Tonnellier]

Bonsoir,

>est-il possible d'obtenir un objet à partir d'un value_identifier ?

oui regarde dans tes fonctions lookup dans object.mli, ça devrait répondre à l'ensemble des tes questions.

Ah oui, t'as laissé ta session ouverte tout à l'heure aussi...

Jérôme.

[Jerome Tonnellier]

Tu dois faire une partie des fonctions lookup aussi pour le plaisir :-).

[Isabelle Richard]

La règle "SubMember" devrait t'aider également !

--

Isabelle

[Sandra Naboulet]

Merci Jerome, je suis tête en l'air !

Bon j'y ai reflechis mais je bloque vraiment !

la regle SubMember je la comprends mais quand il faut appliquer je suis confrontée aux problemes de type.

Dans la regle, on a que dans le contexte o, n s'evalue en o'

n c'est un objet, mais dans un path, c'est un value_identifier ...

je suis perdu entre les objets, les value_idientifier et la récursion...

De plus, le path a.b.x correspond à quel type : 

Sub(Path(Sub(Path(Member(ValueIdentifier "x")),ValueIdentifier "b")),ValueIdentifier "a") ?

ou

Sub(Path(Sub(Path(Member(ValueIdentifier "a")),ValueIdentifier "b")),ValueIdentifier "x") ?

J'ai toujours pensé que c'était la première.. 

Merci pour vos reponses rapides, peut être que demain ca nous semblera plus logique...

bonne nuit et très surement à demain.

[Jerome Tonnellier]

>Dans la regle, on a que dans le contexte o, n s'evalue en o'

>n c'est un objet, mais dans un path, c'est un value_identifier ...

non, n est un [value_identifier name] si je me trompe pas.
Grâce aux fonctions lookup, tu vas le traduire en objet ( dans la règle c'est o' ) qui va te servir de nouveau contexte pour évaluer ton x ( si on a n.x bien sûr ).

[Isabelle Richard]

Oui c'est bien un [value_identifier name].

Sinon je pencherais plutôt pour la deuxième écriture :

Sub(Path(Sub(Path(Member(ValueIdentifier "a")),ValueIdentifier "b")),ValueIdentifier "x")

--

Isabelle

[Jerome Tonnellier]

>Sub(Path(Sub(Path(Member(ValueIdentifier "a")),ValueIdentifier "b")),ValueIdentifier "x") ?

Je pencherai plutôt sur celui-là...

[Sandra Naboulet]

En fait;;; je crois bien que j'ai pigé... merci les arbres de dérivation !

en dérivant sur l'exemple d'un path a.b.n j'ai eu le déclic...

Ca devrait être bon maintenant!

:) merci

[Sandra Naboulet]

la deuxieme?

je pensais que Member allait toujours s'appliquer au petit x tout à la fin...

[Jerome Tonnellier]

Ouai merci les arbres de dérivations ! :-)

En tous cas bonne nuit.

[Jerome Tonnellier]

Si tu regarde bien ( selon moi ), si t'as "a.b.n", si tu veux calculer n, il faut que tu calcule a.b. Et si tu veux calculer b, il te faut a. Et donc finalement a n'est pas dépendant des autres donc tu peux le calculer en premier. Pour moi c'est lui le Member. Si tu regarde la grammaire de la partie 1, de toute façon il y a que comme ça que tu peu le construire. On commence toujours à construire ce qui est tout à droite puis on progresse vers la gauche...

[Sandra Naboulet]

Merci , c'est compris maintenant!
Bon courage !

[Sandra Naboulet]

Rebonjour,

Un doute persiste, si j'ai le programme suivant : 

object a {

     val x = 3

}

object b {

     val y = a.x

}

pour évaluer x, on doit évaluer a.

Mais l'évaluation de a se fait dans quel contexte de définition ? root_object?

mais a un moment donné, l'application se fera comme ceci : lookup_value root_object "a"... mais rechercher un element "a" dans root_object c'est bizarre non ? root_object ne contient rien...seulement un objet pere...

Je vous remercie

[Jerome Tonnellier]

Re,

>Mais l'évaluation de a se fait dans quel contexte de définition ? root_object?

Non, il se fera dans champs outer de l'objet b...

Jérôme.

[Sandra Naboulet]

Le 2 juin 2012 14:23, Jerome Tonnellier <jerome.t...@gmail.com> a écrit :

Non, il se fera dans champs outer de l'objet b...

mais dans mon exemple, le champs outer, il ne contient rien... s'il ne contient rien ca veut dire qu'il s'évalue en lui même ? 

[Sandra Naboulet]

que b s'évalue en b

[Jerome Tonnellier]

Je te propose de RTFS à propos du "composant outer". Et en plus, bonne pioche, il y a même un exemple.

[Sandra Naboulet]

Le 2 juin 2012 14:33, Jerome Tonnellier <jerome.t...@gmail.com> a écrit :

Je te propose de RTFS à propos du "composant outer". Et en plus, bonne pioche, il y a même un exemple.

j'ai lu 1000 fois ce passage

[Jerome Tonnellier]

>j'ai lu 1000 fois ce passage

Est-ce que t'as vu que ton exemple était quasiment le même que celui du sujet ?

[Sandra Naboulet]

ca fait mtn 2000 fois que je le regarde.

Ce que je ne comprends pas dans la semantique c'est qu'on va aller évaluer récursivement toujours le path dans le meme contexte (qui est c !!!

Je reprends l'exemple du sujet, mais sans la methode.

object a {

   val x = 42

   object b { let y  = x }

}

object c {

    val z = b.y

}

 

 val(c,b) = o'            val(o',y) = o"

____________        _____________

  c |-- b ⇓ o'             o' |-- y ⇓ o"

______________________________

                c |-- b.y ⇓ o"

ici on veut évaluer b.y dans le contexte de c.

donc on va evaluer b dans le contexte c toujours.

Mais dans le contexte c, il n'existe pas de b. b est dans le contexte a, val(c,b) ne va rien trouver... 

c'est ca que je ne comprends pas!

[Jerome Tonnellier]

>Mais dans le contexte c, il n'existe pas de b. b est dans le contexte a, val(c,b) ne va rien trouver...

Eh si, il va trouver parce que c est un Object qui contient un champs outer qui lui-même contient des fermetures ( dont bien-sûr a et implicitement b ).

Sinon, ce que je te propose c'est de pas trop te prendre la tête dessus parce que tu dois perdre pas mal de temps. Fais comme si tu y croyais et que c'est vrai pour toi :p

[Sandra Naboulet]

Mais dans le code, Object (object_instance) est vide !! 

c'est ecrit let object_instance = { empty with id = -1 }

a aucun moment on lui a ajouté un outer ... comment tu as trouvé que object_instance avait un champs outer?

je ne comprends plus rien.

c n'est pas un Object comme tu dis, mais c contient Object dans son champs Super

[Sandra Naboulet]

Est ce que mon arbre etait correct ?

[Jerome Tonnellier]

Oui désolé, c'est un object sans le O. Je voulais faire référence au module Object.ml.

[Jerome Tonnellier]

>Est ce que mon arbre etait correct ?

Oui, je crois bien.

[Sandra Naboulet]

alors c, c'est un objet qui contient l'objet b dans son outer ?

(et b contient a dans son outer evidemment)  

pourquoi c contient b dans son outer...? que veut dire fermeture?

Si tu m'éclaircies dessus.. je t'offre deux paquets de shokobons ! 

[Jerome Tonnellier]

>alors c, c'est un objet qui contient l'objet b dans son outer ?

Oui.

>(et b contient a dans son outer evidemment) 

Nan, b contient a dans son "super".

>pourquoi c contient b dans son outer...?

Parce que :-)

>que veut dire fermeture?

En gros, une fois que t'as fini de définir un objet, tu peux l'utliser dans sa totalité ailleurs.

Jérôme.

[Jerome Tonnellier]

Pardon, j'ai dit une bêtise...

>(et b contient a dans son outer evidemment)

a contient b dans ses "values".

[Sandra Naboulet]

>(et b contient a dans son outer evidemment) 

Nan, b contient a dans son "super".

je suis pas d'accord. dans le champs super, c'est l'objet duquel il herite.

b n'herite pas de a... si on avait "object b extends a" oui, mais la par defaut c'est "object b extends Object", le seul lien entre a et b c'est que a est le contexte de definition de b. donc il est contenu dans le champs outer de b.

[Sandra Naboulet]

a contient b dans ses "values".

 

et b contient a dans son outer... 

[Jerome Tonnellier]

Ok, prouves-le. Je vais chercher aussi. :-)

[Sandra Naboulet]

Il faudrait que Gianas explique ce passage une bonne fois pour toute...

Le 2 juin 2012 17:35, Jerome Tonnellier <jerome.t...@gmail.com> a écrit :

[Jerome Tonnellier]

T 'as peu-être raison mais je veux quand même au moins un paquet de shokobon :p

[Sandra Naboulet]

Le 2 juin 2012 17:56, Jerome Tonnellier <jerome.t...@gmail.com> a écrit :

T 'as peu-être raison mais je veux quand même au moins un paquet de shokobon :p

pas de soucis ! Lundi tu l'as ! 

[Jerome Tonnellier]

Ok, j'y serai :p

[Yann Régis-Gianas]

2012/6/2 Sandra Naboulet <s.nab...@gmail.com>:

> object a {
>      val x = 3
> }
>
> object b {
>      val y = a.x
> }
> pour évaluer x, on doit évaluer a.

Pour évaluer _y_, on doit évaluer a.

> Mais l'évaluation de a se fait dans quel contexte de définition ?
> root_object?

Oui.

> mais a un moment donné, l'application se fera comme ceci : lookup_value
> root_object "a"... mais rechercher un element "a" dans root_object c'est
> bizarre non ? root_object ne contient rien...seulement un objet pere...

Au début de l'évaluation, on évalue "a" dans le root_object, ce qui
rajoute "a" dans cet objet.

Cet objet est justement le "outer" de "b". Du coup, en évaluant le
champ "y" de "b" : on cherche d'abord "x" dans "b", ce qui échoue et
cette méme recherche échoue dans le super de "b", Object. Du coup, on
cherche dans "outer" et là, miracle, "a" s'y trouve!

Est-ce que c'est plus clair maintenant?

>
> Je vous remercie

[Stephane Wong]

Un peu plus clair.
Merci.