Re: function ... return <objet li mité>;

Je vois avec plaisir passer des courriels sur les choix du langage et 
les choix de compilation.
Je mets mon grain de sel, ... pour une seule fois.

Pour Ada 95, j'avais lu avec délectation ( je confirme délectation, au 
moins pour la partie que je connais bien, la programmation concurrente) 
le livre consacré à
Ada 95 rationale (publié entre autre par Intermetrics en 1995);
On y trouve un état du savoir faire de l'époque et une explication très 
complète et très claire des choix du langage, des raisons de prendre ou 
de ne pas prendre certains aspects.
Sa lecture m'avait convaincu de la qualité du langage. J'ai toujours 
conseillé la lecture de Ada 95 rationale (c'est aussi un bon test de 
niveau de connaissance; tout informaticien digne de ce nom devrait 
pouvoir le comprendre)
Avec Ada 2005, certaines mesures de prudence ont été levées et on a 
tenu compte de l'expérience de Ada 95, des besoins et des progrès de la 
discipline. Tout cela est apparu dans les divers congrès Ada.

Ma question.
Existe-t-il un effort de synthèse comparable à Ada 95 rationale pour 
présenter les concepts et mécanismes disponibles parmi lesquels des 
choix ont été faits pour le langage et pour expliquer les raisons de 
ces choix? Ce serait une mise à jour de Ada 95 rationale en un Ada 2005 
rationale, complet pour l'ensemble du langage.

Suggestion
Si cela n'existe pas, Ada France ne pourrait-il pas se donner comme 
projet de faire des fiches permettant de compléter les divers chapitres 
de Ada 95 rationale, ou au minimum des parties "Highlights of Ada 95 et 
"Overview of the Ada Language". Ce serait aussi une bonne façon de 
continuer à promouvoir sinon le langage, au moins les concepts et choix 
de celui-ci. Cela permettrait à d'autres langages de partir sur des 
bases plus saines.

Claude Kaiser

Le 7 déc. 07, à 03:13, Thomas De Contes a écrit :

>
> Le 2 nov. 07 à 19:55, Jean-Pierre Rosen a écrit :
>
>> Thomas De Contes a écrit :
>>>> Effectivement. Le problème est qu'en Ada 95, on était obligé de
>>>> faire des acrobaties pas possibles: normalement une fonction
>>>> renvoie une *valeur*, or on ne peut pas copier une valeur limitée.
>>> des acrobaties, tu veux dire au niveau du compilateur ?
>> Et aussi au niveau de la définition formelle du langage.
>>
>>> (c'était que pour les types limités ? c'était pas aussi pour des
>>> choses comme les gros record ?)
>> Un compilateur a toujours le droit de choisir son mode de passage
>> de paramètres, mais pour ce cas là, c'était des règles spéciales au
>> niveau du langage.
>
> ah ?
> ça me surprend un peu, parce qu'au niveau du langage tout me
> paraissait logique
>
>
>>> En fait, j'aurais tendance à dire "tant pis si ça donne du travail
>>> au compilateur, il est là pour ça", son but c'est de simplifier la
>>> tache du programmeur en vérifiant tout ce qui est droit de
>>> modifier, droit d'affectation, etc ...
>> Ada a été très loin dans cette voie, les rares cas où on a eu un
>> peu pitié de ceux qui font les compilateurs, c'est quand il y avait
>> vraiment un GROS problème - ou une inefficacité cachée: on préfère
>> que l'utilisateur soit au courant de ce qui se passe plutôt que de
>> lui faire croire qu'il dispose d'une fonctionnalité dont
>> l'implémentation est catastrophique.
>
> bon ben, si tu dis qu'il y avait vraiment de GROS problèmes, je te
> crois :-)
> et je me met donc "au travail" pour comprendre "les nouvelles
> manières de faire qui en découlent" ...
>
>
>
>>> Je me suis donné comme règle de programmation de ne jamais
>>> utiliser de pointeurs dans la partie publique des paquetages
>> Oui, mais il ne faut pas confondre pointeur et référence. C'est en
>> celà qu'un accès anonyme est différent d'un type accès explicite.
>
> donc
> type machin is access truc;
> ça fait un type pointeur, cad que toutes les variables de type machin
> sont des pointeurs,
>
> alors que si on voit "access truc" en paramètre d'une procédure, sans
> que le type machin soit cité,
> c'est une référence,
>
> c'est bien ça ?
>
>
>> En particulier, il n'implique pas d'allocation dynamique.
>> Et les règles (obscures il est vrai) sur les niveaux d'accessibilité
> (j'ai cru comprendre que si les variables globales n'existaient pas,
> ça simplifierait bcp de choses à ce niveau là, c'est vrai ?)
>> empêchent de créer un accès sur une variable locale qui aurait
>> disparu.
>
> ça veut dire que je peux utiliser "access truc" autant que je veux
> dans la partie publique des paquetages,
>
> tant que je ne déclare pas de type machin (dans le code utilisateur
> non plus, bien entendu),
> je peux utiliser le paquetage comme je veux sans faire attention,
> il n'y a pas de risque de se retrouver dans un état absurde
> (référence qui pointe sur rien) ?
>
> super, je vais pouvoir programmer (un peu) différemment :-))
>
>
> tu parlais de "généralisation des accès anonymes en Ada2005",
> ça veut dire que maintenant on peut mettre "access truc" à des
> endroits où on pouvait pas avant ?
>
> par exemple, comme type renvoyé par une fonction ?
>
>
> -- 
> j'agis contre l'assistanat, je travaille dans une SCOP !
>
>
> _______________________________________________
> Site WWW de l'association Ada-France: http://www.ada-france.org/
> [email protected]
> http://www.ada-france.org/mailman/listinfo/ada-france


_______________________________________________
Site WWW de l'association Ada-France: http://www.ada-france.org/
[email protected]
http://www.ada-france.org/mailman/listinfo/ada-france