Re : Question sur le type() de la variable déclarée avec expr()La principale chose à retenir est que Imprimer() , Écrire() et Spectacle() traitez leurs arguments un peu différemment de la plupart des fonctions - ils décompressent mais n'évaluent pas. Ainsi Imprimer( c ) imprimera la chose qui c est -- c'est une expression. Taper() décompressera puis évaluera son argument puis retournera son type. Si tu veux Taper() se comporter davantage comme Imprimer() , puis utilisez Nom Expr() , comme Type( Nom Expr( c ) )
Re : Question sur le type() de la variable déclarée avec expr()Merci @ErraticAttach
Je comprends bien ce que vous expliquez.
Cependant, j'ai une question pour vous.
Si Taper () est déballé et évalué, puis Expr (a + b) est évalué dans le cas 4, Number ne devrait-il pas être renvoyé comme valeur de retour de Taper () comme dans le cas 3 ?Dans le processus d'évaluation du type après décompactage, le traitement diffère-t-il selon que l'argument est spécifié comme une variable ou une fonction ?
Re : Question sur le type() de la variable déclarée avec expr()Des langages comme C et C++ évaluent les arguments des appels de fonction avant l'appel. C et C++ n'ont pas de type de données Expression car les expressions sont compilées dans le code au moment de la compilation. Exécution plus rapide, mais limite certaines des façons dont vous pouvez penser à résoudre un problème.
JSL a une fonction parse() qui prend une chaîne et la transforme en arbre d'expression. La fonction eval() évalue l'arbre. L'arborescence est évaluée automatiquement lorsqu'elle est accessible en tant que côté droit d'une affectation, à moins qu'une attention particulière ne soit prise pour y jeter un coup d'œil.Il existe une fonction nameExpr() qui ne doit être utilisée que si vous devez consulter l'expression stockée dans une variable sans l'évaluer accidentellement. Pour une raison quelconque, perdue dans le temps, et peut-être trop tard pour corriger maintenant, print/show/write ont été écrits sans l'appel pour évaluer leurs arguments si l'argument semble être une simple variable. Ok, à l'époque, cela semblait probablement être une accélération car il y a une surcharge pour eval(c) vs juste obtenir la valeur de c. Mais print(c+0) évaluera l'argument, tout comme print(eval(c)), car l'argument n'est pas une simple variable.
Re : Question sur le type() de la variable déclarée avec expr()@Craige_Hales a certainement raison - le déballage n'est pas un bon terme, désolé pour toute confusion !Le comportement que j'essayais de décrire est cependant documenté -- consultez ce lien : https://www.jmp.com/support/help/en/15.2/index.shtml#page/jmp/expressions.shtml
Voici le bit pertinent :
Re : Question sur le type() de la variable déclarée avec expr()MERCI!! vous avez été extrêmement utile! 
Re : Question sur le type() de la variable déclarée avec expr()Merci! Devenu très utile.
Re : Question sur le type() de la variable déclarée avec expr()a = 1;
b = 2;
type( a + b );
"Nombre"
En interne, type a reçu une arborescence d'expressions qui ressemble à add( a, b ). L'arbre est évalué à un nombre.
a = 1;
b = 2;
type( expr( a + b ) );
"Expression"
En interne, le type a reçu une arborescence d'expressions qui ressemble à expr( add( a, b ) ). Encore une fois, l'arbre est évalué ; le nœud expr() dans l'arbre renvoie son argument sous forme d'expression.
a = 1;
b = 2;
c = expr( a + b );
type( c );
"Nombre"
En interne, le type a reçu un arbre d'expression qui ressemble à c. Encore une fois, il est évalué. c est une expression, add(a,b), qui utilisera les valeurs courantes de a et b chaque fois que c est évalué.c n'a PAS de nœud expr() dans son arbre.
"déballer" n'est pas une idée bien définie dans JSL. Chaque fonction intégrée voit initialement ses arguments comme des arbres d'expression. Certaines fonctions évaluent leurs arguments sans les regarder au préalable. Les autres fonctions ne les évaluent jamais. Certaines fonctions vérifient si le nœud racine de l'expression est eval() ou expr() ou send() et font quelque chose de différent. (send() est l'opérateur <<. Il existe une utilisation unaire dans les listes d'arguments pour identifier des arguments spéciaux, souvent des messages réels envoyés à une boîte d'affichage en cours de création.) L'ajout d'une expression de formule à une colonne est un exemple qui me fait parfois trébucher ; il suppose que l'argument ne doit pas être évalué. L'ajout de eval() autour de la formule entraîne son évaluation, car formula(...) jette un coup d'œil à l'argument. L'alternative aurait été de toujours évaluer l'argument, puis le cas d'utilisation normal nécessiterait expr() autour de la formule (parce que l'évaluation de expr(...) ne fait que renvoyer son argument.)
Question sur le type() de la variable déclarée avec expr()Salut
J'utilise 'expr()' et j'ai quelques questions.
Je poserai des questions selon le nombre écrit dans les commentaires.
1) Peut-on considérer que eval() est appliqué lorsque c est exécuté tel quel ?
2) -
3) Pourquoi Number apparaît-il lorsque le type de variable c déclaré comme expr() est coché ?
Si type() exécute l'argument, reconnaît le type et affiche le résultat, je me demande pourquoi c'est Expression en cas de 4).
4) -
a = 1;
b = 2;
c = expr(a + b);
c; // 1) Result : 3
print(c); // 2) Result : a + b
type(c); // 3) Result : Number
type(expr(a + b)); // 4) Result : Expression
Merci
Ingénierie de la qualité et des procédésRe : Question sur le type() d'une variable déclarée avec expr()Intéressant de voir que l'écriture fait des choses différentes selon le type d'argument.
Il existe d'autres fonctions qui font l'inverse : elles recherchent un nom simple, mais n'évaluent PAS une expression plus complexe.
Quelqu'un a-t-il une liste complète des fonctions qui « recherchent », « décompressent », « évaluent » ... son argument avant de l'utiliser ?
Combien de cas faut-il considérer ?
J'ai remarqué qu'il existe des cas particuliers comme pour chacun - qui vérifie si le premier argument est une liste.
x= Expr(Print(2));
y = "hello";
Write(x); // ->Print(2)
Write(y || " world"); // hello world
Head(x); // Print()
Type(x); //-> 2
...
