Bibliothèque de sous-programmes

J'en suis encore avec ma marotte d'avoir une bibliothèque de sous-programmes (ou fonctions) indépendants dans laquelle on pourrait puiser selon les besoins.
Le sujet a déjà été abordé un certain nombre de fois, avec des solutions (entre autres par Klaus), et c'est également dans les projets de Jack d'offrir cette fonction dans des versions futures.

Il y a bien le Include, mais le problème est en fait dans la déclaration des variables locales de chacun des sous-programme qui ne doivent pas faire double emploi avec d'autres variables du programme principal, et qui doivent être déclarées avant usage.

Je pensais à quelque chose de ce genre (mais c'est sans doute très semblable à ce qui a déjà été proposé, cf Klaus):

Code:

' Utilisation de bibliothèques de sous-programmes
LABEL Instrs: DIM Instrs: GOSUB Instrs: ' une ligne semblable pour chacun des sous-programme insérés

DIM i%, j%, a$, b$, c$, u%, k% : ' variables générales du programme (par exemple)
LABEL rr: ' labels généraux

a$ = "Au clair de la lune, prête-moi ta plume."
PRINT a$
u% = 1: b$ = "u": ' recherches successives de "u" dans a$
rr:
GOSUB Instrs
IF k% > 0 THEN PRINT k%: u% = k% + 1: GOTO rr
' END_IF
END
' -----------------------------------------------------------------------------------------
Instrs:
' s/p de recherche de b$ dans a$, à partir de la position u%, résultat dans k%
IF Instrs = 0
    ' ici, déclaration des variables et labels internes au sous-programme
    DIM Instrs_c$
    LABEL Instrs_aa
    Instrs = 1: RETURN
END_IF
Instrs_c$ = MID$(a$, u%, LEN(a$))
k% = INSTR(Instrs_c$, b$)
Instrs_aa:
IF k% > 0 THEN k% = k% + u% - 1
RETURN
' -----------------------------------------------------------------------------------------

Une petite erreur ligne 12 avec then.

L'idée est bonne et simple. C'est fait pour des gens comme moi.

Merci A+

Tu as raison Jean Claude, le End_If est en trop, j'ai remonté le print mais j'ai oublié le end_if ! ça m'apprendra à faire des modifs de dernière minute sans relancer le programme. Allez, j'édite, je le mets en commentaire.

Et si c'est simple tant mieux, c'est aussi ce que je préfère.
Et je précise que l'étiquette Instrs_aa ne sert à rien, c'est juste pour l'exemple.

Le principe est identique au mien, dans mes pseudo-objets. Il y a une différence de détail: je dois définit deux labels (un pour le sous-programme à appeler et un pour servir de cible à un o_error_goto), et je détecte le premier passage par une instruction protégée par ce on_error_goto? Tu définies un label (sous-programme) et une variable dont tu utilises le contenu initial à zéro pour détecter le premier passage. Sinon, c'est la même idée, celle de définir une logique de nommage des variables et labels afin d'éviter les conflits.

J'ai beau tourner et retourner le problème dans tous les sens, au fond, je ne vois pas d'autres solutions que celles montrées ici, tant que nous n'avons pas les directives
SUBROUTINE xxx(p1,p2,...)
FUNCTION xxx(p1,p2n...)
avec des définitions de labels et variables locales à ces modules. jack avait dit en son temps que ceci était possible sans bouleverser la structure du compilateur...

Au niveau des includes, il y a en basic classique la commande "merge" qui permet de chainer un code avec un autre, donc ce serait facile d'ajouter à nos programme un groupe de fonctions utiles si on a un mini-fichier par fonction.
Chaque fichier aurait son nom représentatif bien sûr.

En Panoramic tu as l'équivalent avec la commande CHAIN, mais ça ne résout pas le problème des sub et functions, et puis comment se fait le passage de paramètres et la récupération des résultats ?

Bein une fois que la fonction ecrite dans le petit fichier est incluse dans le programme principal, le passage de paramètre et le retour de résultat se font aisément puisque la fonction fera partie du programme ainsi.

Mais on en revient toujours au même problème !
Les variables contenues dans tes 'petits fichiers' doivent être connues du programme principal, donc déclarées avant utilisation, et ne doivent pas interférer avec celles du programme principal.

D'où la solution (batarde) que je préconise plus haut, maintenant si tu as mieux à proposer, un petit exemple serait le bienvenu, parce que je ne vois pas bien ce qu'on peut faire d'autre...

J'ai connu, dans le temps, une commande MERGE dans un Basic, et dans un autre, il y avait une commande OVERLAY. On a l'impression que ça ressemble à #INCLUDE ou à CHAIN, mais en réalité, il y a une différence fondamentale.
#INCLUDE: insérer un fichier source,, AVANT la compilation, dans le fichier source principal, puis traiter le résultat comme un seul et même fichier lors de la compilation. Conséquence: les numéros de ligne subséquentes sont forcément décalés, tous les labels et variables du module inclus sont vus et connus à l'extérieur et vice-versa. Pas de passage de paramètres, pas de valeur retour structurellement définie, pas de variables locales.
#CHAIN: effacer totalement le programme en cours et le remplacer par un nouveau fichier source qui est compilé totalement indépendamment. Résultat: aucun label ni variable commun entre module chaîné et module d'origine, pas de passages de paramètres, pas de valeur de retour, d'aulleurs aucun retour n'est possible.
MERGE et OVERLAY: mots-clés différents dans deux clones de Basic mais fonctionnalité identique: on REMPLACE une série de numéros de lignes, contibues bien sûr, par les lignes contenus dans un fichier source indépendant. Conséquence: identique à #INCLUDE concernant variables, labels, paramètres et valeur de retour, mais AUCUNE incidence sur les numéros de lignes subsequentes - ces numéros restent identiques. On utilisait ces commandes dans des Basic sur des machines n'ayant que 64ko (oui, pas Mo, mais ko), quelque fois 32ko seulement, pour faire de gros programmes, en réservant une plage de numéros de lignes dès la conception (car à l'époqaue, il fallait taper le numéro de ligne !) dans lesquelles on chargeait, selon les besoins, tantôt un module, tantôt l'autre, sans occuper plus de place mémoire. C'était très asticueux.

Mais ce qui manque vraiment, ce sont des commandes ressemblant à cela:

Code:

dim i%, j%, res%
' ... programme habituel
i% = 1
j% = 2
CALL MonSousProgramme(res,j%,"Essai de paramètres",i%*2)
print str$(i%)  : ' affiche 1, pas 19 !
' ... suite du programme habituel
print MaFonction(j%,"Essai de paramètres",i%*2)
'...suite du programme habituel


SUBROUTINE MonSousProgramme(param1,param2%,param3$,param4%)
dim i%  : ' variable locale
i% = len(param3$)
param1 = param2% + i% + param4%  : ' un exemple pour montrer le RETOUR d'un résultat
if param2%<3 then EXIT_SUB
param1 = 20
END_SUB

FUNCTION MaFonction(param1%,param2$,param3%)
dim i%  : ' variable locale
i% = len(param2$)
MaFonction = param1% + i% + param3%  : ' un exemple pour montrer le RETOUR d'un résultat
if param1%<3 then EXIT_FUNCTION
MaFonction = 20
END_END_FUNCTION

Tout ce qui serait défini entre les directives SUBROUTINE et END_SUB et entre les directives FUNCTION et END_FUNCTION serait local à cette partie et invisible en-dehors, et les labels et variables définies en-dehors seraient invisibles entre ces directives. Le retour d'un résultat serait possible par un paramètre passé "par référence", c'est-a-dire une variable simple ou éventuellement un tableau passé par son nom suivi de () SANS indice, et dans le cas des fonctions, le nom de la fonction servirait de pseudo-variable pour le retour d'un résultat.

Et à partir de ce moment-là, on pourra vraiment commencer à parler de bibliothèques de sous-programmes ou de fonctions. ET j'entends là bien sur des modules en source Panoramic, pas compilés ou sous forme binaire quelconque.

100% d'accord avec toi Klaus !

SUBROUTINE , FUNCTION... Ca serait vraiment le top !

Exactly ! et c'est ce qui existait et qu'on pratiquait couramment en QBasic (et existe Freebasic d'ailleurs).
En QBasic j'avais une bibliothèque d'uen bonne centaine de sous-programmes dans laquelle je puisais allègrement, inutile de réinventer la poudre à chaque fois, j'avais même un programme d'insertion d'un sous-programme donné dans un autre programme.
ET dans un sous-programme, on pouvait déclarer les variables soit locales, soit communes, soit globalement, soit individuellement.

Mais Jack a promis...

Bon allons-y! Tant pis pour le résultat.
Vous savez, et je ne vous l'apprend pas, Panoramic est un langage, et en vous disant cela, vous vous dites, où est-ce qu'il veut en arriver.

Et bien personne ne nous interdit de faire la même chose avec Panoramic.
Sur un autre poste, j'ai montré qu'on pouvait détourner Panoramic, et suivre un programme au fur et à mesure, et voir les variables. Et pourtant, personne ne pensait cela possible. Que ce programme ne vous intéresse pas, passons. Mais ici:on peut très bien imaginer la chose suivante: On fait un programme en Panoramic, en imaginant les instructions faites: variables globales et locales, procédure et fonctions. Celui-ci a des includes avec ses variables qui peuvent _être globales ou locales également. Et on fait à côté un autre programme qui analyse le programme en question, et qui le transforme. Il est évident que le premier n'est pas exécutable, mais le second le devient.

Je vous montre un exemple. En parlant du mode trace, je viens de reprendre le loader qui lance le programme pour qu'il soit suivi. Et je viens de faire un programme qui suit ligne par ligne le programme précédent, et qui et qui regarde si il y a des includes.Ainsi je recompose le programme en entier, avec tout les niveaux inférieurs d'include qui en appelle d'autre. Je me trouve avec un nouveau programme recomposé entier. Et c'est là, en voyant ce poste, je me suis dis que l'on pouvait faire mieux pour les variables.
A la définition des variables, on peut très bien avoir une commande en commentaire, du genre:
' dim_local a%,b% etc...
et au fur et à mesure que ouvre un nouvelle include, on prend dans une liste, un mot, dont la liste serait par exemple: un,deux,trois,quatre... Chaque include aurait sont mot, et lors de la découverte d'une ligne d'include, on prendrait le mot comme préfixe, et on aurait: un_a%,un_b% deux_a%,deux_b%...
Il suffirait donc de modifier les variables en cause qui sont définies en locales, pour quelles optent ce changement.

Ainsi, on conçoit les includes avec des variables simples, sauvegardés tels quels. Et c'est notre programme qui fait le reste.

Pour ce qui est des fonctions, on suit le même principe. Il faut donc avoir une attitude commune pour s'accorder les violons, et faire un chargeur, un loader enfin quoi un programme, qui lie tout cela et le lance.

A vous de voir ce que vous en pensez et de donner votre opinion.
Je me suis lancé au début, et maintenant je freine.

eh bien Cosmos70, pour une idée intéressante, c'en est une ! Tu viens de nous montrer comment, avec les moyens techniques du Panoramic actuel, on peut réaliser ce que je suggérais plus haut ! BRAVO !

J'ai bien conscience qu'il s'agit d'un très gros projet. Pour le réaliser, il faudra du temps et de la persévérance. Mais avoue qu'il est dommage que Panoramic n'offre pas ces fonctions de façon "native". Cela fait un bon moment qu'un certain nombre d'entre nous en parlent, et Jack avait dit en son temps que c'était envisageable. Ce n'est bien sûr pas une critique dirigée contre Jack: je sais bien qu'il élève son "bébé" dans son temps libre et selon son bon plaisir. C'est juste un regret. Jack a appelé son langage Panoramic puisqu'il le dédiait à un usage "panoramique". Ces derniers temps, il y a eu beaucoup d'évolutions, et des évolutions importantes dont je ne minimise pas la charge de programmation. Mais force est de constater que, peut-être pour des raisons de préférences personnelles, Jack a privilégié un peu plus l'univers "jeu" que l'univers "gestion" ces derniers temps. Rien que de bien légitime, mais j'avoue que j'espère toujours une évolution dans le domaine de mon post ci-dessus, ainsi que dans le domaine du lien avec les DLL ou alors, oserais-je ? dans le domaine des plug-in proposé par Jack lui-même et qui m'intéresse au plu haut point...

Bien d'accord avec Klaus.
Cosmos nous confirme qu'en informatique presque rien n'est impossible, mais avec plus ou moins de complications.

Mais Jack a bien promis (je ne sais plus trop où (1)), l'implémentation des SUB et FUNCTION, ou équivalents, mais il n'a évidemment pas donné de date, c'est fonction de la longueur de la file d'attente et surtout de ses possibilités en temps, qui semblent assez limitées !
Et c'est vrai qu'au départ je pense que son optique était plutôt 'jeux' et que nous l'avons un peu fait dériver de son objectif en réclamant toujours plus de possibilités dans d'autres domaines.
Mais les fonctions que nous réclamons auraient également leur utilité pour des jeux, pourquoi pas ?

Mais bon, n'ayons pas de scrupules à demander (en restant réalistes quand même), au final c'est lui qui décidera ce qu'il en fera.

(1) c'était là: https://panoramic.1fr1.net/presentation-et-bavardage-f5/bavardage-sur-basic-t1231.htm

Citation :

Citation:
La possibilité de créer des fonctions et des sous-programmes avec passage de paramètres fait défaut à Panoramic.
Réponse de Jack:
Cela est prévu, mais je ne peux pas vous dire quand.

Y a un truc que je comprend pas, faire appel à des fonctions externes, cela est quand même l'utilité des DLL que je sache, donc pourquoi ce topic ?

Pour plusieurs raisons.

1. une DLL externe est un module externe comme son nom l'indique, fourni en binaire, et on est obligé de la distribuer avec le programme d'application en cas d'installation extérieure. D'autre part, certains n'aiment pas beaucoup utiliser des modules dont ils n'ont pas la maîtrise, s'il est possible de faire autrement.

2. utiliser une DLL n'est pas si facile que ça. On ne peut appeler que des fonctions DLL, pas des procédures. Les fonctions doivent avoir entre 0 et 6 paramètres; des fonctions de plus de 6 paramètres ne peuvent être appelés par PAnoramic. Or, beaucoup de fonctions DLL, en particulier celles de Windows, dépassent cette limite. On ne peut pas appeler une fonction DLL avec un nombre de paramètres variables. On ne peut pas appeler une fonction DLL dont un des paramètres doit être passé par référence. Tous les paramètres sont passés par valeur par Panoramic. On peut bien passer des adresses (à l'aide de la fonction ref), mais ça ne marche pas pour un tableau ou pour un élément de tableau, justement parce que tout est passé par valeur.

3. Panoramic ne peut utiliser qu'une seule DLL à la fois, ce qui est bien contraignant. Il faut jongler avec les DLL_on et DLL_off pour y arriver (je fais abstraction de ma DLL DynamicallyLoadDLL qui contourne ce problème, mais au prix d'un format d'appel encore plus contraignant).

4. et SURTOUT, en dehors de ceux qui sont les outils pour réaliser des DLL, personne ne peut se constituer une bibliothèque de sous-programmes réutilisables, ni pour lui-même, ni pour les partager avec d'autres, à cause justement des problèmes de nommage des labels et variables, de la visibilité des variables, etc, enfin, tout ce qui a été débattu dans les posts précédents.

Il en ressort de tout ceci que les DLL et les bibilothèques de sous-programmes en Panoramic ne sont pas équivalentes, et les unes ne rendent pas les autres obsolètes? Elles ont toutes leur champ d'application spécifique, et elles ont toutes leur intérêt.

En s'appuyant de ce que l'on a déjà fait avec nos prog d'analyse de code, ne peut-on pas faire du pseudo-panoramic ?

Je m'explique:
On tape par exemple dans un prog un truc de ce genre :

DIM a%,i%
for i%=0 to 5
a%=a%+toto(i,5)
nexti%
print a%
end

FUNCTION toto(a,b)
LOCAL i%
i%=a
RETURN a*b
END_FUNC

Dans le cadre de cet exemple, imaginons que le prog d'analyse fasse ceci :

- il isole le bloc de fonction toto (facile: détection des mot-clés FUNCTION et END_FUNCTION)
- il voit qu'il y a 2 paramètres en entrée et une variable locale:
. création des lignes :
DIM nom_de_la_fonction_param1,nom_de_la_fonction_param1
DIM nom_de_la_fonction_var_locale (mot clé LOCAL ou DIM, au choix)
DIM nom_de_la_fonction_return
LABEL nom_de_la_fonction

Dans notre exemple rajout des lignes dans une dlist:
DIM toto_a,toto_b
DIM toto_i%
DIM toto_return
LABEL toto

. remplacement dans ce bloc de code par les nouveau nom de variable et suppression du mot-clé FUNCTION
toto:
toto_i%=toto_a
toto_return=toto_a*toto_b
return

on se retrouve avec ce code :

DIM toto_a,toto_b
DIM toto_i%
DIM toto_return
LABEL toto
DIM a%,i%

for i%=0 to 5
a%=a%+toto(i,5)
nexti%
print a%
end

toto:
toto_i%=toto_a
toto_return=toto_a*toto_b
return

Vous commencez à voir où je veux en venir ?

maintenant on parcoure l'ensemble du code et on adapte les appels à toto:
- init des variables avec la ligne d'appel :
toto(i,5) génère la ligne -> toto_a=i : toto_b = 5 :gosub toto
- modif de l'appel :
a%=a%+toto(i,5) génère la ligne -> a%=a%+toto_return

Notre exemple devient :

DIM toto_a,toto_b
DIM toto_i%
DIM toto_return
LABEL toto
DIM a%,i%

for i%=0 to 5
toto_a=i : toto_b = 5 :gosub toto
a%=a%+toto_return
next i%
print a%
end

toto:
toto_i%=toto_a
toto_return=toto_a*toto_b
return

Bon cela promet des grosses prises de tête, il y aura des tonnes de cas tordus mais cela peut fonctionner dans le cas de fonctions simples...

Exemple de départ pour servir de base.
Je dois dire qu'avec PsPad et le programme de Nardo pour cet éditeur, tout est plus simple. Il n'y a qu'à appuyer sur le raccourci pour lancer le programme sur lequel au travail. Le chargeur qui récupère le code fait tout en transparence. Et du côté de la coloration syntactique, il n'y a pas photo.

Je réédite, c'est pour le programme que je mets ce post, et non pas pour la pub de PsPad:
ceci est un exemple pour récupérer les includes, et à la lecture de celui-ci, c'est pas bien compliqué de récupérer une ligne pour la modifier ( je pense aux dim, et labels locaux)

Code:

' Pour les includes
width 0,screen_x:height 0,600 :top 0,100
error_french
dim a%,b%,c%,a$,b$,c$,f$ ,v% ,lig_b% , lig_a% , nb% ,A ,B
A=21 : B=22
memo A:width A,screen_x/2-10:height A,560:font_size A,12  :'  item_add A," #INCLUDE "+ chr$(34)+"  taratata.bas" +chr$(34) :font_name A,"Bistream Vera Sans Mono"
memo B:width B,screen_x/2-10:height B,560:font_size B,12:left B,screen_x/2

bar_horizontal A:bar_horizontal B :color A,255,255,153
file_load A,"C:\TESTE\M_au _P_TRACE\teste prg.bas"

a%=1  :nb%=0
  repeat
      a$=item_read$(A,a%) :a$=rtrim$(a$)
      if left$(trim$( upper$(a$)) ,8) ="#INCLUDE"
        nb%=nb%+1
        v%=instr( upper$(a$),"#INCLUDE")
        c$=mid$( a$,v% +9,80 )  :c$=trim$(c$)
        if left$(c$,1)=chr$(34) then c$=mid$(c$,2,80)
        ' tel que codé, seul un include avec chemin complet fonctionne  (163=CTRL droit )
        ' repeat:until scancode=163 or scancode=27  :wait 100 :if scancode=27 then stop
        item_add 22,"' #" + str$(nb%) + " dépilé: " + trim$(a$)
        lig_b%=count(B) : lig_a%=a%
        item_delete A,lig_a%
        file_add B,c$
        while lig_b%<=count(B)
            a$=item_read$(B,lig_b%)
           
          ' ////////////////////////////////////////////////////////////
          ' a$ pourrait à ce niveau aller dans un sous-prg pour analyse
          ' et traiter les dim_locaux
          ' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

            item_insert A,lig_a%,a$ :lig_a%=lig_a%+1
            item_delete B,lig_b%

        end_while
      else
        item_add B,a$
      end_if
      a%=a%+1
  until a%> count(A)
  message "le listing jaune est le programme de départ, et celui qu'on récupère
  clear B
 
  ' A partir de là, les dim_locaux, ils faut les mettre au haut de liste de A, de cette façon
  ' l'include peut être appelé plusieur fois et ne pas être géné par les variables déjà définies.
  ' ainsi un include peut-être une fonction, et il n'y a pas à faire des sous appels pour d'abord
  ' définir séparément les variables et labels de la "procédure", c'est le chargeur qui s'en charge
 

exemple de présentation:



de plus, il a l'auto-complétion, et autre. La sauvegarde est plus simple puisqu'à CTRL S suffit, sans compter que si vous fermez l'éditeur,, il s'ouvre tel qu'il est fermé, les fichier bak et autre

Je viens de voir que pour essayer le programme, il fallait lui donner à manger.
Donc voici les ingrédients:

le programme teste.prg

Code:

' programme d'essai  Panoramic "C:\TESTE\M_au _P_TRACE\teste prg.bas"
 ' **TRON**
 label branche
 width 0,600 :left 0,600 :height 0,200:caption 0,"teste prg.bas"
 dim a% , a$ ,b%,b$
 memo 1 :on_click 1,branche
 item_add 1,"voyons voir"
 #include "C:\TESTE\M_au _P_TRACE\inclusion.bas"
 for a%=1 to 10
  item_add 1,a%
 next a%
 message "nouvelle inclusion du même prg"
 #include "C:\TESTE\M_au _P_TRACE\inclusion.bas"
 end

branche:
message "click sur le memo"
return

le programme inclusion:

Code:

 rem "ceci est un essai d'inclusion dans un autre programme"
 ' et ne sert à rien
 message "inclusion réussi"
#include "C:\TESTE\M_au _P_TRACE\suite_include.bas"   

le programme suite_include:

Code:

 ' essai de rajouter un nouvel include
 message "include sous_niveau"

Il est évident que les chemins des dossiers, n'est pas bon!

Bonne Appétit, et mollo sur l'apéro à cette heure

Je trouve les pistes de Nardo26 et Cosmos70 sont très intéressantes.

Mais je me pose tout-de-même une question. C'est quand-même la cavalerie lourde que de faire un pré-processeur pour pouvoir exécuter un programme Panoramic. L'algorithme proposé me paraît simple dans sa définition, surtout avec la directive LOCAL. Pour résoudre également le problème des labels, on pourrait peut-être proposer
LOCAL_DIM i%, s$,
LOCAL_LABEL test, essai
pour avoir des variables et des labels locaux. Et dans ce cas, est-ce vraiment si compliqué d'intégrer cela dans Panoramic ? C'est vrai, il faut savoir où s'arrête le champ d'applicatiion de LOCAL_DIM et LOCAL_LABEL. On pourrait imaginer une directive
END_LOCAL
pour revenir en mode normal.

Ou peut-être encore plus simple: si Jack réussit à intégrer les directives suivantes dans Panoramic, le problème des variables et labels locaux sera résolu:

Code:

#LOCAL_MODE_ON
#LOCAL_MODE_OFF

Et toute variable et tout label défini entre ces deux directives par LABEL et DIM seraient automatiquement modifiés par Panoramic par un préfice du type "LOCAL_nnnn_" où nnnn est une valeur numérique qui au premier LOCAL_MODE_ON prend la valeur 1, qui est incrémentée à chaque #LOCAL_MODE_ON et décrémentée à chaque #LOCAL_MODE_OFF. On aurait ainsi, même pour plusieurs sous-programmes inclus par #INCLUDE, des espaces de nommage indépendants.

Reste bien sûr le problème des directiives SUBROUTINE...END_SUB et FUNCTION...END_FUNCTION, avec la gestion des paramètres formels et de l'attribution de la valeur de retour d'une fonction à une variable créée automatiquement portant le nom de la fonction. Mais des paramètres formels, au fond, ce n'est rien d'autre que des variables locales. Et si les directives SUBROUTINE et FUNCTION exécutent un #LOCAL_MODE_ON implicite, et si END_SUB et END_FUNCTION exécutent un #LOCAL_MODE_OFF implicite, le problème est totalement résolu !

J'ai l'impression que de cette façon, l'ajout de cette fonctionnalité majeure sera possible dans Panoramic sans perturbation majeure. Qu'en penses-tu, Jack ? Est-ce que tu préfères que je poste cette idée dans la section "Vos souhaits d'amélioration de Panoramic" ?

Qu'entend tu pas "label local" ?
"private" c'est ça ?

Je vois ton post très rapidement. J'ai quitté ma campagne pour aller en ville (rdv), et j'avais commencé à faire la partie de dim_local et label_local.
Sans aller plus loin, et sans avoir lu complètement ton topique, il faut qu'on définisse une marge à suivre. Que ce soit dim_local, ou local_dim ou autre peut importe. Pour l'instant rien n'est définitif. mais pendant que j'étais "en route", j'ai pensé qu'à chaque mot clé que nous proposons, il faudrait mettre un préfixe devant. En GFA Basic, il y avait @ qui était un raccoucis pour remplacer procedure. Que cela soit celui-là ou un autre, peut importe. Mais si Jack mets à notre disposition un mot clé qui a la même syntaxe, on est marron. Avec un préfixe devant, ce qui aurait été écrit avant pourra rester, surtout si le cheminement de la sybtaxe est différente de ce que nous faisons. Ainsi si je code @fonction(patati-patata), les paramètres seront en rapport avec ce que nous aurions écrit; et si Jack nous fait à un moment donné le mot FONCTION..., alors le loader pourra faire la différence.

Ensuite je crois que l'on doir rester simple: si je fais dim_local, il n'y aura que des dim locaux dans cette ligne. Si chacun fait à sa manière, on ne s'en sort pas. Le basic Panoramic a ses règles, nous devons aussi avoir les nôtres.

Je te dis franchement que je ne suis pas d'accord pour qu'il y est une fin dans les dim_locaux, avec end_local. Cela suppose que de détourner les lignes, il me faut un flag pour savoir si je suis avant ou après. Dans mon cas, (pour l'instant je suis sur les dim, et je ferais la même chose avec les labels, je détourne les dim_locaux, pour mettre à la place un préfixe comme dit dans mon autre post, et cette nouvelle variable est stockée dans un dlist. Une fois le programme composée, la ligne de dim est insérée au début du programme, et la list des variables locales, est mis en dim également au début du programme. à l'emplacement les dim et dim_locaux sont mis en commentaire et c'est également vrai pour les labels. Il n'est plus nécessaire d'aller définir à part ceux-ci pour pouvoir faire fonctionner un include. Tout se fait par le chargeur, ou préprocesseur comme tu dis.

Il faut qu'on définisse les conditions et les mots clés, ou chacun travaille pour soit. Cela ne peut pas être autrement.
Maintenant, Jack lisant nos topiques, peut-être pourrait-il nous donner les mots-clés avec leurs comportements pour qu'on est les mêmes principes. Ainsi, le jour où un mot clé sur ce qu'on fait, apparaît, on retire du chargeur, le détour.

Il faut que je quitte. Je prendrais plus de temps pour voir vos réactions. Toujours est-il que si vous vous mettez pas d'accord, je continuerai sur ma lancé, parce que mon problème est vaste, et que si je pensais le faire plus tard, vu que je suis dedans, autant continuer.
J'ai été obligé d'aller vite, et c'est la raison qui fait que klaus j'ai pas tout lu. Je me rattraperai.

Eh bien, un label local, c'est un label défini A L'INTERIEUR d'une section entourée de #LOCAL_MODE_ON et #LOCAL_MODE_OFF, SUBROUTINE et END_SUB ou FUNCTION et END_FUNCTION, et qui est référencée par du code dans cette section. Exemple:

Code:

label MonSousprogramme, erreur
...
on_error_goto erreur : ' on va au label erreur de niveau 0
...
SUBROUTINE MonSousprogramme  : ' exécute un #LOCAL_MODE_ON implicite
label erreur : ' ceci est le label local à MonSousprogramme
on_error_goto erreur : ' on va au label local
...

return
erreur:  ' label erreur local de niveau 1 de MonSousprogramme
...
return
END_SUB : ' exécute un #LOCAL_MODE_OFF implicite
erreur: ' label erreur de niveau 0
...

Donc, à l'intérieur de MonSouprogramme, toutes les apparitions de "erreur" seront modifiée automatiquement pas Panoramic en LOCAL_0001_erreur ce qui résoud parfaitement le problème des labels locaux. Et idem pour les variables. Le résultat "virtuel" serait:

Code:

label MonSousprogramme, erreur
...
on_error_goto erreur : ' on va au label erreur de niveau 0
...
SUBROUTINE MonSousprogramme  : ' exécute un #LOCAL_MODE_ON implicite
label LOCAL_0001_erreur : ' ceci est le label local à MonSousprogramme
on_error_goto label LOCAL_0001_erreur : ' on va au label local
...

return
label LOCAL_0001_erreur:  ' label erreur local de niveau 1 de MonSousprogramme
...
return
END_SUB : ' exécute un #LOCAL_MODE_OFF implicite
erreur: ' label erreur de niveau 0
...

@Cosmos70: mon dernier post s'est croisé avec le tien. J'ai beau réfléchir, je ne vois pas de problème de fond pour ton programme pour tenir compte des directives #LOCAL_MODE_ON et LOCAL_MODE_OFF. Cela s'apparente au #INCLUDE. Il suffit, comme je le suggère à Jack pour le compilateur, de gérer une variable du type

dim niveau_local% : niveau_local_% = 0

Et pour chaque variable, on fait ceci

if niveau_local%>1 then < le nom de la variable est préfixé par LOCAL_nnnn_ , nnnn étant niveau_local% >

Et cette cariable est simplement incrémentée lorsqu'on rencontre #LOCAL_MODE_ON, SUBROUTINE et FUNCTION, et elle est décrémentée lorsqu'on rencontre #LOCAL_MODE_OFF, END_SUB et END_FUNCTION. C'est aussi simple que ça.

Et cette technique vaut pour TOUS les programmes d'analyse de source comme le tien, et également pour Jack au niveau de l'implémentation dans Panoramic. Cela me semble vraiment jouable.

Je ne sais pas quoi te dire. Je n'ai pas ton expérience, ni tes connaissances. Je me suis fait tout seul, et tu as appris des langages et fait des cours que je n'ai pas fait.

Gérer comme je le fais, me parait simple, et c'est en partie fait. Je vais continuer provisoirement dans mon coin, pour voir ce que cela donne. Et si entre temps, j'ai la preuve que c'est plus simple., sur ma machine j'ai la marche arrière pour reprendre les idées des autres. Avec moi, rien n'est définitif et je sais me remettre en question le temps venu.

Ce que j'espère c'est que ce qu'on peut apporter reste le plus simple possible. J'ai provoqué l'idée au départ pour shunter les commandes, mais au final, je souhaite qu'on ne complique pas. Contrairement à ce que tu peux penser, je ne comprends pas tout J'ai des fois des analyses à faire sur les mots qui ne sont pas courant dans ma modeste vie et de mon entourage, et lorsque vous employez des mots informatiques qui ne me sont pas habituels, j'ai besoin d'expérience pour approfondir.

A+
@ Nardo:
Je considère que tout label dans un include, est un label local: Si dans un programme tu as le label fin, et que ton include a aussi le label fin avec un traitement en conséquence, il te faut un autre nom. Donc obligatoirement il faut considérer le label d'un include comme étant un label local, et dans mon cas, j'y rajoute un préfixe.