2009/4/29 Gustavo <[email protected]>: > Nossa, então esse mulisp já foi bem famoso um dia... > > Como você tem uns 300 programas, o interessante seria se a gente conseguisse > desenvolver um script que traduz o código. O problema mesmo, pelo visto, vai > ser a declaração das variáveis. Se o namekuseijin estiver certo e as > variáveis locais são declaradas na própria função, então acredito que > inserir um &optional na frente dos parâmetros da função deve funcionar.
Acho que funcionaria dessa forma sim. > resto das variáveis é declarar com defvar (ou defparameter, nos casos que > tem um setf solto por aí), com valor inicial nil. Seria interessante > demarcar as variáveis com asteriscos (por exemplo *pilha*, como é de > costume), mas não é estritamente necessário. Eu comecei fazendo isso, mas estou realmente mais tentado a remover globais e usar parâmetros nas funções. Mas devo dizer que estou fazendo em Scheme, não Lisp. ;) Me parece que a única função realmente necessária é (teorema formula) que retorna 'sim ou 'nao. Ela não é usada em lugar algum. As outras funções são todas usadas em chamadas originadas nessa. Muitas das funções auxiliares mais cripticas como I, C, D e similares poderiam ser definidas dentro das funções que as usam para reduzir lixo no namespace. Dessa forma necessidade de globais também vão desaparecendo... :) > Uma alternativa é criar uma camada de abstração - definir um package com as > macros e funções compatíveis com o mulisp. Eu gosto mais da primeira idéia, > mas essa ainda é uma solução válida. Lisp é perfeito para criar DSLs. Podemos considerar muLisp como uma DSL. :) Em particular, como algum amigo percebeu aí em cima, muitos dos corpos da função usam simplesmente um cond implicito: ((foo? isso) isso) ((bar isso) aquilo) (faz mais isso) (e mais isso) (ate o fim da funcao) E isso deveria ser corretamente encapsulado em (cond ((foo? isso) isso) ((bar isso) aquilo) (t (progn ; eh isso mesmo em CL? (faz mais isso) (e mais isso) (ate o fim da funcao) ))) ; fecha progn t e cond De repente, redefinir defun com uma macro para automaticamente pôr &optionals nos parametros e encapsular esses conds implicitos seria um bom ponto de partida. O código continuaria feio, imperativo e cheio de globais, mas rodaria de primeira, eu acho. Analisar o código não é muito difícil, são só cerca de 800 linhas e mesmo notepad dá conta de mostrar onde são usadas as funções definidas. Ele também implementa um esquema de pattern matching primário para traduzir as formulas, que parecem não ser escritas em notação prefixada, mas infixada. Não parece ter muito IO texto como a princípio pensei: put é para criar assoc lists. :P Um desafio bastante interessante e nobre, de qualquer forma: ajudar pesquisadores brasileiros a recuperar código antigo em uma linguagem proprietária morta e traduzí-la para uma linguagem padrão com várias implementações abertas... :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lisp-br" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/lisp-br?hl=en -~----------~----~----~----~------~----~------~--~---
