Quelques nouvelles ...

Ces derniers mois, j'ai fait quelques déplacements professionnels de longue durée et pendant lesquels, comme d'habitude, je n'avais presque aucun temps libre, puis j'ai développé un logiciel de génération de GCODE pour une machine à commande numérique.
Je n'ai donc pas pu continuer le développement de Panoramic comme je l'aurai voulu.

Cependant, j'ai quand même avancé sur certains points.

Les bugs 2, 3 et 4 sont corrigés et je vais bientôt sortir une nouvelle version qui possèdera les fonctions.
Une fonction sera définie par FNC et se terminera par END_FNC ou EXIT_FNC et sera appelable dans toute expression.
J'aurai l'occasion d'en reparler.

J'ai commencé à porter le compilateur en FreePascal, mais je me suis heurté à des difficultés dont voici quelques exemples:
- le portage sous Android et sous MACOS n'est pas facile.
- il me faut trouver une astuce pour les DATA, READ, RESTORE et en particulier RESTORE_LABEL car intégrer des données dans un source pascal n'est pas évident. Y accéder par un LABEL (RESTORE_LABEL) est encore moins évident.
- il me faut faire la différence entre les LABEL sur lesquels pointe un GOTO et ceux sur lesquels pointe un GOSUB. Je m'interroge d'ailleurs sur la pertinence du GOSUB alors que les SUB existent ...
Ces difficultés ne sont pas insurmontables, mais je pense que le compilateur avec FreePascal ne sera pas prêt avant quelques mois.
Aussi, la prochaine version du compilateur risque bien de se faire encore avec FreeBasic.

Je suis en outre en train de développer une version de Panoramic qui se situe entre un interpréteur et un compilateur.
Dans un premier temps, une analyse de la structure du source est effectuée puis chaque ligne est analysée : la syntaxe est vérifiée puis la ligne est transformée en un code interne.
Enfin, l'exécution se résume à une exécution de ce code interne. Il n'y a plus aucun travail d'analyse pendant l'exécution. Il en résulte que l'exécution est autrement plus rapide que précédemment.

Voila pour le moment, je donnerai bientôt d'autres nouvelles.

Je suis content d'avoir de tes nouvelles, et des nouvelles de Panoramic !

Tout d'abord, je te souhaite une excellente année 2018. Tout a fait égoïstement, je te souhaite une année plus calme professionnellement . Non, blague à part, je te souhaite réussite, santé et bonheur, pour toi et tes proches.

Maintenant, pour Panoramic:
Je suis très content d'apprendre que les fonctions Panoramic vont venir. C'est un gros morceau, et ça nous sera très utile !

Personnellement, je suis moins concerné par le compilateur, mais je suis cela de loin.

Par contre ton idée d'un hybride entre interpréteur et compilateur m'intéresse beaucoup - on garde la souplesse de l'interpréteur et on gagne en exécution via le byte code. C'est prometteur et je vais guetter la sortie de cette version !

A l'évidence, tout cela implique un remaniement profond du coeur de Panoramic. C'est peut-être le moment de suggérer une modification, si je peux me permettre. A ce jour, on peut appliquer la fonction intrinsèque ADR() sur un tableau. Ca marche bien pour un tableau en 1 seule dimension. Pour un tableau en 2 dimensions, seules les cellules de la première série sont accessibles. J'avais déjà constaté que les données sont mémorisées de façon contigue pour les cellules (i,0), (i,1), ..., (i,n), pour i de 0 à maxi du premier indice. Cependant, ces "segments" eux-mêmes ne sont pas contigus. En particulier, si je définis:

Code:

dim MonTableau%(4,3)

la cellule (0,1) ne suit pas la cellule (4,0), etc. Ceci exclut de pouvoir travailler avec un tableau de deux dimensions dans une DLL. Serait-ce possible de changer cela, de sorte que les données soient physiquement contigues ? Si ce n'est pas possible, ou si ce n'est pas le moment, alors oublie ce que je viens de poster.

En tout tas, Bravo pour ces annonces et un grand MERCI pour ta persévérance sur Panoramic !

Merci Jack pour ces nouvelles.

Bonne année à toi et tes proches.

Klaus a écrit:

Par contre ton idée d'un hybride entre interpréteur et compilateur m'intéresse beaucoup - on garde la souplesse de l'interpréteur et on gagne en exécution via le byte code. C'est prometteur et je vais guetter la sortie de cette version !

+1

A+

bonne année 2018 Jack et plein de bonnes choses.
de toute évidence +1 pour la version hybride
c'est une idée qui me plait vraiment
bon courage

Les FNC, le bytecode, en voilà des avancées alléchantes
J'attend avec impatience la version bytecode pour le gain en rapidité d'éxécution que cela va apporter, car le compilateur refuse de fonctionner sur mon pc .

Bonne année, Jack.
Et merci pour ces bonnes nouvelles,
en particulier les fonctions !
Pour ce qui est des gosub
peut-être cela peut encore servir
(à vrai dire, je n'ai pas vérifié)
en remplacement pour quand les sub
fonctionnent mal, en particulier avec
les variables tableaux.
Enfin, c'est une idée...
Sans compter que rien n'empêche
d'améliorer les sub.

JJN4 a écrit:

Pour ce qui est des gosub, peut-être cela peut encore servir

Pour stratégo, j'ai utilisé des LABEL(s) à l'intérieur de certaines SUB(s) et je me suis rendu compte que GOTO est bien plus adapté dans ce cas, car il n'y a pas besoin d'un RETURN comme après un GOSUB.

C'est vrai que je ne vois plus très bien l'utilité de GOSUB, maintenant que nous avons les procédures SUB.
Le seul problème que je vois c'est qu'en cas de suppression de GOSUB il faudra bien expliquer aux accrocs du basic ancien comment c'est facile de s'en passer.

C'est un débat, peut-être que je ne pense pas à tous les cas.....

A+

En ce qui me concerne, j'ai un certain nombre de Subs (beaucoup en réalité) qui comportent chacune plusieurs sous-programmes internes appelés par Gosub, avec étiquette et Return, et je ne vois pas trop comment faire autrement...

Les spécialistes (les seniors des PANO) peuvent-ils expliquer au béotien que je suis les différences entre ...
- une fonction (ce mot n'est-il pas polysémique, avec plusieurs significations ?)
- un sous-programme
- une procédure
- une routine

et j'en oublie probablement.

Merci pour vos réponses.

NB. Des exemples seraient bienvenus.

Un sous-programme (ou procédure) ne retourne pas de résultat.

Une fonction retourne un résultat, que parfois on peut ignorer, ce qui revient à utiliser la fonction comme une procédure, d'où l'ambigüité de ce dernier terme !

Exemple tiré de la documentation FBPano :

Code:

- Une fonction (`function`) retourne un résultat, que l'on peut affecter à une variable ;
  les paramètres de la fonction doivent alors être placés entre parenthèses :

        y = exp(x)

    Toutefois, il est possible (bien que généralement déconseillé) d'ignorer
    le résultat et d'utiliser la fonction comme une procédure.

    Exemple : la fonction `file_open_read` ouvre un fichier texte en lecture
    et retourne la valeur TRUE ou FALSE selon que l'opération a réussi ou non.

    La syntaxe recommandée est de la forme :

        if file_open_read(1, "fichier.txt") = FALSE then
          ' Erreur
        else
          ' Suite du programme

    Si l'on décide d'ignorer le résultat on peut appeler la fonction comme
    une procédure :

        file_open_read 1, "fichier.txt"

Je ne suis pas tout à fait d'accord avec toi Jean.

Citation :

Un sous-programme (ou procédure) ne retourne pas de résultat.

Oui, une procédure est un sous-programme.
Mais comme tout sous-programme, elle peut retourner un résultat en modifiant la valeur d'une variable globale.

Ce qui est discutable dans ce que je dis, c'est que la modification de la valeur d'une variable doit-elle être considérée comme un résultat...

Citation :

Une fonction retourne un résultat, que parfois on peut ignorer, ce qui revient à utiliser la fonction comme une procédure, d'où l'ambigüité de ce dernier terme !

Là je suis complètement d'accord.

Excuse-moi Jean, je pinaille. Mais c'est volontaire pour que Ouf_ça_passe saisisse bien la différence.

Mais, j'ai quand même un doute sur ce que je dis. Je vais aller, de ce pas, chercher une réponse sur le Web.

A+

Suite à mes recherches, je vois que ce sujet sur les différences entre procédures et fonctions perturbe les programmeurs.

Je pense que la meilleur explication est:

CCM:

je l'ai trouvée ici => http://www.commentcamarche.net/forum/affich-6435771-procedure-et-fonction

A+

@Ouf_ca_passe
Un sous programme est dépendant du programme principal, il ne peut pas s'éxécuter sans lui.
C'est un branchement à un label(instruction GOSUB ou un évènement) avec retour à l'appelant(instruction RETURN).
En panoramic, les sous programmes sont placés après l'instruction END. Il y a forcément un branchement; si on accède à un sous programme sans l'avoir appelé, alors panoramic signale une erreur.

Une routine est indépendante du programme.
Une routine contient une collection de sous-routines, c'est une sorte de bibliothèque à thème (par ex. une pour la manipulation de fichiers, une autre pour la gestion graphique, etc...). La routine est spécifique à un langage de programmation et ne peut pas être utilisé pour un autre langage.
Une sous-routine est soit une procédure(instruction SUB), soit une fonction(instruction FNC, que jack met en place). Une procédure éxécute un ensemble d'instruction mais ne renvoi aucune valeur (comme par ex. 2D_CLEAR) contrairement à une fonction (ex. x=COS(45)).
En panoramic, les routines sont placés après l'instruction END(sinon il signale une erreur), ou dans un #INCLUDE.

Au sujet des procédures ou sous-programmes, il y a un tutoriel sur le forum:
https://panoramic.1fr1.net/t2497-les-sous-programmes-les-variables-globales-et-locales

Ce qu'il faut retenir:
- un sous-programme ou sub-routine ou procedure est un bout de programme, dont la déclaration commence par SUB suivi de son nom, et qui se termine par END_SUB.
- on peut définir des paramètres entre parenthèses.
- on appelle un sous-programme ou sub-routine ou procedure par son nom suivi de () s'il n'y a pas de paramètres, ou par des paramètres séparés par des virgules et entourés de parenthèses.
- un sous-programme est donc appelé comme une commande, sauf qu'il y a des parenthèses.

exemple:

Code:

DIM I%,R
- - -
SANS_PARAMETRE()
AVEC_UN_PARAMETRE(3*I%)
AVEC_DEUX_PARAMETRES(3*I%, 7-4*R)
END

SUB SANS_PARAMETRE()
- - -
END_SUB

SUB AVEC_UN_PARAMETRE(K%)
- - -
END_SUB

SUB AVEC_DEUX_PARAMETRES(Z%, W)
- - -
END_SUB

- les paramètres (par exemple Z% et W) ne doivent pas être déclarés. Ils peuvent avoir les mêmes noms que des variables globales (variables qui sont déclarées par DIM) mais n'affectent en aucun cas les variables globales, car ces paramètres n'ont d'existence que dans le sous-programme.
- dans un sous-programme, si dans la définition un nom de paramètre est identique au nom d'une variable globale, c'est la variable en paramètre qui est utilisée.
- enfin, ils peuvent posséder des variables locales, définies par DIM_LOCAL



Pour les fonctions, c'est pareil, sauf qu'elles retournent un résultat et qu'on les utilise dans des expressions ou dans des affectations.
- une fonction est définie par FNC suivi d'un nom et se termine par END_FNC. On peut définir des paramètres entre parenthèses.
- dans la fonction, la valeur de retour est définie par RESULT
- on appelle une fonction dans une expression ou dans une affectation par son nom suivi de () s'il n'y a pas de paramètres, ou par des paramètres séparés par des virgules et entourés de parenthèses.

Code:

DIM I%,R$,A
- - -
A=SANS_PARAMETRE()
BUTTON 150+AVEC_UN_PARAMETRE%(3*I%)
CAPTION 0,"ABC"+AVEC_DEUX_PARAMETRES$(3*I%, 7-4*R$)
END

FNC SANS_PARAMETRE()
RESULT 21.89
END_FNC

FNC AVEC_UN_PARAMETRE%(K%)
RESULT K%*23
END_FNC

FNC AVEC_DEUX_PARAMETRES$(Z%, W$)
RESULT LEFT$(W$,Z%+10)
END_FNC

Les fonctions sont typées comme les variables :
- si le nom d'une fonction se termine par %, elle retourne un entier
- si le nom d'une fonction se termine par $, elle retourne une chaine de caractères
- si le nom d'une fonction se termine par une lettre ou un chiffre, elle retourne un réel



PANORAMIC permet en outre d'utiliser les sous-programmes "à l'ancienne", comme dans les BASIC des années 80...
Un sous-programme est défini par un LABEL suivi de son nom, et se termine par RETURN
On l'appelle par GOSUB
Il n'y a alors pas de paramètres et pas de variables locales et le sous-programme utilise les variables globales (variables définies par DIM)

Merci les amis

Je me coucherai moins bête ce soir.

Comme Monsieur Jourdain qui faisait de la prose sans le savoir, je codais depuis toutes ces années en parfaite ignorance.

Je vais ajouter vos éclaircissements dans mon YAPUKA (mon vademecum informatique).

J'aime ta lecture Ouf_ça_passe, ça sent la culture...

BREF !
Moi aussi je vais me coucher un peu moins bête.
Les explications de Jack, m'ont fait entrevoir des possibilités que je ne soupçonnais pas concernant les fonctions...

J'attends avec impatiente la nouvelle version de Panoramic.

A+

Merci Jack pour ces bonnes nouvelles et notamment la définition des fonctions par le programmeur : c’est une grande avancée pour ceux qui savent en profiter.

Jack a écrit:

Je m'interroge d'ailleurs sur la pertinence du GOSUB alors que les SUB existent ...

Personnellement, je n’ai jamais senti le besoin d’utiliser GOSUB depuis l’avènement des SUBs.

Suite à la demande de Klaus concernant les tableaux, j’ose demander une amélioration des variables de type tableaux : étendre les dimensions de ces variables à des dimensions supérieures à deux (trois par exemple, plus si c’est possible)

Code:

DIM Coordonnee(x,y,z) : ‘ pour un tableau à 3 dimensions

@ Papydall

Nous croyions t'avoir perdu mais voilà que tu OSES.

Amitiés panoramiciennes

Bonsoir.
Je reprend la discussion sur l'utilisation de gosub.

Je connais l'utilité de gosub, et il est parfois difficile de l'éviter. Evidemment on fait la comparaison avec d'autre langage qui ne l'utilise pas, mais on est en basic, et on a pas toutes les possibilité qu'on les autres.

Je sais que cette instruction est utile, la majorité du temps on s'en passe facilement, mais il est des cas, où cela arrange. Je vous montre un cas que j'utilise actuellement, et vraiment si il n'y avait pas gosub, cela compliquerait le problème.

Je suis en train de faire une sub importante (à mon sens évidemment) où j'ai besoin de beaucoup de variables, et j'en suis qu'au début. Normalement j'aurai utilisé une bonne quantité de variables globales, chose que je voulais éviter au maximum. En faite je n'utilise en tout et pour tout, qu'une seule variable, car j'ai besoin d'une référence, et j'ai procédé ainsi:

sub diverse()
  GOSUB BOX_variables
  ' traitement ...
end_sub


et le sous-programme:

Code:

BOX_variables:
   dim_local edit% , box% ,ec% , var% , img% , obj_img% , gd% , tx$ , lequel%
   dim_local list_obj% , parent% , memo% , cur% , list_cur%  , prem%
   prem% = caption$(box_manadger%-1)
  
    lequel%   = caption$(prem%+1)
    edit% = prem%+2
    obj_img% =  prem%+9   :rem IMAGE
    list_obj% = prem%+3 :' liste du N° de chaque memo_style (le parent)
    box% = item_read$(list_obj%,lequel%)   :' list des variables
    memo%= box% +3
    list_cur% = box%+5
    var% = box%+7
    gd%  = item_read$(BOX%+7,1)  :' ligne en cours    
    ec%  = item_read$(box%+7,2)   :' écart décalage écran  
    img% = item_read$(box%+7,4)  :' ht écran pour décalage
    parent% = item_read$(list_obj%,lequel%)      
return

La définition des variables se fait dans le sous-programme, et les variables sont définies ici.
L'avantage de gosub, est que le sous-programme est considéré comme faisant partie du code qui l'appel.

Presque toutes les sub du programme font appel à ce s/p.

Pour moi il est de    Excusez-moi.

Bonjour à tous,

Vu comme ça, Oscaribout, GOSUB est incontournable. C'est le seul moyen que ta bibliothèque de variables locales te renvoi bien des variables locales.

L'idée de cette bibliothèque est intéressante pour certain cas, où on aurait besoin de beaucoup de SUB(s) avec les mêmes variables locales.

Concernant GOSUB, comme disait mon grand-père "Il ne faut pas jeter un outil sous prétexte qu'il ne sert jamais, un jour ou l'autre tu le regretteras".

A+

C'est bien pour ça que j'ai toujours la hache de pierre de mon ancêtre, on ne sait jamais...

Merci pour vos commentaires.
Pour ce qui est des outils, j'en ai encore des années 70 (même de mon grand-père) et même s'il est rare que je les utilise, il m'arrive d'en avoir besoin.

Gosub, je ne l'utilise que très rarement. Avant ce programme, je ne sais plus dans quel programme je l'ai utilisé auparavant.

Ceux qu'ils veulent voir cette instruction disparaitre, disent qu'ils en ont pas besoin, seulement la majorité du temps, ils présentent le même type de programme. J'ai eu à programmer dans d'autres langages qui ne possédés pas cette instruction, et bien cela n'a pas été simple de trouver le moyen de contourner ce manque. De plus ces langages ont des possibilités de construction que n'a pas Panoramic. En tout cas la trouvaille de se servir d'un gosub pour passer des variables locales en paramètres, je suis content de l'avoir trouvé, et je pense que ce ne sera plus une première fois.