est-ce un bug sur IF et END_IF?

Ok je comprend ce que tu veux dire.
Mais là c'est d'un cas bien particulier : tu parles d'un bug au niveau de l'interpréteur (qui se plante dans le décompte des if-end_if) et non pas d'une erreur de syntaxe (quoique on ne s'attend pas à avoir des commandes après un goto...)

Oui, mais c'est un bug qui n'était pas connu. C'est vrai qu'on ne s'attend pas à voir une instruction après un goto. Mais l'exemple qui a fait que j'ai ouvert ce post, montre que cela arrive. Que s'est-il passé? J'avais un autre codage sur la ligne, mais avant de tout transformer, j'ai laissé une partie du code derrière le goto pour le cas où!

Dans un de mes programmes qui a une erreur de décompte, j'ai peut-être ce type d'erreur. Jusqu'à présent ce n'est pas une instruction après un goto que je recherchais, mais la cohérence des boucles. Je verrais le moment venu. Même Superman ne pouvais faire qu'une chose à la fois.

Je crois qu'on a tout dit. Y aura plus qu'à finir le programme. Pour ce qui est des goto, une simple recherche avec de l'éditeur. Maintenant qu'on le sait!

Juste pour vous "titiller" un peux, j'ai fait un petit bout de code qui passe parfaitement dans l'éditeur sans erreur, qui s'exécute dans erreur, mais qui posera certainement problème à l'analyse. Voilà:

Code:

label loop

dim i%, j%

i%=1

loop:
if i%<3
    print "i%=";i%
    i% = i% + 1
else
    i% = i% + 1
    if i%>5 then end_if
    print "coucou ";i%

end_if
if i%>8 then end
goto loop

Tordu, non ? Et pourtant, Panoramic ne dit rien. Et vos analyseurs de source ?

Titilles Klaus! Tu as ma permission de coder comme ça. En réalité mon programme était fait pour mon codage, et pour moi. Je peux encore le retirer, d'autant que je ne l'ai pas encore mis dans mes sources à partager.

Maintenant Klaus, la porte est ouverte pour que tu fasses le code. Comme je l'ai dit, mon seul but est de débogger mes codes. Même si ce programme n'est pas fini, peut-être n'aurais-je pas du le publier, vu qu'il correspond à ma méthode de programmation. Ce qui est certain, c'est que si je reprend le codage de ce programme, je ne résoudrai pas tout les cas. Ce n'était pas le but, et comme je l'ai dit j'espérais que JL35 le fasse.

Je dois dire que j'ai commencé un programme qui servira pour faire un autre programme, qui lui même cela la base d'un troisième, et cela est bien plus intéressant pour moi. Je crois que si cela se passe comme je le pense, ça va durer. Le teste de boucle était pour moi un petit détour, et maintenant j'ai repris le droit chemin.

Mais je vous mets au défit de faire un teste qui résout tous les cas. A tout amateur!

cela ne veut pas dire que ce n'est pas possible, je suis même certain qu'avec un cahier des charges, cela le devient. Mais je n'ai pas la foi pour ce programme, et lorsque c'est le cas, j'ai tendance à traîner!

Perso, ton bout de code Klaus ne me pose aucun problème, c'est un IF suivi d'un THEN sur la même ligne donc il est indépendant, le end_if n'est considéré significatif qu'en début de ligne (ce que fait sans doute également l'interpréteur).

Maintenant ça ne paraît pas très propre comme codage, on verrait mieux un goto sur une étiquette avant le end_if.

@cosmos, je ne comprends pas bien ce que tu attendais concernant les IF ELSE END_IF et que je n'ai pas fait ?

Bravo Klaus ! (c'est bien la 1ere fois que je felicite quelqu'un pour avoir pondu un truc pareil !)
c'est exactement le genre de bout de code que je voulais voir.
Perso, je n'y arrivait pas... je dois pas être suffisamment tordu pour cela!

@JL35:
Dans le cadre d'une programme qui viendrait tester (comme par ex. celui de cosmos70), les blocs if/end_if,
Le code de Klaus est intéressant car dans le source on se retrouve avec plus de end_if que de if.

@JL35.
Ça n'a rien de grave. Je voulais voir l'indentation des boucles pour bien voir si il y avait un manque et je l'ai fait.

Ton code montre les boucles, mais ne rectifie pas l'indentation si celui-ci n'est pas respecté. Ainsi le programme que j'ai essayé, et qui est rempli de boucles IF/END_IF n'avait pas une indentation parfaite, et la sortie présentée par ton programme ne faisait pas la correction d'indentation des boucles.

J'aurais du traité la casse des instructions, et je pense que pour tes programmes, vu que tu code en majuscule, si tu veux essayer mon propre programme, cela doit te poser problème. Le mieux est de prendre mes propres programmes pour faire l'essai, vu que je code en minuscule, et tu verras que chaque sous programme a une indentation de départ à zéro, et si tout est correct, se retrouve à zéro au vu du return.

Tel qu'il est mon programme me convient, vu qu'il suit mes méthodes. C'est pour le codage de chacun d'entre vous que ça pose problème.

Je vais arrêter, je voudrais avancer un peu ce soir.

Pour la présentation ça ne me gêne pas, étant donné que j'ignore le end_if si ce n'est pas la 1ère instruction sur la ligne (j'ai peut-être tort, mais c'est comme ça que je fais).
Et ce end_if de Klaus en plein milieu du if, il branche où ? derrière le véritable end_if je suppose, mais ce n'est pas évident.

@cosmos pourtant j'ai bien fait l'indentation comme tu avais dit, que je réinitialise à chaque nouveau sous-programme... c'est pour ça que je liste aussi les labels et les return. Ou alors il y a une structure de if qui m'a échappé...
Et pour les majuscules, ça ne change rien, étant donné que je passe systématiquement la ligne en majuscules avant l'analyse, et je teste tout en majuscules.

Il y avait néanmoins une petite erreur dans la recherche des labels (cas des if/end_if), j'en trouvais qui n'en étaient pas dans le programme de cosmos, erreur que j'ai corrigé.

je te mets une partie du teste de nos deux programmes sur le teste des IF et END_IF.
Tu verras que l'indentation n'est pas la même.


Ton programme est plus beau. J'ai souligné des parties qui à mon sens devraient être décalés. Il y en a d'autre, mais ici on voit la différence.

Je voulais simplement jeter un petit pavé dans la mare. Bien sûr que nous avons tous le droit de programmer comme on le sent, et j'avais parfaitement compris, Cosmos70, que tu avais fait ton programme pour toi et pour résoudre un cas bien précis, sans chercher à créer un outil général.

Je suis encore d'accord avec l'idée que de faire un programme général, est probablement une chimère, en tout cas avec des moyens et dans un temps raisonnable, tous passionnés que nous sommes. Il était simplement intéressant de montrer que Panoramic ne "dénonce" pas toutes les "incohérences" sur les end_if, et apparemment à juste titre puisque le programme marche bien. Je suppose que dans le compilateur de Panoramic, il y a un peu plus qu'un simple décompte des IF...END_IF et autres constructions de la programmation structurée, et ceci justement parce que dans Panoramic, ces mots-clé ne sont pas de simples "délimiteurs" comme peuvent l'être dans certains langages des signes spéciaux comme des accolades, mais bien des commandes exécutables. Oui, le END_IF et le END sont des commandes et de ce fait soumises au déroulement dynamique du programme, pas simplement aux règles d'uns structure statique visualisable graphiquement.

Observez par exemple le code suivant:

Code:

label label1
dim i%

i% = 1
' i% = 5

print "i%=";i%
if i%>3 : print "ne doit pas arriver si i%=1" : else : i% = i% + 1 : print "i%=";i% : goto label1 : end_if : print "fin de ligne"
print "ne doit pas arriver non plus si i%=1"
label1:
print "on arrive ici" : if i%>0 then end_if

end

D'accord, c'est encore mauvais, pas beau, tout ce que vous voulez. Mais ça marche. Pour s'en convaincre, il suffit d'enlever l'apostrophe devant la ligne 5 et le placer devant la ligne 6. Je reconnais, programme parfaitement illisible, impossible à maintenir, etc. Mais on voit bien à la ligne 9 tout le sens de la qualité de "commande" des mots_clé comme ELSE, END_IF etc. Puis on peut faire un autre essai. Insérez "END : "devant le "end_if" de la ligne 12. Du coup, le compilateur découvre "more end_if than if" ! Et ce AVANT d'exécuter la première ligne du programme ! Intriguant, non ? Logique, mais intriguant. Comment fait le compilateur pour découvrir cela ? Sans parler bien sûr du problème de l'indentation de la ligne 9, ou alors quoi faire si on réécrit la ligne 9 comme suit:

Code:

if i%>3 : print "ne doit pas arriver si i%=1" : else : i% = i% + 1
print "i%=";i% : goto label1 : end_if : print "fin de ligne"

ce qui est parfaitement légal. Mais l'indentation ?

Je pense qu'il faudrait dire que pour telle version d'analyseur (ou représentation améliorée du source), il faut appliquer telle convention d'écriture, sinon, on se perd forcément dans un dédale de cas plus tordus les uns que les autres et qui sont tous parfaitement viables ét légaux dans la syntaxe très libre de Panoramic. Et que dire des fonctions et mots-clé qu'un peut placer dans des data...

Je ne veux surtout froisser personne, et je suis ce débat avec un grand intérêt, mais jusqu'à maintenant, j'ai l'impression que ce tourne un peu dans le vide autour de conceptions d'écriture implicites, non énoncées mais tacitement convenues dont je dis tout de suite que j'y adhère très certainement aussi, mais qui devraient être posées clairement pour introduire de tels programmes.

Désolé, je ne voulais pas jouer le trouble-fête :

Bonjour Klaus,

Je n'ai pas l'impression que tu joue les troubles-fêtes. (les gens sont susceptibles en ce moment - même moi -, c'est le temps peut être? )
Je pense qu'il faut prendre ces programmes pour ce qu'ils sont : de simples outils d'aide "personnalisés" et non pas généraliste. (je ne sais pas si je suis clair là)

Nous avons tous notre propre "style" de programmation. Ces "outils" collent forcements à ces "styles".
Je suis sûr à 99% (je me réserve 1%, on ne sait jamais ) que ce qu'a fait JL35, Cosmos70 ou ce que j'ai fais moi-même, fonctionne pour le code que nous développons nous-même. et c'est largement suffisant !

Il est toujours bon quand ça coince quelque part d'avoir dans ses cartons ce genre "d'outils". Il est plus intéressant d'écrire du "nouveau code" que de passer son temps à vérifier ligne par ligne où se trouve le satané end_if que l'on viré par erreur. Je dis bien viré car au moment de l'écriture initiale, le 'end_if' était, j'en suis persuadé, présent.

Maintenant, par curiosité, par JEUX, on se prend peut-être la tête pour imaginer des cas tordus...
Prenons l'exemple de ton code : remplacer les CR+LF par des ":" sur une dizaine de commande ne nous viendrais pas à l'esprit. Regarde dans mon code (analyseur d'objets) : j'ai plusieurs if-end_if imbriqués avec des "else" qui font pratiquement la même chose, j'ai rechigné à écrire ces "else", l'instruction goto m'a bien tenté, mais je ne l'ai pas utilisé. Au final j'ai fais des copier/coller de mes blocs de "else". Pourquoi ? parce que je préfère privilégier la lisibilité (quand il n'y a pas de contrainte de temps). Donc si je dois utiliser un utilitaire qui me fait le décompte des if_endif, ce qu'a fait cosmos ou JL35 me satisfait pleinement car dans mon cas, l'écriture des blocs conditionnels reste simple...

Bonjour,

Citation :

Je voulais simplement jeter un petit pavé dans la mare

Citation :

(les gens sont susceptibles en ce moment -

Ne croyait pas que vous me dérangez. J'essaye simplement d'expliquer mon point de vue. De plus:

Citation :

Je n'ai pas fait de contrôle de rem pour l'instant, je modifirais lorsque le temps me sera fournit.
Si il y a des remarques, j'en tiendrai compte d'ici là.

Donc vos remarques sont les bien venues.

Si j'avais du temps j'aurai déjà apporté des corrections. Mais j'ai réussi a rentrer de nouveau dans le programme qui était en cours (cela fait plusieurs jours que je n'y arrivais pas), donc j'y reste.

Lorsque vous publiez vos programmes, je ne vois pas beaucoup de différence dans la construction, par rapport au mien. D'ailleurs je constate qu'ici cela ressemble à un forum de "jeune vieux". La majorité d'entre nous sommes des dinosaures, avons connus les premières consoles. Tout comme vous j'ai vu le TRS80 du copain, ou le TO7. Mois ça été ZX81, commodore avec le PET2001, ORIC 1, LAZER2000 (un (in)compatible de l'APPLE IIE pour le lazer il n'était compatible qu'en 40 colonnes), Atari 520ST et Mega ST4.
Je remarque que la majorité d'entre nous codent les programmes de façon similaire, car nous avons les mêmes expériences. Si je vais dans mes archives, j'aurai du mal de les lire. J'ai du à ce moment là apprendre à faire du tricot!

Donc la polémique je crois qu'ici c'est vous que la faites, moi je suis d'accord sur tout. Seulement personnellement je n'irais pas plus loin. Je rectifierai pour éviter de lire le return en fin de ligne, ainsi que ce qui concerne la casse. J'y rajourterai un check pour que l'indentation corresponde à la méthode Panoramic, sans tenir compte des labels et return. Et je crois que tel quel, ce programme suffira. Quant à ceux qui ont un code déroutant, désolé, mais avec moi ils n'auront pas satisfaction.

Mais comme il y a des mastodontes ici, et qui veut relever le défi, libre à eux de tout reprendre à zéro, et refaire le code.

Là je suis entièrement d'accord avec ce que disent Nardo et Cosmos, que finalement on ne peut pas couvrir tous les cas tordus de programmation, mais que globalement, pour quelqu'un qui programme à peu près dans les règles, les programmes fonctionnent (quoique je suis un peu intriguè par les erreurs que me signale cosmos dans le mien: par exemple la ligne 736 qui ne déclenche pas d'indentation, par contre les lignes affichées intempestivement, par exemple 764 à 779, ça devrait être corrigé dans la dernière version en ligne ).

Je reste un peu abasourdi par l'exemple que donne Klaus, je n'avais jamais imaginé que le if else end_if tout sur la même ligne puisse être accepté par l'interpréteur et fonctionner ! et évidemment, si on veut prendre en compte tous ces cas tordus (il y en a sûrement bien d'autres), ça devient inextricable...

Une petite remarque concernant l'exemple qu'a fourni Klaus et qui syntaxiquement me parait correct et qui n'est pas si tordu que ça :

3 règles à appliquer :
1- une étiquette est une ligne se terminant par ":" et contenant EXCLUSIVEMENT les caractères [A-Z][a-z][0-9]
2- remplaçer tout les ":" par des CR+LF --> le code redevient limpide.
3- si un if est suivi d'un 'then', ce "if" ne possède pas de end_if

Code:

01
02 label label1
03 dim i%
04
05 i% = 1
06 ' i% = 5
07
08 print "i%=";i%
09 if i%>3 : print "ne doit pas arriver si i%=1" : else : i% = i% + 1 : print "i%=";i% : goto label1 : end_if : print "fin de ligne"
10 print "ne doit pas arriver non plus si i%=1"
11 label1:
12 print "on arrive ici" : if i%>0 then end_if
13
14 end

En appliquant la 2ème règle, cela devient :

Code:

01 label label1
02 dim i%
03
04 i% = 1
05 ' i% = 5
06
07 print "i%=";i%
08 if i%>3
09  print "ne doit pas arriver si i%=1"
10 else
11  i% = i% + 1
12  print "i%=";i%
13  goto label1
14 end_if
15 print "fin de ligne"
16 print "ne doit pas arriver non plus si i%=1"
17 label1:
18 print "on arrive ici"
19 if i%>0 then end_if
20
21 end

Citation :

Insérez "END : "devant le "end_if" de la ligne 12. Du coup, le compilateur découvre "more end_if than if" ! Et ce AVANT d'exécuter la première ligne du programme ! Intriguant, non ? Logique, mais intriguant. Comment fait le compilateur pour découvrir cela ?

au vu de la 2ème règle, l'interpréteur n'a aucun mal à détecter une erreur si on a mis un end à la ligne 12 avant le end_if (du prog initial; ligne 19 après application de la 2ème règle) car les ":" entre le 'end' et le 'end_if' font basculer celui-ci sur la ligne d'en-dessous, il devient donc visible à l'interpréteur.

PS:
Pour l'étiquette c'est déjà le principe de la 1ère règle que j'utilise et cela fonctionne très bien !

Code:

  ...
  ...
  NotInStr$=ligne$ : NotInStr1$=" =$%" : gosub NotInStr : ' recherche si caractères illégaux
  if NotInStr%=0 and right$(ligne$,1)=":"
    ' c'est une etiquette, on vérifie si on connait la déclaration
    ...
    ...

' ---------------------------------------------------------------------------------------------
' recherche si caractères présent dans une chaine
' paramètres :
'    NotInStr$  : chaine de caractères à tester
'    NotInStr1$ : liste des caractères à controler
'    NotInStr%  : valeur de retour <> 1 si des caractères sont présents
' ---------------------------------------------------------------------------------------------
NotInStr:
  NotInStr%=0
  for NotInStr_i%=1 to len(NotInStr1$)
    NotInStr% = NotInStr% + instr(NotInStr$,mid$(NotInStr1$,NotInStr_i%,1))
  next NotInStr_i%
return

Certes, tout cela est bel et bon.
Pour les étiquettes dans le code, je n'avais pas pris en compte qu'elle doit impérativement être seule sur sa ligne, composée des caractères que tu cites suivie de ':', et c'est tout, ce qui simplifie la recherche.

Et effectivement, si tu déplies toutes les lignes en remplaçant les ':' par des crlf, ça simplifie tout pour l'analyse (j'avoue que je n'y avais pas pensé). Mais ça devient peut-être plus coton pour le listage des résultats avec leurs numéros de lignes ?

Si if est suivi de then effectivement il ne peut y avoir de end_if. En basic classique on pouvait faire if...then...else sur la même ligne, il m'est arrivé de le faire machinalement en panoramic, mais là le else et ce qui suit sont purement et simplement ignorés, sans signalement d'erreur, ça trompe !

Comme le dis Klaus, c'est loin d'être simple.
Pour les n° de ligne cela signifie qu'il faut mémoriser pour chaque parcelle de code que tu décomposes, le numéro de ligne initial. Ca commence à être lourd...


Est-ce vraiment nécessaire?...
perso je ne coderai jamais des dizaines de commandes avec des if dedans, le tout sur la même ligne...

[Edit]
Jack doit bien se marrer car il s'est déjà posé ces questions en 2007...
Et notre vision certainement 'simpliste' du problème doit le faire sourire...
[/Edit]

Je suis bien de ton avis (implicite), ça devient un peu trop lourd si on veut vraiment traiter tous les cas de figure même les plus farfelus sous prétexte que le compilateur les accepte.

En ce qui me concerne j'en resterai là a priori, et s'il m'arrive d'empiler des instructions sur la même ligne pour gagner de la place, ça ne dépasse pas le if...then

.... et l'éléphant a pondu un oeuf !!!

C'est pourtant pas Pâques ! et la montagne a accouché d'une souris tant que tu y es
Tu as raison, il vaut peut-être mieux arrêter là ces discussions byzantines

Pas encore, c'est oublier une chose, mais avant:

Citation :

Pour les étiquettes dans le code, je n'avais pas pris en compte qu'elle doit impérativement être seule sur sa ligne, composée des caractères que tu cites suivie de ':'

Un de mes programmes qui est de côté pour l'instant, code de cette façon. Je rigole!!! (et ça marche)

Ceci n'est qu'une partie du code, donc inutile d'essayer. Par contre tous les codes du listing ne sont pas visibles mais se copie.

Code:

q$="150
150":gosub q:' -------
q$="151
151":gosub q:on_click 102,fonte_2
q$="152
152":gosub q:END
q$="153
153":gosub q:' ==========================================================================================================
q$="154
154":gosub q:b1:
q$="155
155":gosub q:item_add 3,"a$="+a$
q$="156
156":gosub q:item_add 3,"b1$="+b1$
q$="157
157":gosub q:return
q$="158
158":gosub q:' =============================================================================
q$="159
159":gosub q:supprime:
q$="160
160":gosub q:  item_delete 90,count(90):gosub ecrire
q$="161
161":gosub q:  ' à défaut de lire la hauteur:
q$="162
162":gosub q:  text 173,str$(imY%)                          :' lig précédente
q$="163
163":gosub q:return
q$="164
164":gosub q:' =============================================================================
q$="165
165":gosub q:fonte:
q$="166
166":gosub q:  show 295:color 297,0,0,0 : END
q$="167
167":gosub q:  fonte_1:
  ' c'est le choix den list 296 qui enclenche ici
q$="169
169":gosub q:  2d_target_is 297:print_target_is 297:color 297,0,0,0
q$="170
170":gosub q:  font_name 297,item_index$(296)  :  2d_fill_color 0,0,0
q$="171
171":gosub q:  print_locate 10,00: print "aàâ eéèê iî oô uù y "
q$="172
172":gosub q:  print_locate 10,70: print "bcdfghjklmnpqrstxwxz"
q$="173
173":gosub q:  print_locate 10,140:print "ABCDEFGHIJKLM"
q$="174
174":gosub q:  print_locate 10,210:print "NOPQRSTUVWXYZ"
q$="175
175":gosub q:  END
q$="176
176":gosub q:  fonte_2:
q$="177
177":gosub q:  ' l'appui sur la représentation de la fonte, branche ici
q$="178
178":gosub q:  if number_click=102
q$="179
179":gosub q:      if fonte$<>""
q$="180
180":gosub q:        font_name 102,fonte$:fonte%=font_defaut%
q$="181
181":gosub q:      else
q$="182
182":gosub q:        fonte%=17:fonte$=item_read$(296,fonte%):font_name 102,fonte$:font_defaut%=fonte%
q$="183
183":gosub q:      end_if
q$="184
184":gosub q:  else
q$="185
185":gosub q:      if number_click =297
q$="186
186":gosub q:        if fonte%>0
q$="187
187":gosub q:            fonte%=item_index(296):fonte$=item_read$(296,fonte%):font_defaut%=fonte%:caption 2,fonte$
q$="188
188":gosub q:        else
q$="189
189":gosub q:            fonte%=17 : fonte$=item_read$(296,fonte%) : font_defaut%=17
q$="190
190":gosub q:        end_if
q$="191
191":gosub q:        if der_obj%=193 then font_name 193,fonte$
q$="192
192":gosub q:        if der_obj%=102 then font_name 102,fonte$
q$="193
193":gosub q:      end_if
q$="194
194":gosub q:  end_if
q$="195
195":gosub q:  size%=position(299)
q$="196
196":gosub q:  ' ICI IL FAUT FAIRE UN TESTE POUR SAVOIR QU'ELLE TYPE DE FONTE ON UTILISE
q$="197
197":gosub q:  gosub teste_fonte
q$="198
198":gosub q:  ' à force d'en rajouter, il faudra simplifier cette procédure
q$="199
199":gosub q:  hide 295:set_focus 101
q$="200
200":gosub q:return

Là ,tu m'en bouche un coin !

Citation :

Jack doit bien se marrer car il s'est déjà posé ces questions en 2007...
Et notre vision certainement 'simpliste' du problème doit le faire sourire...

Pas du tout. Je lis tout sérieusement et avec un grand intérêt.

On a beau se dire qu'on arrête, mais il y a toujours du nouveau pour vous surprendre !
Après le post de cosmos, j'ai essayé ça:

Code:

DIM a$
LABEL toto

a$ = "Au clair"
GOTO toto
a$ = "de la lune":toto:
print a$
end

Eh bien j'en reste baba , mais ça marche, on va bien directement sur l'étiquette en plein milieu d'une ligne de code !
Certes, ça ouvre peut-être des possibilités, mais pour l'analyse...

Je précise: il faut bien que l'étiquette toto soit la dernière chose sur la ligne, sinon erreur.

Il faut donc revoir la 1ère règle (pas celle d'Asimov!) de cette manière:

1- une étiquette est un mot final d'une ligne

• commençant par une lettre alphabétique,
  
• se terminant par ":"
  
• contenant EXCLUSIVEMENT les caractères [A-Z][a-z][_][0-9]
  

Une fois cette règle bien définie, le codage n'est qu'une simple formalité...

Nardo26, ton analyse semblent parfaitement définir le comportement du module d'analyse de Panoramic quant à la structure d'un programme. En tout cas, cela me semble plausible et je n'arrive pas à imaginer un cas de figure pour le mettre en défaut. Donc, bravo, et cela mériterait d'être inclus d'une manière ou d'une autre dans le User' Guide.