Discussion :

[hains]

Christophe et moi venons d'avoir une discussion sur ma possible contribution au projet en tant que spécialiste, ainsi que des idées plus générales.

Je mentionne des idées qui me semblent prioritaires et qu'on aurait avantage à garder en tête dès le début:

1° R++ peut reprendre un maximum de choses de R mais s'imposer d'avoir R comme sous-langage risque de rendre impossible d'en éliminer les défauts.

2° [exemple de 1°] Les entitées peuvent être fortement typées.

3° [exemple de 2°] Les colonnes peuvent être typées différemment des lignes. Par ex une ligne serait un tuple, d'un type produit, et une colonne un type spécial (num column) ou (string column) etc.

4° [entorse à 2°] Peut-être faut-il une entorse à la séparation entre nombres en virgules flottante, doubles, entiers... et n'avoir qu'un seul type (num) ?

5° Si on peut associer aux entités des méta-données sur leur taille ce serait idéal pour mettre au point une gestion efficace du parallélisme.

Vos commentaires seront les bienvenus.
Gaétan

[Christophe Genolini]

1° Je suis totalement d'accord avec toi : si on est "parfaitement" compatible, on va hériter des erreurs. Personnellement, je pense qu'être "propre et efficace" est plus important que d'être compatible. Par contre, assurer un minimum de compatibilité permettra aux utilisateurs de migrer facilement de R vers R++. Au final, si R++ est un bon logiciel et que la migration de R vers R++ est facile, on devrait rapidement toucher une large communauté.

2° Oui, clairement nous utiliserons des types.

3° Oui.

4° Effectivement, c'est une simplification intéressante. Je pense qu'on peut proposer deux niveaux : 1/ l'utilisateur de base n'aurait à sa disposition que integer et numeric (*). 2/ l'expert aurait le choix de préciser long, short, double ou float.

5° Je ne suis pas sur de comprendre ce point...

Christophe

(*) en statistique, il est important de faire la différence entre les entiers et les réels