On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Je voulais dire typage dynamique. Je me suis trompé. L'important c'est
l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de *vrais* types et pas juste des récorations pense-bête pour le programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
À un point que les casts sont bien souvent indispensables (et un cast, c'est faire appel à une fonction qui convertit un objet d'un certain type vers un autre objet d'un autre type). Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe. Les types de Caml n'ont rien à voir avec les classes. Les classes ne
font pas partie des spécifications de Caml : c'est une couche rajoutée par l'implémentation Objective Caml. Le système de typage est en dessous.
Lol. T'en as beaucoup des comme ça ? Allez lire des livres sur les lambda-calculs typés et on en reparlera.
Visiblement vous ne savez pas de quoi vous parlez.
Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir. J'ai un collègue qui travaille là-dessus, qui prouve des propriétés pour des fonction d'arithmétique d'intervalle (il cherche à prouver la correction des différentes fonctions de la bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de couille, je peux t'affirmer que c'est pas de la tarte. Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Tom
"Typage statique" ? Qu'est-ce que tu veux dire par là ?
Je voulais dire typage dynamique. Je me suis trompé. L'important c'est
l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de
*vrais* types et pas juste des récorations pense-bête pour le
programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
À un point que les casts sont bien souvent
indispensables (et un cast, c'est faire appel à une fonction qui
convertit un objet d'un certain type vers un autre objet d'un autre
type).
Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Alors que OCaml, comme tout langage objet, a des types dynamiques
à cause de l'héritage de classe.
Les types de Caml n'ont rien à voir avec les classes. Les classes ne
font pas partie des spécifications de Caml : c'est une couche rajoutée
par l'implémentation Objective Caml. Le système de typage est en dessous.
Lol. T'en as beaucoup des comme ça ?
Allez lire des livres sur les lambda-calculs typés et on en reparlera.
Visiblement vous ne savez pas de quoi vous parlez.
Évidemment, avoir un typage
rigoureux est une des conditions pour faire une preuve de programme,
mais c'est loin de suffir. J'ai un collègue qui travaille là-dessus, qui
prouve des propriétés pour des fonction d'arithmétique d'intervalle (il
cherche à prouver la correction des différentes fonctions de la
bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et
ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de
couille, je peux t'affirmer que c'est pas de la tarte. Alors quand tu
racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement
rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais
pas (mais alors vraiment pas) du tout de quoi tu parles.
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de
prouver les programmes, mais que c'est nécessaire. Je vous renvoie au
discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972.
Comme quoi l'idée ne date pas d'hier.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Je voulais dire typage dynamique. Je me suis trompé. L'important c'est
l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de *vrais* types et pas juste des récorations pense-bête pour le programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
À un point que les casts sont bien souvent indispensables (et un cast, c'est faire appel à une fonction qui convertit un objet d'un certain type vers un autre objet d'un autre type). Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe. Les types de Caml n'ont rien à voir avec les classes. Les classes ne
font pas partie des spécifications de Caml : c'est une couche rajoutée par l'implémentation Objective Caml. Le système de typage est en dessous.
Lol. T'en as beaucoup des comme ça ? Allez lire des livres sur les lambda-calculs typés et on en reparlera.
Visiblement vous ne savez pas de quoi vous parlez.
Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir. J'ai un collègue qui travaille là-dessus, qui prouve des propriétés pour des fonction d'arithmétique d'intervalle (il cherche à prouver la correction des différentes fonctions de la bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de couille, je peux t'affirmer que c'est pas de la tarte. Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Tom
Tom
Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai tout de suite commencé à pleurer et je continue toujours à pleurer. Maintenant, j'ai ma boite de kleenex à côté. Pratique. Moi je sors d'une grippe. J'ai aussi fait honneur au mouchoir.
Tom
Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai
tout de suite commencé à pleurer et je continue toujours à pleurer.
Maintenant, j'ai ma boite de kleenex à côté.
Pratique. Moi je sors d'une grippe. J'ai aussi fait honneur au mouchoir.
Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai tout de suite commencé à pleurer et je continue toujours à pleurer. Maintenant, j'ai ma boite de kleenex à côté. Pratique. Moi je sors d'une grippe. J'ai aussi fait honneur au mouchoir.
Tom
Olivier Beyssac
Tom writes:
ils ont le C dans le sang et ils seraient prets à donner leur vi pour le défendre !
J'ai la permission de me faire une signature avec cette phrase ?
-- Olivier Beyssac -
Tom <tom@tom.com> writes:
ils ont le C dans le sang et ils seraient prets à donner leur vi pour
le défendre !
J'ai la permission de me faire une signature avec cette phrase ?
Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Ça dérappe !
-- Joe Cool
Tom
Tom writes:
ils ont le C dans le sang et ils seraient prets à donner leur vi pour le défendre ! J'ai la permission de me faire une signature avec cette phrase ?
C'est une faute de frappe, j'ai oublié le e à la fin de vie. Mais ca donne un lapsus assez cocasse. Tu peux en faire ta signature si ça te chante, ça ne me dérange pas :-)
Tom
Tom <tom@tom.com> writes:
ils ont le C dans le sang et ils seraient prets à donner leur vi pour
le défendre !
J'ai la permission de me faire une signature avec cette phrase ?
C'est une faute de frappe, j'ai oublié le e à la fin de vie. Mais ca
donne un lapsus assez cocasse. Tu peux en faire ta signature si ça te
chante, ça ne me dérange pas :-)
ils ont le C dans le sang et ils seraient prets à donner leur vi pour le défendre ! J'ai la permission de me faire une signature avec cette phrase ?
C'est une faute de frappe, j'ai oublié le e à la fin de vie. Mais ca donne un lapsus assez cocasse. Tu peux en faire ta signature si ça te chante, ça ne me dérange pas :-)
Changer de type c'est comme changer de sexe : ça n'a pas de sens. Ça dérappe !
Problème de rugosité.
Tom
Joe Cool
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le Fortran.
Morceaux choisis :
Le PC :
« Le plus affligeant peut-être est que, même après toutes ces années d'expérience frustrantes, il y a toujours tant de gens qui croient honnêtement que quelque loi de la nature nous dit que les machines doivent être ainsi. Ils font taire leurs doutes en considérant la quantité de ces machines qui s'est vendue, et en retirent la fausse impression de sécurité qu'après tout, la conception n'a pu en être si mauvaise. Mais en y regardant de plus près, cette ligne de défense à la même force de conviction que l'argument selon lequel fumer des cigarettes serait bon pour la santé puisque tant de gens le font. »
Le C :
« Le destin tragique du FORTRAN a été sa large diffusion, enchaînant mentalement des milliers et des milliers de programmeurs à nos erreurs passées. Je prie tous les jours qu'un plus grand nombre de mes collègues programmeurs trouve des moyens de se libérer de la malédiction de la compatibilité. »
L'ingénieur informaticien :
« Aujourd'hui, la technique habituelle est de réaliser un programme puis de le tester. Mais si tester un programme peut être une technique très efficace pour montrer la présence de bogues, elle est désespérément incapable d'en montrer l'absence. La seule manière efficace de relever significativement le niveau de confiance en un programme est de produire une preuve convaincante de sa justesse. Mais on ne doit pas d'abord réaliser le programme et ensuite prouver sa justesse, car l'exigence de fourniture de preuve ne ferait qu'alourdir le fardeau du pauvre programmeur. Au contraire, le programmeur doit faire croître la preuve de justesse et le programme de concert. »
Le Caml :
« Je prédis un grand avenir aux langages de programmation très systématiques et très modestes. Quand je dis « modeste », je veux dire que, par exemple, non seulement l'instruction « for » d'ALGOL 60, mais aussi la boucle « DO » de FORTRAN pourrait être rejetées comme trop baroques. J'ai conduit une petite expérience de programmation avec des volontaires très expérimentés, et elle a montré quelque chose de vraiment imprévu et de plutôt surprenant. Aucun de mes volontaires n'a trouvé la solution évidente et la plus élégante. Après analyse approfondie cela s'avéra avoir une origine commune : leur notion de la répétition était si étroitement liée à l'idée d'une variable associée à incrémenter qu'ils étaient mentalement bloqués de la vision de la solution. Leurs solutions étaient moins efficaces, inutilement difficile à comprendre et leurs avaient pris très longtemps à trouver. »
Le blocage linuxien :
« Je vous laisse le choix de décider quelle importance vous allez donner à mes réflexions, je ne sais que trop bien que je ne peux forcer personne à partager mes convictions. Comme chaque révolution, celle-ci provoquera une opposition violente, et l'on peut se demander où sont les forces conservatrices qui essaieront de contrer de tels développements. Je ne m'attends pas à les trouver principalement dans les grandes entreprises, ni même dans l'industrie informatique ; je m'attends plutôt à les trouver dans les institutions d'éducation qui fournissent les formations actuelles et dans ces groupes conservateurs d'utilisateurs d'ordinateurs qui pensent que leurs anciens programmes sont si importants qu'il n'est pas utile de les récrire et de les améliorer. »
Tout est dit, depuis 33 ans.
-- Joe Cool
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de
prouver les programmes, mais que c'est nécessaire. Je vous renvoie au
discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972.
Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le
Fortran.
Morceaux choisis :
Le PC :
« Le plus affligeant peut-être est que, même après toutes ces années
d'expérience frustrantes, il y a toujours tant de gens qui croient
honnêtement que quelque loi de la nature nous dit que les machines
doivent être ainsi. Ils font taire leurs doutes en considérant la
quantité de ces machines qui s'est vendue, et en retirent la fausse
impression de sécurité qu'après tout, la conception n'a pu en être si
mauvaise. Mais en y regardant de plus près, cette ligne de défense à la
même force de conviction que l'argument selon lequel fumer des
cigarettes serait bon pour la santé puisque tant de gens le font. »
Le C :
« Le destin tragique du FORTRAN a été sa large diffusion, enchaînant
mentalement des milliers et des milliers de programmeurs à nos erreurs
passées. Je prie tous les jours qu'un plus grand nombre de mes collègues
programmeurs trouve des moyens de se libérer de la malédiction de la
compatibilité. »
L'ingénieur informaticien :
« Aujourd'hui, la technique habituelle est de réaliser un programme puis
de le tester. Mais si tester un programme peut être une technique très
efficace pour montrer la présence de bogues, elle est désespérément
incapable d'en montrer l'absence. La seule manière efficace de relever
significativement le niveau de confiance en un programme est de produire
une preuve convaincante de sa justesse. Mais on ne doit pas d'abord
réaliser le programme et ensuite prouver sa justesse, car l'exigence de
fourniture de preuve ne ferait qu'alourdir le fardeau du pauvre
programmeur. Au contraire, le programmeur doit faire croître la preuve
de justesse et le programme de concert. »
Le Caml :
« Je prédis un grand avenir aux langages de programmation très
systématiques et très modestes. Quand je dis « modeste », je veux dire
que, par exemple, non seulement l'instruction « for » d'ALGOL 60, mais
aussi la boucle « DO » de FORTRAN pourrait être rejetées comme trop
baroques. J'ai conduit une petite expérience de programmation avec des
volontaires très expérimentés, et elle a montré quelque chose de
vraiment imprévu et de plutôt surprenant. Aucun de mes volontaires n'a
trouvé la solution évidente et la plus élégante. Après analyse
approfondie cela s'avéra avoir une origine commune : leur notion de la
répétition était si étroitement liée à l'idée d'une variable associée à
incrémenter qu'ils étaient mentalement bloqués de la vision de la
solution. Leurs solutions étaient moins efficaces, inutilement difficile
à comprendre et leurs avaient pris très longtemps à trouver. »
Le blocage linuxien :
« Je vous laisse le choix de décider quelle importance vous allez donner
à mes réflexions, je ne sais que trop bien que je ne peux forcer
personne à partager mes convictions. Comme chaque révolution, celle-ci
provoquera une opposition violente, et l'on peut se demander où sont les
forces conservatrices qui essaieront de contrer de tels développements.
Je ne m'attends pas à les trouver principalement dans les grandes
entreprises, ni même dans l'industrie informatique ; je m'attends plutôt
à les trouver dans les institutions d'éducation qui fournissent les
formations actuelles et dans ces groupes conservateurs d'utilisateurs
d'ordinateurs qui pensent que leurs anciens programmes sont si
importants qu'il n'est pas utile de les récrire et de les améliorer. »
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le Fortran.
Morceaux choisis :
Le PC :
« Le plus affligeant peut-être est que, même après toutes ces années d'expérience frustrantes, il y a toujours tant de gens qui croient honnêtement que quelque loi de la nature nous dit que les machines doivent être ainsi. Ils font taire leurs doutes en considérant la quantité de ces machines qui s'est vendue, et en retirent la fausse impression de sécurité qu'après tout, la conception n'a pu en être si mauvaise. Mais en y regardant de plus près, cette ligne de défense à la même force de conviction que l'argument selon lequel fumer des cigarettes serait bon pour la santé puisque tant de gens le font. »
Le C :
« Le destin tragique du FORTRAN a été sa large diffusion, enchaînant mentalement des milliers et des milliers de programmeurs à nos erreurs passées. Je prie tous les jours qu'un plus grand nombre de mes collègues programmeurs trouve des moyens de se libérer de la malédiction de la compatibilité. »
L'ingénieur informaticien :
« Aujourd'hui, la technique habituelle est de réaliser un programme puis de le tester. Mais si tester un programme peut être une technique très efficace pour montrer la présence de bogues, elle est désespérément incapable d'en montrer l'absence. La seule manière efficace de relever significativement le niveau de confiance en un programme est de produire une preuve convaincante de sa justesse. Mais on ne doit pas d'abord réaliser le programme et ensuite prouver sa justesse, car l'exigence de fourniture de preuve ne ferait qu'alourdir le fardeau du pauvre programmeur. Au contraire, le programmeur doit faire croître la preuve de justesse et le programme de concert. »
Le Caml :
« Je prédis un grand avenir aux langages de programmation très systématiques et très modestes. Quand je dis « modeste », je veux dire que, par exemple, non seulement l'instruction « for » d'ALGOL 60, mais aussi la boucle « DO » de FORTRAN pourrait être rejetées comme trop baroques. J'ai conduit une petite expérience de programmation avec des volontaires très expérimentés, et elle a montré quelque chose de vraiment imprévu et de plutôt surprenant. Aucun de mes volontaires n'a trouvé la solution évidente et la plus élégante. Après analyse approfondie cela s'avéra avoir une origine commune : leur notion de la répétition était si étroitement liée à l'idée d'une variable associée à incrémenter qu'ils étaient mentalement bloqués de la vision de la solution. Leurs solutions étaient moins efficaces, inutilement difficile à comprendre et leurs avaient pris très longtemps à trouver. »
Le blocage linuxien :
« Je vous laisse le choix de décider quelle importance vous allez donner à mes réflexions, je ne sais que trop bien que je ne peux forcer personne à partager mes convictions. Comme chaque révolution, celle-ci provoquera une opposition violente, et l'on peut se demander où sont les forces conservatrices qui essaieront de contrer de tels développements. Je ne m'attends pas à les trouver principalement dans les grandes entreprises, ni même dans l'industrie informatique ; je m'attends plutôt à les trouver dans les institutions d'éducation qui fournissent les formations actuelles et dans ces groupes conservateurs d'utilisateurs d'ordinateurs qui pensent que leurs anciens programmes sont si importants qu'il n'est pas utile de les récrire et de les améliorer. »
Tout est dit, depuis 33 ans.
-- Joe Cool
Joe Cool
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
Objective Caml version 3.08.2
# let t = Array.make 10 0;; val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|] # t.(10) <- 1;; Exception: Invalid_argument "index out of bounds". #
C'est quoi le problème ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution que ça marche (ou pas). Pas très efficace, Tom ne serait pas très content de ta façon de programmer quelque peu hasardeuse.
Extrait du manuel Ocaml version 3.08 :
« Array.get a n returns the element number n of array a. The first element has number 0. The last element has number Array.length a - 1. You can also write a.(n) instead of Array.get a n.
Raise Invalid_argument "index out of bounds" if n is outside the range 0 to (Array.length a - 1). »
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml ne peut en aucun cas gérérer une erreur à la compilation. Il fait la seule chose possible en l'absence d'algorithme exact : il envoie une exception pour signaler l'erreur. Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
-- Joe Cool
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml
let a = Array.create 10 0;;
a.(10) <- 1
% ocamlc foo.ml -o foo
%
Objective Caml version 3.08.2
# let t = Array.make 10 0;;
val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|]
# t.(10) <- 1;;
Exception: Invalid_argument "index out of bounds".
#
C'est quoi le problème ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution
que ça marche (ou pas). Pas très efficace, Tom ne serait pas très
content de ta façon de programmer quelque peu hasardeuse.
Extrait du manuel Ocaml version 3.08 :
« Array.get a n returns the element number n of array a. The first
element has number 0. The last element has number Array.length a - 1.
You can also write a.(n) instead of Array.get a n.
Raise Invalid_argument "index out of bounds" if n is outside the range 0
to (Array.length a - 1). »
Aucun typage ne peut garantir dans le cas général d'un langage universel
qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml
ne peut en aucun cas gérérer une erreur à la compilation. Il fait la
seule chose possible en l'absence d'algorithme exact : il envoie une
exception pour signaler l'erreur. Tout bon programmeur Caml, si il n'a
pas prouvé la validité de son algorithme, doit enrober son code d'un
try...with pour traiter ce cas.
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
Objective Caml version 3.08.2
# let t = Array.make 10 0;; val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|] # t.(10) <- 1;; Exception: Invalid_argument "index out of bounds". #
C'est quoi le problème ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution que ça marche (ou pas). Pas très efficace, Tom ne serait pas très content de ta façon de programmer quelque peu hasardeuse.
Extrait du manuel Ocaml version 3.08 :
« Array.get a n returns the element number n of array a. The first element has number 0. The last element has number Array.length a - 1. You can also write a.(n) instead of Array.get a n.
Raise Invalid_argument "index out of bounds" if n is outside the range 0 to (Array.length a - 1). »
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml ne peut en aucun cas gérérer une erreur à la compilation. Il fait la seule chose possible en l'absence d'algorithme exact : il envoie une exception pour signaler l'erreur. Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
