Resumo

  • O LAP6 mostrava um manuscrito longo como um rolo móvel: o usuário adicionava ou apagava uma linha na posição corrente e via a mudança incorporada ao texto.
  • Salvar o manuscrito atualizava uma entrada nomeada na LINCtape; converter, carregar, executar e validar um experimento continuavam sendo operações posteriores e distintas.
  • Wilkes escreveu o LAP6, mas o registro verificado também atribui a técnica de edição com manipulação de fita a Mishell J. Stucki e Severo M. Ornstein, o contexto do LINC a Wesley Clark e sua equipe, e parte dos requisitos e testes aos usuários e colegas da Washington University.

Uma linha de código aparece na tela do LINC. A operadora chega até ela, apaga-a e digita a substituta. As linhas seguintes se fecham; a numeração muda; a correção fica visível no contexto. Em uma máquina com apenas 2.048 palavras de 12 bits, isso não era um enfeite de interface. Era o centro de um ambiente de desenvolvimento.

No artigo de 1970 “Conversational Access to a 2048-Word Machine”, Mary Allen Wilkes apresenta o LAP6 como um sistema on-line de edição de texto, arquivamento automático, manutenção de arquivos, preparação e montagem de programas. A realização foi ligar essas atividades sem fingir que elas produziam a mesma espécie de evidência.

O manuscrito era um objeto de trabalho visível

No LAP6, um manuscrito podia ser qualquer coleção útil de caracteres do teclado. Código-fonte era o uso típico, mas o sistema não impunha esse formato. O rolo padrão ocupava 45 blocos de fita, ou 23.040 caracteres, enquanto apenas uma parte pequena precisava estar na memória principal a cada momento.

O texto avançava conforme o usuário digitava. Um potenciômetro regulava quantas linhas ficavam visíveis. Os números de linha eram referências relativas e eram refeitos depois de cada alteração. Para chegar longe, indicava-se uma linha; perto do destino, combinações de teclas moviam o rolo por uma tela ou uma linha, nos dois sentidos. A edição não exigia uma linguagem separada: uma linha era acrescentada ou eliminada no ponto corrente e a tela incorporava a mudança.

O artigo específico de Wilkes sobre edição por rolagem explica o mecanismo. O texto permanecia como uma sequência contínua em endereços fixos da fita. Uma área de 512 caracteres no ponto de corte absorvia inserções e exclusões, e o material voltava a ser emendado à medida que o rolo se movia. O algoritmo alterava o texto diretamente, sem manter uma lista oculta de mudanças para reconciliar depois.

O resultado visível provava algo limitado: o manuscrito corrente havia mudado. Não provava que outra cópia nomeada na fita também mudara, que o novo texto pudesse ser montado ou que o programa resultante se comportaria como pretendido.

Arquivar criava outro estado e outro limite de falha

Os arquivos do LAP6 eram governados por um índice de dois blocos. Uma entrada podia ser manuscrito ou programa binário. Eram tipos diferentes e podiam ter o mesmo nome sem ser o mesmo objeto. O comando de salvamento levava o manuscrito corrente, ou um trecho escolhido, a uma entrada. Outros comandos copiavam entre duas fitas manuscritos, binários ou todas as entradas que não estivessem duplicadas.

O sistema procurava blocos livres contíguos perto do índice. Uma substituição não garantia reutilizar a localização física anterior. Quando o nome já existia, a tela mostrava REPLACE? e esperava uma tecla de decisão. A pergunta evitava uma sobrescrita distraída; não era um certificado de transação atômica.

O LAP6 Handbook torna a limitação concreta. Depois que o índice é atualizado, uma interrupção já não desfaz o arquivamento. Além disso, o LAP6 escreve o índice antes da entrada correspondente. Uma falha de fita entre as duas etapas pode deixar um índice que descreve uma entrada inexistente. O índice não tinha cópia de segurança.

Salvar estabelecia mais do que uma tela editada: o LAP6 tinha agido sobre uma entrada nomeada. Ainda assim, o uso confiável dependia de fita, índice e conteúdo continuarem coerentes. Os procedimentos de recuperação do manual existem justamente porque essa coerência podia falhar.

Montar e executar não eram sinônimos de arquivar

Para programas-fonte, CONVERT montava o manuscrito corrente em forma binária. O LAP6 podia exibir erros de definição de símbolos com números de linha, o intervalo de memória exigido e a tabela de atribuição de símbolos. Diante de erros, o usuário voltava ao manuscrito, corrigia e convertia outra vez.

LOAD era outra operação. Levava à memória o binário corrente ou um binário arquivado e o iniciava segundo a convenção documentada. Manter a fita do LAP6 montada facilitava retornar ao texto, consultar a tabela de símbolos, corrigir e montar novamente. O ciclo rápido reduzia a necessidade de remendar o binário; não transformava uma edição do código em resultado de execução.

A cadeia de evidência continuava sequencial: a tela mostrava o estado da fonte; o arquivamento registrava uma entrada nomeada; a conversão produzia um binário e diagnósticos; o carregamento colocava um binário específico na memória; o teste observava sua execução. Um protocolo externo ainda precisava demonstrar se o instrumento conectado e o experimento haviam produzido um resultado válido.

A fronteira de autoria também importa

Segundo seu depoimento oral ao Computer History Museum, Wilkes escreveu a maior parte do LAP6 em 1965, em um LINC instalado na sala da casa de seus pais em Baltimore. Ela recordou ter desenvolvido o sistema em grande medida do zero, reaproveitando rotinas anteriores quando úteis, e enviado a versão LAP5 a St. Louis para meses de uso antes da distribuição geral.

É uma evidência forte de autoria, não uma licença para apagar o entorno. Wesley Clark liderou o projeto LINC e assinou com Wilkes “Programming the LINC”. O manual credita expressamente Mishell J. Stucki e Severo M. Ornstein pela técnica de manejo de fita usada no editor. Colegas da Washington University testaram versões preliminares; visitas a laboratórios LINC moldaram a especificação. O MIT Lincoln Laboratory ofereceu o ambiente anterior do LINC e de seu simulador.

Alguns relatos secundários também embaralham nomes. As fontes primárias analisadas identificam Mishell J. Stucki e Severo M. Ornstein. Elas não comprovam contribuições separadas ao LAP6 por pessoas chamadas “Philip Mishell” ou “Ted Severo”. Uma história responsável preserva a discrepância em vez de inventar identidades ou redistribuir crédito.

Fontes