Discussion :

[DavidDeharbe]

Bonjour,

Je suis enseignant universitaire et ai adopté Objective Caml comme langage pour un cours intitulé "Concepts et Techniques de Programmation", destiné à des étudiant(e)s fraîchements arrivés à l'université pour y suivre une formation de 4 années en Informatique.

Je souhaite échanger des idées sur la séquence de présentation des différents concepts de programmation et leur mise en oeuvre en Objective Caml.

Je suis en train de donner le cours pour la 4ème fois, et j'en suis à la séquence suivante:
1. Types, operateurs et expressions numériques (le langage comme calculatrice)
2. Variables, portée de variable, variables globales et locales.
3. Fonctions, curryfication, fonctions d'ordre supérieur.
4. Expressions conditionnelles et le type booléen.
5. Fonctions récursives
6. Types registres
7. Filtrage ("pattern matching")
8. Types tuples
9. Types variants
10. Listes
11. Types et fonctions génériques
12. Références
13. Programmation impérative (séquence, boucles)
14. Vecteurs
15. Entrées-sorties textuelles
16. Construction de programmes
17. Programmation modulaire
18. Programmation orientée à classes
19. Programmation graphique

Les items 17., 18. et 19. sont optionnels et introduits si la classe arrive à bien assimiler les concepts antérieurs.

David.
--

[gorgonite]

pour infos, une présentation du langage OCaml et de ces fonctionnalités est en cours de rédaction sur dvp.com (http://gorgonite.developpez.com/tuto...presentation/), et InOCamlWeTrust avait opté pour un plan légèrement différent... mais qui peut sembler plus adaptée aux personnes ayant déjà quelques bases de programmation

-------------------------------------------


le plan que vous proposez me semble assez bon... mais qu'en est-il du découpage des parties par rapport aux séances de cours ?

par exemple, référence et programmation impérative sont-ells vues dans la même séance (ce qui me semblerait logique)

en effet, un mauvais découpage d'un bon cours, peut être préjudiciable à la pédagogie (mais je ne vous apprends rien, vous êtes prof )

[Garulfo]

Bonjour,
Je suis enseignant universitaire[...]
David.
--

Voici le plan de ce que j'enseigne pour Scheme
1- éléments de syntaxe [1,2,4]
2- Expressions symboliques [7,10]
3- Programmation fonctionnelle [3,5]
4- Programmation impérative [13]
5- Évaluations et ordres
6- Environnements et fermetures
7- Données structurées et algorithmes
8- Appels par continuation
9- Macros
10- Flots et flots infinis
11- Programmation par objets [18]

Chaque chapitre représente une semaine (2h de cours + 2h de travaux dirigés en lab environ). J'ai mis entre crochets les liens évidents pour le reste cela dépend ce que tu donnes dans le détail.

Personnellement j'adore le chapitre 8 qui est rarement enseigné mais permet de leurs montrer comment implémenter des mécanismes d'exceptions en e cumulant avec le 9. J'aime beaucoup le 11 pour leur montrer le fondement des objets, Scheme offrant une solution très élégante. Le 10 est un must aussi car ils ne verront ça nul part ailleurs.

Cependant pour moi c'est un cours de 3e session (deuxième année donc).

Dans ton cas, il faut mettre plus l'emphase sur les principes et les méthodes de développement, et moins sur les éléments très particulier au langage fonctionnel.

Quel est le temps accordé à chaque chapitre ?

[HS]On partage beaucoup en recherche aussi je vois [/HS]

[InOCamlWeTrust]

Les items 17., 18. et 19. sont optionnels et introduits si la classe arrive a bien assimiler les concepts anterieurs.

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

La programmation graphique devrait être relayée au stade de jouet, à mon avis, et les forumistes ici et là cherchant quasi-désespérément une solution à leurs problèmes avec le module Graphics le montrent bien. Je pense qu'en parler ou faire un ou deux TP n'est pas une mauvaise idée, mais il faudrait insister lourdement sur le fait que ce ne sont que des exercices, et non des modèles de véritable programmation graphique, un monde à part entière, disposant de ses propres compilateurs, et qui se fait quasiment, d'ailleurs, entièrement en C (sauf rares cas).

La programmation orientée objet peut être vue dans la partie modulaire. Un module définissant un type principal et l'exportant sous forme abstraite, peut être vu comme une classe, dont les méthodes sont les fonctions, qui ici prennent, en général, un paramètre supplémentaire, du type le type principal. Les modules String, Stack, Queue, Map et Set de la librairie standard en sont de bons exemples.

Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose, étant donné que le système objet de Objective Caml est parfois complexe, surtout très fin dans l'approche et pas vraiment standard.

A ce stade, la question des foncteurs reste encore ouverte, étant donné que c'est une chose que l'on ne trouve nulle part ailleurs.

Il serait bon (et très sain) de présenter (ou dire deux mots) sur l'ensemble de la distribution :

- énumération des modules et possibilités de la librairie standard
- présentation des compilateurs ocamlc et ocamlopt
- ocamllex et ocamlyacc (juste dire ce dont il s'agit, hein !)
- ocamldep et les Makefile (très très très utiles... surtout que ça sert pour n'importe quel autre langage)
- threads
- module Unix (juste dire que ça existe et que c'est bien !)
- Camlp4 (présenter et en parler un tout petit peu, car pour les flots, c'est indispensable, même si, c'est vrai, on peut l'utiliser sans savoir comment !)

[Garulfo]

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

Pas exactement. La programmation modulaire (utilisation de modules indépendant sous forme boîte noire) est indépendante en théorie de la programmation structurée (utilisation des trois énoncés classiques pour la construction d'un programme). Cependant il est vrai qu'elles sont souvent liées en pratique.

Mais on peut très bien commencer par parler des principes de la programmation modulaire sont parler des modules de ocaml. À la fin du cours, on peut parler des modules d'ocaml, et revenir sur ces principes en expliquant comment ils sont bien représentés dans le langage.

La programmation graphique [...]

La programmation orientée objet peut être vue dans la partie modulaire. [...]
Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose[...].

Encore une fois, on peut parler des principes et montrer comment implémenter les mécanismes de programmations objets sans utiliser les objets d'ocaml.

Tout dépend des objectifs pédagogiques du cours. Si le but est de présenter les concepts qui seront repris dans les autres cours, alors c'est une bonne chose de le présenter comme je le propose. Si par contre c'est un cours qui se veut suffisant (pour des étudiants en physique ou en math) alors je suis d'accord avec IOCWT.

[Jedai]

10- Flots et flots infinis

Le 10 est un must aussi car ils ne verront ça nul part ailleurs.

Si, en Haskell non ? C'est parfaitement naturel de travailler avec des listes infinies en Haskell, à moins que tu ne parles de tout à fait autre chose ? (je dois avouer que je ne suis pas vraiment un connaisseur en Scheme)
A moins que tu ne veuilles dire que les étudiants ne risquent pas de tomber sur beaucoup d'autres cours abordant le sujet ? (bien que les itérateurs permettent des choses très proches dans d'autres langages, moins élégamment, soit)

NB : Je sais que d'autres langages permettent la même chose (OCaml entre autres), mais je n'en avais jamais rencontré qui le rende aussi "évident" qu'Haskell (ceci découlant directement de l'évaluation paresseuse bien sûr).

--
Jedaï

[gorgonite]

NB : Je sais que d'autres langages permettent la même chose (OCaml entre autres), mais je n'en avais jamais rencontré qui le rende aussi "évident" qu'Haskell (ceci découlant directement de l'évaluation paresseuse bien sûr).

+1


d'ailleurs, ce n'est pas pour rien que Haskell est utilisé pour modéliser des structures manipulant des flux d'information "non stop" comme les réseaux, circuits électroniques, etc. (cf le projet Lava par exemple)

[InOCamlWeTrust]

D'accord... mais enfin, vous conviendrez tout de même que les flots Caml, c'est quasiment des listes paresseuses, non ? On peut pas dire que leur manipulation diffère énormément de celle des listes : ça se filtre, il y a le mot-clef parser, ça s'écrit presque pareil, etc... Le seul truc qui me dérange, c'est leur utilisation avec le module Stream, entre autres l'impossibilité de mélanger les flots issus de Stream et ceux construits à la main : je trouve qu'il y aurait un effort à faire de ce côté-là.

[gorgonite]

D'accord... mais enfin, vous conviendrez tout de même que les flots Caml, c'est quasiment des listes paresseuses, non ? On peut pas dire que leur manipulation diffère énormément de celle des listes : ça se filtre, il y a le mot-clef parser, ça s'écrit presque pareil, etc...

tout à fait
d'ailleurs, c'est très bien décrit dans le papier d'origine d'implémentation des structures paresseuses en Caml
(Michel Mauny 1992, si je ne me trompe pas )

edit confirmé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Integrating lazy evaluation in strict ML, Michel Mauny
 
@TechReport{inria-techniques-137,
  author = 	 "Michel Mauny",
  title = 	 "Integrating lazy evaluation in strict ML",
  institution =  "Institut National de Recherche en Informatique et an
		  Automatique",
  year = 	 1992,
  number =	 "Rapports Techniques No.137"
}

Le seul truc qui me dérange, c'est leur utilisation avec le module Stream, entre autres l'impossibilité de mélanger les flots issus de Stream et ceux construits à la main : je trouve qu'il y aurait un effort à faire de ce côté-là.

perso, je fais plutot du Haskell dans ces cas-là... donc je peux pas trop de dire

[Garulfo]

Si, en Haskell non ? [...]
Jedaï

Bien sûr en Haskell aussi quand je disais qu'ils ne le verraient nulle part ailleurs, je parlais hors de la programmation fonctionnelle. Le Scheme et le Haskell sont très proches de toute façon. Plus encore que le Scheme et le ML...

Et IOCWT a complètement raison puisque les flots infinis sont des listes évaluées de manière paresseuse. Quelque soit le langage, c'est de ça qu'on parle quand on parle de flots infinis.

Pour des gens qui croient s'y connaître en informatique (étudiants de 2e année) c'est souvent assez incroyable. De même que le continuation passing style.

[gorgonite]

De même que le continuation passing style.

pour le CPS, il vaut mieux voir SML et ses call/cc

[Garulfo]

pour le CPS, il vaut mieux voir SML et ses call/cc

Ou Scheme... ou Haskell...

Mais tu parles des call/cc.
On peut coder des CPS à la main.
C'est ça le plus intéressant.
Après, si on a compris, il est pertinent de voir le call/cc.

C'est comme dépecer un système objet en scheme (ou autres).
On se rend compte du point de vue dual très vite.

[gasche]

1. Types, operateurs et expressions numeriques (le langage comme calculatrice)
2. Variables, portee de variable, variables globales et locales.
3. Fonctions, curryfication, fonctions d'ordre superieur.
4. Expressions conditionnelles et le type booleen
5. Fonctions recursives
6. Types registres
7. Filtrage ("pattern matching")
8. Types tuples
9. Types variants
10. Listes
11. Types et fonctions generiques
12. References
13. Programmation imperative (sequence, boucles)
14. Vecteurs
15. Entrees-sorties textuelles
16. Construction de programmes
17. Programmation modulaire
18. Programmation orientee a classes
19. Programmation graphique

Je pense que les listes devraient être traitées avant. En effet, il est à mon avis plus utile et plus compréhensible de présenter les listes comme un type algébrique particulier au moment de la découverte des types algébriques, et après la présentation des listes, que l'inverse.
Je pense que par exemple 6. serait une bonne place : juste après la récursion, un type de donnée récursif s'impose.
Par ailleurs, je ne vois pas trop à quoi sont sensé servir les "type registres" (si c'est bien les {machin:truc; bidule:chouette}) dans une présentation du langage en général. Ils sont peut-être utiles, mais ne servent pas à grand chose pour comprendre le langage dans son ensemble à mon avis, et pourraient largement être inclus dans une semaine "construction de types complexes", genre les 8/9.

Je pense que le typage (11.) mériterait d'être présenté bien avant (vers 4/5). D'une part parce que c'est fondamental en caml, et d'autre part parce que ça doit faire chier de voir des 'a et des 'b pendant 11 semaines sans rien comprendre. Tu fais le choix de présenter les fonctions d'ordre supérieur assez tôt, ce serait alors logique de faire pareil pour le typage.

Pour le reste, tu fais le choix de présenter la programmation impérative bien après la programmation fonctionnelle, ce qui est à mon avis une bonne idée, même si ça risque de mettre dans le flou les étudiants ayant déjà fait de la programmation (impérative). Autant les surprendre un bon coup dès le début ^^

Pour ce qui est de la programmation modulaire et objet, je suis un peu sceptique quant à leur capacité à assimiler tout ça dans un intervalle de temps raisonnable.
Puisque le sujet de ton cours est très généraliste ("Concepts et Techniques de programmation"), on peut penser que leur montrer un peu de POO serait utile, mais je suis un peu dubitatif. Cependant, la POO Ocaml est très intéressante et novatrice (par rapport aux langages impératifs classiques, en tout cas) dans son approche au typage etc., donc ça pourrait être bien qu'ils en aient ne serait-ce qu'une vague idée.

Les modules puis foncteurs sont à mon avis un must, à présenter dans le genre "vous voyez bien qu'on peut faire de la modularité sans POO !"

[Garulfo]

Je pense que les listes devraient être traitées avant.[...]
Je pense que par exemple 6. serait une bonne place : juste après la récursion, un type de donnée récursif s'impose.

Assez d'accord avec ça.

Par ailleurs, je ne vois pas trop à quoi sont sensé servir les "type registres"

Plus discutable ça.

Je pense que le typage (11.) mériterait d'être présenté bien avant

Il l'est... regarde le premier mot du chapitre 1.
Je suppose qu'il y a la partie simple à comprendre, puis la partie plus complexe. Il me semble que c'est correct ainsi.

Pour le reste, tu fais le choix de présenter la programmation impérative bien après la programmation fonctionnelle, ce qui est à mon avis une bonne idée, même si ça risque de mettre dans le flou les étudiants ayant déjà fait de la programmation (impérative). Autant les surprendre un bon coup dès le début ^^

Non normalement ça passe bien de le présenter plus tard.
En fait c'est même nécessaire. Si tu le présentes trop tôt, ceux et celles qui ont déjà programmé n'arrives plus à penser autrement (fonctionnel).

Pour ce qui est de la programmation modulaire et objet, je suis un peu sceptique quant à leur capacité à assimiler tout ça dans un intervalle de temps raisonnable.

Là encore, je réitère... le fait que le cours soit général peut permettre de montrer des concepts et des idées sans approfondire. C'est-à-dire dans ce cas, de montrer la programmation objet sans les objets de caml, mais avec l'approche fonctionnelle classique par prototype et message. Si le cours veut par contre donner des bases pratiques pour des étudiants qui ne sont pas des futures informaticiens, je trouvais par contre ça plus douteux.

Les modules puis foncteurs sont à mon avis un must, à présenter dans le genre "vous voyez bien qu'on peut faire de la modularité sans POO !"

Mais là tu t'adresses plus à des personnes avancées qui connaissent déjà ces sujets. Donc probablement peu pertinent pour ce cours.

[gasche]

Je pense que le typage (11.) mériterait d'être présenté bien avant

Il l'est... regarde le premier mot du chapitre 1.
Je suppose qu'il y a la partie simple à comprendre, puis la partie plus complexe. Il me semble que c'est correct ainsi.

Je suppose, d'après le titre du chapitre 11 (générique) qu'il parle de polymorphisme paramétrique. Et si c'est bien ça (je vois pas trop de quoi d'autre on pourrait parler au sujet du typage en ocaml), ça mérite quand même d'être présenté bien avant.

D'une part, bien que ça soit effectivement "plus complexe" que les types non polymorphes, c'est pas non plus très difficile à comprendre (à la rigueur il y a les '_a qui peuvent poser des difficultés, mais ça j'imagine qu'on les introduit quand on commence la programmation impérative).

D'autre part, c'est omniprésent. Je vois mal comment on peut faire un cours sur les "fonctions d'ordre supérieur" et la "curryfication" par exemple, sans rencontrer des types polymorphes. Et je pense que si j'étais étudiant, ça me gênerait de me taper des 'a, 'b et 'c pendant 10 chapitres sans savoir ce que ça veut dire.

[Garulfo]

Je suppose, d'après le titre du chapitre 11 (générique) qu'il parle de polymorphisme paramétrique. [...]

Il peut très bien en parler au besoin en disant que ce sont des types « généraux » et il revient pour les détails au moment du chapitre 11 en expliquant les difficultés et les pièges, qu'est ce que le polymorphisme vs. le monomorphisme etc. ^_^

Tout n'est pas dans les titres. Sinon la tâche de job serait criss'ment plate.

[DavidDeharbe]

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

Mon objectif est plutôt de donner les outils pour faire de la programmation à petite échelle (programming in the small) qu'à grande échelle (programming in the large). Pour autant que je trouve la programmation modulaire intéressante, et nécessaire, l'expérience m'a montré qu'il (m') était difficile de faire passer ce concept. En effet ces très jeunes étudiants commencent à apprendre à programmer et ne saisissent pas vraiment la problématique de la construction de grands programmes. Mon objectif est de leur fournir les outils intellectuels pour mettre en oeuvre les structures de données et algorithmes qu'ils voient par la suite.

Leur formation inclut d'autres matières, telles que "Paradigmes de Concepts et Techniques de Programmation" où sont exposés des concepts plus avancés de programmation.

La programmation graphique devrait être relayée au stade de jouet, à mon avis, et les forumistes ici et là cherchant quasi-désespérément une solution à leurs problèmes avec le module Graphics le montrent bien. Je pense qu'en parler ou faire un ou deux TP n'est pas une mauvaise idée, mais il faudrait insister lourdement sur le fait que ce ne sont que des exercices, et non des modèles de véritable programmation graphique, un monde à part entière, disposant de ses propres compilateurs, et qui se fait quasiment, d'ailleurs, entièrement en C (sauf rares cas).

Tout à fait d'accord. Néanmoins, l'attention des étudiants est beaucoup plus grande lorsque je leur montre comment programmer les primitives du langage LOGO em OCaml que la séquence de Fibonacci (même si Dan Brown a donné un bon coup de main).

Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose, étant donné que le système objet de Objective Caml est parfois complexe, surtout très fin dans l'approche et pas vraiment standard.

A ce stade, la question des foncteurs reste encore ouverte, étant donné que c'est une chose que l'on ne trouve nulle part ailleurs.

Oui, d'accord (voir d'ailleurs mon 1º paragraphe). Mais il me semble que Java commence à s'en approcher.

[QUOTE]

Il serait bon (et très sain) de présenter (ou dire deux mots) sur l'ensemble de la distribution :

- énumération des modules et possibilités de la librairie standard

J'évoque au fur et à mesure certains modules.

- présentation des compilateurs ocamlc et ocamlopt

C'est présenté dès le début, en fait. Et j'essaie d'y revenir à la fin (module Arg).

- ocamllex et ocamlyacc (juste dire ce dont il s'agit, hein !)
- ocamldep et les Makefile (très très très utiles... surtout que ça sert pour n'importe quel autre langage)
- threads
- module Unix (juste dire que ça existe et que c'est bien !)
- Camlp4 (présenter et en parler un tout petit peu, car pour les flots, c'est indispensable, même si, c'est vrai, on peut l'utiliser sans savoir comment !)

Bonne suggestion, je pourrai en parler au dernier cours, histoire de faire le lien avec les autres cours qu'ils vont suivre dans leur formation.

Merci pour le feed-back.

David.
--

[DavidDeharbe]

Je pense que les listes devraient être traitées avant. En effet, il est à mon avis plus utile et plus compréhensible de présenter les listes comme un type algébrique particulier au moment de la découverte des types algébriques, et après la présentation des listes, que l'inverse.
Je pense que par exemple 6. serait une bonne place : juste après la récursion, un type de donnée récursif s'impose.

Rappelons qu'il s'agit d'une première exposition à la programmation: même si quelques étudiants ont déjà quelques bases, je ne peux pas en faire une hypothèse de travail. De plus, j'enseigne au Brésil, où la formation au niveau lycée est généraliste et unique - donc pas spécialement scientifique. Ainsi, les étudiants ne savent pas ce que c'est qu'une preuve par induction. Donc, je fais une première introduction à la récursion et me cantonne au traitement récursif sur les nombres naturels. J'ai fait le choix de ne pas traiter immédiatement les listes ici, pour deux raisons:

• Je préfère présenter les concepts de base nécessaires à la définition des listes avant de présenter les listes: types tuples, types variants et filtrage. Ainsi, dans le cours que je donne, je présente une définition de liste d'entiers ad hoc: type list_int = Empty | Cons of int * list_int. Une série d'exercices sur ce type permet de voir les algorithmes de traitement de listes. Ensuite, je leur demande de faire la même choice pour des listes de float. Cela me permet de facilement justifier le polymorphisme paramétrique.
• Le cours est formellement divisé en 3 modules. Je préfère ne traiter la récursivité que dans le second module afin de répartir les difficultés de manière homogène sur la durée du cours.

-

Ce qui nous amène à:

Par ailleurs, je ne vois pas trop à quoi sont sensé servir les "type registres" (si c'est bien les {machin:truc; bidule:chouette}) dans une présentation du langage en général. Ils sont peut-être utiles, mais ne servent pas à grand chose pour comprendre le langage dans son ensemble à mon avis, et pourraient largement être inclus dans une semaine "construction de types complexes", genre les 8/9.

Mon but n'est pas de présenter le langage. Le type registre est une construction très utile pour représenter les données. Les exemples que j'utilise sont principalement tirés de la géométrie euclidienne: définition d'un type pour représenter un point, un segment, un cercle, un vecteur, etc. Cela ouvre un éventail d'exercices intéressants: étant donné un point et un vecteur calculer la translation du point par ce vecteur, puis d'un segment, d'un cercle. Ceci met en exergue la possibilité de réutiliser des fonctions définies par ailleurs.

Je pense que le typage (11.) mériterait d'être présenté bien avant (vers 4/5). D'une part parce que c'est fondamental en caml, et d'autre part parce que ça doit faire chier de voir des 'a et des 'b pendant 11 semaines sans rien comprendre. Tu fais le choix de présenter les fonctions d'ordre supérieur assez tôt, ce serait alors logique de faire pareil pour le typage.

En fait, la manière dont les choses sont présentées permet de ne (presque) pas avoir de contact avec les types génériques. Le polymorphisme paramétrique est donc introduit comme je l'ai décrit ci-dessus (exemple des listes). Ensuite je peux expliquer que les listes c'est tellement bien, qu'il existe une définition pré-existante dans le langage, et je peux leur montrer les opérateurs spécifiques et leur avouer que toutes les fonctions qu'ils ont créées dans les exercices existente déjà.

Pour le reste, tu fais le choix de présenter la programmation impérative bien après la programmation fonctionnelle, ce qui est à mon avis une bonne idée, même si ça risque de mettre dans le flou les étudiants ayant déjà fait de la programmation (impérative). Autant les surprendre un bon coup dès le début ^^

Oui, avec le choix de OCaml, c'est aussi une manière de mettre tout le monde sur un pied d'égalité.

Pour ce qui est de la programmation modulaire et objet, je suis un peu sceptique quant à leur capacité à assimiler tout ça dans un intervalle de temps raisonnable.
Puisque le sujet de ton cours est très généraliste ("Concepts et Techniques de programmation"), on peut penser que leur montrer un peu de POO serait utile, mais je suis un peu dubitatif. Cependant, la POO Ocaml est très intéressante et novatrice (par rapport aux langages impératifs classiques, en tout cas) dans son approche au typage etc., donc ça pourrait être bien qu'ils en aient ne serait-ce qu'une vague idée.

Les modules puis foncteurs sont à mon avis un must, à présenter dans le genre "vous voyez bien qu'on peut faire de la modularité sans POO !"

Je trouve que la POO est difficile à faire passer en quelques heures. Il faut tout de même présenter un certain nombre de concepts de modélisation qui sortent un peu du cadre de ce cours. Les modules et les foncteurs sont hyper-intéressants, mais je pense qu'il faut plus de maturité qu'en ont les étudiants en premier semestre d'université pour les apprécier.

En tous cas, merci pour les conseils.

David.
--

[DavidDeharbe]

J
D'autre part, c'est omniprésent. Je vois mal comment on peut faire un cours sur les "fonctions d'ordre supérieur" et la "curryfication" par exemple, sans rencontrer des types polymorphes.

Il y a un exemple classique de fonction d'ordre supérieur non polymorphique, qui fait mouche avec ces étudiants (qui voient en parallèle le concept de dérivation de fonction en mathématique). De tête, et sans vérifier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
let derive f : (float -> float) -> float -> float =
  let epsilon = 1e-5 in
    (fun x -> (f x) -. (f (x +. epsilon)) /. epsilon

À part cela, il est vrai que les fonctions d'ordre supérieur vont réapparaître dans le traitement des listes (par exemple: fold_left).

Quand à la curryfication, c'est bien simple, puisqu'en OCaml toute fonction n'a fondamentalement qu'un seul paramêtre.

Et je pense que si j'étais étudiant, ça me gênerait de me taper des 'a, 'b et 'c pendant 10 chapitres sans savoir ce que ça veut dire.

Donc, comme je l'ai écrit par ailleurs, jusqu'au moment où le polymorphisme est introduit, rares sont les exercices où les fonctions qu'ils doivent écrire se trouvent être polymorphes. Il s'agit principalement de fonctions comme: "écrire une fonction qui, étant donnés 3 entiers, retourne le plus grand des trois".

Ceci étant dit, il est vrai qu'il est gênant et peu pédagogique d'exposer des concepts sans être capable de les justifier. Introduire le polymorphisme paramétrique lors des premières discussions sur le système de typage ne devrait pas trop augmenter le niveau de difficulté, et leur permettrait effectivement de comprendre ce qui se passe dans ce type de situation.

Cordialement,

David.
--

[SpiceGuid]

À mon avis l'idéal à atteindre pour l'enseignement de la programmation fonctionnelle, ça serait de pouvoir donner un type et l'élève imaginerait quelle est cette fonction puis l'implémenterait, par exemple on donnerait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

val flat_map : ('a -> 'b list) -> 'a list -> 'b list = <fun>

Et l'élève écrirait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
let rec flat_map f l =
  match l with
  | [] -> []
  | h::t -> f h @ flat_map f t;;

De cette façon l'élève serait convaincu que la synthèse de type est bien un mécanisme d'assistance à l'écriture de programmes et il l'utiliserait à son avantage au lieu de le subir à son désavantage.
Caml fait la synthèse de type, l'étudiant fait la synthèse de fonctions.