Subroutine, Function ainsi que labels et variables locales

@Jack:
Suite à une série de posts dans un autre fil de discussion, je voudrais relancer l'idée d'avoir des sous-programmes et fonctions dans Panoramic avec possibilité de passage de paramètres, ainsi que la possibilité d'avoir des labels et variables "locales", c'est-à-dire avec une visibilité restreinte à une zone particulière.

Je propose, pour cela, plusieurs ajouts.

1. la création d'une variable système interne reflétant le niveau actuel de visibilite. Elle pourrait s'appeler LOCAL_LEVEL et aurait la valeur 0 au départ.

2. la création de deux directives allant par paire:
#LOCAL_MODE_ON
et
#LOCAL_MODE_OFF

La directive #LOCAL_MODE_ON incrémenterait la variable LOCAL_LEVEL, la directive #LOCAL_MODE la décrémenterait.

3. dès que LOCAL_LEVEL>0, Panoramic "préfixerait" ou "modifierait" le nom de chaque variable définie par DIM et chaque label défini par LABEL à l'aide de cette variable système, du type
dim i% ---> dim LOCAL_0001_i%
label test ---> label LOCAL_0001_test
si LOCAL_LEVEL contient 1.

Avec ce procédé, on aurait immédiatement la possibilité, dans un sous-programme appelé par GOSUB, par exemple, d'inclure ces directives au début et à la fin du source de ce sous-programme, et les variables et labels définis par ce sous-programme seraient propres à ce sous-programme. Toutes les variables et labels restent bien sûr visibles partout, à l'intérieur et à l'extérieur d'une telle section, comme c'est le cas actuellement. Mais l'effet net serait qu'on aurait plus besoin de se soucier de conflits - dès qu'on redoute un conflit, on redéfinit les variables entre ces deux directives et on se trouve automatiquement avec des variables distinctes, et idem pour les labels.

4. la création de 2 nouvelles commandes allant par paire:
SUBROUTINE MonSousprogramme(param1,param2,...)
END_SUBROUTINE ou END_SUB

La directive SUBROUTINE ayant pour effet d'effectuer de façon implicite la commande existante suivante:
MonSousprogramme:
ET l'exécution d'une directive #LOCAL_MODE_ON implicite. Tous les paramètres formels seraient implicitement définis en variables locales, préfixées comme décrit ci-dessus, sachant que la commande LABEL correspondante doit toujours être placée à un endroit stratégique du code et être exécuté chronologiquement AVANT l'utilisation de la commande CALL ci-dessous.

La commande END_SUB aurait pour effet l'exécution d'unhe directive LOCAL_MODE_OFF et servirait de contrôle de cohérence - pour tout SUBROUTINE il doit y avoir un END_SUB. Le return continuerait à être assuré par la commande RETURN.

5. la commande CALL MonSousprogramme(par1,par2,...) transférerait le contrôle au label MonSousprogramme comme par une commande GOSUB, puis chargerait les variables locales représentant les paramètres formels par le contenu des paramètres actuels de l'appel.

6. la création de deux nouvelles commandes allant par paire:
FUNCTION MaFonction(par1,par2,...)
END_FUNCTION

Le fonctionnnement serait identique à celui des commandes SUBROUTINE...END_SUB, Mais la commande FUNCTION créerait une variable locale préfixée supplémentaire du nom de la fonction, ce serait donc
LOCAL_nnnn_MaFonction
et avant le RETURN de la fonction, on ferait
MaFonction = expression
ce qui serait traduit automatiquement par
LOCAL_nnnn_MaFonction = expression

Et L'appel de la fonction par
MonResultat = MaFonction(expression1,expression2,...)
serait remplacé automatiquement par
MonResultat = LOCAL_nnnn_MaFonction
Et cette variable serait définie car elle aurait été créé à l'appel par la commande FUNCTION.

Reste un probl_me à résoudre, celui des appels successifs au même sous-programme ou à la même fonction.
Pour résoudre cela, il suffirait, si les variables locales correspondant aux paramètres formels ou au nom de la fonction existen déjà, de simplement les réinitialiser (entiers et flottants à zéro, strings à vide), et le tour sera joué.

J'espère, Jack, que je ne t'importune pas avec ce post très long, mais je tenais à expliquer le plus clairement possible mon idée.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Je vais regarder tranquillement et attentivement ta proposition dès que je le pourrai.
Je suis tès très pris par le travail et je n'ai pas beaucoup de temps libre (je n'arrive même pas à terminer la documentation pour sortir la V 0.9.20)
Mais les sous-programmes et fonctions sont des choses importantes.

Je te remercie de prendre ma proposition au sérieux. Je pense que cela apportera un sérieux plus à Panoramic, mais il est évident que cela n'a aucun caractère d'urgence. Je suis pleinement satisfait si tu juges ma suggestion digne d'intérêt, et tout va bien.

Juste une petite remarque, si vous le permettez :
LOCAL_LEVEL sert à quoi ?
Une variable locale est déclarée dans la pile normalement... non ?
une fois dépilées (sur return par ex) les variables locales n'existent plus...

Oui et non. On pourrait l'implémenter comme ça, avec une pile contenant l'espace de données pour les variables locales et éventuellement la table de symboles correspondante, ou alors celle-ci est dans une pile à part.

Non, car je voulais éviter cela, justement. D'une part, cela complique considérablement la gestion de mémoire. Il faudrait en plus chercher dans plusieurs tables de symboles, à un instant t donné. Mon idée consiste simplement à changer de façon automatique et transparente les noms des variables et labels, de sorte qu'il n'y ait plus de conflit possible. Et du même coup, tout ça est géré dans le même espace mémoire et dans la même table de symboles, ce qui veut dire que pour Panoramic, RIEN n'est changé au niveau de la logique d'implémentation, et on ne complique pas la gestion de mémoire dynamique déjà complexe. Et le petit bonus, c'est que toutes ces variables sont en réalité des variables absolument normales, visibles partout, et de ce fait, la variable générée automatiquement au moment de la commande FONCTION nommée LOCAL_nnnn_MaFonction (et et as compris que nnnn est le contenu de la variable LOCAL_LEVEL et MaFonction est le nom qu'un donne à une fonction) existe non seulement à l'intérieur de la fonction, pour lui attribuer une valeur, mais surtout en-dehors, après le RETURN, pour affecter cette valeur là où on avait appelé la fonction.

La variable LOCAL_LEVEL est une variable système (donc utilisable en lecture mais non modifiable par le programmeur) qui indique à quel niveau d'imbrication des sections locales on se trouve, et cette variable est utilisée de façon automatique par Panoramic pour préfixer les noms des variables et labels définis dans une section locale. En Panoramic, on écrirait:
NomDeVariableLocale = "LOCAL_"+str$(LOCAL_LEVEL)+"_"+NomDeVariable
(pardon pour cette facilité d'écriture).

Je rappelle la gestion automatique de cette variable:
LOCAL_MODE_ON, SUBROUTINE, FUNCTION: LOCAL_LEVEL = LOCAL_LEVEL + 1
LOCAL_MODE_OFF, END_SUB, END_FUNCTION: LOCAL_LEVEL = LOCAL_LEVEL - 1
si (LOCAL_LEVEL>0) alors
__si (commande=DIM ou commande=LABEL) alors NomLocal = "LOCAL_"+str$(LOCAL_LEVEL)+"_"+Nom
__si variable ou label utilisé alors
____si "LOCAL_"+str$(LOCAL_LEVEL)+"_"+Nom existe alors
________remplacer nom par LOCAL_"+str$(LOCAL_LEVEL)+"_"+Nom
____fin
__fin
fin

On peut ainsi écrire:

Code:: dim i%
i% = 1
...
#LOCAL_MODE_ON
dim i%
i% = 2
...
#LOCAL_MODE_ON
dim i%
i% = 3
...
print str$(i%)
#LOCAL_MODE_OFF
print str$(i%)
#LOCAL_MODE_OFF
print str$(i%)

et on obtient:
3
2
1

Et à tout momentl le programmeur peut savoir à quel niveau on est, en utilisant la variable systèmz LOCAL_LEVEL.

ça m'a l'air bien compliqué tout ça Wink

Je pense que le principal c'est de dire à Jack ce que tu veux comme type de changements et lui saura trouver comme apporter le plus que tu souhaite, j'en suis sûr.

#LOCAL_MODE_ON
#LOCAL_MODE_OFF

Y a pas moyen de raccourcir les noms des instructions ?

Si, bien sûr. On pourrait faire aussi:
#LOCAL_ON
#LOCAL_OFF
par exemple. L'important, c'est de pouvoir activer/désactiver la fonctionnalité.

@Jack:
Pour approfondir mon idée:

Je pense (et tu l'auras compris) que la commande FUNCTION doit prendre 3 formes, selon les 3 types de données possibles:
FUNCTION MaFonction(par1,par2,...) --> retourne un réel
FUNCTION MaFonction%(par1,par2,...) --> retourne un entier
FUNCTION MaFonction$(par1,par2,...) --> retourne une chaîne de caractères

Ces commandes agiraient ainsi:
' FUNCTION MaFonction(par1,par2,...)
#LOCAL_MODE_ON
label MaFonction_FLOAT
dim LOCAL_nnnn_MaFonction
MaFonction_FLOAT:

' FUNCTION MaFonction%(par1,par2,...)
#LOCAL_MODE_ON
label MaFonction_INT
dim LOCAL_nnnn_MaFonction%
MaFonction_INT:

' FUNCTION MaFonction$(par1,par2,...)
#LOCAL_MODE_ON
label MaFonction_STRING
dim LOCAL_nnnn_MaFonction$
MaFonction_STRING:

et la commande END_FUNCTION agirait ainsi:
' END_FUNCTION
#LOCAL_MODE_OFF
return

L'utilisation d'une fonction serait ainsi:
' res$ = MaFonction$(pas1,par2,...)
gosub MaFonction_STRING(par1,par2)
res$ = LOCAL_nnnn_MaFonction$ : ' avec nnnn = LOCAL_LEVEL + 1 car END_FUNCTION a décrémenté NIVEAU_LOCAL !

Ainsi, on peut retourner un résultat selon le type attendu, et on peut définir des fonctions selon leur type exactement comme les variables an Panoramic: i% et i$ sont des variables différentes et peuvent cohabiter, et pour MaFonction% et MaFonction$ ce serait pareil.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Où est la bonne vieille simplicité du QBasic ?
Il y avait:
SUB Toto (paramètres)
...
.... (EXIT_SUB)
...
END_SUB

FUNCTION Tata (paramètres)
...
END_FUNCTION

SUB et FUNCTION déclarés en tête du programme
Les SUB étant appelées par
Toto (paramètres)
et les FUNCTION par:
resultat = Tata (paramètres)

Les variables étaient implicitement locales à l'intérieur de la SUB, mais on pouvait y introduire les mots-clés:
SHARED var1,var2... les variables citées étaient partagées avec le programme principal
STATIC v1,v2... la valeur des variables citées était conservée d'un appel à l'autre de la sub.

Eh bien, dans ma suggestion, l'espace local et global est géré automatiquement, à l'intérieur d'une SUBROUTINE ou d'uen FUNCTION. Ce que j'ai indiqué ci-dessus, ce ne sont que des écritures symboliques pour représenter l'action à effectuer. Je l'au dit plus haut: SUBROUTINE et FUNCTION incrémentent automatiquement LOCAL_LEVEL ouvrant ainsi leur propre espace local. Toute variable et tout label défini à partir de ce moment, sera local à cette section, les variables définies auparavant sont globales et continuent à être visibles, sans déclaration particulière. Les commandes END_SUB et END_FUNCTION ferment l'espace local et on revient au niveau précédent. Tout cela est très simple et se fait sans aucune gymnastique. Les commandes #LOCAL_MODE_xxx ne servent qu'à produire locaement le même effet, SANS être dans un sous-programme ou dans une fonction. Ceci permettrait, par exemple, d'avoir un espace de variables locales dans un sous-programme classique appelé par GOSUB...

Pour retourner le résultat d'une fonction, je me suis conformé aux règles en vigueur dans Panoramic. Les fonctions retournant une chaîne de caractères dans Panoramic ont un $ à la fin de leur nom - je me suis dit que ce serait logique si des fonctions écrites par nous suivent la même logique. Un programme serait aussi plus lisible si on voyait tout de suite qu'une fonction doit retourner une chaîne, un entier ou un flottant.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

C'était effectivement implicite que le nom des Function correspond à la valeur retournés:
resultat$ = Toto$(param), ou res% = Zozo%(...) etc.

Par contre je suis plus dubitatif concernant la possibilité de variables locales dans un sous-programme qui pour moi fait partie intégrante du programme principal, je voyais cette possibilité réservée plutôt aux SUB et FUNCTION... mais bon, Jack tranchera tout ça, un de ces jours...

Tu as raison bien sûr pour les sous-programmes internes - il faut qu'ils restent comme ils sont ! Mais mon idée, c'est de leur apporter un plus, de leur permettre d'utiliser également cette possibilité, pour des variables de travail. Qui n'a pas eu de conflit sur des variables genre i%, n% etc ? Dans les sous-programmes que j'ai mis à disposition sur mon site, j'ai fait des constructions compliquées pour réduire le risque de conflit de nommage lorsque ces modules sont utilisés par un autre. Avec l'inclusion de directives #LOCAL_MODE_ON...#LOCAL_MODE_OFF, plus aucun problème: tout le monde peut inclure ces modules sans aucun risque de conflit, MEME si de mon côté, j'utilise des noms de variables simples !

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Tu as raison sur le fond... moi qui me sers de i%, j% et a$ à tout bout de champ il m'est arrivé d'avoir quelques problèmes...

Je publie ci-dessous une "maquette" d'un programme utilisant des fonctions écrites en Panoramic !

Le programme contient au début, le code tel qu'on l'écrirait si l'on avait les fonctions Panoramic avec paramètres, et à la suite, il y a un code 100 % Panoramic standard réalisant exactement cela. J'ai implémenté deux fonctions:
n% = InString%(chaine$,crit$,depart%) cherche crit$ dans chaine$ A PARTIR DE POSITION depart%
s$ = GetSegment$(chaine$,sep$,nseg%) retourne le segment numéro nseg% dans chaine$ en foncton du séparateur sep$

Ces fonctions font débat depuis longtemps sur le forum, et j'ai fait ici une version en utilisant les fonctions Panoramic (simulées car elles n'existent pas encore). Vous verrez que la fonction GetSeglent$ utilise elle-même la fonction InString%. Le programme est exécutable tel quel dans l'éditeur, il n'utilise aucune DLL.

Code:: label execute
goto execute

' Ceci est un essai d'utilisation de fonctions dans Panoramic.
' Cet essai est réalisé par les moyens seuls de Panoramic.
' Voici d'abord le code tel qu'on l'écrirait AVEC les fonctions:

label InString_i, InString_i_dim
label GetSegment_s, GetSegment_s_dim

dim res%, res$

res% = InString%("Lundi,Mardi,Mercredi,Jeudi",",",8)
print "Position 2ème virgule dans [Lundi,Mardi,Mercredi,Jeudi]": "+str$(res%)

res% = InString%("Lundi,Mardi,Mercredi,Jeudi","di",2)
print "Position 1er 'di' dans [Lundi,Mardi,Mercredi,Jeudi]: "+str$(res%)

res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",2)
print "2ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: "+res$
res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",4)
print "4ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: "+res$
res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",5)
print "5ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: "+res$

end

FUNCTION GetSegment$(st$,sep$,nseg%)
dim n%, p_debut%, p_fin%
n% = 0
p_debut% = 1

while n%<nseg%
p_fin% = InString(st$,sep$,p_debut%)
if p_fin%=0

if n%=nseg% - 1
p_fin% = len(st$) + 1
result$ = mid$(st$,p_debut%,p_fin%-p_debut%)
return
else
result$ = ""
return
end_if
end_if
result$ = mid$(st$,p_debut%,p_fin%-p_debut%)
p_debut% = p_fin% + 1
n% = n% + 1
end_while
return
END_FUNCTION

FUNCTION InString%(st$,crit$,start%)
dim s$
dim k%
s$ = right$(st$,len(st$)-start%+1)
k% = instr(s$,crit$)
if k%>0 then k% = k% + start%-1
InString% = k%
return
END_FUNCTION

=======================================================================================

execute:

' Et voici le code Panoramic simulant les fonctions:

label InString_i, InString_i_dim
label GetSegment_s, GetSegment_s_dim

dim res%, res$, x%

' res% = InString%("Lundi,Mardi,Mercredi,Jeudi",",",8)
' -------------------- début d'appel de fonction
gosub InString_i : ' pour définir les variables
InString_i_st$ = "Lundi,Mardi,Mercredi,Jeudi"
InString_i_crit$ = ","
InString_i_start% = 8
gosub InString_i
res% = InString_i_result%
InString_i_result% = -1
' -------------------- fin d'appel de fonction

print "Position 2ème virgule dans [Lundi,Mardi,Mercredi,Jeudi]: "+str$(res%)

' res% = InString%("Lundi,Mardi,Mercredi,Jeudi","di",2)
' -------------------- début d'appel de fonction
gosub InString_i : ' pour définir les variables
InString_i_st$ = "Lundi,Mardi,Mercredi,Jeudi"
InString_i_crit$ = "di"
InString_i_start% = 2
gosub InString_i
res% = InString_i_result%
InString_i_result% = -1
' -------------------- fin d'appel de fonction

print "Position 1er 'di' dans [Lundi,Mardi,Mercredi,Jeudi]: "+str$(res%)

' res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",2)
' -------------------- début d'appel de fonction
gosub GetSegment_s : ' pour définir les variables
GetSegment_s_st$ = "Lundi,Mardi,Mercredi,Jeudi"
GetSegment_s_sep$ = ","
GetSegment_s_nseg% = 2
gosub GetSegment_s
res$ = GetSegment_s_result$
GetSegment_s_result$ = "GetSegment_s_init"
' -------------------- fin d'appel de fonction

print "2ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: "+res$+"]"

' res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",4)
' -------------------- début d'appel de fonction
gosub GetSegment_s : ' pour définir les variables
GetSegment_s_st$ = "Lundi,Mardi,Mercredi,Jeudi"
GetSegment_s_sep$ = ","
GetSegment_s_nseg% = 4
gosub GetSegment_s
res$ = GetSegment_s_result$
GetSegment_s_result$ = "GetSegment_s_init"
' -------------------- fin d'appel de fonction

print "4ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: ["+res$+"]"

' res$ = GetSegment$("Lundi,Mardi,Mercredi,Jeudi",",",5)
' -------------------- début d'appel de fonction
gosub GetSegment_s : ' pour définir les variables
GetSegment_s_st$ = "Lundi,Mardi,Mercredi,Jeudi"
GetSegment_s_sep$ = ","
GetSegment_s_nseg% = 5
gosub GetSegment_s
res$ = GetSegment_s_result$
GetSegment_s_result$ = "GetSegment_s_init"
' -------------------- fin d'appel de fonction

print "5ème segment dans [Lundi,Mardi,Mercredi,Jeudi]: ["+res$+"]"

end

' FUNCTION GetSegment$(st$,sep$,nseg%)
' -------------------- début définition de fonction
GetSegment_s:
on_error_goto GetSegment_s_dim
label GetSegment_s_check, GetSegment_s_check1
dim GetSegment_s_result$
dim GetSegment_s_st$
dim GetSegment_s_sep$
dim GetSegment_s_nseg%
off_error_goto
return
GetSegment_s_dim:
off_error_goto
if GetSegment_s_result$="GetSegment_s_init"
GetSegment_s_result$ = ""
return
end_if
GetSegment_s_result$ = ""

' dim n%, p_debut%, p_fin%
gosub GetSegment_s_check

' n% = 0
LOCAL_GetSegment_s_n% = 0

' p_debut% = 1
LOCAL_GetSegment_s_p_debut% = 1

' while n%<nseg%
while LOCAL_GetSegment_s_n%<GetSegment_s_nseg%

' p_fin% = InString(st$,sep$,p_debut%)
' -------------------- début d'appel de fonction
gosub InString_i : ' pour définir les variables
InString_i_st$ = GetSegment_s_st$
InString_i_crit$ = GetSegment_s_sep$
InString_i_start% = LOCAL_GetSegment_s_p_debut%
gosub InString_i
LOCAL_GetSegment_s_p_fin% = InString_i_result%
InString_i_result% = -1
' -------------------- fin d'appel de fonction

' if p_fin%=0
if LOCAL_GetSegment_s_p_fin%=0

' if n%=nseg% - 1
if LOCAL_GetSegment_s_n%=GetSegment_s_nseg% - 1

' p_fin% = len(st$) + 1
LOCAL_GetSegment_s_p_fin% = len(GetSegment_s_st$) + 1

' result$ = mid$(st$,p_debut%,p_fin%-p_debut%)
GetSegment_s_result$ = mid$(GetSegment_s_st$,LOCAL_GetSegment_s_p_debut%,LOCAL_GetSegment_s_p_fin%-LOCAL_GetSegment_s_p_debut%)

return
else
' result$ = ""
GetSegment_s_result$ = ""
return
end_if
end_if
' result$ = mid$(st$,p_debut%,p_fin%-p_debut%)
GetSegment_s_result$ = mid$(GetSegment_s_st$,LOCAL_GetSegment_s_p_debut%,LOCAL_GetSegment_s_p_fin%-LOCAL_GetSegment_s_p_debut%)

' p_debut% = p_fin% + 1
LOCAL_GetSegment_s_p_debut% = LOCAL_GetSegment_s_p_fin% + 1

' n% = n% + 1
LOCAL_GetSegment_s_n% = LOCAL_GetSegment_s_n% + 1
end_while
return

' END_FUNCTION
return
GetSegment_s_check:
on_error_goto GetSegment_s_check1
dim LOCAL_GetSegment_s_n%
dim LOCAL_GetSegment_s_p_debut%
dim LOCAL_GetSegment_s_p_fin%
GetSegment_s_check1:
off_error_goto
LOCAL_GetSegment_s_n% = 0
LOCAL_GetSegment_s_p_debut% = 0
LOCAL_GetSegment_s_p_fin% = 0
return
' -------------------- fin définition de fonction

' FUNCTION InString%(st$,crit$,start%)
' -------------------- début définition de fonction
InString_i:
on_error_goto InString_i_dim
label InString_i_check, InString_i_check1
dim InString_i_result%
dim InString_i_st$
dim InString_i_crit$
dim InString_i_start%
off_error_goto
return
InString_i_dim:
off_error_goto
if InString_i_result%=-1
InString_i_result% = 0
return
end_if

' dim s$
gosub InString_i_check

' dim k%
gosub InString_i_check

' s$ = right$(st$,len(st$)-start%+1)
LOCAL_InString_i_s$ = right$(InString_i_st$,len(InString_i_st$)-InString_i_start%+1)

' k% = instr(s$,crit$)
LOCAL_InString_i_k% = instr(LOCAL_InString_i_s$,InString_i_crit$)

' if k%>0 then k% = k% + start%-1
if LOCAL_InString_i_k%>0 then LOCAL_InString_i_k% = LOCAL_InString_i_k% + InString_i_start%-1

' InString% = k%
InString_i_result% = LOCAL_InString_i_k%

' END_FUNCTION
return
InString_I_check:
on_error_goto InString_i_check1
dim LOCAL_InString_i_s$
dim LOCAL_InString_i_k%
InString_i_check1:
off_error_goto
LOCAL_InString_i_s$ = ""
LOCAL_InString_i_k% = 0
return
' -------------------- fin définition de fonction

Bonjour à tous !

@Klaus :
Comment procèderait-on pour une variable i% que je déclarerai localement aussi bien dans la fonction toto%() que dans toto$()?
Au final, quel serait le nom de ces 2 variables ?

C'est simple. Je construis le nom des variables locales comme suit:

"LOCAL_"+<nom_fonction>+"_"+{F,I,S}+"_"+<nom_variable>

dans ton cas, cela donne:

dans toto%() : (résultat integer)
LOCAL_toto_i_i%

dans toto$() : (résultat string)
LOCAL_toto_s_i%

dans toto(): (résultat float)
LOCAL_toto_f_i%

Tu vois, aucune confusion possible. ceci dit, je pourrais egalement inclure str$(local_level%) dans la construction du nom, selon la formule suivante:
"LOCAL_"+str$(loval_level%)+'_'+<nom_fonction>+"_"+{F,I,S}+"_"+<nom_variable>
Dans cette solution, les fonctions seraient en plus réentrantes !
Cela donne, pour un local_level%=3:

dans toto%() : (résultat integer)
LOCAL_1_toto_i_i%

dans toto$() : (résultat string)
LOCAL_1_toto_s_i%

dans toto(): (résultat float)
LOCAL_1_toto_f_i%

Cela donne, pour un local_level%=3:

dans toto%() : (résultat integer)
LOCAL_3_toto_i_i%

dans toto$() : (résultat string)
LOCAL_3_toto_s_i%

dans toto(): (résultat float)
LOCAL_3_toto_f_i%

Qu'est-ce que tu penses de cette idée ? As-tu essayé le programme posté dans mon post précédent ?

Bonsoir Klaus !

Non j'ai vaguement regardé car je n'ai pas beaucoup de temps en ce moment...
mais je reste connecté pour jeter un coup d'oeil de temps en temps sur le forum...

Le principe me parait correct.

Bon je vais jouer au vilain petit canard :
Il y a quand même une chose que tu n'a pas prévu...

FUNCTION factorielle(k)
if k=0
return 1
else
return k * factorielle(k-1)
end_if
END_FUNC

Tu fais comment dans ce cas précis ? Wink

Bon je suis vache (et non pas canard)...
mais je suis dans des pb de récursivite en ce moment : je remplace toutes mes fonctions récursive de traitement d'arbre binaire par des versions iteractives.... Smile

Eh bien, c'est justement de sujet de la deuxième partie de mon post précédent: la récursivité.

On ne parle pas de récursivité normalement en Basic. C'est réservé à des langages comme Delphi, Algol, C, PL1 etc qui sont massivement basés sur l'usage des stacks. J'ai utilisé la variable LOCAL_LEVEL% pour la construction du nom comme solution de secours à ce problème. Tu vois que les noms des variables contiennent cette information, et cela devient donc réentrant.

On pourrait aussi construire ces variables comme des tableaux avec la variable LOCAL_LEVEL% servant de pointeur. Problème: on ne peut pas utiliser cela pour des tableaux à deux dimensions. Je n'ai donc pas retenu cette solution.

Ceci dit: il s'agit là de ma "maquette" du code Panoramic avec vraies fonctions, converti par un préprocesseur (sur lequel je travaille) en code Panoramic pur. Mais dans ce cas, pour que la récursivité marche, il faudrait pouvoir définir des variables dont le nom est le résultat d'une expression de chaînes de caractères. Mais ça, ce n'est plus Panoramic...

Quand j'avais demandé ces commandes #LOCAL_LEVEL_xxx, SUBROUTINE...END_SUB, FUNCTION...END_FUNCTION, je lui avais suggéré de définir les variables locales "comme" si elles portaient un nom selon comme je l'ai décrit ci-dessus, en incluant LOCAL_LEVEL%. Je sais bien que si Jack le fait, il ne le fera pas exactement de cette manière - j'ai juste voulu montrer la faisabilité à l'aide d'un pseudo-code 100 % Panoramic.

Ceci dit, abstraction faite de la récursivité, c'est parfaitement jouable en Panoramic pur si l'on accept'e l'idée d'un préprocesseur. Mais ce serait dommage car on perdrait l'avantage énorme de pourvoir exécuter directement dans l'éditeur.

On ne pourrait pas en direct avec l'editeur de panoramic mais passant par un chain...

De toutes façons dans la mesure du possible un programmeur ne prend pas deux fois le même nom de variable, donc....

Oui, un programmeur ne prend pas deux fois le même nom de variable.

Sauf que ça nous est arrivé à tous- par erreur, bien sûr, mais des conflits de noms, nous les avons tous expérimentés. Mais le débat n'est pas là. L'intérêt des variables locales réside dans la perspective de réutiliser des sous-programmes ou modules écrits une fois, dans d'autres programmes, et surtout, d'utiliser des modules écrits par d'autres pour éviter de réinventer chaque fois la ficelle à couper le beurre.

Bon, je sais, il y en a qui veulent tout maîtriser et qui n'utilisent que des modules réalisés par eux-même. Très bien. C'est leur choix, et je le respecte. Mais pour tous ceux qui souhaitent utiliser un module parce qu'il réalise une fonction qui leur est utile et qu'ils ne peuvent pas réaliser pour x raisons honorables, le problème des noms de variables et labels est crucial. Car en Panoramic, tout est global. Une fois défini, tout est visible partout dans un programme. Une variable même définie dans un sous-programme, est visible dans le corps principal du programme. J'en ai fait l'expérience difficile lorsque j'ai commencé à réaliser des modules à partager avec d'autres Panoramiciens, voir à réutiliser dans mes propres programmes. Il faut apporter un soin extrême à choisir dans le module partageable des noms qui en aucun cas ne rentreront en conflit avec d'autres noms, quelque soit le programme dans lequel on inclut ce module (c'est d'ailleurs le sens même de la directive #INCLUDE).

Un espace dans lequel on peut définir des variables qui n'ont pas de définition en-dehors de cet espace est essentiel dans la démarche de créer des bibliothèques de modules ou sous-programmes. Qu'on appelle cela "mode local" ou "name space" comme dans d'autres langages, ou autrement encore, ne change rien sur le fond.

Ce que j'ai proposé avec mes petites "maquettes", n'est qu'une simulation avec les moyens du Panoramic actuel afin de rendre palpable ce dont je parle. Je sais bien que mes variables LOCAL_xxx sont en réalité, une fois définies, absolument identiques aux autres variables de Panoramic et visibles partout. L'idée, c'est justement d'introduire dans Panoramic un moyen de créer ces variables COMME SI c'étaient des variables préfixées de telle ou telle façon, afin de les rendre distinctes d'une variable du cours principal du rpogramme portant le même nom. Mais je sais bien que si Jack implémente cette fonctionnalité, ce ne sera pas en altérant artificiellement le nom des variables, mes en leur attribuant, dans la table de symboles interne à Panoramic, un identifiant quelconque avec une référence au niveau de profondeur de l'espace local dans lequel elles sont définies.

Bon, là, je rentre un peu dans un débat technique que pour ma part je connais bien ayant, dans ma vis professionnelle, conçu et réalisé plusieurs langages, compilateurs et interpréteurs, et je parle de notions techniques que concernant Panoramic, Jack est seul à maîtriser. Ceci étant dit, j'ai d'une part l'impression que la suggestion de mon post initial dans leur contenu (et évidemment pas dans les quelques lignes de maquette) est réalisable, et que d'autre part, pouvoir apporter de vrais sous-programmes et de vraies fonctions avec des paramètres formels apporte une nouvelle dimension à Panoramic qui pourra profiter à tout le monde, y compris ceux dont la passion est l'écriture de jeux.

Invité

Bonsoir et bientôt bonne nuit, vu que je vais arrêter.

Sur le modèle provisoire que j'ai mis dans la bibliothèque, je suis en train de refaire l'ensemble pour que toutes les variables soient dynamiques. Tous les dim seront à proscrire, c'est le loader qui s'en chargera. Tu ne m'as pas donné de nouvelle sur la partie que j'ai mise, et je me demande si c'est ce que tu cherches en attendant.
Les deux parties, locales et globales fonctionnent individuellement. Il y a encore quelques problèmes d'assemblage. Si tu n'es pas intéressé par ma méthode, tu le dis franchement, que je n'intervienne pas pour rien. Il me faudra faire le loader pour que ce soit au plus simple.

Il est évident qu'une version de Jack sera mieux que ma méthode.
Bonne nuit. study

tient un barbu!

LOl Cosmos Wink

(pour le barbu)

Bien dit Maître Klaus !
Ce sera super utile à tous pour nos programmes et surtout pour le partage de sources.

» Variables locales et DIM dynamique
» Fonctions Chaine et variables locales
» Gestion des labels pour ON_ERROR_GOTO
» Labels et sous-programmes dans une variable ?
» sur les SUB: vérification avec les variables locales.