☑ nouvelle fonctionnalité intéressante
☑ pourrait aider de nombreux utilisateurs !
☑ supprime quelque chose qui ressemble à un « bug »
☐ agréable à avoir
☐ personne n'en a besoin
#monTop10_2024
Court:
Laissez l'éditeur JSL montrer quelle fonction évalue ses arguments et quelle fonction ne le fait pas !
Long:
Qu'est-ce qui a inspiré cette demande de liste de souhaits ?
Il existe un comportement très puissant dans JSL qui, d'un autre côté, rend difficile pour les nouveaux utilisateurs de démarrer sans problème :
Certaines fonctions évaluent leurs arguments et d'autres non.
Ceci est très important pour les fonctions utilisées pour la gestion des expressions.
Il y a une merveilleuse conférence de @joseph_morgan : Utiliser JSL pour développer des applications efficaces et robustes (UE 2018 415) sur les différences, comment vivre avec elles et comment les utiliser pour développer des applications efficaces et robustes.
... décrivant l'état à ce moment-là : Jmp 14 [2018] :
Cela n'existe pas dans la documentation.
C'est quelque chose que j'ai découvert [ ] en procédant à une rétro-ingénierie du comportement des fonctions de gestion des expressions.
Croyez-moi, [ ] si vous ne pensez pas à ces fonctions, vous ne les obtiendrez jamais correctement.
Outre les fonctions de gestion d’expression répertoriées ici, la même chose s’applique à toutes les fonctions :
si vous ne pensez pas à ces fonctions, vous ne les obtiendrez jamais correctement :
Il est très important de savoir si un argument est évalué avant l'appel de fonction not.
Est-ce que ce code fonctionne ou pas ?!?
dt = Expr(current data table());
myscript = Expr(get script());
dt << myscript
Malheureusement, pour le scripteur JSL, il n'y a aucune indication sur le comportement de la fonction : évalue-t-elle ses arguments ou non ?
Peut-être qu'il s'agit simplement d'évaluer l'un des arguments ? Qui sait ?
L'utilisateur doit savoir !
... ou : rétro-ingénierie du comportement des fonctions respectives.
Quelle amélioration souhaiteriez-vous voir ?
Veuillez implémenter une coloration syntaxique pour indiquer les différentes manières dont une fonction évalue - ou n'évalue pas - ses arguments.
Module complémentaire : veuillez également indiquer la différence dans l'index de script.
Dans l'éditeur JSL, la mise en surbrillance peut être activée/désactivée via un raccourci clavier.
L'exemple Expr(_x_^2) montre un certain type de dilemme :
l'argument de Expr() n'est pas évalué. Mais les deux arguments de ^ seraient évalués.
Peut-être que la mise en surbrillance réagit à la position de la souris ou du curseur - seuls les arguments situés sous la branche sont mis en surbrillance là où se trouve actuellement la souris/le curseur.
Pourquoi cette idée est-elle importante ?
Avec la nouvelle coloration syntaxique, JMP guidera automatiquement l'utilisateur pour générer le bon code.
L'utilisateur n'a pas besoin d'exécuter le code pour obtenir un message d'erreur ou pour voir le mauvais résultat
... ou de procéder à une rétro-ingénierie de la fonction - comme @JosephMorgan a dû le faire pour préparer son article.
autres souhaits de 
Il semble qu'entre
1) l'argument est évalué
2) l'argument n'est pas évalué
il existe une troisième variante :
1b) l'argument est évalué "une fois"
fonctions qui se comportent de cette façon :
- Tête
- Recode Column (1er argument et argument de l'argument Target Column()
-... ?
Une troisième couleur sera donc nécessaire.
dt = Open("$SAMPLE_DATA/Big Class.jmp");
col = Name Expr(As Column("name"));
Head(As Column("name"));
Head(col);
dt << Recode Column(AsColumn("name"),{1},Target Column(col));Head évalue-t-il son argument ?
https://community.jmp.com/t5/Discussions/Begin-Data-Update/mp/753037/highlight/true#M93483
... décrivant la situation à cette époque : Jmp 14 [2018] :
Cela n'existe pas dans la documentation.
C'est quelque chose que j'ai compris [ ] en procédant à l'ingénierie inverse du comportement des fonctions de gestion des expressions.
Croyez-moi, [ ] si vous ne pensez pas à ces fonctions, vous ne les réussirez jamais.
Statut actuel, Jmp18 (2024) :
Hm, il reste encore quelques problèmes qui pourraient ne pas être résolus par la coloration syntaxique avancée...
par exemple
from the printed "2" one can see that JMP actually evaluates the argument of the Set File List setting - 3 times !?!
... but at the end, it complains about the "print" ?!?
... and without the print it won't do anything, neither complain nor open the file from liste de fichiers.
folder= "$SAMPLE_DATA/../Import Data/";
file= "Animals.txt";
filelist= Eval List({folder||file});
Multiple File Import(
<<SET folder=""></SET><SPAN class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="hogi_0-1720645070503.png" style="width: 400px;"><SPAN class="lia-inline-image-display-wrapper" image-alt="hogi_0-1720645070503.png" style="width: 400px;"><SPAN class="lia-inline-image-display-wrapper" image-alt="hogi_0-1720645070503.png" style="width: 400px;"><span class="lia-inline-image-display-wrapper" image-alt="hogi_0-1720645070503.png" style="width: 400px;"><img src="https://us.v-cdn.net/6038925/uploads/images/66063i6C7744FFCF743C3B/hogi_0-1720645070503.png" role="button" title="hogi_0-1720645070503.png" alt="hogi_0-1720645070503.png" /></span></SPAN></SPAN></SPAN>
<STRONG>TS-00152969:</STRONG>
<EM>J'ai parlé du problème avec le développement. Il s'agit d'un défaut et je l'ai signalé au développement afin qu'il puisse être résolu dans une future version de JMP.<BR /><BR /> merci beaucoup -> corrigé dans JMP19EA5</EM>
