Impossible d'utiliser "with sexp"

Bonjour à tous,

Je suis en train de suivre le livre Real World OCaml, et, à titre d'exemple, je dois créer un module avec un type utilisant les s-expressions. Voici l'interface que le livre utilise :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

open Core.Std

(** Configuration type for query handlers *)
type config with sexp

(** Name of the query handler *)
val name : string

(** Query handler abstract type *)
type t

(** Create a query handler from an existing [config] *)
val create : config -> t

(** Evaluate a query, where both input and output an s-expressions. *)
val eval : t -> Sexp.t -> Sexp.t Or_error.t

Lorsque j'essaye de compiler une implémentation de cette interface, je récupère cette erreur :

1
2
3

File "Query_Handler.mli", line 4, characters 12-16:
Error: Syntax error
Command exited with code 2.

J'ouvre donc utop pour essayer quelque chose de plus simple :

1
2
3

module type Test = sig
  type t with sexp
end;;

Et là, c'est le drame.

1

Error: Parse Error: "end" expected after [sig_items] (in [module type])

Pourtant, sexplib est installé et ni le livre ni mes recherches sur Internet ne donnent de "prérequis" pour l'utilisation de cette syntaxe.

J'ai l'impression d'être passé à côté de quelque chose. Une idée ?

Yep, j'ai vu ça. Au final, ce n'est qu'un changement de syntaxe, de mon point de vue. Tu as des sources concernant l'utilisation de Core ?

Et je jetterai un oeil au livre de Xavier Leroy, ça ne peut qu'être bénéfique de recouper les sources. Merci pour l'info !

Je me permet de faire un peu de hors sujet par rapport à la remarque de Dinosaure. J'avais trouvé ceci comme introduction à OCaml qui avait l'air pas mal, il me contredira peut être.

Ce n'est pas le sujet mais ça peut être interessant d'avoir un avis et d'éventuellement le faire découvrir à des gens si l'avis est bon.

Concernant le lien de @backmachine, en effet le cours à l'air très bien et mieux à jour que "Le Langage Caml" et je pense même qu'il serait bon de préférer ce document à la place du Real World OCaml ou encore du LLC. Après, le LLC reste tout de même une référence qui peut compléter le document car il contient notamment des exercices pour implémenter un mini-pascal, un mini-processeur ainsi qu'un mini-caml (avec son système de type) et ces exercices sont, pour moi, très intéressant !

Concernant Core, le problème est assez complexe car il concerne à la fois un aspect historique que financier. Il y a certainement des projets qui utilisent Core comme Flow et à raison comme oci. C'est une librairie qui reste de qualité industrielle.

Maintenant, il faut premièrement être au courant des autres librairies qui ont le même objectif que Core comme Batteries ou Containers qui sont tout autant d'une bonne qualité. Le monde de Core, et en particulier Async n'est pas seul.

Ensuite, il faut savoir que RWO a été co-écrit avec Yaron Minsky, qui travaille à Jane Street et qui avait tout intérêt à faire en sorte que l'un des outils standards que devrait utiliser les jeunes apprentis soit Core. C'est ce point que je critique vivement qui bien entendu offusque les autres librairies dont je viens de parler.

La raison historique (et raisonnable) et qu'ocaml n'a jamais voulu d'une librairie standard comme Python dans sa distribution. Le point est que la stdlib d'ocaml ne devrait servir qu'au compilateur. Batteries et Containers ont ceci d'intéressant qu'ils gardent la compatibilité avec la stdlib d'ocaml ce qui n'est pas le cas de Core.

Enfin, il faut bien séparer ce qu'utilise la communauté et ce que veux Jane Street. Dans les faits, Core est utilisé mais beaucoup préfèrent ne pas utiliser de librairies standards tout simplement et d'autres se raccrochent aux autres librairies citées plus haut. La grosse divergence (et surtout l'incompatibilité) réside surtout dans Async qui, au final, n'est utilisé que par Jane Street pour le coup où la communauté préfère utiliser Lwt. Certaines librairies font l'effort d'utiliser les deux implémentations comme Cohttp mais voici un article d'un des mainteneurs de Cohttp justement qui critique Async.

PS: Même si Real World OCaml est une bonne source, à mon sens, elle est trop centré sur l'utilisation de Core, qui, en toute honnêteté, n'est utilisé que par Jane Street.

C'est sans doute dommage de ne pas au moins présenter les alternatives (… c'est-à-dire en fait Batteries), mais c'est un peu bête de jeter le bébé avec l'eau du bain : quels sont les chapitres de RWO qui apprennent vraiment des choses qui dépendent de Core et ne sont plus utilisables autrement ?

Je préfère de loin l'introduction de Xavier Leroy (le créateur d'OCaml) et Pierre Weis avec Le Langage Caml qui ne demande pas des extensions comme sexplib ou des librairies standards comme core. Ce dernier livre s'intéresse à ce qu'est réellement OCaml.

"RWO ne présente pas réellement OCaml parce qu'ils utilisent Core, par contre ce livre qui en fait utilise Caml Light présente ce qu'est réellement OCaml" ? C'est un excellent livre, mais soyons honnêtes deux minutes, tu pousses un peu mémé dans les orties.

C'est sans doute dommage de ne pas au moins présenter les alternatives (… c'est-à-dire en fait Batteries), mais c'est un peu bête de jeter le bébé avec l'eau du bain : quels sont les chapitres de RWO qui apprennent vraiment des choses qui dépendent de Core et ne sont plus utilisables autrement ?

Tout le chapitre II sauf la partie concernant l'utilisation d'ocamllex et menhir utilise Core et Async. Comme je l'ai dit, Core n'essaye pas d'être compatible avec la stdlib ce qui fait que les signatures des fonctions sont différentes (particulièrement pour le module List).

Le véritable problème c'est l'incompatibilité voulu entre le monde de Jane Street et celui d'OCaml en général. Le problème de l'OP illustre bien ce qu'il en est. Le passage d'RWO vers le vrai monde OCaml (qui inclut donc Lwt, Batteries et ocamlbuild qui sont des outils qui ont été remplacé dans RWO par Async, Core et corebuild) est d'autant plus rude car dans les faits, la communauté n'utilise pas que Core, n'utilise pas Async et n'utilise pas corebuild.

Au final, si les personnes ne recoupe pas le RWO avec d'autres informations comme le LLC, il se retrouve enfermer dans le monde de Jane Street et doit ré-apprendre certaines notions (en particulier Lwt qui est un gros morceau) pour réellement interagir avec la communauté OCaml. En ce sens, même si le livre contient de très bonnes parties (notamment la partie III), il n'est pas à l'image de se qu'est réellement le monde OCaml.

"RWO ne présente pas réellement OCaml parce qu'ils utilisent Core, par contre ce livre qui en fait utilise Caml Light présente ce qu'est réellement OCaml" ? C'est un excellent livre, mais soyons honnêtes deux minutes, tu pousses un peu mémé dans les orties.

Il est vrai que le LLC présente Caml-light et il est de plus en plus divergent par rapport au monde OCaml. Le point est que en lisant le LLC avec OCaml, on ne se retrouve pas à ré-apprendre certaines notions. Au pire, on se retrouve à devoir en apprendre des nouvelles (comme les objets ou Lwt) - le seul point qui pèche et l'utilisation de Stream dans ce livre. Mais il n'y a pas de piège et si il y a bien une chose qui soit remarquable dans ce livre, c'est que les exemples sont toujours valides.

C'est à mettre en opposition avec le RWO qui demande à se mettre à jour non seulement avec le langage (ce que n'a pas fait le LLC, j'en convient) mais aussi avec les librairies qu'il utilise (et typiquement, ce topic est révélateur de ce problème). Après bien entendu, RWO n'est pas a jeté mais il est dommage de devoir signaler au lecteur qu'il doit recouper l'information avec d'autres sources. Ce ne devrait pas être le cas.

Tout le chapitre II sauf la partie concernant l'utilisation d'ocamllex et menhir utilise Core et Async.

Donc parce qu'un peu moins d'un tiers du livre apprend à utiliser une librairie, on brûle le tout ?

Comme je l'ai dit, Core n'essaye pas d'être compatible avec la stdlib ce qui fait que les signatures des fonctions sont différentes (particulièrement pour le module List).

Et alors ? La syntaxe de Caml Light n'est pas compatible avec celle d'OCaml non plus, pourtant il me semble qu'on est tous les deux d'accord pour dire que ça n'est pas une raison pour jeter LLC. Où est la logique ?

Le véritable problème c'est l'incompatibilité voulu entre le monde de Jane Street et celui d'OCaml en général. Le problème de l'OP illustre bien ce qu'il en est. Le passage d'RWO vers le vrai monde OCaml (qui inclut donc Lwt, Batteries et ocamlbuild qui sont des outils qui ont été remplacé dans RWO par Async, Core et corebuild) est d'autant plus rude car dans les faits, la communauté n'utilise pas que Core, n'utilise pas Async et n'utilise pas corebuild.

Les guerres de clocher ne m'intéressent pas du tout, et la discussion « oui mais non Core c'est pas du vrai caml, les vrais utilisent batteries et lwt » non plus. Mon propos est que RWO et LLC sont tous les deux des bons ouvrages, qui sont complémentaires et certainement pas en concurrence, et que tes arguments pour critiquer RWO sont entre un peu bancaux et à la limite du ridicule (RWO demande de « se mettre à jour avec le langage », vraiment ?)

Après bien entendu, RWO n'est pas a jeté mais il est dommage de devoir signaler au lecteur qu'il doit recouper l'information avec d'autres sources. Ce ne devrait pas être le cas.

Bien sûr que si, ça devrait être le cas. Depuis quand on est censé se contenter d'une seule source ? C'est d'ailleurs exactement la même chose pour LLC.

Donc parce qu'un peu moins d'un tiers du livre apprend à utiliser une librairie, on brûle le tout ?

Bon déjà, j'ai jamais dit qu'on devait tout brûler. J'ai toujours dit qu'il fallait utiliser une autre source que le RWO donc merci de ne pas caricaturer mon propos.

Et alors ? La syntaxe de Caml Light n'est pas compatible avec celle d'OCaml non plus, pourtant il me semble qu'on est tous les deux d'accord pour dire que ça n'est pas une raison pour jeter LLC. Où est la logique ?

Ensuite, c'est la syntaxe d'OCaml qui n'est pas compatible avec celle de Caml-light. Et c'est de cela dont il est question, c'est que tu peux tout autant prendre la majorité des exemples du LLC et les utiliser avec utop ce qui en fait encore aujourd'hui un livre de référence (bien entendu, cette assertion devient de plus en plus fausse avec le temps, notamment avec Stream récemment). La logique est qu'après la mise à jour de Core avec les PPX, les exemples d'RWO deviennent invalides - et ce topic en est la preuve.

L'incompatibilité devrait plus être dénoncé avec RWO et Core qu'avec le LLC et les ajouts dans OCaml. Et c'est bien ce que je dénonce.

Les guerres de clocher ne m'intéressent pas du tout, et la discussion « oui mais non Core c'est pas du vrai caml, les vrais utilisent batteries et lwt » non plus. Mon propos est que RWO et LLC sont tous les deux des bons ouvrages, qui sont complémentaires et certainement pas en concurrence, et que tes arguments pour critiquer RWO sont entre un peu bancaux et à la limite du ridicule (RWO demande de « se mettre à jour avec le langage », vraiment ?)

La vrai question, c'est pas de savoir si on fait du vrai OCaml avec Lwt ou avec Async, la question est surtout de savoir si il est normal de considérer que le vrai OCaml se fait avec Async - et c'est cette opinion que tente de défendre RWO en expliquant comment faire de la programmation asynchrone en OCaml avec Async (et donc en omettant Lwt).

LLC est bien plus proche de ce qu'est Caml car il se limite à Caml. Le livre ne fait mention d'aucunes librairies tierces et d'extra fait pas je ne sais qu'elle personne ou entreprise et présente Caml dans sa version la plus canonique - en somme, on a besoin uniquement de Caml pour lire ce livre (et par extension, d'OCaml). Et c'est là qu'intervient le problème car, non le vrai OCaml n'est ni Lwt, ni Async. Le vrai OCaml, c'est uniquement OCaml (toute sa distribution).

Ensuite, on peut amener la personne à utiliser des outils extérieurs à la distribution initiale d'OCaml et c'est notamment ce que fait RWO avec menhir. Mais encore faut il que dans le vrai monde d'OCaml tout le monde s'accorde à dire que si tu souhaites créer un parser, tu utilises menhir. Et pour le coup, c'est le cas - personne n'utilise ocamlyacc et on essaye même d'intégrer se que produit menhir dans OCaml. Donc pour ce coup, RWO ne se trompe pas. Mais pour le 1/3 du livre qui semble négligeable pour toi (mais qui ne l'est pas, c'est quand même 1/3 du livre), on considère que Core et Async sont les outils de bases pour développer en OCaml alors que ce n'est pas le cas - et c'est même pas en considérant que la norme est d'utiliser Lwt, c'est juste considérer que ce n'est pas le cas.

Ce n'est pas une question de savoir qui a raison entre utiliser Lwt/Async Core/Batteries, c'est surtout de savoir si ce livre a raison de présenter des outils qui (et tu ne pas le nier) ne font l'unanimité dans la communauté OCaml. Et donc non, il a tort. Ce livre devrait présenter OCaml (de part son nom) mais il présente OCaml selon Jane Street ce qui est complétement différent et c'est ce que je dénonce.

Bien sûr que si, ça devrait être le cas. Depuis quand on est censé se contenter d'une seule source ? C'est d'ailleurs exactement la même chose pour LLC.

Non ce n'est pas la même chose, LLC à l'époque était suffisant pour apprendre Caml. Bien entendu, aujourd'hui, il n'est plus suffisant pour apprendre OCaml alors on pourrait croire que RWO est suffisant pour apprendre OCaml mais ce n'est pas le cas. Il est quand même aberrant de dire qu'il faut à la fois lire le LLC (qui a plus de 20 ans) et le RWO qui est beaucoup plus récent. D'une certaine manière, c'est que le RWO ne fait pas son boulot de présenter OCaml tel qu'il est et qu'on a besoin d'une source tierce pour comprendre les erreurs et les pièges de ce livre.

Le LLC était suffisant pour savoir faire du Caml et tu pouvais bien entendu étendre ton apprentissage avec d'autres sources mais en aucun cas il contredisait les autres sources comme c'est le cas avec RWO en montrant List.Assoc.find comme une fonction disponible dans OCaml de base alors que c'est List.assoc qui est disponible de base. Si le livre expliquait bien qu'il existe d'autres librairies et que les fonctions qu'il explique dans le chapitre II sont à prendre en compte comme des ajouts de Core (et donc bien séparé ce qui appartient au monde OCaml et ce qui appartient au monde de Jane Street), il n'y aurait rien à redire.

Le problème, c'est que ce n'est pas le cas et donc dès que tu sors du monde de RWO (donc un monde sans Core et sans Async) et c'est ce qu'il risque d'arriver vu l'état de la communauté OCaml, tu penses avoir le bagage nécessaire pour programmer en OCaml ? La vérité est que non, il faut que tu ré-apprennes l'utilisation d'ocamlbuild (à défaut d'avoir toujours utiliser corebuild), il faut que tu découvres ce qu'est réellement la librairie standard d'OCaml (à défaut de n'avoir appris que Core), et il faut que tu ignores ce que tu as appris à propos d'Async parce que le standard selon la communauté, c'est Lwt.

Donc pour un livre qui se nomme REAL WORLD OCaml, c'est tout de même paradoxal!

Le problème, c'est que ce n'est pas le cas et donc dès que tu sors du monde de RWO (donc un monde sans Core et sans Async) et c'est ce qu'il risque d'arriver vu l'état de la communauté OCaml, tu penses avoir le bagage nécessaire pour programmer en OCaml ? La vérité est que non

C'est pas un problème de livre, c'est un problème de lecteur. C'est exactement pareil avec LLC. Et avec n'importe quel livre. Et comme j'ai l'impression de répéter toujours la même chose depuis le début de la discussion et de relire les mêmes arguments de fanboy qui se résument en gros en "RWO c'est caca parce qu'ils utilisent pas la même lib que moi, LLC c'est pas caca parce qu'ils utilisent pas le même langage que moi mais au moins ils utilisent pas la lib des gens caca", je vais m'arrêter là.

Edit : Sur github, core a 100 stars de plus que batteries. De quel "standard dans la communauté" tu parles, exactement ?

C'est pas un problème de livre, c'est un problème de lecteur. C'est exactement pareil avec LLC. Et avec n'importe quel livre. Et comme j'ai l'impression de répéter toujours la même chose depuis le début de la discussion et de relire les mêmes arguments de fanboy qui se résument en gros en "RWO c'est caca parce qu'ils utilisent pas la même lib que moi, LLC c'est pas caca parce qu'ils utilisent pas le même langage que moi mais au moins ils utilisent pas la lib des gens caca", je vais m'arrêter là.

Ow, c'est drôle d'en arriver à devoir me discréditer en utilisant les mots d'un gamin de primaire et encore une fois à déformer mes propos (car entre nous, Core n'est pas caca, c'est, comme je l'ai dit, une librairie de qualité industrielle) sur ce qu'est RWO (car non, RWO n'est pas caca non plus, il n'est pas représentatif du monde OCaml, c'est tout et c'est la seule chose que je dénote depuis le début).

Ensuite, il est en général mauvais de considérer le lecteur comme assez débile pour considérer le RWO comme une bible et de le définir comme étant le problème. Donc oui mon propos c'est de dire que RWO est le problème. Ce que tu ne veux pas comprendre, c'est que LLC (si on re-contextualise à son époque) n'a pas été un problème et c'est bien la différence fondamentale entre ces deux livres.

Edit : Sur github, core a 100 stars de plus que batteries. De quel "standard dans la communauté" tu parles, exactement ?

Enfin, l'argument d'autorité comme quoi parce qu'il y a plus de star sur GitHub, c'est que c'est forcément mieux, c'est un contre-sens grossier. Sinon, puisque tout le monde fait du JavaScript, c'est forcément mieux que OCaml ? Non ?

Bref, tout ceci montre que tu ne veux juste pas accepter que j'ai peut être un point de vu qui à le mérite d'être réfléchi et qui tient la route. En ce sens, tu as besoin d'utiliser des stratagèmes qui discréditent plus ma personne que mon propos pour essayer de montrer que tu es forcément dans le vrai car il est difficile d'accepter que ce que je dis peut être raisonnable (et qu'il peut être sain de critiquer le livre d'ailleurs).

PS: L'art d'avoir toujours raison - Schopenhauer

TL;DR de la conversation : on n'a pas de bon livre pour apprendre OCaml et il n'y a pas de "standard de la communauté", pas la peine d'en chercher un.

Ce que les gens feraient pas pour avoir raison sur Internet…

Ce que tu ne veux pas comprendre, c'est que LLC (si on re-contextualise à son époque) n'a pas été un problème et c'est bien la différence fondamentale entre ces deux livres.

Quel est le rapport avec la discussion ? Pourquoi un livre qui n'a pas posé de problème il y a 30 ans n'en poserait pas aujourd'hui ?

Ensuite, il est en général mauvais de considérer le lecteur comme assez débile pour considérer le RWO comme une bible et de le définir comme étant le problème. Donc oui mon propos c'est de dire que RWO est le problème.

Si le lecteur n'est pas débile et ne considère pas RWO comme une bible, il n'y a pas de problème. À propos de point de vue réfléchi…

Enfin, l'argument d'autorité comme quoi parce qu'il y a plus de star sur GitHub, c'est que c'est forcément mieux, c'est un contre-sens grossier. Sinon, puisque tout le monde fait du JavaScript, c'est forcément mieux que OCaml ? Non ?

Non, il faut apprendre à lire. Je n'ai écrit nulle part "c'est mieux", j'ai dit que tu parles d'un soi-disant "standard de la communauté" pour justifier ton rejet de Core qui n'a absolument aucun sens, puisque comme le fait remarquer Lz36GQfANCkOchnWu2yv, il n'y a justement aucun standard dans ladite communauté (et s'il y en avait un, ce ne serait certainement pas batteries).

En faite, je sais pas si tu le fais exprès au fond.

Tu considères que RWO est bien ? Alors pourquoi tu es capable de dire que c'est pas cool de présenter Core sans parler de Batteries/Containers ?

Tu considères que LLC est mal ? Alors pourquoi tu dis qu'il faut le recouper avec RWO ?

Tu considères que les deux sont complémentaires ? Alors pourquoi être intervenu ? Ne me fais pas dire ce que je n'ai pas dit. J'ai pas dit que RWO est nul, j'ai pas non plus dit que LLC était le livre par excellence.

Tu considères que je rejette Core ? Où j'ai dit que Core était mal ?

Enfin Lz36GQfANCkOchnWu2yv a surtout à chercher à arrêter le massacre que tu tentes de continuer. Mais j'ai certainement pas dit que Batteries était un standard (comme Containers). Et je maintiens que Lwt reste un standard (comme l'est à juste titre menhir).

Donc au fond, il est où le problème dans ce que je viens dire ? Celui de conseiller de lire aussi LLC ? Car j'ai jamais dit aussi de jeter RWO. Au fond, est ce que tu cherches pas juste à montrer grossièrement: "Regarez, j'ai raison, il a tort (sur quoi ?)". Tu critiques quoi exactement dans ce que je viens de dire ?

En faite, je sais pas si tu le fais exprès au fond. À propos d'attaques ad hominem, tu disais quoi juste au dessus ?

Tu considères que RWO est bien ? Alors pourquoi tu es capable de dire que c'est pas cool de présenter Core sans parler de Batteries/Containers ?

Parce que "bien" ne veut pas dire "parfait", et que c'est pas parce qu'il manque un paragraphe d'explication que ça rend le bouquin mauvais. Bienvenue dans le vrai monde où les choses ne sont pas binaires.

Tu considères que LLC est mal ? Alors pourquoi tu dis qu'il faut le recouper avec RWO ?

Apprends à lire, j'ai explicitement écrit dans mon premier message que c'est un excellent livre. Qui fait exprès, vraiment ?

Tu considères que les deux sont complémentaires ? Alors pourquoi être intervenu ? Ne me fais pas dire ce que je n'ai pas dit. J'ai pas dit que RWO est nul, j'ai pas non plus dit que LLC était le livre par excellence.

Je suis intervenu parce que tu as dit en substance "plutôt que RWO, il vaut mieux lire LLC". Alors que, précisément, comme ils sont complémentaires, il ne faut pas lire l'un plutôt que l'autre. Tu comprends maintenant où il faut encore que j'explique ?

Enfin Lz36GQfANCkOchnWu2yv a surtout à chercher à arrêter le massacre que tu tentes de continuer. Mais j'ai certainement pas dit que Batteries était un standard (comme Containers). Et je maintiens que Lwt reste un standard (comme l'est à juste titre menhir).

Non. Une bonne librairie, oui, probablement plus utilisée qu'Async (encore que, ce n'est pas dit), mais certainement pas un « standard ».

Donc au fond, il est où le problème dans ce que je viens dire ? Celui de conseiller de lire aussi LLC ? Car j'ai jamais dit aussi de jeter RWO. Au fond, est ce que tu cherches pas juste à montrer grossièrement: "Regarez, j'ai raison, il a tort (sur quoi ?)". Tu critiques quoi exactement dans ce que je viens de dire ?

Je cite :

Même si Real World OCaml est une bonne source, à mon sens, elle est trop centré sur l'utilisation de Core, qui, en toute honnêteté, n'est utilisé que par Jane Street. Je préfère de loin l'introduction de Xavier Leroy (le créateur d'OCaml) et Pierre Weis avec Le Langage Caml.

Et je cite le wiktionary :

préférer \pʁe.fe.ʁe\ transitif 1er groupe (conjugaison) Mettre au-dessus, aimer mieux, se déterminer en faveur d’une personne, d’une chose plutôt que d’une autre.

"Au dessus", "se déterminer", "plutôt". Je ne vois pas de "aussi" ou de "complémentaire". Peut-être veux-tu changer ta phrase pour en écrire une qui reflète vraiment ce que tu veux dire, du coup ?

Oui donc tu as raisons. Bravo! Je fais une propagande pour ne pas lire RWO, pour ne pas utiliser Core et Async.

Je suis un réactionnaire qui oblige les gens à lire LLC pour apprendre OCaml, qui veut la suprématie de Lwt et de Batteries dans la communauté OCaml.

Mon avis n'a donc pas de valeur et il semble que tu sois infaillible et que j'ai fondamentalement tort. Il aura fallu pas mal de post pour en arriver à cette conclusion, félicitation.

EDIT: et oui le monde n'est pas aussi binaire comme tu le dis, et c'est bien dommage qu'on me fasse un procès d'intention pour quelque chose de si spécifique et protéiforme que mon point de vue personnel alors, qu'à le base, je voulais juste aider. Mais bon, même ma réponse ne semble suffire à ton esprit cartésien omniscient. Dans ces conditions, je préfère autant me tromper.

Peut-être, ou sinon :

Peut-être veux-tu changer ta phrase pour en écrire une qui reflète vraiment ce que tu veux dire, du coup ?