j'ai aussi tout de suite pensé Prolog.
Prolog c'est vachement intéressant, mais beaucoup trop limité. On peut difficilement écrire un logiciel de gestion avec.
Dans ton exemple avec itself, j'ai l'impression que ce que tu cherches c'est que ton langage évolue au fil du temps : itself n'avait pas de sens avant le exist file. Tu n'as pas eu à le définir ensuite, parce que son sens est devenu intrinsèquement lié à l'objet considéré au moment présent. A première vue ça ressemble à une déclaration de variable/objet qui serait induite par le langage et non imposée par une instanciation effectuée par le développeur.
C'est exactement ça. Du sens de chaque mot et de la grammaire formée emmerge le sens.
On pourrait définir dans la bibliothèque le mot clé create de la façon suivante.
Create [in] <élément> et Create <élément> []
(En effet, je taxinomise pour le moment (je peux changer d'avis) en terme de "notion", "d'agent non vivant" et "d'agent vivant", sachant que chaque agent est potentiellement un SMA peuplé lui même d'agent formés par des SMA... Il y aura aussi probalement les notions de temps et de localisation)
On a donc deux dérivation possible associée à "Create".
Dans Create [in] <élément> l' ensemble est un objet "physique", donc on créé un élément dans l'ensemble.
Si Create est associé à une notion, cela veux dire que l'on crée un élement qui est une instanciation de cette notion, donc ici un fichier. La notion de localisation se réfère ici à l'endroit où elle se crée. La notion de localisation sera une primitive qui pourra se décliner en fonction du contexte. Dans un contexte fichier, il s'agit de préciser sur quel disque physique, ressource réseaux etc... on crée le fichier.
Cela pourra aussi donner lieu à la localisation d'un endroit particulier du fichier, en fonction du pattern.
(je réfléchis encore en écrivant)
Dans un fichier xml, il s'agit de retrouver un ou plusieurs pattern.
exemple find in (file "toto.xml" of type xml) (pattern [folder] [type ="(\w*)"][/folder]) and replace capture [0-9]+ by "coucou"
On a find in <qq_chose>
and est une conjonction de coordination, donc là la machine déduit qu'il s'agit d'un ordre associé. replace <qq_chose> by <qq_chose>
("find in" sera toujours associé à un ensemble)
find in <qq_chose>: désigne (file "toto.xml" of type xml). Le système comprend que l'ensemble en question est un ensemble structuré par une grammaire (xml en l'occurence).
Le <qq_chose>de find doit donc se rapporter à l'ensemble désigné et être compatible avec la grammaire. De plus, on ne sait pas si on cherche un élément ou un sous ensemble, d'où l'utilisation de <qq_chose> dont hérite et <éléments>
Ici il est remplacé par (pattern [folder] [type ="(\w*)"][/folder]) qui est un sous ensemble (un sous arbre) de l'xml.
Ensuite, on passe à l'ordre suivant : replace capture [0-9]+ by "coucou"
Comme j'ai mis ma regexp entre parenthèse, j'ai une capture. Il y aura donc autant de captures que de sous ensembles trouvés. '[0-9]+' veut dire n'importe laquelle. replace <élément> by <élément>
Bon j'arrête le délire ici.
Tel que je l'imagine, le système serait doté d'un moteur logique qui détecterait les ambiguité et demanderait à l'utilisateur de les lever.
Merci pour vos intervention multiples qui m'ont fait beaucoup réfléchir , je crois qu'il va falloir que j'étudie la théorie des grammaires génératives de chomsky, ainsi que les types ayant essayé de concevoir un langage logique destiné à supprimer les sous entendus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Du côté de la syntaxe
Posté par Ontologia (site web personnel) . En réponse au journal [annonce]Formalisation grammaticale d'un pidgin. Évalué à 2.
Prolog c'est vachement intéressant, mais beaucoup trop limité. On peut difficilement écrire un logiciel de gestion avec.
Dans ton exemple avec itself, j'ai l'impression que ce que tu cherches c'est que ton langage évolue au fil du temps : itself n'avait pas de sens avant le exist file. Tu n'as pas eu à le définir ensuite, parce que son sens est devenu intrinsèquement lié à l'objet considéré au moment présent. A première vue ça ressemble à une déclaration de variable/objet qui serait induite par le langage et non imposée par une instanciation effectuée par le développeur.
C'est exactement ça. Du sens de chaque mot et de la grammaire formée emmerge le sens.
On pourrait définir dans la bibliothèque le mot clé create de la façon suivante.
Create [in] <élément> et Create <élément> []
(En effet, je taxinomise pour le moment (je peux changer d'avis) en terme de "notion", "d'agent non vivant" et "d'agent vivant", sachant que chaque agent est potentiellement un SMA peuplé lui même d'agent formés par des SMA... Il y aura aussi probalement les notions de temps et de localisation)
On a donc deux dérivation possible associée à "Create".
Dans Create [in] <élément> l' ensemble est un objet "physique", donc on créé un élément dans l'ensemble.
Si Create est associé à une notion, cela veux dire que l'on crée un élement qui est une instanciation de cette notion, donc ici un fichier. La notion de localisation se réfère ici à l'endroit où elle se crée. La notion de localisation sera une primitive qui pourra se décliner en fonction du contexte. Dans un contexte fichier, il s'agit de préciser sur quel disque physique, ressource réseaux etc... on crée le fichier.
Cela pourra aussi donner lieu à la localisation d'un endroit particulier du fichier, en fonction du pattern.
(je réfléchis encore en écrivant)
Dans un fichier xml, il s'agit de retrouver un ou plusieurs pattern.
exemple find in (file "toto.xml" of type xml) (pattern [folder] [type ="(\w*)"][/folder]) and replace capture [0-9]+ by "coucou"
On a find in <qq_chose>
and est une conjonction de coordination, donc là la machine déduit qu'il s'agit d'un ordre associé.
replace <qq_chose> by <qq_chose>
("find in" sera toujours associé à un ensemble)
find in <qq_chose>: désigne (file "toto.xml" of type xml). Le système comprend que l'ensemble en question est un ensemble structuré par une grammaire (xml en l'occurence).
Le <qq_chose>de find doit donc se rapporter à l'ensemble désigné et être compatible avec la grammaire. De plus, on ne sait pas si on cherche un élément ou un sous ensemble, d'où l'utilisation de <qq_chose> dont hérite et <éléments>
Ici il est remplacé par (pattern [folder] [type ="(\w*)"][/folder]) qui est un sous ensemble (un sous arbre) de l'xml.
Ensuite, on passe à l'ordre suivant :
replace capture [0-9]+ by "coucou"
Comme j'ai mis ma regexp entre parenthèse, j'ai une capture. Il y aura donc autant de captures que de sous ensembles trouvés. '[0-9]+' veut dire n'importe laquelle.
replace <élément> by <élément>
Bon j'arrête le délire ici.
Tel que je l'imagine, le système serait doté d'un moteur logique qui détecterait les ambiguité et demanderait à l'utilisateur de les lever.
Merci pour vos intervention multiples qui m'ont fait beaucoup réfléchir , je crois qu'il va falloir que j'étudie la théorie des grammaires génératives de chomsky, ainsi que les types ayant essayé de concevoir un langage logique destiné à supprimer les sous entendus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker