Inférence de type en Eiffel

[Victorien Elvinger]

Bonsoir à tous !

Je viens discuter d'une proposition que je vais certainement inscrire dans la "Wish List" du langage Eiffel.

Il s'agit d'un mécanisme d'inférence de type. Il s'inspire largement du patron d'attachement dans un souci d'unité.

proposition ici

En quelques phrases :

source as new_target

1. Le mécanisme provoque la création d’une nouvelle variable et son initialisation ('new_target').

2. Le nom de la variable nouvellement créée ne doit pas déjà avoir été utilisé.

3. Le type de la variable nouvellement créée est identique à celui de la source.

4. La variable nouvellement créée est en lecture seule.

[Jocelyn Batton]

Bonjour,

J'ai parcouru ton article concernant cette proposition.

Pourrais-tu donner un exemple concret d'utilisation de ce mécanisme afin de bien comprendre les facilités/sécurités qu'il apporte ainsi que ses limites (sans le mécanisme/avec le mécanisme) ?

Car si je comprends bien ton mécanisme est un "like amélioré" ce qui induit de fortes contraintes sur la variable.

Je ne me suis pas encore vraiment penché sur le concept "attached/detached", mes questions sont peut-être triviales.

Jocelyn B.

[Victorien Elvinger]

Bonsoir,

Ce ne sont pas des questions triviales :)

Je me suis posé également l’utilité d’une telle fonctionnalité.

Cette proposition est principalement motivée par l’envie de rendre Eiffel plus « user-friendly ». Je me suis longtemps demandé si c’était vraiment nécessaire d’introduire un mécanisme supplémentaire autour du typage.

Ce qui m’a décidé est le fait que l’inférence de type a déjà un point d’ancrage dans Eiffel via le patron d’attachement (CAP-able expression). C’est donc « juste » une généralisation.

Il est vrai que le mécanisme que je propose à une fenêtre d’utilisation plus réduite, mais elle ajoute une simplicité et une flexibilité supplémentaire au typage statique.

Il est vrai que les nouvelles variables créées sont plus contraintes : elles sont attachées et en lecture seule.

Mais la deuxième contrainte (lecture seule) pourrait être relâchée (à discuter) et donc permettre l’affectation.

Si j’ai fait ce choix par défaut c’est pour être cohérent avec le patron d’attachement qui créé une variable en lecture seule.

Je ne l’ai pas inséré dans mon article, mais l’introduction de variable en lecture seule permet aussi d’introduire des concepts appréciés en programmation fonctionnelle.

Voici deux exemples:

Remarque : Nous supposerons que « x » est en lecture seule dans le premier. Une possibilité de simuler ce comportement serait d’utiliser une deuxième routine à laquelle on passerait « x » en paramètre.

Exemple "abstrait" :

local

x: like att.something

y: STRING

do

x := att.something

y := "Hello"

x.do_something

-- ...

end

do

att.something as x

"Hello" as y

x.do_something

-- ...

end

La flexibilité supplémentaire par rapport aux ancres est que nous pouvons changer le type de la source sans  nécessité de redéclaration.

Exemple concret : {V_LINKED_LIST}.replace_substring (voir Eiffel Base 2)

replace_substring (s: READABLE_STRING_32; start_index, end_index: INTEGER)

local

new_size: INTEGER

diff: INTEGER

l_area: like area

s_count: INTEGER

old_count: INTEGER

do

s_count := s.count

old_count := count

diff := s_count - (end_index - start_index + 1)

new_size := diff + old_count

if diff > 0 then

grow (new_size)

end

l_area := area

if diff /= 0 then

l_area.overlapping_move (end_index, end_index + diff, old_count - end_index)

end

set_count (new_size)

l_area.copy_data (s.area, s.area_lower, start_index - 1, s_count)

end

replace_substring (s: READABLE_STRING_32; start_index, end_index: INTEGER)

do

s.count as s_count

count as old_count

(s_count - (end_index - start_index + 1)) as diff

diff + old_count as new_size

if diff > 0 then

grow (new_size)

end

area as l_area

if diff /= 0 then

l_area.overlapping_move (end_index, end_index + diff, old_count - end_index)

end

set_count (new_size)

l_area.copy_data (s.area, s.area_lower, start_index - 1, s_count)

end

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Groupe des Eiffelistes Francophones.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

--
Victorien ELVINGER

[Jocelyn Fiat]

Au sujet du "type inference"

Il me semble que ce serait plus propre d'avoir un code comme celui qui suit.

replace_substring (s: READABLE_STRING_32; start_index, end_index: INTEGER)

        local

              s_count
              old_count
              diff

              new_size
              l_area

do

s_count := s.count

old_count := count

diff := (s_count - (end_index - start_index + 1))

new_size := diff + old_count

if diff > 0 then

grow (new_size)

end

l_area := area

if diff /= 0 then

l_area.overlapping_move (end_index, end_index + diff, old_count - end_index)

end

set_count (new_size)

l_area.copy_data (s.area, s.area_lower, start_index - 1, s_count)

end

c.a.d  declarer les locals sans typage sous "local",
et utiliser la syntaxe de l'affectation ":="

Je trouve que cela plus propre, et vraiment en adaqueation avec la notion de "type inference" .
Sans même mentionner le fait que pour le parseur , cela serait plus simple, pas de conflit avec "attached foo as f" .. or even  "across lst as c"

Mais cela n'adresse pas le besoin de local en "lecture seule"

-- Jocelyn

2013/4/12 Victorien Elvinger <cona...@gmail.com>

-- Jocelyn Fiat.

[Victorien Elvinger]

Ta proposition à un certain avantage.

En effet, on peut constater le nombre de variables qui sont mises en jeu.

Je pense que c’est pour cette raison que tu dis qu’elle est plus propre ?

Mais une forme de déclaration est toujours présente.

De plus, nous avons deux formes d’inférence :

— La solution proposée

— Le patron d’attachement (attached x as x_attached)

Il est vrai que je n’ai pas pris en considération le passeur...

La discussion n’intéresse-t-elle personne d’autre ?

[Jocelyn Fiat]

Par plus propre je voulais dire que ca n'imposerait pas d'inclure une toute nouvelle syntaxe.
De plus on declare les locals dans "local .." ce qui a un certain avantage.

Biensur, du tout le "scope" de ces locals sont la routine meme, cela dit dans l'absolu il faudrait eviter les routines trop longues, donc pas si critique.

il y a aussi le Remote Anchor Type  (i.e like {FOO}.bar.value)

Pour le "attached x as x_attached", cela n'etait pas pour repondre a de l'inference, je dirai que l'inference est "cadeau" , mais la c’était surtout pour le status attached et le scope bien defini (et donc readonly).

Concernant la discussion, je suis certain que ca interesse bcp de personnes, mais peut etre qu'un post "in english" serait plus suivi.

La communauté Eiffel inclue beaucoup de francophone, mais la plupart des discussions langages se font en anglais, et vu la taille de la communauté les utilisateurs francophones preferent se concentrer sur les discussions in english.

De mon coté, j'essaie de faire le lien entre la communauté Eiffel internationale et celle-ci plus francophone.

Donc si l'anglais ne te pose pas de soucis, je t'encourage a discuter de tout ceci sur http://groups.yahoo.com/group/eiffel_software/join

Amicalement,
-- Jocelyn F.

2013/4/20 Victorien Elvinger <cona...@gmail.com>

[Victorien Elvinger]

Merci.

Je comprends mieux ta proposition.

Oui je compter de toute manière passé à une audience plus large (in english).

Mais j’ai pensé que passer par ce nouveau groupe francophone avant serait une bonne idée pour dynamiser un peu plus le groupe... :)

--
Victorien ELVINGER

[Jocelyn Batton]

Je confirme, c'était une excellente idée ! :)