Résumé

  • LAP6 présentait un long manuscrit comme un rouleau mobile : l'utilisateur ajoutait ou supprimait une ligne au point courant et voyait immédiatement le nouvel état du texte.
  • Enregistrer ce manuscrit modifiait une entrée nommée sur LINCtape ; convertir, charger, exécuter et valider une expérience restaient des opérations distinctes.
  • Wilkes a écrit LAP6, tandis que les sources attribuent aussi la technique d'édition sur bande à Mishell J. Stucki et Severo M. Ornstein, le cadre du LINC à Wesley Clark et son équipe, et une part des exigences et des essais aux utilisateurs et collègues de Washington University.

Une ligne de code apparaît sur l'écran du LINC. L'opératrice s'y place, la supprime, saisit sa remplaçante. Les lignes suivantes remontent et leur numérotation est recalculée. Sur une machine limitée à 2 048 mots de 12 bits, cette scène ne relève pas de l'ornement ergonomique : elle constitue le cœur d'un environnement de développement.

Dans son article de 1970, « Conversational Access to a 2048-Word Machine », Mary Allen Wilkes présente LAP6 comme un système en ligne d'édition, de classement automatique, de gestion de fichiers, de préparation et d'assemblage des programmes. Son apport fut d'enchaîner ces gestes tout en laissant apparaître le moment où la nature de la preuve changeait.

Le manuscrit, objet de travail visible

Un manuscrit LAP6 pouvait contenir toute suite utile de caractères saisis au clavier. Le code source était le cas habituel, sans être un format imposé. Le rouleau standard occupait 45 blocs de bande, soit 23 040 caractères, alors que deux blocs seulement devaient être manipulés en mémoire à un instant donné.

Le texte avançait pendant la frappe. Un potentiomètre réglait le nombre de lignes affichées. Les numéros de ligne servaient de repères relatifs et étaient recomposés après une modification. On pouvait rejoindre une zone éloignée par son numéro, puis faire défiler le rouleau d'une image ou d'une ligne dans les deux sens. Ajouter ou supprimer une ligne ne demandait pas d'apprendre un langage de commandes séparé : l'écran intégrait directement le changement.

L'article distinct de Wilkes sur l'édition par défilement décrit le mécanisme. Le texte demeurait une chaîne continue sur des adresses fixes de la bande. Une zone de travail de 512 caractères au point de rupture absorbait insertions et suppressions, puis le contenu était réinséré au fil du déplacement du rouleau. L'algorithme agissait sur le texte lui-même, sans accumuler une liste invisible de corrections à réconcilier plus tard.

L'affichage prouvait donc un fait précis : l'état courant du manuscrit avait changé. Il ne prouvait ni qu'une autre copie nommée sur bande avait été mise à jour, ni que le nouveau texte s'assemblerait, ni que le programme obtenu ferait ce que l'expérience attendait.

Le classement ajoutait un état et un risque de panne

Un index de deux blocs décrivait les fichiers LAP6. Une entrée de type manuscrit et une entrée binaire pouvaient porter le même nom sans désigner le même objet. La sauvegarde copiait le manuscrit courant, ou une plage choisie, dans une entrée. D'autres commandes déplaçaient entre deux bandes les manuscrits, les binaires ou l'ensemble des entrées non dupliquées.

LAP6 cherchait des blocs libres contigus près de l'index. Lors d'un remplacement, il pouvait choisir un autre emplacement physique. Si le nom existait déjà, l'écran affichait REPLACE? et attendait une touche de décision. Cette confirmation protégeait le nom contre un écrasement distrait ; elle ne certifiait pas une transaction indivisible.

Le LAP6 Handbook est explicite. Une fois l'index mis à jour, une interruption n'annule plus le classement. Surtout, le système écrit l'index avant l'entrée correspondante. Un incident de bande entre les deux peut donc laisser un index qui annonce un fichier absent. L'index n'avait pas de copie de secours.

Une sauvegarde réussie établissait ainsi davantage qu'un écran corrigé : le système avait agi sur une entrée nommée. Mais la fiabilité dépendait encore de la cohérence durable entre bande, index et octets enregistrés. Les procédures de récupération du manuel existent précisément parce que cette cohérence pouvait se rompre.

Assembler et exécuter n'étaient pas des synonymes d'enregistrer

Pour un programme source, CONVERT assemblait le manuscrit courant en binaire. LAP6 pouvait afficher les erreurs de définition de symboles avec leurs numéros de ligne, l'intervalle de mémoire requis et la table des symboles. En cas d'erreur, l'utilisateur revenait au manuscrit, corrigeait et lançait une nouvelle conversion.

LOAD constituait une étape supplémentaire. Il plaçait en mémoire le binaire courant ou un binaire classé, puis le démarrait selon la convention documentée. Garder la bande de LAP6 montée permettait de retrouver vite le texte, la table des symboles, la correction et un nouvel assemblage. Ce cycle court évitait une partie des corrections directes du binaire ; il ne transformait pas une édition en résultat d'exécution.

La chaîne de preuve restait donc ordonnée : l'affichage attestait un état de source ; le classement, une entrée nommée ; la conversion, un binaire et ses diagnostics ; le chargement, un binaire particulier en mémoire ; l'essai, un comportement observé. Enfin, seul un protocole extérieur pouvait dire si l'instrument relié et l'expérience avaient produit un résultat valide.

La frontière des contributions est elle aussi nécessaire

Selon son témoignage oral au Computer History Museum, Wilkes a écrit l'essentiel de LAP6 en 1965 sur un LINC installé dans le salon de ses parents à Baltimore. Elle explique avoir construit le système en grande partie à partir de zéro, en réutilisant certaines routines antérieures, puis envoyé la version LAP5 à Saint-Louis pour plusieurs mois d'usage avant la diffusion générale.

Cette source étaye solidement son rôle d'autrice, sans effacer l'écosystème. Wesley Clark dirigeait le projet LINC et a cosigné avec Wilkes « Programming the LINC ». Le manuel crédite expressément Mishell J. Stucki et Severo M. Ornstein pour la technique de manipulation de bande employée par l'éditeur. Les collègues de Washington University ont mis à l'épreuve les versions préliminaires ; les visites aux laboratoires LINC ont façonné les besoins. MIT Lincoln Laboratory avait fourni le cadre antérieur du LINC et de son simulateur.

Certaines évocations secondaires brouillent également les noms. Les documents primaires étudiés identifient Mishell J. Stucki et Severo M. Ornstein. Ils n'établissent pas de contributions LAP6 distinctes pour des personnes nommées « Philip Mishell » ou « Ted Severo ». Une histoire responsable conserve cette incertitude au lieu de fabriquer des identités ou des rôles.

Sources