Le langage LTR3 est dans son principe très traditionnel :
- Identifier dans le langage une structure de données, c'est définir un type. Il en résulte alors nombre de complications qui sont liées au typage fort : pas de conversion implicite de types, pas d'« objets mutants » (des objets qui changent de type parce que l'utilisateur a changé dans sa manière de les regarder), peu d'outils pour structurer les types (héritage, dérivation, ...).
- Identifier un traitement, c'est définir un sous-programme. Il faut alors lui trouver un nom, lui trouver un endroit pour le définir (ce qui n'est pas nécessairement simple si le traitement se retrouve en de nombreux points du programme). Il résulte de la définition syntaxique du sous-programme qu'à l'exécution on retrouvera ce sous-programme : l'exécution du traitement demande un changement de contexte, parfois inutile, souvent coûteux ; on localise le traitement à un point donné du code objet, ce qui complique la gestion des pages mémoires (l'"overlay") et ne conviendrait pas dans le cas d'une exécution distribuée.
Comme il a été dit, l'atelier ENTREPRISE ne descend pas à un niveau plus précis de détail que l'interface, le corps ou le module-programme. On pourrait en fait attendre de lui qu'il réalise une analyse plus fine des objets sources qu'il manipule.
Le module est une unité de programme qui sert à définir conjointement plusieurs éléments du langage (des constantes, des types, des sous-programmes) qui travaillent tous dans le "même esprit" – c'est-à-dire généralement sur une même structure de données. Cela ne signifie nullement qu'un utilisateur d'un tel module souhaite avoir une vue complète des services présentés par le module – typiquement un premier utilisateur ne s'occupe que d'empiler des valeurs et un deuxième de les dépiler : les deux utilisateurs ont la même visibilité du module mais n'en ont pas la même vision. L'atelier, en s'arrêtant au module dans son contrôle sur les objets, s'arrête aussi à la visibilité des identificateurs LTR3 ; un éditeur structuré permettrait de plus finement exprimer le lien de dépendance de l'utilisateur vis-à-vis de la collection des services qui lui sont proposés, dont il a potentiellement l'usage mais qu'en pratique il n'utilisera pas en totalité.
(le commentaire appartient en propre au module : sa modification n'entraîne aucun contrôle sur les dépendances).