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

Donc on est 2 pour le maintien des () pour un SUB sans paramètres.

A+

3 ...

!!! Q U A T R E !!!

C'est étrange, cette discussion.

Je trouve qu'il n'y a aucune confusion possible entre une procédure et un label.

Un label est déclaré par la commande label et defini par une chaîne de caractères commençant en colonne 1 et se terminant par un :, et rien d'autre derrière sauf un commentaire introduit par un apostrophe. Ceci est parfaitement unique à travers la syntaxe de Panoramic et ne peut en aucun cas être confondu avec autre chose.

Une prodédure n'est pas déclaré, ni par la commande label ni par autre chose. Elle est définie par le mot-clé réservé SUB. La chaîne de caractères qui suit jusqu'au prochain séparateur est le nom de la procédure. Le séparateur peut être une parenthèse ouverte (, une fin de ligne un double-point pour introduire une ligne de continuation. Aucune confusion possible avec un label, à ce niveau.

Un label peut être utilisé dans des commandes GOTO, GOSUB et la série des ON_xxx. Aucune procédure ne peut être utilisée ici.

Une procédure peut être utilisée à la place d'une commande. A la limite, il n'y aurait même pas besoin des parenthèses autour des paramètres. Imaginez une procédure comme une commande personnelle, créée par nous. Les parenthèses ne sont certainement là qu'n prévision de la structure très similaire des fonctions, à venir plus tard.

Donc, pour ma part, je ne vois pas de problème à omettre les parenthèses s'il n'y a pas de paramètres? C'est comme une commande genre RETURN, DISPLAY etc.

Les parenthèses permettent de voir tout de suite que l'on appel une procédure, je trouve.

\ 5 /

Salut tout le monde.

Testez ce code.

Code:

dim a$
a$ = "PANORAMICIENS !"

' test(a$)            : ' ---> ERREUR : la procédure n'est pas appelée
' test("PROGRAMMEURS") : ' ---> ERREUR : la procédure n'est pas appelée
' test("PROGRAMMEURS",0) : ' ---> la procédure est appelée et son exécution est correcte
' test("1")  : ' ---> la procédure est appelée et son exécution est correcte
' test(1)    : ' ---> la procédure est appelée et son exécution est correcte
 test(x,0,0,0,0,0,0,0,0) : ' la procédure est appelée et son exécution est correcte
' test("",1)  : ' ---> la procédure est appelée et son exécution est correcte
' test("",1,1,"")    : ' ---> la procédure est appelée et son exécution est correcte

end

SUB test(n$,colonne%,ligne%,phrase$)

  colonne% = 100 : ligne% = 50 : phrase$ = "HELLO " + a$
  color 0,0,0,0 : font_color 0,255,255,0 : font_bold 0 : font_size 0,20
  print_locate colonne%,ligne% : print phrase$

END_SUB

Quelles conclusions peut-on faire ?
Ces procédures SUB/END_SUB ont besoin de révision, non ?

Certes

@ papydall,

Ces choses là étant très confuses pour moi,
je ne rajouterai pas de la confusion à la confusion.
Comme je l'ai dit, j'attends la doc et une version stable
de la commande.

J'espère que l'on ne m'en voudra pas de m'abstenir
des test là concernant .

@ygeronimi

Tu as certainement raison et personne ne t’en voudra pour quoi que ce soit !

Dis-toi ceci : actuellement, on est tous dans le brouillard, mais le soleil s’élèvera bientôt !

ET TOUT SERA CLAIR

Klaus a écrit:

C'est étrange, cette discussion.
Je trouve qu'il n'y a aucune confusion possible entre une procédure et un label.

Ce n'est pas d'un risque de confusion auquel je pensais, mais plus a une meilleure lisibilité du code. Maintenant s'il les () ne sont pas obligatoires ce ne sera pas gênant non plus.


@Papydall, j'ai testé ton code et je dois admettre que pour l'instant il faut rester prudent, mais soyons patient un jour ou l'autre tout çà va se mettre en place....

A+

@papydall:
C'est parce que le nombre de paramètres passés n'est pas testé.

A tous:
Merci d'avoir testé cette première version, je prends en compte toutes vos remarques.
Je la retire car elle n'est pas utilisable en l'état.

D'ici quelques jours je vous soumettrai une autre version plus aboutie et qui aura les variables locales grace à DIM_LOCAL que je suis en train de coder.

Jack, c'est génial ! On attendait vraiment ça !

Pour ma part, je garde les deux versions en parallèle, et je teste tous mes codes avec les deux versions. Tant qu'on respecte les règles de codage, la syntaxe, tout semble marcher correctement. Bien sûr, si je fais des choses non prévues, il y a des messages et réactions bizarres. Mais je n'ai qu'à m'en prendre à moi-même.

Merci beaucoup Jack, c'est le début d'une nouvelle ère Panoramicienne qui commence avec la programmation avec des sous programmes réutilisables et les fonctions des DLL de Klaus pour compléter dans des domaines spécifiques. Ce qui est faisable devient énorme... Juste à nous d'être à la hauteur maintenant

merci Jack,

petite question, pourquoi pas utiliser juste DIM pour du local ?

jp

Je vais oser une réponse de mon point de vue, jpcr.

En créant une nouvelle commande DIM_LOCAL, Jack nous offre la possibilité, dans une procédure, non seulement de créer des variables locales, mais EGALEMENT des variables globales, ce qui mime ce qui est possible actuellement dans les sous-programmes appelés par GOSUB. Et je m'en sers à profusion: absolument toutes mes définitions de variables globales sont réalisées par un sous-programme appelé par GOSUB. Je pense que ce serait une bonne chose de maintenir cette possibilité également pour les procédures.

Klaus,
je ne suis pas trop d'accord avec toi sur ce point, en effet gosub ne sort pas du programme principal donc tu peut déclarer ce que tu veux alors qu'une sub interromp le programe principal le temps d'executer le code de la sub.

le principe de la sub est que tu crée un vrai sous programme qui peut avoir ces propres variables internes : les variables locales. suivant ce principe, ce qui est déclaré dans le programe principal est global et le reste est local, ça me semble moins confus .

jp

Perso, je suis pour le dim_local aussi, je trouve que ça donne plus de souplesse.
En plus un débutant ne peut gérer que des dim globaux pour ne pas se mélanger les pinceaux.
Après, pour ceux qui savent et qui comprennent le principe, le dim_local permet de faire une programmation par procédure.

Je comprends ton point de vue. Mais c'est une question de philosophie du langage, et Jack tranchera.

J'ai pratiqué bien d'autres langages, et ce point est traité différemment selon les langages. J'ai travaillé avec des Basic, pour ne parler que de ce groupe de langages, qui ne connaissant pas du tout la notion de variable globale dans le sens que tu l'entends. Dans ces langages, toute variable déclarée est locale à l'unité dans laquelle est déclarée. Et pour qu'elle soit globale, il faut un mot-clé particulier (GLOBAL en général, ou COMMON etc). C'est aussi un point de vue, plus rigoriste que ce que tu suggères.

Dans d'autres langages encore, on peut déclarer un ou plusieurs modules de "données". Ces modules ne contiennent pas de code, mais uniquement des variables globales, avec ou sans initialisation.

Tu vois, les possibilités sont très diverses. J'ai l'impression que Jack a toujours en vue de garder l'esprit de base de Panoramic: simplicité et compatibilité ascendante. Ce qui marche dans une version antérieure doit marcher dans la nouvelle. Le nouveautés apportées à une nouvelle version ne marchent pas bien sûr dans les anciennes. Et je pense que c'est pour cela qu'il a simplement prévu un nouveau mot-cle DIM_LOCAL qui apporte une nouvelle fonctionnalité, sans pour autant entrer en conflit avec l'existant et sans supprimer des fonctionnalités.

Mais c'est une impression personnelle.

oui , Klaus, j'ai moi aussi pratiqué bien des langages basic ou non, peut etre suis-je un peu ancré dans mes habitudes...

je ne pense pas que ce soit très grave de toute façon et effectivement Jack tranchera.

c'est de toute façon formidable d'avoir des sub.

jp

Jack a écrit:

...Je la retire car elle n'est pas utilisable en l'état.
D'ici quelques jours je vous soumettrai une autre version plus aboutie et qui aura les variables locales grace à DIM_LOCAL que je suis en train de coder.

Merci Jack !

Le DIM_LOCAL va me faciliter la vie !! (je n'aurais pas besoin de rajouter les lignes de FREE sans fin...

Pour l'heure, je garde cette version, car en faisant attention à ce que l'on écrit, elle reste quand même utilisable !...

(y a trop longtemps que je l'attendais !!... )

Au sujet de "DIM_LOCAL"


Je me permet d' apporter mon point de vue sur la chose
dans le rôle du néophyte.

Je pense que pour tous ceux qui débutent, un mot clé est important
pour :

- bien faire la distinction entre les deux
- repérer si et où est déclarée une variable (même en ayant "Variable(V$)")

J'apprends une chose intéressante pour moi en suivant de loin le débat,
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".
La libération des variables est intéressante aussi...parfois je suis en panne d'inspiration pour les nommer...

C’est bien le DIM_LOCAL.
Mais laissez-moi rêver puisque le rêve est gratuit.
La version qui nous sera soumise dans quelques jours, comportera-t-elle aussi l’implémentation des fonctions ?
Autorise-t-elle la récursivité ?

Dans l’affirmatif ça sera

!!! SUPER GENIAL !!!

@Ygeronimi:
Je pense qu'au niveau de la suspension des évènements lorsqu'une procédure est en cours, cela ne peut être qu'une difficulté passagère que Jack va certainement lever rapidement. En effet, il n'est pas envisageable de ploquer le mécanisme des évènements dès qu'on rentre dans une procédure.

Si c'est un comportement recherché, il faudrait pouvoir de déclencher par programme, par exemple par une commande EVENTS_OFF et le réenclencher par une commande EVENTS_ON. Tant qu'il n'y a pas ce type d'option, je pense qu'il faut absolument que les évènements restent actifs.

Bien sûr, il y a un problème. Lorsqu'on interrompt une procédure pour aller dans une routine évènement (forcément déclarée par comme d'habitude par la commande LABEL et définie par nom: ... RETURN), on voit toues les variables déclarées par DIM (les variables globales), mais on ne peut pas voir les variables locales de la procédure interrompue (et éventuellement d'autres en cascade) qui sont déclarées par DIM_LOCAL.

L'autre question qui se pose, c'est la persistance d'un évènement déclaré dans une procédure. Doit-il rester local à la procédure, en utilisant un label à l'intérieur de la procédure ? Doit-il être global et persister, en utilisant forcément un label en-dehors de la procédure ? Toutes sortes de question auxquelles Jack est certainement en train de réfléchir, et nous n'avons pas beaucoup d'éléments à ce jour pour en parler sérieusement.

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