"Michel Michaud" writes:Ceci dit, mon avis est que l'indentation devrait suffire à
délimiter les blocs d'instructions
c'est pythonesque ;-)
"Michel Michaud" <mm@gdzid.com> writes:
Ceci dit, mon avis est que l'indentation devrait suffire à
délimiter les blocs d'instructions
c'est pythonesque ;-)
"Michel Michaud" writes:Ceci dit, mon avis est que l'indentation devrait suffire à
délimiter les blocs d'instructions
c'est pythonesque ;-)
writes:
[...]
| Rien ici ni sur unsigned, ni sur un nom de type défini par
| l'utilisateur. Tous les deux tombent dans la catégorie «
| type-specifier », et en particulier « simple-type-specifier ».
| Décrit en §7.1.5.2, où il est bien précisé, sans ambigüité, que la
| combinaison « unsigned typedef-name » est illégal.
où vois-tu cette précision ? Le passage que tu as cité dans ton
précédent message ne le dit pas.
| Mais je remarque avec ta mauvaise fois habituelle,
c'est l'hôpital qui se fout de la charité.
| tu as négligé à citer
| tes commentaires sur la légalité de :
| typedef int I ;
| unsigned I i ;
Non, je ne l'ai pas negligé puisque le passage auquel tu répondais ci
haut le couvre. Mais, c'est vrai que pour toi il faut tout repeter.
kanze@gabi-soft.fr writes:
[...]
| Rien ici ni sur unsigned, ni sur un nom de type défini par
| l'utilisateur. Tous les deux tombent dans la catégorie «
| type-specifier », et en particulier « simple-type-specifier ».
| Décrit en §7.1.5.2, où il est bien précisé, sans ambigüité, que la
| combinaison « unsigned typedef-name » est illégal.
où vois-tu cette précision ? Le passage que tu as cité dans ton
précédent message ne le dit pas.
| Mais je remarque avec ta mauvaise fois habituelle,
c'est l'hôpital qui se fout de la charité.
| tu as négligé à citer
| tes commentaires sur la légalité de :
| typedef int I ;
| unsigned I i ;
Non, je ne l'ai pas negligé puisque le passage auquel tu répondais ci
haut le couvre. Mais, c'est vrai que pour toi il faut tout repeter.
writes:
[...]
| Rien ici ni sur unsigned, ni sur un nom de type défini par
| l'utilisateur. Tous les deux tombent dans la catégorie «
| type-specifier », et en particulier « simple-type-specifier ».
| Décrit en §7.1.5.2, où il est bien précisé, sans ambigüité, que la
| combinaison « unsigned typedef-name » est illégal.
où vois-tu cette précision ? Le passage que tu as cité dans ton
précédent message ne le dit pas.
| Mais je remarque avec ta mauvaise fois habituelle,
c'est l'hôpital qui se fout de la charité.
| tu as négligé à citer
| tes commentaires sur la légalité de :
| typedef int I ;
| unsigned I i ;
Non, je ne l'ai pas negligé puisque le passage auquel tu répondais ci
haut le couvre. Mais, c'est vrai que pour toi il faut tout repeter.
writes:Mais ça se discute si on adopte une syntaxe Algol 68 (Modula-3, et
je crois Ada). Le problème avec cette syntaxe, c'est qu'il n'y pas
toujours une ouverture explicite -- c'est le then de l'if ou le do
de while ou de for qui ouvre un bloc.
Si j'ai bonne memoire Algol 68 a besoin d'une ouverture explicite (et
on peut utiliser { et } toujours si ma memoire est bonne meme si
.begin et .end etaient plus courant dans l'usage que j'ai vu -- Algol
68 est un langage amusant qui definit un langage de base et la
possibilite pour chaque implementation d'avoir son langage de
representation, le choix { ou .begin ou ( fait partie du langage de
representation). Ada et Modula 3 (Modula 2, oberon aussi si j'ai bonne
memoire, en fait tout les representants recents) ont une ouverture
implicite.
Apparamment, aussi, il y aurait des avantages à utiliser des end
différents selon le type de bloc, du genre :
if ( condition ) then statements endif ;
while ( condition ) do statements enddo ;
etc.
Mais je n'ai pas un fort avis sur la question.
Ada utilise "end if" "end loop", l'avantage est un avantage de
diagnostic en cas d'erreur et de documentation (j'ai vu des gens
commenter toute } avec la structure qu'elle ferme).
le = pour l'affectation,
Intuitivement, je verrais = pour la comparaison, et donc quelque
chose d'autre (:=, <-, etc.) pour l'affectation. Mais là non plus,
je n'ai pas d'avis très fort. L'importance, pour que l'affectation
multiple fonction, c'est que l'affectation ne soit pas un opérateur
comme les autres. Ce qui est un grand écart par rapport à la famille
C.le type avant la variable,
Mais c'est là précisement la source du problème.
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
J'avoue que j'allais plus loin. Les valeurs de rétour d'une
fonction, c'était des variables prédéfinies dans la fonction. Il n'y
avait pas de return (ni de break, ni de goto, ni de continue).
Je connais quelques methodes
return
nom de la fonction (comme en Pascal, pose un probleme avec la
recursivite)
mot cle reserve/variable predefinie (comme en Eiffel)
variable de retour explicitement definie (comme la defunte
extention de g++)
Si tu veux des retours multiples, je crois que pouvoir les nommer est
un avantage. (De meme pour le this, Ada, Oberon permettent de le
nommer explicitement; peu d'avatange quand on a un dispatching simple
comme en C++ -- et dans ces langages d'ailleurs, sauf que ca donne le
choix sur le type de this pointeur, reference ou valeur ce qui peut
aider les optimisations quand l'objet tient dans un registre -- mais
uniformise la syntaxe -- pour Ada, pas pour Oberon -- et ouvre la voie
au dispatch multiple).De même pour les tableaux :
double[] da;
Tu n'aurais pas fait du Java ?
En fait, non. Je me disais bien que cette syntaxe me rappelait quelque
chose.Pourquoi pas :
variable da : array [] of double ;
Plus de trente lettres contre une douzaine...
Plus facile à lire. Alors, tu écris un programme une fois, mais il
sera lu une multitude de fois. Il faut donc priviléger la lecture.
Sur le sujet, vous faite des tableaux multiples, des tableaux de
tableaux ou les deux?
kanze@gabi-soft.fr writes:
Mais ça se discute si on adopte une syntaxe Algol 68 (Modula-3, et
je crois Ada). Le problème avec cette syntaxe, c'est qu'il n'y pas
toujours une ouverture explicite -- c'est le then de l'if ou le do
de while ou de for qui ouvre un bloc.
Si j'ai bonne memoire Algol 68 a besoin d'une ouverture explicite (et
on peut utiliser { et } toujours si ma memoire est bonne meme si
.begin et .end etaient plus courant dans l'usage que j'ai vu -- Algol
68 est un langage amusant qui definit un langage de base et la
possibilite pour chaque implementation d'avoir son langage de
representation, le choix { ou .begin ou ( fait partie du langage de
representation). Ada et Modula 3 (Modula 2, oberon aussi si j'ai bonne
memoire, en fait tout les representants recents) ont une ouverture
implicite.
Apparamment, aussi, il y aurait des avantages à utiliser des end
différents selon le type de bloc, du genre :
if ( condition ) then statements endif ;
while ( condition ) do statements enddo ;
etc.
Mais je n'ai pas un fort avis sur la question.
Ada utilise "end if" "end loop", l'avantage est un avantage de
diagnostic en cas d'erreur et de documentation (j'ai vu des gens
commenter toute } avec la structure qu'elle ferme).
le = pour l'affectation,
Intuitivement, je verrais = pour la comparaison, et donc quelque
chose d'autre (:=, <-, etc.) pour l'affectation. Mais là non plus,
je n'ai pas d'avis très fort. L'importance, pour que l'affectation
multiple fonction, c'est que l'affectation ne soit pas un opérateur
comme les autres. Ce qui est un grand écart par rapport à la famille
C.
le type avant la variable,
Mais c'est là précisement la source du problème.
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
J'avoue que j'allais plus loin. Les valeurs de rétour d'une
fonction, c'était des variables prédéfinies dans la fonction. Il n'y
avait pas de return (ni de break, ni de goto, ni de continue).
Je connais quelques methodes
return
nom de la fonction (comme en Pascal, pose un probleme avec la
recursivite)
mot cle reserve/variable predefinie (comme en Eiffel)
variable de retour explicitement definie (comme la defunte
extention de g++)
Si tu veux des retours multiples, je crois que pouvoir les nommer est
un avantage. (De meme pour le this, Ada, Oberon permettent de le
nommer explicitement; peu d'avatange quand on a un dispatching simple
comme en C++ -- et dans ces langages d'ailleurs, sauf que ca donne le
choix sur le type de this pointeur, reference ou valeur ce qui peut
aider les optimisations quand l'objet tient dans un registre -- mais
uniformise la syntaxe -- pour Ada, pas pour Oberon -- et ouvre la voie
au dispatch multiple).
De même pour les tableaux :
double[] da;
Tu n'aurais pas fait du Java ?
En fait, non. Je me disais bien que cette syntaxe me rappelait quelque
chose.
Pourquoi pas :
variable da : array [] of double ;
Plus de trente lettres contre une douzaine...
Plus facile à lire. Alors, tu écris un programme une fois, mais il
sera lu une multitude de fois. Il faut donc priviléger la lecture.
Sur le sujet, vous faite des tableaux multiples, des tableaux de
tableaux ou les deux?
writes:Mais ça se discute si on adopte une syntaxe Algol 68 (Modula-3, et
je crois Ada). Le problème avec cette syntaxe, c'est qu'il n'y pas
toujours une ouverture explicite -- c'est le then de l'if ou le do
de while ou de for qui ouvre un bloc.
Si j'ai bonne memoire Algol 68 a besoin d'une ouverture explicite (et
on peut utiliser { et } toujours si ma memoire est bonne meme si
.begin et .end etaient plus courant dans l'usage que j'ai vu -- Algol
68 est un langage amusant qui definit un langage de base et la
possibilite pour chaque implementation d'avoir son langage de
representation, le choix { ou .begin ou ( fait partie du langage de
representation). Ada et Modula 3 (Modula 2, oberon aussi si j'ai bonne
memoire, en fait tout les representants recents) ont une ouverture
implicite.
Apparamment, aussi, il y aurait des avantages à utiliser des end
différents selon le type de bloc, du genre :
if ( condition ) then statements endif ;
while ( condition ) do statements enddo ;
etc.
Mais je n'ai pas un fort avis sur la question.
Ada utilise "end if" "end loop", l'avantage est un avantage de
diagnostic en cas d'erreur et de documentation (j'ai vu des gens
commenter toute } avec la structure qu'elle ferme).
le = pour l'affectation,
Intuitivement, je verrais = pour la comparaison, et donc quelque
chose d'autre (:=, <-, etc.) pour l'affectation. Mais là non plus,
je n'ai pas d'avis très fort. L'importance, pour que l'affectation
multiple fonction, c'est que l'affectation ne soit pas un opérateur
comme les autres. Ce qui est un grand écart par rapport à la famille
C.le type avant la variable,
Mais c'est là précisement la source du problème.
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
J'avoue que j'allais plus loin. Les valeurs de rétour d'une
fonction, c'était des variables prédéfinies dans la fonction. Il n'y
avait pas de return (ni de break, ni de goto, ni de continue).
Je connais quelques methodes
return
nom de la fonction (comme en Pascal, pose un probleme avec la
recursivite)
mot cle reserve/variable predefinie (comme en Eiffel)
variable de retour explicitement definie (comme la defunte
extention de g++)
Si tu veux des retours multiples, je crois que pouvoir les nommer est
un avantage. (De meme pour le this, Ada, Oberon permettent de le
nommer explicitement; peu d'avatange quand on a un dispatching simple
comme en C++ -- et dans ces langages d'ailleurs, sauf que ca donne le
choix sur le type de this pointeur, reference ou valeur ce qui peut
aider les optimisations quand l'objet tient dans un registre -- mais
uniformise la syntaxe -- pour Ada, pas pour Oberon -- et ouvre la voie
au dispatch multiple).De même pour les tableaux :
double[] da;
Tu n'aurais pas fait du Java ?
En fait, non. Je me disais bien que cette syntaxe me rappelait quelque
chose.Pourquoi pas :
variable da : array [] of double ;
Plus de trente lettres contre une douzaine...
Plus facile à lire. Alors, tu écris un programme une fois, mais il
sera lu une multitude de fois. Il faut donc priviléger la lecture.
Sur le sujet, vous faite des tableaux multiples, des tableaux de
tableaux ou les deux?
Il me semble avoir lu une étude quelque part que les débuttants
faisaient moins d'erreurs avec les fermatures typées. J'avoue être
sceptique sur la différence que ça pourrait faire si les fonctions sont
convenablement petites.
Évidemment, si tu codes des fonctions de 400 lignes, avec 10 niveaux
d'imbrication, j'imagine qu'une indication de ce qu'on ferme pour être
util:-).
Il me semble avoir lu une étude quelque part que les débuttants
faisaient moins d'erreurs avec les fermatures typées. J'avoue être
sceptique sur la différence que ça pourrait faire si les fonctions sont
convenablement petites.
Évidemment, si tu codes des fonctions de 400 lignes, avec 10 niveaux
d'imbrication, j'imagine qu'une indication de ce qu'on ferme pour être
util:-).
Il me semble avoir lu une étude quelque part que les débuttants
faisaient moins d'erreurs avec les fermatures typées. J'avoue être
sceptique sur la différence que ça pourrait faire si les fonctions sont
convenablement petites.
Évidemment, si tu codes des fonctions de 400 lignes, avec 10 niveaux
d'imbrication, j'imagine qu'une indication de ce qu'on ferme pour être
util:-).
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
Est-ce que tu permettras les declarations dans la fonction ? Si oui,
comment distinguer entre une declaration et une affectation ou une
expression (sans avoir tout parsé, évidemment).
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
Est-ce que tu permettras les declarations dans la fonction ? Si oui,
comment distinguer entre une declaration et une affectation ou une
expression (sans avoir tout parsé, évidemment).
Perso dans mes fantasmes de definition d'un nouveau langage, c'est
identifieur : definition
pour tout (variable, type, fonction, block...) -- comme en Eiffel mais
peut-etre encore plus pousse au rang de principe de conception.
Est-ce que tu permettras les declarations dans la fonction ? Si oui,
comment distinguer entre une declaration et une affectation ou une
expression (sans avoir tout parsé, évidemment).
Dans news:,Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à dix
C'est quoi ta définition exacte de « savoir taper » ?
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Ça me prend donc à peu près le même temps que taper un Q, un ( ou un
è.parle encore d'un clavier US -- avec un clavier français, c'est
pire. (Or que tu veux bien des accents dans les commentaires,
n'est-ce pas.)
Mauvais clavier, changer de clavier :-)
Ceci dit, mon avis est que l'indentation devrait suffire à délimiter
les blocs d'instructions (inversement, un éditeur intelligent en C++,
devrait mettre les {} automatiquement).
Dans news:d6652001.0309232330.2f0f008c@posting.google.com,
Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à dix
C'est quoi ta définition exacte de « savoir taper » ?
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Ça me prend donc à peu près le même temps que taper un Q, un ( ou un
è.
parle encore d'un clavier US -- avec un clavier français, c'est
pire. (Or que tu veux bien des accents dans les commentaires,
n'est-ce pas.)
Mauvais clavier, changer de clavier :-)
Ceci dit, mon avis est que l'indentation devrait suffire à délimiter
les blocs d'instructions (inversement, un éditeur intelligent en C++,
devrait mettre les {} automatiquement).
Dans news:,Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à dix
C'est quoi ta définition exacte de « savoir taper » ?
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Ça me prend donc à peu près le même temps que taper un Q, un ( ou un
è.parle encore d'un clavier US -- avec un clavier français, c'est
pire. (Or que tu veux bien des accents dans les commentaires,
n'est-ce pas.)
Mauvais clavier, changer de clavier :-)
Ceci dit, mon avis est que l'indentation devrait suffire à délimiter
les blocs d'instructions (inversement, un éditeur intelligent en C++,
devrait mettre les {} automatiquement).
"Michel Michaud" wrote in message
news:<bNhcb.6135$...Dans news:,Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à
dix
C'est quoi ta définition exacte de « savoir taper » ?
La même chose que ça veut dire pour une secrétaire. Il existe des
cours de dactylographie pour ceux qui veulent.
En fin de compte, un professionnel, quelque soit le domaine, sait se
servir de ses outils. Et le clavier, c'est bien un outil important
pour la plupart des programmeurs.
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Et où se trouve ce AltCar ? Est-ce que tu peux l'utiliser
regulièrement sans risques des problèmes du tunnel carpien ? Sur
mon clavier Sun (US), le } se trouve déjà bien loin de la position
de base, et exige une extension du petit doigt qui ne doit pas
faire du bien à la longue.
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<bNhcb.6135$yD1.985344@news20.bellglobal.com>...
Dans news:d6652001.0309232330.2f0f008c@posting.google.com,
Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à
dix
C'est quoi ta définition exacte de « savoir taper » ?
La même chose que ça veut dire pour une secrétaire. Il existe des
cours de dactylographie pour ceux qui veulent.
En fin de compte, un professionnel, quelque soit le domaine, sait se
servir de ses outils. Et le clavier, c'est bien un outil important
pour la plupart des programmeurs.
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Et où se trouve ce AltCar ? Est-ce que tu peux l'utiliser
regulièrement sans risques des problèmes du tunnel carpien ? Sur
mon clavier Sun (US), le } se trouve déjà bien loin de la position
de base, et exige une extension du petit doigt qui ne doit pas
faire du bien à la longue.
"Michel Michaud" wrote in message
news:<bNhcb.6135$...Dans news:,Il ne faut pas oublier non plus que pour peu qu'on sait tapper (ce
que doit savoir tout programmeur), on tappe des lettres jusqu'à
dix
C'est quoi ta définition exacte de « savoir taper » ?
La même chose que ça veut dire pour une secrétaire. Il existe des
cours de dactylographie pour ceux qui veulent.
En fin de compte, un professionnel, quelque soit le domaine, sait se
servir de ses outils. Et le clavier, c'est bien un outil important
pour la plupart des programmeurs.
fois plus vite que les caractères spéciaux. Je sais qu'il me faut
moins de temps à tapper « begin » que de tapper un « { ». Et je
Pas moi. AltCar+` me donne un }, c'est seulement deux touches.
Et où se trouve ce AltCar ? Est-ce que tu peux l'utiliser
regulièrement sans risques des problèmes du tunnel carpien ? Sur
mon clavier Sun (US), le } se trouve déjà bien loin de la position
de base, et exige une extension du petit doigt qui ne doit pas
faire du bien à la longue.
