Ouais, et il faudrait peut être voir ce qu'il y a à piquer comme idées...
Ca fait deux ans que je connais Singularity et que j'y penses quelques-fois.
Il faudrait dans l'idéal :
1/ Preuve formel des contrats, voir pour cela http://why.lri.fr
2/ Que l'OS ait une réfléxivité sur lui même au moyen d'une ontologie qui lui permettrai de structurer sémantiquement son organisation. On pourra alors concevoir des systèmes d'autoréparations, etc...
3/ Un méta-langage de programmation
Je travaille sur le 3/ de plus en plus, en commançant par le bas niveau.
Ca donne :
- Connaissance de la sémantique des données par le compilateur (sources XML, BDD, etc... par connaissances des grammaires, modèle de donnés respectifs (DTD, MLD,...))
- Pré structuration des données en fonction de la structure de celle-ci
- Généralisation du pattern matching
Exemple, je récupère pour tous mes client l'ensemble des références achetées et voudrait savoir quels sont pour chacun d'entre les plus achetées. Je voudrai aussi savoir si ceux-ci on acheté mon nouveau produit dont la référence est du type "ZX80-xxxxx", et enfin repérer ceux qui m'achète pour plus de 10 000 ¤ par référence (pour leur faire un prix spécial).
J'évite de demander au SGBD de faire le boulot.
Ne faites pas attention à la syntaxe, elle est pourrie.
Req := BDD.query "select nom_cli, ref_achetee, qte, prix_unit from commande_ligne";
Req.group by nom_cli;
// Req est une liste de struct où la struct contient un nom, une liste de ref, qte, prix
Tri_cli := Req.for_each nom_cli do
Req.select ref_achetee, sum(qte*prix_unit) as px_tot group by ref_achetee order by sum(qte*prix_unit);
let rec f l =Tri_cli.for_each
Règle1 : Match (e=(px_tot > 10 000))::[] -> Cli_special.add e |
Règle2 : Match (e=(ref_achetee.match "ZX80-[\w]{5}"))::[] -> Cli_techno.add e |
Règle3 : Match t::q and (not Règle1) and not (Règle2) -> f(t) ; f(q);;
f(Tri_cli);
L'idée c'est de mélanger le pattern matching de type avec le contenu des données en posant des contraintes. Idéal pour XML....
Bon stop, j'arrête de délirer....
En attendant, je cois beaucoup au concepts que j'ai conçu pour mettre dans Lisaac que sont les agents.
On pourrait faire beaucoup de choses avec un OS entièrement constitués d'agent autonomes (des threads) à mémoire étanche (toute transmission de données se fait par copie) basé sur de l'évènementiel. http://wiki.loria.fr/wiki/0.5 (Outs, merci pour la remise en page ...)
Je crois que le concept est encore à largement affiner, mais ça permettrait de se simplifier la vie... et de tomber dans de gros bordel (pas facile de gérer les effets de bords des logiciels émergeants...)
IsaacOS va pour l'heure quand même beaucoup plus loin que Singularity qui reste un OS à micronoyau.
Il n'y a tout simplement plus de noyau dans IsaacOS....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Contrat
Posté par Ontologia (site web personnel) . En réponse au journal La vengeance de Tanenbaum. Évalué à 3.
Ca fait deux ans que je connais Singularity et que j'y penses quelques-fois.
Il faudrait dans l'idéal :
1/ Preuve formel des contrats, voir pour cela http://why.lri.fr
2/ Que l'OS ait une réfléxivité sur lui même au moyen d'une ontologie qui lui permettrai de structurer sémantiquement son organisation. On pourra alors concevoir des systèmes d'autoréparations, etc...
3/ Un méta-langage de programmation
Je travaille sur le 3/ de plus en plus, en commançant par le bas niveau.
Ca donne :
- Connaissance de la sémantique des données par le compilateur (sources XML, BDD, etc... par connaissances des grammaires, modèle de donnés respectifs (DTD, MLD,...))
- Pré structuration des données en fonction de la structure de celle-ci
- Généralisation du pattern matching
Exemple, je récupère pour tous mes client l'ensemble des références achetées et voudrait savoir quels sont pour chacun d'entre les plus achetées. Je voudrai aussi savoir si ceux-ci on acheté mon nouveau produit dont la référence est du type "ZX80-xxxxx", et enfin repérer ceux qui m'achète pour plus de 10 000 ¤ par référence (pour leur faire un prix spécial).
J'évite de demander au SGBD de faire le boulot.
Ne faites pas attention à la syntaxe, elle est pourrie.
Req := BDD.query "select nom_cli, ref_achetee, qte, prix_unit from commande_ligne";
Req.group by nom_cli;
// Req est une liste de struct où la struct contient un nom, une liste de ref, qte, prix
Tri_cli := Req.for_each nom_cli do
Req.select ref_achetee, sum(qte*prix_unit) as px_tot group by ref_achetee order by sum(qte*prix_unit);
let rec f l =Tri_cli.for_each
Règle1 : Match (e=(px_tot > 10 000))::[] -> Cli_special.add e |
Règle2 : Match (e=(ref_achetee.match "ZX80-[\w]{5}"))::[] -> Cli_techno.add e |
Règle3 : Match t::q and (not Règle1) and not (Règle2) -> f(t) ; f(q);;
f(Tri_cli);
L'idée c'est de mélanger le pattern matching de type avec le contenu des données en posant des contraintes. Idéal pour XML....
Bon stop, j'arrête de délirer....
En attendant, je cois beaucoup au concepts que j'ai conçu pour mettre dans Lisaac que sont les agents.
On pourrait faire beaucoup de choses avec un OS entièrement constitués d'agent autonomes (des threads) à mémoire étanche (toute transmission de données se fait par copie) basé sur de l'évènementiel.
http://wiki.loria.fr/wiki/0.5 (Outs, merci pour la remise en page ...)
Je crois que le concept est encore à largement affiner, mais ça permettrait de se simplifier la vie... et de tomber dans de gros bordel (pas facile de gérer les effets de bords des logiciels émergeants...)
IsaacOS va pour l'heure quand même beaucoup plus loin que Singularity qui reste un OS à micronoyau.
Il n'y a tout simplement plus de noyau dans IsaacOS....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker