Lisp et Ti - Page 2

HIPPO: je suis pas d'accord sur le point de vue des parentheses, les parentheses si elle sont utilisé servent a enlever toute ambiguité de sens

Par exemple l'expression :

a = 1 - 2 - 3
peut etre egale a
a = (1 - 2) - 3
ou
a = 1 - (2 - 3)
Qui n'on pas du tout le meme sens !

Tu me dira qu'on a affaire une associativité a gauche habituellement. ok ! mais pq on pourrait pas le faire a droite ??

Les parentheses sont loin d'etre inutiles, et sont au contraire généralement d'un gd secours, quelque soit le language, permettant une compréhension plus aisé des expression complexes. (mais bon faut pas tomber dans l'excé de parentheses lol ni ecrire comme une porcasse) faut respecter un minimum de style d'écriture, surtout en C d'ailleur..

Les parenthèses sont à supprimer au maximum, tant que l'expression reste non ambigue.

f(1,2) => f 1 2

3*(f(x)+g(y)) => 3*(f x + g y)

(1-2)-3 => 1-2-3

HIPPOPOTAME a écrit :
Non. (enfin tu peux donner le sens que tu veux à « pas mal »)

Ben, je trouve que:
If x<0 Then
x=1
EndIf
ou:
if (x<0) then begin
x=1;
end
n'est pas si différent que ça de:
if (x<0) {
x=1;
}
Par rapport au Pascal, dans cet exemple, il y a juste un mot-clé supprimé (car inutile) et 3 mots-clés transformés en symboles.

1) Les réponse style « on peut », c'est pas des réponse quand, dans la pratique, « on a pas ».

Ça dépend. Parfois, il n'est pas si dur que ça de la coder toi-même. Et après, tu pourras l'utiliser dans tous tes projets. Cf. ci-dessous pour les chaînes de caractères.

Caml est aussi efficace que le C, la complication en moins.

Pas sûr...

Elles ne sont pas écrites, ou pas connues, ou pas standard. Bref.

Mais ça prend 10 minutes d'en écrire une toi-même:

char numstrings=0;
char **strtab=0;
typedef int string;

string new_string(const char *v)
{
  numstrings++;
  strtab=realloc(strtab,numstrings*sizeof(char*));
  strtab[numstrings-1]=malloc(strlen(v)+1);
  strcpy(strtab[numstrings-1],v);
  return numstrings-1;
}

void delete_string(string s)
{
  if (s<0||s>=numstrings) return;
  if (strtab[s]) {free(strtab[s]);strtab[s]=0;}
}

char *string_value(string s)
{
  if (s<0||s>=numstrings) return 0;
  else return strtab[s];
}

string string_copy(string dest, string src)
{
  if (dest<0||dest>=numstrings||src<0||src>=numstrings) return -1;
  delete_string(dest);
  strtab[dest]=malloc(strlen(strtab[src])+1);
  strcpy(strtab[dest],strtab[src]);
  return dest;
}

string string_concat(string dest, string src)
{
  if (dest<0||dest>=numstrings||src<0||src>=numstrings) return -1;
  if (!(strtab[dest])) return string_copy(dest,src);
  strtab[dest]=realloc(strtab[dest],strlen(strtab[dest])+strlen(strtab[src])+1);
  strcat(strtab[dest],strtab[src]);
  return dest;
}

(Attention, je n'ai pas testé ces routines, je les ai écrites directement ici.)
Où est le problème?

Plus dur que si c'était fait intelligemment.

Tu entends quoi par "intelligemment"? Le système C est très pratique parce qu'il suffit de penser à la manière de laquelle on accèdera à la variable pour comprendre sa déclaration.

Il faut tuer les parenthèses.
Les parenthèses sont un fléau de l'informatique. D'ailleurs, dans caml, on en met le moins possible. Pourquoi écrire f(x) quand on peut se contenter de f x ? Un charme de plus de caml

Et vive le code illisible...

Non.
L'informatique actuelle est ravagée aussi bien au niveau hard qu'au niveau soft par des programmeurs porcs qui n'en font qu'à leur tête et ne respectent pas les standards. Sur PC, le programmeur doit faire les choses proprement pour assurer la compatibilité, et parce que les processeurs sont conçus pour optimiser l'exécution des codes propres. Le C est trop permissif, il faut sévir.

Je ne suis pas du tout d'accord. Le programmeur est en général () plus intelligent que le compilateur, donc c'est au programmeur d'avoir le dernier mot. Pour la compatibilité, GCC compile pour une vaste rangée de plateformes, donc je ne vois pas l'intérêt de coder pour d'autres compilateurs. Quant au fait que, selon toi, "les processeurs s[eraie]nt conçus pour optimiser l'exécution des codes propres", cf. mon exemple de la variable initialisée d'une manière non reconnue par le compilateur.

Parce que c'est dans la nature du C d'être sale. Essaie un peu de faire ça en caml...

Ben, avec des notations de style f x, ça promet bien.

qu'entends tu par "variable initialisée"? (Je ne vois pas vraiment le rapport)

Un exemple pratique de Backgammon:

          short keypress;
          for (short i=0;i<6;i++) {
            Gray3PDBufSetActiveAMSPlane(i%3);
            DrawStr(Q(0,6),Q(46,59),"Really quit?",A_XOR);
            if (i==2) keypress=GetKeyInput();
          }
          FontSetSys(OldFont);
          if (keypress==KEY_ENTER) {victory=0;break;} else goto retry1;

Commentaire de GCC: "warning: 'keypress' might be used uninitialized in this function". Regarde la boucle pour voir à quel point ce warning est bidon! J'ai déjà rencontré un truc du même style en Java et j'ai été obligé de mettre une initialisation bidon parce que le compilateur Java (de SUN) pond une erreur plutôt qu'un warning. Vive l'efficacité du code.

1) On a le choix entre utiliser la librairie "sûre" et la librairie "rapide".

En C aussi: il y a des patches de "bound-checking" pour GCC, et GCC 3.5 ou 3.6 le supportera probablement nativement.

moué, pourquoi pas... c'est standard, en dehors de GNU?

Non. Mais cf. plus haut pour ce que je pense de la compatibilité avec d'autres compilateurs.

C'est pratique, inutile, et peu lisible.

Ce n'est pas inutile, et c'est très lisible si on vient de l'assembleur (comme c'est mon cas).

Un compilateur digne de ce nom trouve tout seul le meilleur mode d'adressage.

Évidemment que GCC le trouvera lui-même lui aussi.

Le programmeur qui programme en langage TRUC n'a pas à s'occuper du hardware sous jacent (qu'il ne connait pas) mais à programmer en TRUC, point!

C'est bien le cas pour le C. Par exemple, tu peux utiliser *(++x) alors que le mode d'adressage +(an) n'existe pas sur 68k (juste -(an) et (an)+).

En C, la ou plutôt les fonctions * servent de multiplication entière, de multiplication réelle, de déréférencement. Trois usages différents, donc deux de trop.

1. Une multiplication est une multiplication. Les nombres à virgule flottante sont dans la même hiérarchie de types que les nombres entiers. Le type choisi en l'absence de transtypages explicits sera le type le plus large, et les types flottants sont considérés comme "plus larges" que les types entiers.
2. Quel est le problème si le même opérateur est utilisé différemment en unaire et en binaire? C'est un contexte différent!

Du point de vue du programmeur, c'est malpropre. Du point de vue du compilateur, ce n'est pas très bon pour l'efficacité.

Pas vraiment. Il sait encore distinguer un opérateur unaire d'un opérateur binaire...

Sans compter les conneries du genre *=

C'est:
1. un opérateur différent que *
2. plus court et moins redondant que x=x*(...)
3. pas inutile si on considère les effets de bord, par exemple: *(x++)*=y;
4. plus acceptable du point de vue mathématique qu'une horreur de style x=x*2, ou pire: x=x+1

HIPPOPOTAME
a écrit : f(1,2) => f 1 2

Oula, je sens qu'il y a des bases pour une compétition de "obfuscated CAML"...

Mais non, mais non, c'est très lisible, si on fait attention à ce qu'on écrit. Et ça force à faire bien attention à sa syntaxe.
Caml Powaaaaaaa !!!!!!

Au fait, le Unlambda ça a l'air , faut que j'essaye :

3 s'écrit : ``s``s`ksk``s``s`kski

`d````````````.H.e.l.l.o.,. .w.o.r.l.d.! k k `k``s``s`ksk`k.*

Voila l'exemple de comment écrire une boucle qui écrit Hello World suivi d'une astérisques, puis deux, puis trois, etc...```s``sii`ki
 ``s``s`ks
     ``s``s`ks``s`k`s`kr
               ``s`k`si``s`k`s`k
      

Il ya aussi un script qui parait puissant (jamais utilisé) et qui peut être integré au C/C++
En cherchant sur le net G trouvé ça comme commentaire pour le lua

"Le meilleur langage de scripting du monde. Oubliez Python, LUA est deux fois plus rapide, et est super facilement intégrable dans un projet C/C++. Jettez un coup d'oeil au shell d'Orion3D !"

et voila la page d'accueil du Lua:
http://www.lua.org
Je me demande s'il est possible de l'adapter pour l'utiliser avec tigcc Nan ???

Ben, je trouve que:
If x<0 Then x=1 EndIf
ou:
if (x<0) then begin x=1; end
n'est pas si différent que ça de:
if (x<0) { x=1; } Par rapport au Pascal, dans cet exemple, il y a juste un mot-clé supprimé (car inutile) et 3 mots-clés transformés en symboles.

Mauvaise foi...

for (short i=0;i<6;i++) {
  Gray3PDBufSetActiveAMSPlane(i%3);
  DrawStr(Q(0,6),Q(46,59),"Really quit?",A_XOR);
  if (i==2) keypress=GetKeyInput();
}

ne ressemble de près ou de loin ni au basic ni au pascal.

>>> Caml est aussi efficace que le C, la complication en moins. Pas sûr...

http://www.bagley.org/~doug/shootout/craps.shtml

Où est le problème?

Une quarantaine de lignes de code pour rien.

Tu entends quoi par "intelligemment"? Le système C est très pratique parce qu'il suffit de penser à la manière de laquelle on accèdera à la variable pour comprendre sa déclaration.

Le système C n'est pas très pratique du tout. C'est un mélange affreux de notation préfixée et postfixée avec des règles de priorité chiantes. D'ailleurs, ça coince toujours les débutants.
Quant à « la manière avec laquel on accèdera à la variable », c'est un prétexte. On pouvait faire différemment (mais le C est un empilage de trucs qui n'ont pas été pensés globalement...)

Le plus simple est encore de ne pas déclarer les types, comme en caml.

Et vive le code illisible...

Du code illisible c'est ça :

void Miam_Pic16_OR(unsigned short *s,short x,short y,void *v)
{
register char *z=v+(y<<5)-(y<<1)+(x<0?-((1-(x>>3))&30):(x>>3)&30);
...
}

Du code lisible et joli c'est ça :
let compose f g = function x -> f (g x);;


D'autre part, si ça ne te plaît pas d'écrire f x au lieu de f(x), tu dois bien te rendre compte que pour caml, x est équivalent à (x). Donc tu peux très bien écrire f(x) ou même (((f((((x))))))) si ça te chante...

Pour la compatibilité, GCC compile pour une vaste rangée de plateformes, donc je ne vois pas l'intérêt de coder pour d'autres compilateurs.

L'intérêt est des compilateurs divers et variés et pas juste une usine à gaz unique.

Quant au fait que, selon toi, "les processeurs s[eraie]nt conçus pour optimiser l'exécution des codes propres", cf. mon exemple de la variable initialisée d'une manière non reconnue par le compilateur.

Les compilateurs suivent les processeurs et les processeurs suivent les compilateurs. Les deux ont besoin de supposer que le code est raisonnablement propre pour avoir les meilleures performances. c'est ainsi que la dernière génération de proc est bien mauvaise avec le code automodifiant.
Ton exemple ne me convainct pas. Le C râle pour rien.

Ben, avec des notations de style f x, ça promet bien.

wishful thinking.
caml est beaucoup plus clair que du C.

Commentaire de GCC: "warning: 'keypress' might be used uninitialized in this function". Regarde la boucle pour voir à quel point ce warning est bidon! J'ai déjà rencontré un truc du même style en Java et j'ai été obligé de mettre une initialisation bidon parce que le compilateur Java (de SUN) pond une erreur plutôt qu'un warning. Vive l'efficacité du code.

Caml ne mettrait pas d'erreur de toute façon, car ce problème n'existe pas.
Et, chose très appréciable, il n'y a pas de goto en caml, donc il faudrait reprendre ton code.

Non. Mais cf. plus haut pour ce que je pense de la compatibilité avec d'autres compilateurs.

Qu'est ce que tu penses des programmeur C qui utilisent les mots clés spécifiques à certains compilateurs, genre UInt32 ?
Et bien là, le problème est le même mais dans l'autre sens.

et c'est très lisible si on vient de l'assembleur (comme c'est mon cas).

C'est donc tout à fait illisible quand on ne vient pas de l'assembleur (ce qui n'est pas mon cas, mais ce qui est le cas d'une majorité de débutants).

C'est bien le cas pour le C. Par exemple, tu peux utiliser *(++x) alors que le mode d'adressage +(an) n'existe pas sur 68k (juste -(an) et (an)+).

Tout le C est quand même orienté pour mimer l'assembleur. C'était moderne il y a 20 ans, c'est dépassé aujourd'hui.

1. Une multiplication est une multiplication.

une multiplication float*float est fondamentalement différente d'une multiplication int*int. D'ailleurs, en caml, ce n'est pas le même symbole d'opération.

Les nombres à virgule flottante sont dans la même hiérarchie de types que les nombres entiers. Le type choisi en l'absence de transtypages explicits sera le type le plus large, et les types flottants sont considérés comme "plus larges" que les types entiers.

C'est encore une faute de goût du C.

2. Quel est le problème si le même opérateur est utilisé différemment en unaire et en binaire? C'est un contexte différent!

C'est le même contexte, celui d'une expression.
et 2**x c'est fort moche.

Pas vraiment. Il sait encore distinguer un opérateur unaire d'un opérateur binaire...

Il sait faire.
Mais il fatigue, le pauvre compilateur.

3. pas inutile si on considère les effets de bord, par exemple: *(x++)*=y;

Ce serait donc inutile si on virait ces #@\[ d'effets de bord.

4. plus acceptable du point de vue mathématique qu'une horreur de style x=x*2, ou pire: x=x+1

Le C accepte quand même ces horreurs!
Mais le plus joli est encore de mettre un let ou des références.
let x = x*2;;
x:= !x*2;
let x = x+1;;
x:= !x+1; ou inc x, tout simplement.

f(1,2) => f 1 2
Oula, je sens qu'il y a des bases pour une compétition de "obfuscated CAML"...

wishful thinking.
ça n'existe pas et ça n'existera jamais.

HIPPOPOTAME a écrit :
Du code illisible c'est ça :

void Miam_Pic16_OR(unsigned short *s,short x,short y,void *v)
{
register char *z=v+(y<<5)-(y<<1)+(x<0?-((1-(x>>3))&30):(x>>3)&30);
...
}

Certes il manque des espaces
Mais j'aimerais bien que tu m'explique ou t'as obtenu ce bout de code !

HIPPOPOTAME a écrit :
Mauvaise foi...

for (short i=0;i<6;i++) {
  Gray3PDBufSetActiveAMSPlane(i%3);
  DrawStr(Q(0,6),Q(46,59),"Really quit?",A_XOR);
  if (i==2) keypress=GetKeyInput();
}

ne ressemble de près ou de loin ni au basic ni au pascal.

For i%=0 To 5
  Gray3PDBufSetActiveAMSPlane i Mod 3
  DrawStr Q(0,6),Q(46,59),"Really quit?",A_XOR
  If i=2 Then keypress=GetKeyInput()
Next

Ce n'est évidemment pas tout à fait pareil (sinon ça serait le même langage!), mais ce n'est pas si différent que ça.

http://www.bagley.org/~doug/shootout/craps.shtml

C gcc 752 0 Ocaml ocaml 751 0

Bref, ta page vient de montrer que GCC est mieux. Et en plus, c'est une très vieille version de GCC (3.0), l'optimisation a été nettement améliorée depuis.

Une quarantaine de lignes de code pour rien.

Tu l'écris une fois (en 10 minutes), et on n'en parle plus.

Le système C n'est pas très pratique du tout. C'est un mélange affreux de notation préfixée et postfixée avec des règles de priorité chiantes. D'ailleurs, ça coince toujours les débutants.

Ça coince ceux qui ne connaissent pas l'astuce de penser à la manière de laquelle on accèdera à la variable. Une fois qu'on connaît l'astuce, il suffit de savoir penser logiquement.

Quant à « la manière avec laquel on accèdera à la variable », c'est un prétexte. On pouvait faire différemment (mais le C est un empilage de trucs qui n'ont pas été pensés globalement...)

Mais pourquoi faire différemment? La méthode du C est la plus logique.

Le plus simple est encore de ne pas déclarer les types, comme en caml.

Beurk! C'est à la fois sale et inefficace, ça.

Du code illisible c'est ça :

void Miam_Pic16_OR(unsigned short *s,short x,short y,void *v)
{
register char *z=v+(y<<5)-(y<<1)+(x<0?-((1-(x>>3))&30):[i][/i](x>>3)&30);
...
}

Et comment coderais tu la même chose en CAML? Probablement pas de manière beaucoup plus lisible... Et ne triche pas en transformant les shifts en multiplications, on peut faire la même chose en C:

void Miam_Pic16_OR(unsigned short *s,short x,short y,void *v)
{
register char *z=v+y*30+(x<0?-((1-x/8)&30):[i][/i](x/8)&30);
...
}

mais c'est moins efficace.

Du code lisible et joli c'est ça :
let compose f g = function x -> f (g x);;

Sauf que ça n'a aucun rapport avec l'autre code...

D'autre part, si ça ne te plaît pas d'écrire f x au lieu de f(x), tu dois bien te rendre compte que pour caml, x est équivalent à (x). Donc tu peux très bien écrire f(x) ou même (((f((((x))))))) si ça te chante...

Certes, mais pourquoi permettre d'écrire f x? Ça donne facilement du code illisible.

L'intérêt est des compilateurs divers et variés et pas juste une usine à gaz unique.

Mais pourquoi? GCC est très portable, donc un programme écrit en GNU C est automatiquement très portable.

Les compilateurs suivent les processeurs et les processeurs suivent les compilateurs. Les deux ont besoin de supposer que le code est raisonnablement propre pour avoir les meilleures performances. c'est ainsi que la dernière génération de proc est bien mauvaise avec le code automodifiant.

Mais le code automodifiant est une autre forme de "saleté" que celles dont je parlais.

Ton exemple ne me convainct pas. Le C râle pour rien.

Mais alors, le compilateur est censé faire quoi s'il ne peut pas déterminer qu'une variable est initialisée correctement? Initialiser automatiquement la variable à une valeur arbitraire (0?). Ben, dans ce cas, ce n'est pas mieux du point de vue efficacité de code que de le faire faire à l'utilisateur!

wishful thinking. caml est beaucoup plus clair que du C.

Ben, j'ai jeté un coup d'œil sur les exemples de code dans le bench que tu m'as indiqué, et je trouve qu'ils manquent vraiment cruellement de parenthèses.

Caml ne mettrait pas d'erreur de toute façon, car ce problème n'existe pas.

Comment ça, il n'existe pas? Il initialise automatiquement à une valeur arbitraire?

Et, chose très appréciable, il n'y a pas de goto en caml, donc il faudrait reprendre ton code.

Beurk! C'est donc carrément un langage inutilisable. J'ai aussi horreur du Java pour ça. L'absence de goto oblige souvent à écrire du code très lourd à lire et très inefficace. Par exemple, on est souvent obligés de copier-coller du code à plusieurs endroits alors qu'il aurait suffit d'y sauter.

Qu'est ce que tu penses des programmeur C qui utilisent les mots clés spécifiques à certains compilateurs, genre UInt32 ?

#define UInt32 unsigned long et le problème est règlé. C'est un grand avantage des macros.

C'est donc tout à fait illisible quand on ne vient pas de l'assembleur (ce qui n'est pas mon cas, mais ce qui est le cas d'une majorité de débutants).

Je trouve que *(x++) est une notation très intéressante à la quelle il faut savoir s'habituer.

Tout le C est quand même orienté pour mimer l'assembleur. C'était moderne il y a 20 ans, c'est dépassé aujourd'hui.

Malheureusement.

une multiplication float*float est fondamentalement différente d'une multiplication int*int. D'ailleurs, en caml, ce n'est pas le même symbole d'opération.

Une multiplication est toujours une multiplication! C'est débile d'utiliser 2 symboles différents!

C'est encore une faute de goût du C.

Je ne vois pas pourquoi. Pour moi, c'est le fait d'utiliser 2 symboles différents qui est une faute de goût. Et les créateurs du BASIC, du Pascal et du Java (à titre d'exemples) sont tous d'accord avec moi. À la limite, pour la division, on peut envisager 2 symboles différents pour que la division tronquante ne soit pas celle choisie par défaut même quand on divise 2 entiers (c'est ce que font le BASIC et le Pascal). Mais pour la multiplication, je ne vois carrément pas l'intérêt.

C'est le même contexte, celui d'une expression. et 2**x c'est fort moche.

C'est très moche, surtout parce que ça veut dire autre chose en C++ qu'en C! (Ça veut dire 2^x en C++!) Tout programmeur C qui se respecte mettra des parenthèses: 2*(*x) ou 2 * (*x), ou au moins des espaces: 2 * *x.

Il sait faire. Mais il fatigue, le pauvre compilateur.

Alors là pas du tout. Même un parseur strictement LR sait faire la distinction.

Ce serait donc inutile si on virait ces #@\[ d'effets de bord.

Mais ces effets de bord sont très pratiques si on sait les utiliser!

Le C accepte quand même ces horreurs!

Mais il ne t'oblige pas à l'utiliser.

Mais le plus joli est encore de mettre un let ou des références.
let x = x*2;;
x:= !x*2;
let x = x+1;;
x:= !x+1; ou inc x, tout simplement.

let = un mot clé inutile.
:=, soit, mais x := x+2 n'a pas beaucoup de sens en mathématiques non plus. (C'est une définition circulaire.)

Et d'ailleurs, si le CAML est tellement meilleur que le C, alors explique-moi pourquoi le "compilateur natif" de OCAML se contente de convertir le programme OCAML en un programme C.

Kevin Kofler a écrit :

void Miam_Pic16_OR(unsigned short *s,short x,short y,void *v)
{
register char *z=v+y*30+(x<0?-((1-x/8)&30):[i][/i](x/8)&30);
...
}

Tant qu'à dé-optimiser, on peut écrire :

[b][12]register char[/12][/b] [b][7]*[/7][/b]z [b][7]=[/7][/b] v [b][7]+[/7][/b] y [b][7]*[/7][/b] 30;
[b][12]if[/12][/b] (x [7][b]<[/b][/7] 0) z [b][7]-=[/7][/b] (1 [b][7]-[/7][/b] x [b][7]/[/7][/b] 8) [7][b]&[/b][/7] 30[7][b];[/b][/7]
[12][b]else[/b][/12] z [7][b]+=[/b][/7] (x [7][b]/[/b][/7] 8) [7][b]&[/b][/7] 30[7][b];[/b][/7]

Si quelqun n'arrive toujours pas à lire ça, il peut oublier la programmation ou alors il a interet à s'accrocher. Mais je repose ma question : Telchar, ou as tu eu cette source ?

Mais j'aimerais bien que tu m'explique ou t'as obtenu ce bout de code !

Qq part sur yaronet

Ce n'est évidemment pas tout à fait pareil (sinon ça serait le même langage!), mais ce n'est pas si différent que ça.

Bref passons, tu ne voudras jamais admettre les choses les plus évidentes.

>>>C gcc 752 0
Ocaml ocaml 751 0
Bref, ta page vient de montrer que GCC est mieux.

Mais oui mais oui.
Change de 1% le barême (arbitraire) attribué aux différents tests, et caml passe devant...
En treme de performance, les deux langages sont à égalité.

Et en plus, c'est une très vieille version de GCC (3.0), l'optimisation a été nettement améliorée depuis.

Idem pour OCaml, il y a eu d'autres versions distribuées depuis.

Ça coince ceux qui ne connaissent pas l'astuce de penser à la manière de laquelle on accèdera à la variable. Une fois qu'on connaît l'astuce, il suffit de savoir penser logiquement.

Ce n'est pas pratique.

Mais pourquoi faire différemment? La méthode du C est la plus logique.

Non.

>>> Le plus simple est encore de ne pas déclarer les types, comme en caml .
Beurk! C'est à la fois sale et inefficace, ça.

C'est au contraire plus simple pour le programmeur, beaucoup plus efficace, plus propre, et ça permet un typage plus fort.

Certes, mais pourquoi permettre d'écrire f x? Ça donne facilement du code illisible.

C'est pas toi qui écrivais il y a deux ou trois posts qu'il faut autoriser le maximum à l'utilisateur? Trêve de plaisanterie...
La notation sans parenthèses est plus simple à la fois pour le compilateur et pour l'utilisateur, qui n'a pas à se fatiguer à compter les ( et les ).

>>> L'intérêt est des compilateurs divers et variés et pas juste une usine à gaz unique.
Mais pourquoi?

C'est vrai ça, mais pourquoi?
Pourquoi tant de matériel et de logiciels sont disponibles, alors que tout le monde pourrait avoir son Pentium IV + Windows XP + Word.
Je me le demande.

Mais alors, le compilateur est censé faire quoi s'il ne peut pas déterminer qu'une variable est initialisée correctement? Initialiser automatiquement la variable à une valeur arbitraire (0?). Ben, dans ce cas, ce n'est pas mieux du point de vue efficacité de code que de le faire faire à l'utilisateur!

Ne rien faire et laisser passer!

Ben, j'ai jeté un coup d'œil sur les exemples de code dans le bench que tu m'as indiqué, et je trouve qu'ils manquent vraiment cruellement de parenthèses.

Je l'aurais parié!


Et ben oui, il y a moins de parenthèses, c'est plus aéré, c'est plus clair, tout en restant absolument sans ambiguité.

Comment ça, il n'existe pas? Il initialise automatiquement à une valeur arbitraire?

Oui et non.
Les variables ne sont pas utilisées tout à fait de la même manière qu'en C, mais effectivement, une valeur est toujours donnée à une variable au moment de sa création
let x = valeur in ...;;
ou
... where x = valeur;;

Beurk! C'est donc carrément un langage inutilisable. J'ai aussi horreur du Java pour ça. L'absence de goto oblige souvent à écrire du code très lourd à lire et très inefficace. Par exemple, on est souvent obligés de copier-coller du code à plusieurs endroits alors qu'il aurait suffit d'y sauter.

Le programmeur C englué dans ses habitudes les plus sales...
La commande goto n'a qu'un usage décemment possible : ne pas être utilisée!
Enfin bon, la démonstration de boogerman était très bien, je ne vais pas la refaire.

De toute façon, un goto n'aurait aucun sens en caml! Ce n'est pas utilisable, le langage est trop fonctionnel pour ça.

Un langage incompatible avec goto, quelle plus belle preuve de propreté? #lyrique#

Je trouve que *(x++) est une notation très intéressante à la quelle il faut savoir s'habituer.

A la rigueur je suis d'accord.
Simplement, c'est un canon de l'informatique, alors que ça ne le mérite pas.

Une multiplication est toujours une multiplication! C'est débile d'utiliser 2 symboles différents!

Certainement pas!!
C'est une bonne habitude de rigueur à prendre.
(Et d'ailleurs, c'est ça qui permet à caml de typer. Contrairement au C, strictement aucun opérateur n'est surchargé.)

Je ne vois pas pourquoi. Pour moi, c'est le fait d'utiliser 2 symboles différents qui est une faute de goût.

Au passage, en ce qui concerne caml, ce n'est pas du niveau de la faute de gout, c'est tout le langage qui tombe à l'eau si on autorise des fonctions surchargées.

Et les créateurs du BASIC, du Pascal et du Java (à titre d'exemples) sont tous d'accord avec moi.

Le basic n'est pas une référence, et Java est fortement influencé par le C.
L'objection reste pertinente pour le Pascal, langage de la même époque et d'inspiration similaire.

À la limite, pour la division, on peut envisager 2 symboles différents pour que la division tronquante ne soit pas celle choisie par défaut même quand on divise 2 entiers (c'est ce que font le BASIC et le Pascal). Mais pour la multiplication, je ne vois carrément pas l'intérêt.

L'intérêt, c'est le typage puissant, propre et efficace.

C'est très moche, surtout parce que ça veut dire autre chose en C++ qu'en C! (Ça veut dire 2x en C++!) Tout programmeur C qui se respecte mettra des parenthèses: 2*(*x) ou 2 * (*x), ou au moins des espaces: 2 * *x.

Voilà, tu l'as dit, c'est moche et ambigu. Et le programmeur C fait ce qu'il veut, même des cochonneries.

Alors là pas du tout. Même un parseur strictement LR sait faire la distinction.

Je sais.
ça n'en est pas moins une complication.

let = un mot clé inutile.

certainement pas!!
let permet de *créer* une variable!

:=, soit, mais x := x+2 n'a pas beaucoup de sens en mathématiques non plus. (C'est une définition circulaire.)

x:= !x+2 et non pas x:=x+2
:= est du type 'a -> 'a ref -> unit.
x:= !x+2 est l'équivalent de *x = *x +2

Et d'ailleurs, si le CAML est tellement meilleur que le C, alors explique-moi pourquoi le "compilateur natif" de OCAML se contente de convertir le programme OCAML en un programme C.

Et explique moi donc pourquoi C sort de l'assembleur.
Tu as déjà été voir la tronche de ce qui est produit par OCaml?

HIPPOPOTAME a écrit :
Qq part sur yaronet

Ou ça ???

Je trouve que votre dispute n'a pas beaucoup de sens : caml est un langage fonctionnel et de haut niveau alors que C est un langage impératif de haut niveau. Ça ne sert pas à la même chose (c'est d'ailleurs pour ça qu'on peut interfacer le caml avec du C...)

à part ça, quelques commentaires :

Les parenthèses sont à supprimer au maximum, tant que l'expression reste non ambigue.
f(1,2) => f 1 2

Je ne suis pas d'accord et je mets des parenthèses partout en caml. Ce n'est pas parce que ce n'est pas ambigu pour le compilateur que c'est clair pour le programmeur.

D'autre part, f (1, 2) est différent de f 1 2 puisque dans le premier cas f est de type :
int * int -> 'a alors que dans le deuxième cas elle est de type :
int -> int -> 'a
Les deux ne sont pas compatibles.

Oula, je sens qu'il y a des bases pour une compétition de "obfuscated CAML"...

Je ne sais pas ce que ça veut dire, mais s'il s'agit du concours du code le plus illisible, détrompez-vous, ça existe (plus ou moins) : cf. la FAQ :

La reine des méthodes pour obtenir un code illisible est évidemment de mélanger toutes ou partie des méthodes précédentes. Par exemple:
(fun u -> print_string "world"; print_string u)
(let temp = print_string "Hello"; "!" in
((fun x -> print_string x; flush stdout) " ";
temp));;

Si vous écrivez naturellement ainsi le programme print_string "Hello world!", vous pouvez sans doute soumettre vos oeuvres au concours du code Caml le plus illisible.

Le plus simple est encore de ne pas déclarer les types, comme en caml.

Beurk! C'est à la fois sale et inefficace, ça.

Ça n'est pas comparable, et ça n'est ni sale ni inefficace. Le compilateur est capable de déterminer sans ambiguïté le type de pratiquement n'importe quelle expression (parfois il faut l'aider malgré tout, dans des cas compliqués) et ne laissera JAMAIS passer une erreur de type.

Et, chose très appréciable, il n'y a pas de goto en caml, donc il faudrait reprendre ton code.
Beurk! C'est donc carrément un langage inutilisable.

Comme je l'ai déjà dit, caml est un langage fonctionnel. Y a un goto en lisp ?
Je ne vois pas quel sens aurait goto : caml n'exécute pas des instructions, il évalue des expressions... (évidemment ça se traduit en instructions après compilation mais là n'est pas le problème).

Mais le plus joli est encore de mettre un let ou des références.
let x = x*2;;
x:= !x*2;
let x = x+1;;
x:= !x+1; ou inc x, tout simplement.

Alors là, pour le premier et le troisième : BEURK !!
Je rappelle qu'il n'y a pas de variables en caml, seulement des constantes (et pour répondre à Kevin, il est impossible de ne pas les initialiser). Ce que tu fais dans le premier et le troisième exemples, c'est déclarer une nouvelle constante qui n'a aucun rapport avec la précédente sauf qu'elle a le même nom. Ça veut dire que la précédente continue à exister mais est masquée. C'est extrêmement sale, parce que ta nouvelle constante peut ne même pas avoir le même type que la précédente.
D'autre part, dans ton exemple, tu déclares x globalement : c'est impossible de faire ça dans une fonction. La syntaxe correcte est :
let x = x * 3 in <expression>
et x ne désignera x * 3 qu'à l'intérieur de l'expression et reprendra sa valeur initiale à la sortie.

Pour x := !x * 3, pour ceux qui ne connaissent pas le caml, x est ici une référence, dont l'équivalent C est en gros un pointeur. Cette expression ressemblerait en C à :
*x = *x * 3;

(note : ici le compilateur sait que x est une référence à un entier parce qu'on lui applique l'opérateur ! de déréférencement => c'est une référence et on applique à son contenu l'opérateur * de multiplication sur les entiers => ce contenu est un entier. Si l'on essaye plus loin de considérer x comme étant d'un type incompatible, ça ne compile pas.)

(note 2 : comme les opérateurs sont utilisés pour faire l'inférence de types, il est impossible d'utiliser le même opérateur pour une opération sur des types différents (par exemple multiplication d'entiers ou de flottants).)

(Même en français j'utilise les parenthèses imbriquées...)

"let" n'est pas un mot clef inutile (x = 3 tout seul est le booléen qu'on écrirait en C x == 3).

forum c : topics/2-18674-pointer-of-type-void-user-in-arithmetic

Je trouve que votre dispute n'a pas beaucoup de sens : caml est un langage fonctionnel et de haut niveau alors que C est un langage impératif de haut niveau. Ça ne sert pas à la même chose (c'est d'ailleurs pour ça qu'on peut interfacer le caml avec du C...)

Tout à fait d'accord.

Je ne suis pas d'accord et je mets des parenthèses partout en caml. Ce n'est pas parce que ce n'est pas ambigu pour le compilateur que c'est clair pour le programmeur.

Parfois j'en mets, parfois je n'en mets pas.
J'en mets un minimum, pour voir la structure de l'expression, mais je trouve *beaucoup* plus clair et plus léger d'omettre les parenthèses basiques, style f(x).

La reine des méthodes pour obtenir un code illisible est évidemment de mélanger toutes ou partie des méthodes précédentes. Par exemple:
(fun u -> print_string "world"; print_string u)
(let temp = print_string "Hello"; "!" in
((fun x -> print_string x; flush stdout) " "; temp));;

C'est encore lisible si on regarde attentivement. Rien à voir avec du C poussé à bout.

Mais le plus joli est encore de mettre un let ou des références.
let x = x*2;;
x:= !x*2;
let x = x+1;;
x:= !x+1; ou inc x, tout simplement.
Alors là, pour le premier et le troisième : BEURK !!

C'était une recopie des codes en C.

C'est extrêmement sale

Voilà quelqu'un encore plus propre que moi

HIPPOPOTAME a écrit :
forum c : topics/2-18674-pointer-of-type-void-user-in-arithmetic

Ah ok... Je pensais que t'avais la routine complete et là je voyais mal d'ou ça pouvait venir.

bah j'ai tapé au hasard dans le forum C...

Squeak powaaa :

Exemple en squeak déporté a la fin du post a cause d'un bug de [pre]

Enfin c pas avec sa que vous pourrez sentir la puissance de Squeak. Allez faire un tour ici pour voir la puissance de se langage 100% objet, interpreté, aussi complete que java, plus rapide que java et bcp moins lourd que java et aussi, 100% graphique, et assé déroutant vu ses capacitées (bon a savoir aussi l'interpreteur "natif" sur la machine, cad la machine virtuelle est elle meme ecrite en Squeak, et on peut lancer aussi une mv squeak dans une mv )

hello
	Transcript show: 'Hello World'

HIPPOPOTAME
a écrit : Idem pour OCaml, il y a eu d'autres versions distribuées depuis.

J'ai vérifié: Il y a eu une seule mise à jour depuis celle testée. Contre 9 de GCC (3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.1, 3.1.1, 3.2, 3.2.1, 3.2.2). Et le 3.3 va arriver dans très bientôt. (Il est déjà disponible en prerelease pour TIGCC. )

>Ça coince ceux qui ne connaissent pas l'astuce de penser à la manière de laquelle on accèdera à la variable. Une fois qu'on connaît l'astuce, il suffit de savoir penser logiquement. Ce n'est pas pratique.

C'est ton point de vue. Moi, je trouve que c'est très pratique une fois qu'on a pris l'habitude.

C'est au contraire plus simple pour le programmeur, beaucoup plus efficace, plus propre, et ça permet un typage plus fort.

Un typage plus fort en ne typant pas ses variables???
Et ce n'est pas efficace d'avoir des variables qui peuvent contenir n'importe quoi!
Même en VB, ils déconseillent l'utilisation de Variant (et pour une bonne raison: les Variants, c'est leeent...).

C'est pas toi qui écrivais il y a deux ou trois posts qu'il faut autoriser le maximum à l'utilisateur? Trêve de plaisanterie... La notation sans parenthèses est plus simple à la fois pour le compilateur et pour l'utilisateur, qui n'a pas à se fatiguer à compter les ( et les ).

Pour toi qui est un habitué du RPN, peut-être...
Pour quelqu'un qui n'est pas un habitué de la notation polonaise (préfixée ou postfixée, peu importe), ce n'est pas naturel du tout!
Et quant au fait de devoir compter les ( et les ), il suffit d'utiliser un IDE qui colore les parenthèses par paires correspondantes, comme le fait par exemple TIGCC IDE.

C'est vrai ça, mais pourquoi?
Pourquoi tant de matériel et de logiciels sont disponibles, alors que tout le monde pourrait avoir son Pentium IV + Windows XP + Word. Je me le demande.

Tant de matériels et de systèmes d'exploitation sont disponibles, mais ils sont presque tous supportés par GCC. Et s'ils ne le sont pas, il est beaucoup plus utile de porter GCC que d'adapter ses applications à d'autres compilateurs.

Ne rien faire et laisser passer!

Si c'est ça que tu veux, il suffit de ne pas compiler avec -Wall. Mais après, ne te plains pas que le langage est trop tolérant.
Et tu peux aussi désactiver sélectivement ce warning avec -Wno-uninitialized.

Et ben oui, il y a moins de parenthèses, c'est plus aéré, c'est plus clair, tout en restant absolument sans ambiguité.

Sans ambiguité, certes, mais illisible.

Le programmeur C englué dans ses habitudes les plus sales...
La commande goto n'a qu'un usage décemment possible : ne pas être utilisée!
Enfin bon, la démonstration de boogerman était très bien, je ne vais pas la refaire.

De toute façon, un goto n'aurait aucun sens en caml! Ce n'est pas utilisable, le langage est trop fonctionnel pour ça.
Un langage incompatible avec goto, quelle plus belle preuve de propreté? #lyrique#

Je ne comprends pas du tout pourquoi tant le monde gueule sur goto de cette manière. C'est une commande très utile, simple et pratique.

>Une multiplication est toujours une multiplication! C'est débile d'utiliser 2 symboles différents!
Certainement pas!! C'est une bonne habitude de rigueur à prendre.

Et quelle est la différence fondamentale qui justifie cela?
Et tant qu'on y est, il faudrait aussi un symbole différent pour la multiplication de longs que pour la multiplication de shorts???

(Et d'ailleurs, c'est ça qui permet à caml de typer. Contrairement au C, strictement aucun opérateur n'est surchargé.)

Tu appelles ça du typage? Moi, j'appelles ça du codage style "VB sale" (on peut aussi coder proprement en VB!).

Au passage, en ce qui concerne caml, ce n'est pas du niveau de la faute de gout, c'est tout le langage qui tombe à l'eau si on autorise des fonctions surchargées.

Cf. ci-dessus.

Le basic n'est pas une référence,

Et pourquoi pas?

et Java est fortement influencé par le C.

Certes. Mais ça montre à quel point la syntaxe C est pratique.

Voilà, tu l'as dit, c'est moche et ambigu. Et le programmeur C fait ce qu'il veut, même des cochonneries.

S'il fait ça, c'est qu'il est soit un porc, soit un candidat à l'IOCCC, soit les deux.

Je sais. ça n'en est pas moins une complication.

En quoi est-ce une complication si c'est parsable LR?

certainement pas!! let permet de *créer* une variable!

Ah, je ne savais pas que les variables se déclaraient à travers l'initialisation (ça me rappelle encore les pratiques déconseillées du VB).

x:= !x+2 et non pas x:=x+2
:= est du type 'a -> 'a ref -> unit.
x:= !x+2 est l'équivalent de *x = *x +2

Je trouve quand même que *x += 2; est nettement plus clair et plus court.

huuuu c quoi cette merde ??? la moitié de mon post a été sauvagement coupé ??

C corrigé c [pre] qui merde

timoleon
a écrit : Ça n'est pas comparable, et ça n'est ni sale ni inefficace. Le compilateur est capable de déterminer sans ambiguïté le type de pratiquement n'importe quelle expression

Ah, quand-même...

(parfois il faut l'aider malgré tout, dans des cas compliqués)

Beurk! Pourquoi ne pas faire déclarer le type systématiquement alors?

et ne laissera JAMAIS passer une erreur de type.

Ah, quand-même...

Comme je l'ai déjà dit, caml est un langage fonctionnel. Y a un goto en lisp ? Je ne vois pas quel sens aurait goto : caml n'exécute pas des instructions, il évalue des expressions... (évidemment ça se traduit en instructions après compilation mais là n'est pas le problème).

Même dans une évaluation d'expressions, on peut vouloir sauter à une autre étape de l'évaluation.

"let" n'est pas un mot clef inutile (x = 3 tout seul est le booléen qu'on écrirait en C x == 3).

Je pensais que c'était inutile parce que je n'avais pas compris que c'était utilisé pour déclarer une nouvelle variable. Pour l'assignement, il suffit d'utiliser un opérateur = différent (comme le C ou le Pascal, et comme le fait aussi le CAML si j'ai bien compris vos exemples), ou alors de faire comme le BASIC moderne (les premières versions utilisaient LET): selon l'endroit où on se trouve, = veut dire soit comparaison, soit assignement.

Kevin Kofler a écrit :
Beurk! Pourquoi ne pas faire déclarer le type systématiquement alors?

Sa a été ecrit pas des programmeurs poru des programmeurs, donc si on suit les lois d'un programmeur :

Premiere Loi : La fénéantise tu serviras

LOL, parce qu'il est si dur que ça de taper int. Vachement plus dur que de taper let. Il y a le grand nombre de 0 lettres en plus, c'est terrible!

J'ai vérifié: Il y a eu une seule mise à jour depuis celle testée. Contre 9 de GCC (3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.1, 3.1.1, 3.2, 3.2.1, 3.2.2). Et le 3.3 va arriver dans très bientôt. (Il est déjà disponible en prerelease pour TIGCC.)

On mesure les écarts de performance en nombre de microversions qui sont releasées?

Un typage plus fort en ne typant pas ses variables???

Exactement!
(L'utilisateur ne type pas les variables, mais le compilateur le fait à sa place sans erreur. Et une fois la variable déclarée, les vérifications de type sont aussi strictes que possible.)

Par exemple, si on déclare
let f = function n -> n+1;;
on a pas indiqué le type de f, mais le compilateur déduit qu'il s'agit de int->int (et l'indique d'ailleurs à l'utilisateur).
Dans la suite, on ne peut pas appliquer f à un réel, par exemple.

Et ce n'est pas efficace d'avoir des variables qui peuvent contenir n'importe quoi! Même en VB, ils déconseillent l'utilisation de Variant (et pour une bonne raison: les Variants, c'est leeent...).

Il n'y a pas de Variant en caml, ou alors il faut les émuler.

Pour toi qui est un habitué du RPN, peut-être... Pour quelqu'un qui n'est pas un habitué de la notation polonaise (préfixée ou postfixée, peu importe), ce n'est pas naturel du tout!

Rien à voir.
Caml est en notation algébrique classique.

Et quant au fait de devoir compter les ( et les ), il suffit d'utiliser un IDE qui colore les parenthèses par paires correspondantes, comme le fait par exemple TIGCC IDE.

C'est un palliatif, pas toujours satisfaisant. Enfin bon, certes, on peut utiliser un IDE.

Si c'est ça que tu veux, il suffit de ne pas compiler avec -Wall. Mais après, ne te plains pas que le langage est trop tolérant. Et tu peux aussi désactiver sélectivement ce warning avec -Wno-uninitialized.

Ne pas s'occuper de savoir si une variable est ou non initialisée ma paraît un comportement acceptable pour un compilateur.
Enfin ce que j'en dis moi...
Le problème ne doit pas se poser bien souvent.

En tout cas, en caml, le problème ne se pose pas. pour des raisons d'astuce d'implémentation, les variables doivent être initialisées (car en interne, les entiers doivent obligatoirement être impairs)

Sans ambiguité, certes, mais illisible.

Non, aéré et clair.
Mais on peut toujours rajouter des tonnes de parenthèses si on veut. Ca ne change rien au code.

Je ne comprends pas du tout pourquoi tant le monde gueule sur goto de cette manière. C'est une commande très utile, simple et pratique.

Parce que c'est porc.
Je comprends bien que tu ne comprends pas...

Et quelle est la différence fondamentale qui justifie cela?

Différence de type.

Et tant qu'on y est, il faudrait aussi un symbole différent pour la multiplication de longs que pour la multiplication de shorts???

Il n'y a pas de long ni de short en caml. Il n'y a que des int, qui sur x86 font 31 bits.
Les processeurs actuels ne justifient plus tellement les subtilités de taille d'entier.

Tu appelles ça du typage? Moi, j'appelles ça du codage style "VB sale" (on peut aussi coder proprement en VB!).

Le typage caml est de loin le plus propre, le plus précis et le plus rigoureux que j'ai pu tester. L'attitude de caml face au typage est très différente de celle du C, qui est un langage faiblement typé.

>>>Au passage, en ce qui concerne caml, ce n'est pas du niveau de la faute de gout, c'est tout le langage qui tombe à l'eau si on autorise des fonctions surchargées.
Cf. ci-dessus.

Surcharger des opérateurs, c'est le top de la propreté?

>>>Le basic n'est pas une référence,
Et pourquoi pas?

Parce pas.
Pas pour moi, en tout cas.

>>> et Java est fortement influencé par le C.
Certes. Mais ça montre à quel point la syntaxe C est pratique.

répandue, plutôt.
Je ne nie pas qu'elle soit pratique. Mais je trouve que l'écrasante domination du C sur la programmation n'est pas une bonne chose et qu'elle est dûe entre autre à de mauvaises raisons, comme l'inertie et la réticence à passer à des langages nouveaux et clairement techniquement supérieurs.

S'il fait ça, c'est qu'il est soit un porc, soit un candidat à l'IOCCC, soit les deux.

Quand on voit ce qui traîne parfois dans le code source de linux ....

En quoi est-ce une complication si c'est parsable LR?

complication de la grammaire, complication d'implémentation, toutes ces choses...

lol, tu as bien choisi ton exemple...
On peut aussi vouloir utiliser un unsigned long long

hum franchement je trouve vraiment pas que GCC soit une référence. Oui il est surement l'un des plus mutiplateforme, mais non il est loin d'etre le meilleur compilateur au monde et il existe de tres bon compilo qui ne sont pas mi a jour tout les 3 jours et qui fonctionnent ters tres bien (voir mieux que gcc dans pas mal de cas)

Comme ?

Beurk! Pourquoi ne pas faire déclarer le type systématiquement alors?

Parce que trouver le meilleur type possible est un problème NP, me semble t il.
Mais il faut le faire exprès (véritablement) pour que caml ne type pas correctement (en général, il répond correctement mais donne un type juste un peu trop spécifique).
En tout cas, dans la pratique, ça ne m'est jamais arrivé.

Même dans une évaluation d'expressions, on peut vouloir sauter à une autre étape de l'évaluation.

D'abord, si on veut faire un goto, on a l'esprit mal tourné.
Ensuite, dans une évaluation de *fonctions* (caml est un langage fonctionnel), ça n'a pas de sens.

Pour l'assignement, il suffit d'utiliser un opérateur = différent (comme le C ou le Pascal, et comme le fait aussi le CAML si j'ai bien compris vos exemples), ou alors de faire comme le BASIC moderne (les premières versions utilisaient LET): selon l'endroit où on se trouve, = veut dire soit comparaison, soit assignement.

Il n'y a pas d'assignement : Une fois déclarée, une variable est une constante.
Une variable modifiable doit être une référence (= un pointeur)
écrire x:= !x+2 ne modifie pas la variable x, := est une instruction d'affectation à un pointeur.