You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: