On a bien les espaces insécables en typographie française...
Elles ont la même sémantique qu'une espace traditionnelle pour le compilateur (le lecteur). Et dans l'éditeur de texte, normalement, il y a un artifice pour les faire apparaitre différemment (grisé, ou n'importe).
Sans chercher à défendre GNU Make, ton éditeur de texte est incapable d’afficher espaces et tabulations différemment?
Certainement, mais là n'est pas la question ! Évidemment qu'une fois que le problème a été identifié, il est facile de trouver des solutions. Là, le problème était qu'il n'y avait aucun moyen pour un être humain d'identifier la nature du problème.
On sait tous qu'il existe pas mal de caractères qui ont des glyphes proches, voire identiques: le codage ASCII et le rendu dans les éditeurs de texte ne sont pas bijectifs. Un langage de programmation devant être lisible à la fois par un homme et par une machine, il me semble élémentaire d'utiliser une sous-partie du jeu de caractères qui est clairement bijective. Certaines réactions me donnent l'impression que certains considèrent que c'est la machine qui devrait avoir le dernier mot : l'utilisateur devrait se démerder pour utiliser un éditeur de texte avec une fonction spéciale pour distinguer visuellement des caractères habituellement identiques. C'est un point de vue que j'ai du mal à comprendre : le chef, c'est moi, c'est pas la machine.
Tiens, je vais concevoir un langage Brainfuck où seule la fonte est signifiante: g g g ggg g . Tu codes dans LibreOffice, tu copies-colles dans vi et tu exécutes. Comment? La machine ne peut pas faire la différence? Pourtant, pour moi, elle est claire! La machine n'a qu'à se démerder. C'est exactement le même processus, sauf que cette fois on donne la priorité à l'utilisateur. Ah oui, ça ne marche pas. Mais c'était pareil dans l'autre sens.
[^] # Re: Ben voyons
Posté par arnaudus . En réponse à la dépêche GNU Make 4.0 extensible. Évalué à 5.
Elles ont la même sémantique qu'une espace traditionnelle pour le compilateur (le lecteur). Et dans l'éditeur de texte, normalement, il y a un artifice pour les faire apparaitre différemment (grisé, ou n'importe).
Certainement, mais là n'est pas la question ! Évidemment qu'une fois que le problème a été identifié, il est facile de trouver des solutions. Là, le problème était qu'il n'y avait aucun moyen pour un être humain d'identifier la nature du problème.
On sait tous qu'il existe pas mal de caractères qui ont des glyphes proches, voire identiques: le codage ASCII et le rendu dans les éditeurs de texte ne sont pas bijectifs. Un langage de programmation devant être lisible à la fois par un homme et par une machine, il me semble élémentaire d'utiliser une sous-partie du jeu de caractères qui est clairement bijective. Certaines réactions me donnent l'impression que certains considèrent que c'est la machine qui devrait avoir le dernier mot : l'utilisateur devrait se démerder pour utiliser un éditeur de texte avec une fonction spéciale pour distinguer visuellement des caractères habituellement identiques. C'est un point de vue que j'ai du mal à comprendre : le chef, c'est moi, c'est pas la machine.
Tiens, je vais concevoir un langage Brainfuck où seule la fonte est signifiante: g g g g g
gg . Tu codes dans LibreOffice, tu copies-colles dans vi et tu exécutes. Comment? La machine ne peut pas faire la différence? Pourtant, pour moi, elle est claire! La machine n'a qu'à se démerder. C'est exactement le même processus, sauf que cette fois on donne la priorité à l'utilisateur. Ah oui, ça ne marche pas. Mais c'était pareil dans l'autre sens.