[24i2] Au sujet de DIM_LOCAL

Attention :
Je ne sais pas si c'est volontaire mais :
les paramètres ne sont pas reinitialisés par cette instruction !
Cela signifie que leur contenu est conservé après le END_SUB...

Code:

DIM i
FOR i = 0 TO 10
  Test()
NEXT i
END
SUB Test()
 DIM_LOCAL param
 print param
 param = param+1
END_SUB

Bonjour.

Je pense que l'on devrait voir l'affichage de la valeur zéro dix fois, et non 0 à 10.

Effectivement, il était question d'un "free_local" implicite au "end_sub"
et l'affichage devrait être dix fois 0...

Ce n’est pas beau, ça !
Ça peut induire en erreur.
Pour réinitialiser la variable, doit-on avoir recours à FREE ?
Avec FREE variable, ça devient correct.
Mais là quel « plus » le DIM_LOCAL a-t-il ajouté ?

Code:

DIM i
FOR i = 0 TO 10
  Test()
NEXT i
END
SUB Test()
 DIM_LOCAL param
' print param
 param = param+1
 print param
 free param
END_SUB

Eh bien, je crois bien que tu as trouvé un BUG (en gros pour attirer le regard de Jack...) ! En effet, le but même des variables locales, c'est d'être libérées automatiquement par END_SUB. D'ailleurs, au second passage, la commande DIM_LOCAL ne signale pâs que la variable est déjà définie ! Et c'est même pire que ça:

Code:

DIM i
FOR i = 0 TO 10
  Test()
NEXT i
END
SUB Test()
 DIM_LOCAL param
 DIM_LOCAL param
 print param
 param = param+1
END_SUB

Même au premier passage, on devrait avoir une erreur de variable déjà définie. Il y a bien un problème, à la fois avec END_SUB et avec DIM_LOCAL. Et c'est identique pour les variables en flottant, en entier ou en chaîne de caractères.
Et même ceci:

Code:

DIM i
FOR i = 0 TO 10
  Test(i)
NEXT i
END
SUB Test(x)
 DIM_LOCAL param
 DIM_LOCAL param
 DIM_LOCAL x
 x = x*2
 print str$(param)+"  "+str$(x)
 param = param+1
END_SUB

Cela ne vous interpelle pas ? Redéfinir un paramètre formel ? Il y a bien un problème avec DIM_LOCAL.
J'utilise la V0.24i2 du 12 Septembre.

EDIT

J'ai corrigé l'erreur de manipulation qui faisait que le dernier code n'était pas complet. Desculpe-me...

D'après ce que j'ai compris, Jack nous a passé une version non-sécurisée :

il n'y a pas de contrôle par exemple sur le nb de paramètre passé à la procedure.
donc je suppose qu'au niveau contrôle/vérif si une DIM locale est déjà déclarée, rien n'a encore été écrit...(c'est du même style que nb param)

Soit, c'est pas grave... Jack planche certainement déjà sur le sujet.
Par contre, la libération d'une variable locale au moment du END_SUB me parait plus important, fonctionnellement parlant...

C'est ennuyeux cette histoire, je vais rester prudent (et je le suis déjà) avec le dernière version.

Merci pour l'info Nardo

A+

Salut tout le monde.

J’ai une proposition à vous faire. Libre à vous de ne pas en tenir compte.

Etant donné que la version actuelle est une version non stable, je vous propose de ne pas trop vous investir dans le développement de programmes consistants (avec cette version) et de faire des petits essais et tests (aussi inattendus soient-ils) pour découvrir ce qui ne va pas.

Je pense que de cette façon on peut aider Jack un tant soit peu pour qu’il puisse apporter les corrections et les modifications utiles.

A bon lecteur, salut !

je suis d'accord Papydall

Perso, je suis à fond avec cette version.
Je commence même à écrire une petite librairie de"fonctions".
-> Je code mes procédures de manière à être facilement modifiable pour en faire des fonctions par la suite.
Si personne n'utilise cette version, je ne vois pourquoi Jack continuerai dans cette voie et cela serait bien dommage...
il ne faut oublier que c'est une vraie "beta-version" et qu'il faut faire avec. Les petites imperfections inherentes à ce stade sont négligeables en comparaison du gain obtenu avec les SUB...

Il n'a pas dis ça, juste de ne pas créer des énormes programmes s'il y a des problèmes mais de tester à fond sur des tas de petits dans tous les sens pour aider Jack à finir les tests et le debuggage. Enfin, c'est comme ça que je l'ai compris

Peut-être me suis-je mal exprimé.
Je ne suis pas contre l’utilisation de cette version, bien au contraire !
Je dis qu’on devrait procéder à des essais et tests pour valider ou invalider certains comportements des nouveaux ajouts.
C’était un point de vue ; et comme toute chose peut être vue de plusieurs angles, alors ....

J' ai essayé l'exemple de la doc et....rien!
J'ai même eu droit à des accès violation alors
que j'avais un prog en cours d'écriture sur un autre onglet.

Et j'vous dis pas...la violation du bill...faut s'la faire...

C'est effectivement une version d'essai qui est mise au téléchargement, et qui a ses imperfections.

Les mots-clés SUB, END_SUB et DIM_LOCAL sont définitifs. Je veux dire qu'ils resteront ainsi dans toutes les versions futures de PANORAMIC : vous n'aurez pas à modifier vos sources plus tard si vous les utilisez aujourd'hui, ils ne changeront pas.

DIM_LOCAL n'efface pas les valeurs des variables après le END_SUB car je n'avais pas pensé cela utile, vu que ces variables sont normalement réutilisées à chaque appel du SUB et donc devraient être réaffectées à chaque appel. Mais cela se discute.

Le nombre de paramètres lors de l'appel n'est pas complètement testé: si on appelle un SUB avec un nombre de paramètres suppérieur au nombre de paramètres définis par la déclaration du SUB, il y a erreur. Mais si on appelle un SUB avec un nombre de paramètres inférieur à celui de la déclaration (SUB), il n'y a pas encore de message d'erreur.

Je pense qu'il est normal qu'il n'y ait pas d'erreur quand, à chaque appel d'un SUB, une ligne DIM_LOCAL est réexécutée. Une ligne DIM_LOCAL n'est exécutée qu'une seule fois par PANORAMIC : à la première exécution du SUB.
Sinon, l'utilisateur devrait lui-même gérer la ligne et tester s'il exécute le SUB pour la première fois pour exécuter DIM_LOCAL et ne plus l'exécuter lors des appels suivants. Cela est contraire au principe de simplicité de PANORAMIC.

Quant aux fonctions, je rencontre une difficulté inattendue et il faudra patienter encore avant de les utiliser. La difficulté (de taille) est que PANORAMIC n'a pas du tout été pensé pour exécuter une partie de code en plein milieu de l'évaluation d'une expression.
Je m'explique.
Si l'utilisateur définit la fonction "ma_fonction%" par:

Code:

FNC ma_fonction%(x%,y%)
- - -
END_FNC

et qu'on la retrouve dans:

Citation :

button 34+5*ma_fonction%(3+s%*i%,3+24*a%+5*z%)+9*u%*h%

eh bien PANORAMIC n'a pas du tout été conçu pour aller exécuter le code de ma_fonction% pendant l'évaluation de l'expression 34+5*ma_fonction%(3+s%*i%,3+24*a%+5*z%)+9*u%*h%
Je dois changer complètement la manière dont PANORAMIC évalue les expressions avant d'implémenter les fonctions.

Jack, merci pour ces éclaircissements.
Prends ton temps. On peut toujours patienter !

Au moins on sait maintenant que l’appel des fonctions se fera par FNC.... et la sortie par END_FNC.

Merci, Jack, pour ces explications.

J'ai une réserve par rapport à ta vision de DIM_LOCAL. Pour moi, tout ce qui a été mis en place lors d'une entrée dans un SUB doit être épuré complètement à la sortie. Les variables locales doivent être effacées comme s'il y avait un FREE implicite sur chaque variable. En effet, lorsque le programmeur appelle une même procédure à différents endroits d'un programme, il le fait en supposant que la procédure s'exécute de la même manière, quelque soit l'endroit dans son programme qui l'appelle la première fois, ou une des fois suivantes. La notion même de variable locale est contraire avec la persistance de données.

Cela devrait fonctionner comme si toutes les variables locales étaient créées sur la pile, et donc simplement oubliées au retour par le nettoyage de la pile. Je me doute que techniquement, tu ne le réalises pas comme ça, mais il faudrait veiller à faire un FREE implicite sur toutes les variables locales. Et dans ce cas, DIM_LOCAL peut s'exécuter normalement comme le DIM actuel, avec test d'existence des variables PAR RAPPORT AUX VARIABLES LOCALES DE LA MEME PROCEDURE ! Il n'y aura aucun conflit, et une protection contre la redéfinition de variables. De plus, il devrait être interdit de déclarer une variable locale du même nom qu'un paramètre formel de la procédure - cela semble évident et n'est pas le cas aujourd'hui.

Je crois que cette conception contribue à la simplicité de Panoramic par la clarté des règles. Un millième appel à une procédure doit se dérouler EXACTEMENT comme le premier, et ce n'est pas le cas si tu ne libères pas les variables locales.

Klaus, ton analyse est claire.
A y réfléchir une fraction de seconde seulement, j’adhère à cette vision.

Je suis d'accord avec cette vision de la chose

donc +1... plus que 12

Je vais faire celui qui suit pas les idée des autres. Il faut un peu de changement de temps en temps.
Ce qui serait bien, ce serait de pouvoir défionir ainsi:

Code:

dim_local a%=10 , b$="salut, c%

Ainsi les deux cas se rejoignent. Celui qui veut pousuivre sa variable, d'appel en appel, initialise normalement, et celui qui reprend tout-à zéro, lui donne la valeur (ou le contenu) voulue.

En AutoIt cela marche ainsi, et il me semble qu'en Delphi, si mes souvenirs sont bons, une variable peut avoir n'importe quel contenu à l'initialisation. Il faut lui indiquer celui-ci. Je ne crois pas me tromper sur ce point.

Une fois que l'on connait le truc et qu'il faut considérer les variables locales comme étant de type statique, perso cela ne me dérange pas de les initialiser avant utilisation.

De toute manière ces variables, si elles sont déclarées, doivent fatalement subir une affectation à un moment donné. A nous de faire attention à ce que l'on écrit... Même dans d'autres langages, je m'efforce de les initialiser (on ne sait jamais ce qu'il y a dans la pile)

@Jicehel : Mauvaise nouvelle, cela signifie aussi qu'il n'y aura pas possibilité de faire du récursif si chaque appel pointe sur la même zone mémoire pour les variables locales...


Je ne sais pas comment est structuré le noyau Panoramic mais un truc que je ne pige pas, c'est la difficulté de Jack concernant les fonctions qui se trouvent dans une expression...

C'est déjà plus ou moins en place : quand j'écris c = 30 + asc(mid$(a$, i, 1)) + z

on a bien le déroulement du code d'une ou plusieurs fonctions (mid$ + asc) dans cette expression...

Bonsoir,

UN VRAI DÉBAT ET IMPORTANT POUR LA SIMPLICITÉ c'est DIM_LOCAL....

Jack a écrit:

Je pense qu'il est normal qu'il n'y ait pas d'erreur quand, à chaque appel d'un SUB, une ligne DIM_LOCAL est réexécutée. Une ligne DIM_LOCAL n'est exécutée qu'une seule fois par PANORAMIC : à la première exécution du SUB.
Sinon, l'utilisateur devrait lui-même gérer la ligne et tester s'il exécute le SUB pour la première fois pour exécuter DIM_LOCAL et ne plus l'exécuter lors des appels suivants. Cela est contraire au principe de simplicité de PANORAMIC.

Klaus a écrit:

J'ai une réserve par rapport à ta vision de DIM_LOCAL. Pour moi, tout ce qui a été mis en place lors d'une entrée dans un SUB doit être épuré complètement à la sortie. Les variables locales doivent être effacées comme s'il y avait un FREE implicite sur chaque variable. En effet, lorsque le programmeur appelle une même procédure à différents endroits d'un programme, il le fait en supposant que la procédure s'exécute de la même manière, quelque soit l'endroit dans son programme qui l'appelle la première fois, ou une des fois suivantes. La notion même de variable locale est contraire avec la persistance de données.

Dans ma vision (bonne ou mauvaise) l'instruction DIM_LOCAL est écrite à l'intérieur de la procédure ,donc entre SUB() et END_SUB. Si c'est le cas, je ne vois pas pourquoi il n'y aurait pas un FREE_AUTOMATIQUE vu que la ou les variable(s) se retrouvent automatiquement recrées dès que l'on retourne dans la procédure (SUB).

qu'en pensez-vous ? pour ma part je me range à l'avis de Klaus.

Merci Jack pour le travail que tu fais, je sens bien que çà n'a pas l'air d'être de la tarte....


A+

EDIT: ON s'est croisés avec Cosmos et Nardo, mais cela ne change rien à ma pensée sur le sujet.

@Jicehel, rectification concernant les appels récursifs:
On pourra en faire mais les choses risquent d'être un peu plus compliqué :
- Mise en place d'un système avec création de DLIST en dynamique pour simuler les dim locaux...

Citation :

Pour moi, tout ce qui a été mis en place lors d'une entrée dans un SUB doit être épuré complètement à la sortie. Les variables locales doivent être effacées comme s'il y avait un FREE implicite sur chaque variable.

@Klaus:
Cela me parait logique.

Citation :

un truc que je ne pige pas, c'est la difficulté de Jack concernant les fonctions qui se trouvent dans une expression...
C'est déjà plus ou moins en place : quand j'écris c = 30 + asc(mid$(a$, i, 1)) + z
on a bien le déroulement du code d'une ou plusieurs fonctions (mid$ + asc) dans cette expression

@Nardo:
Non, c'est complètement différent:
asc et mid$ de ton exemple ne font pas partie du source.
ma_fonction% de mon exemple fait partie du source.
Et c'est une difficulté énorme car pour obtenir le résultat de "ma_fonction%" en plein milieu d'une expression, alors que la ligne n'est pas complètement évaluée, et qu'on n'est pas encore passé à la ligne suivante, il faut exécuter d'autres lignes du source, celles qui contiennent la fonction utilisateur ma_fonction%.
Le code de asc et de mid$ se trouve dans le code interne de PANORAMIC: il n'y a pas besoin d'exécuter du source pour obtenir un résultat.
Le code de ma_fonction% est dans le source lui-même et il faut l'exécuter en plein milieu de l'exécution d'une autre ligne.
C'est une difficulté, mais rassurez-vous, j'ai une solution. Elle va seulement être longue à implémenter.

ok merci pour l'explication. par contre hors expression, une syntaxe simple de fonction serait elle envisageable du genre s$=mafonction(paramètres) ?
par ce que dans ce cas, on évalue la fonction et on l'utilise après.
Je pense que comme ça, c'est plus simple à coder et tout à fait exploitable dans les programmes.

Réduire les fonctions à l'affectation d'une variable, c'est quelques heures de travail:

Code:

a%=ma_fonction%(5+b%,6+c%)

Pouvoir les utiliser dans une expression, c'est plusieurs semaines de travail:

Code:

a%=ma_fonction%(5+b%,6+c%)+1
a%=ma_fonction%(ma_fonction%(b%,c%),ma_fonction%(d%,e%))+1