Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimiser la representation des types sommes #3201

Closed
vicuna opened this issue Feb 13, 2002 · 1 comment
Closed

Optimiser la representation des types sommes #3201

vicuna opened this issue Feb 13, 2002 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Feb 13, 2002

Original bug ID: 886
Reporter: administrator
Status: closed
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

est-ce qu'il a été envisagé d'utiliser des représentations moins uniformes
des valeurs de type somme, pour éviter de créer des blocs inutiles ?

Par exemple, si on déclare:

type t = A of string | B | C

il n'est pas nécessaire de 'boxer' le constructeur A: le tag dynamique de
l'argument string permet de le distinguer de B et C.

Plus délicat:

type t = A of int list | B | C

Ça marche encore si l'on représente B par 1 et C par 2; 0 représentant
déjà (A []).

Cas trivial:

type t = A of ... [ 1 seul constructeur ]

(ça c'est utilisé quand on veut éviter des types récursifs, ou avoir
de la récursion polymorphe dans les déclarations, ou simplement
pour rendre le code plus lisible)

Évidemment, pour les types paramétrés (type 'a t = A of 'a | B), on ne
peut pas faire grand chose, mais ce n'est pas grave.

L'application principale, ce serait d'avoir des types "option" leger
(une impression de déjà vu ?).

Le problème que je vois, c'est que l'interface d'un module n'est plus
suffisante pour determiner la représentation des types qu'elle définit;
je vois deux solutions:

1- interdire les pertes d'information dans l'interface qui changerait
la representation d'un type (par exemple en en rendant un autre
abstrait); il faudrait dire dans l'implémentation quels types sont
'optimisés', parce que dans le cas général, on ne veut pas de
restriction

2- donner dans la déclaration de type (et l'interface) la représentation
concrète de chaque constructeur de valeur

Le 2- donnerait quelque chose comme:

type t = A of int list | B { 1 } | C { 2 }

Ça aurait aussi l'avantage de pouvoir faire:

type t1 = A { 0 } | B { 1 }
type t2 = C { 2 } | D { 3 }
type t = T1 of t1 | T2 of t2 | E { 4 }

et les valeurs de t ne seraient pas boxées.

Bon, ça peut sembler bidouillesque au possible, mais j'ai l'impression que
ça peut avoir un impact non négligeable sur les performances ...

Alain

@vicuna
Copy link
Author

vicuna commented Nov 13, 2002

Comment author: administrator

Too complex (pattern-matching) and irregular (consider let rec x = A x ....).
Sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant