Version instantanée du 8 septembre 2012 PANORAMIC V 0.9.24i1

ygeronimi a écrit:

...une procédure suspend durant sa réalisation le programme, chose que l'on a pas avec les "gosub"
et qui est parfois gênante quand les actions doivent se suivre alors qu'elles se chevauchent avec "gosub".

Bonjour ygeronimi,
Je comprend pas ta phrase...
l'appel à une procedure ou un gosub vers une etiquette, c'est exactement la même chose.
Jack aurait très bien pu utiliser cette syntaxe:

Code:

IF toto=1 then gosub maProcedure(x%)
...
END

MaProcedure(t%):
....
RETURN

@Klaus: au sujet de la récursivité, je crois qu'en Basic GFA, c'est faisable... (voir ici)

Je te suit Ygeronimi, cette question est importante...

A+

Ne cherchez pas trop pour le moment à ce niveau de détail. Jack nous dira quoi dans quelques jours sur ces sujets

Une petite question à réfléchir pour Jack:

Tu as prévu la commande DIM_LOCAL. Parfait. Attendu depuis longtemps, et l'utilité saute aux yeux.

As-tu prévu une commande LABEL_LOCAL ? De sorte à avoir les labels qui ne sont définies qu'à l'intérieur d'une procédure, et utilisables par GOTO/GOSUB/ON_xxx (en particulier ON_ERROR_GOTO) uniquement dans la procédure ?

As-tu prévu une commande EXIT_SUB ?

Mon avis:
Le LABEL_LOCAL risque d'être redondant et d'apporter une surcharge du langage par rapport au LABEL classique...
(ça à nous de faire attention sur ce que l'on code..)

Par contre le EXIT_SUB est une très bonne idée !!

Euh...

Les procédures (et plus tard les fonctions) devraient faciliter la modularité d'un programme, l'inclusion d'une procédure faite par un autre panoramicien, la constitution d'une bibliothèque de procédures et fonctions de service, ...

Et je suis convaincu que le traitement d'erreurs, géré proprement à l'intérieur d'une procédure, est un minimum pour cela.

Il y a de toutes façons une certaine "perméabilité" puisqu'il y a des variables globales. Mais les labels ? En-dehors des évènements déclarés pour les objets, quel label à l'extérieur d'une procédure pourrait être utilisé de façon sensée par une procédure ? Un GOTO en-dehors d'une procédure ? Très périlleux ! Un GOSUB pour appeler un sous-programme non compris dans la procédure ? Encore pire !

Soit Jack ne change rien aux commandes GOTO, GOSUB, ON_ERROR_GOTO, et on aura forcément des problèmes tôt ou tard, sans parler du conflit de noms de labels déclarés à l'intérieur de la procédure, par rapport à ceux déclarés globalement. C'est le même problème que pour les variables.

Soit Jack ajoute simplement une commande LABEL_LOCAL utilisable uniquement dans une procédure, comme DIM_LOCAL. Plus de conflits de noms de labels, plus de problème de mélange de lignes d'exécution, un codage propre dans une procédure auto-suffisante.

Cela ne ferme pas la porte à un GOTO en-dehors de la procédure. Je pense qu'il faut simplement donner la possibilité d'avoir des labels locaux, exactement comme pour les variables. Car même si l'on sait tester l'existence d'un label, et éventuellement définir un label s'il n'existe pas encore dans une procédure, on ne sait pas de supprimer comme c'est possible pour une variable (FREE) ou un objet (DELETE). On ne peut donc même pas se créer ses propres labels temporaires, comme on le faisait avant avec les variables.

Il y a vraiment matière à réflexion pour Jack sur ce sujet. Mais je suis présomptueux. Je suis certain qu'il a envisagé ces difficultés.

@ Klaus et vous tous

Je crains que l'on perde l'avantage de départ de SUB, s'il faut déclarer DIM_LOCAL et LABEL_LOCAL, ou alors il faudrait que "à la sortie du SUB les DIM_LOCAL et LABEL_LOCAL soit automatiquement supprimés (FREE_AUTOMATIQUE) ou que les LABEL_LOCAL(aux) et les DIM_LOCAL(es) soient réutilisables en les déclarant de nouveau".

Il faut, à mon avis, que le langage reste simple....

A+

Eh bien, c'est justement ça, l'idée. Quand on entre dans un SUB, on entre dans un espace local vierge. C'est un peu comme un disque virtuel en mémoire. On y crée ses variables locales, ses labels locaux. Cela n'empêche pas de voir les variables globales (celles déclarées dans le programme principal, PAS celles déclarées dans d'autres SUB !), un peu comme si on lisait d'autres disques. Et bien sûr, à la sortie du SUB, tout est effacé et oublié - le disque virtuel en mémoire est simplement fermé et supprimé, si je puis continuer l'analogie. A l'appel suivant, tout est recommencé.

Cela permet à une procédure d'être indépendante, et c'est justement l'intérêt. Elle déclare ses propres variables de travail, sans risque de conflit avec les variables du programme principal. Par END_SUB ou EXIT_SUB, tout est effacé. Donc au prochain passage, ce sera recréé, puisqu'un repasse par les commandes DIM_LOCAL. Et le même mécanisme devrait s'appliquer aux labels.

Regarde ce cas fictif (car non opérationnel aujourd'hui):

Code:

edit 1 : top 1,10 ; left 1,10
edit 2 : top 2,10 : left 2,210
...
tester_entier(1)
tester_entier(2)
...
sub tester_entier(obj%)
dim_local v%
label_local non_entier
on_error_goto non_entier : ' ne doit PAS affecter un ON_ERROR_GOTO dans le programme principal !
v% = val(text$(obj%))
' off_error_goto inutile - fait automatiquement par EXIT_SUB
exit_sub
non_entier:
off_error_goto : ' n'affecte que le ON_ERROR_GOTO de cette procédure !
text obj%,"Invalide"
end_sub

Je sais, on peut effectuer ce test autrement. C'est juste un exemple pour montrer un traitement d'erreur local dans une procédure. Tu peux avoir x procédures différentes, chacune ayant son label "non_entier", déterminant ainsi des traitements spécifiques à chaque procédure, sans conflit de nom de label entre procédures et avec le programme principal. Voilà l'intérêt de LABEL_LOCAL. C'est identique à DIM_LOCAL.

Merci Klaus, la comparaison avec des "disques virtuels" est très parlante....

Vu comme çà, alors oui DIM_LOCAL et LABEL_LOCAL ne posent pas de problème et j'y voit aussi un avantage que tu n'a pas souligné, c'est qu'on les déclare à l'intérieur du SUB et ensuite on peut les oublier...

Alors je vote pour

Effectivement. Le but, c'est de pouvoir copier un SUB dans un programme existant et l'utiliser en gérant uniquement les paramètres d'appel.

Imagine un dossier avec tous les SUB dans des fichiers individuels. Et en créant un programme apllication, tu places A LA FIN de ton programme, la liste des #INCLUDE nom1.sub ...etc. Le tour est joué. Tu peux utiliser toutes les procédures, et cela ne change absolument pas la numérotation des lignes dans ton programme source ce qui est important pour la facilité de mise au point en cas d'erreur.

On est ainsi aussi près que possible d'une bibliothèque de sous-programmes échangeables entre nous. Et j'attends cela avec impatience car j'ai énormément de modules intéressants que je transformerai ainsi. Cela me permettra de republier une version plus portable de mes modules Panoramic, sans les contraintes qui gênent leur utilisation à l'heure actuelle.

Tout çà est très alléchant....

Merci Klaus pour ces bonnes suggestions.

A+

C'est le principe même des variables locales. Elles ont une durée de vie restreinte à l'exécution de la procédure...

Citation :

J'aime Panoramic car c'est un langage simple (Heu... j'espère que çà va continuer)

Tu verras que cela va simplifier encore plus les choses !...

@Klaus : Heu... ton exemple du "on_error_goto" dans une procédure ne me convaincs pas...
Surtout la gestion d'un évènement avec une étiquette temporaire...
Que va t'il se passer si tu as ceci :

Code:

SUB test(x)
  LABEL_LOCAL test_err
  ON_ERROR_GOTO test_err
  ...
  shmilblik(125)
  ...
test_err:
  ...
END_SUB

SUB shmilblik(t)
  LABEL_LOCAL shmilblik_err
  ON_ERROR_GOTO shmilblik_err
  ...
shmilblik_err:
  ...
END_SUB

L'utilisation d'un LABEL_LOCAL pour shunter/simplifier un problème structurel du code... à la rigueur... (perso je l'ai déjà fait dans une procédure) mais si le code est bien pensé au départ, on peut s'en passer. (pour les susceptibles : Je ne remet pas en cause le GOTO! )

Je n'y vous aucun problème.

Tu appelles une procédure DANS une procédure. Le ON_ERROR_GOTO test_err est valable localement pour la procédure test. Toute erreur trappable Panoramic dans cette procédure sera déviée vers le label, à l'intérieur même de cette procédure.

Maintenant, tu appelles la procédure schmilblik. Si une erreur se produit dans la procédure schmilblik, deux situations sont possibles:

1. il n'y a aucun ON_ERROR_GOTO dans la procédure schmilblik ==> Panoramic se plante avec un message d'erreur car le ON_ERROR_GOTO test_err est local à la procédure test, et donc inactif dans la procédure schmilblik.

2. la procédure schmilblik a un ON_ERROR_GOTO avec un label local à cette procédure ==> l'erreur déclenche le saut à ce label local à la procédure schmilblik.

Dans ma vue des choses, les labels déclarés par LABEL_LOCAL ne sont en aucun cas visibles en-dehors de cette procédure, quelque soit le contexte. Aucune confusion n'est possible. Dans ton exemple, tu as déclaré un ON_ERROR_GOTO schmilblik_err qui est un label local à la procédure schmilblik. Pour une erreur entre ON_ERROR_GOTO schmilblik_err et END_SUB, c'est le label schmilblik_err qui sera activé. Pour une erreur entre ON_ERROR_GOTO test_err et END_SUB, c'est le label test_err qui sera utilisé. Et quand je dis "entre", cela veut dire dans des lignes source placées entre ces deux repères, et non dynamiquement !

Donc si il n'y a aucune erreur dans la procédure Smilblick, c'est le ON_ERROR_GOTO test_err qui reprend la main après le retour dans la procédure Test ?
Ça risque d'être mariole pour Jack de traiter ces cas...

Klaus a écrit:

@Papydall:
Tu connais des clônes Basic avec la récursivité ?

Ma réponse est OUI.
J’en connais certains.
Par exemple :
GFA BASIC, QBASIC, BBC BASIC for Windows, PURE BASIC, LIBERTY BASIC.
Ces BASICs permettent la récursivité.

Mais surtout (et ce qui nous intéresse tous ) FREE BASIC

Et pour illuster ça, voici un code en Free Basic que je viens de tester.
Il fait un appel récursif à une fonction qui calcule la factorielle de n.
RAPPEL : la factorielle de n (notée n !) se calcule comme ceci :
Calcul itératif : n ! = 1*2*3*…..*n
Calcul récursif : n ! = n*(n-1) !

Code:

' Appel récursif de la fonction "factoriel" en FREE BASIC
function factoriel(n as integer) as integer
    if n < 2 then
        factoriel = 1
    else
        factoriel = n * factoriel(n - 1)
    end if
end function

dim n as integer
for n = 1 to 10
    print n;"! = ";factoriel(n)
next
sleep

Et voici le résultat

Non, je ne crois pas. C'est juste une histoire de pile. Tout comme les variables locales sont certainement allouées avec un système de pile, il faudrait faire de même avec les labels et la valeur active du label ON_ERROR_GOTO. Et toute sortie de la procédure purge la pile en "oubliant" variables, labels et valeur de ON_ERROR_GOTO, et on retombe automatiquement sur la situation précédente. Ceci est une technique classique d'implémentation des interpréteurs.

Ah, Papydall, on s'est croisé avec ma réponse à Nardo26.

Merci beaucoup pour ces exemples - je ne connaissais que des Basic sans aucune récursivité. Il s'agissait de clones Basic puissants et lourds de Digital Equipment, comme Basic+ et Basic+2, compilé et linké pour ce dernier. Des langages commerciaux, bien sûr.

Dont acte: en particulier si FreeBasic le supporte, ta question est alors tout à fait pertinente, et il sera intéressant de voir si Jack donnera accès à cette possibilité.

Free Basic supporte bien la récursivité : la preuve mon post précédent illustrant un exemple et son résultat.
A mon avis, la récursivité est pour bientôt ! Je m’en réjouis d’avance.

papydall a écrit:

Free Basic supporte bien la récursivité : la preuve mon post précédent illustrant un exemple et son résultat.
A mon avis, la récursivité est pour bientôt ! Je m’en réjouis d’avance.

C'est déjà possible...
mais ne brulons pas les étapes : c'est un peu tôt pour en parler : tu vas faire peur à ygeronimi !

Sans compter que la récursivité s'applique dans des cas très spécifiques et n'est pas nécessaire dans la plupart des applic que nous faisons...
(quoique pour supprimer des arborescences de répertoire comme j'ai cherché à le faire l'autre jour, cela ne serait pas un mal )

La récursivité n’est pas un luxe.
C’est une grande souplesse de programmation, surtout pour coder des algorithmes qui sont essentiellement récursifs et il en existe des quantités.

Un algorithme récursif peut être codé itérativement, mais il existe des cas où le codage itératif (on dit aussi impératif) devient trop complexe et le recours à la récursivité s’impose.

Certes un codage récursif demande plus de ressource en mémoire mais il donne un code concis, mieux compréhensible, plus élégant.
C’est certainement un goût personnel

Pour mes dames, j'ai toujours dit que je m'y remettrais pour l'algo de l'IA quand cela serait possible.
Ca simplifie énormément l'écriture et la réflexion. C'est pour bientôt. mince, je vais devoir me remettre à bosser dessus (Je plaisante, j'en suis ravis)

@ Nardo26,

La peur n'évite pas le danger...

...et avec tout ce que je lis, le danger est de partout même sur ce forum .

Du Moment où les choses ont une doc clair, net, et précise
et qu' il ne faut pas avoir fait polytechnique pour la décrypter...
( style IKEA...çà vous rappelle rien )

Je suis partant pour tout

(Ton index va devenir très pratique justement pour faire une séparation
ou plutôt une différenciation entre certains mots clé et leurs utilisations)