% vim:tw=74:
\section{Conclusões e Trabalho Futuro}

Consideramos que o trabalho realizado atinge os objectivos propostos.
Pensamos que o módulo desenvolvido atingiu um grau de maturidade em que
pode ser divulgado para o público em geral e para a comunidade \ac{Perl}
em particular. Um dos próximos passos será disponibilizar este módulo no
\ac{CPAN} de forma a obtermos \emph{feedback} de outros programadores.

Um possível desenvolvimento será procurar integrar este trabalho com
outras ferramentas do projecto Natura. Existem também outro projecto
ligado a cronologias, o \ac{HEML}. Este projecto usa um formato de
ficheiros em \ac{XML} para descrever as cronologias. Um futuro trabalho
será a construção de um módulo que seja capaz de importar cronologias
neste formato e até exportá-las. Se isto for jeito podem-se usar as
ferramentas disponíveis na página deste projecto para manipular cronologias.
Convém referir que, apesar de não ter sido feita nenhuma integração
directa entre ambos os projectos, foram aproveitadas ideias do \ac{HEML} e
tentou-se que a linguagem definida fosse próxima da já existente, apesar
de seguirem abordagens diferentes (\ac{XML} vs. \ac{DSL}).

Um campo que foi experimentado mas não foi incluido no módulo desenvolvido
foi a criação de \emph{timelines} cronológicas. Para tal foi investigado o
módulo \ac{Perl} \texttt{Image::Timeline} mas, infelizmente, ainda
apresenta algumas limitações. Poderia ser feito um trabalho de integrar
essa funcionalidade nas cronologias que daria mais um modo de visualização
à aplicação Web. Um trabalho conjunto de colaboração com o autor do módulo
não deverá ser posto de parte.

Outro aspecto que deve ser desenvolvido é o \emph{parser} da linguagem
ChronL. O objectivo de ter um parser funcional foi atingido mas este
apresenta alguns problemas de \emph{performance} quando manipula ficheiros
com alguma complexidade. Para resolver isto apresentam-se duas possíveis
soluções. A primeira implicaria em optimizar a gramática, talvez até
impondo algumas limitações extra à linguagem, de forma a que a
complexidade fosse reduzida. Uma segunda alternativa passaria por
implementar o \emph{parser} nalguma linguagem mais eficiente (uma escolha
sensata seria C+lex+yacc) e interligá-lo de alguma forma com o código em
\ac{Perl} (nesse caso uma análise do XS\footnote{O XS é um formato de
descrição de interfaces usado para criar uma ligação em C e Perl.} ou do
SWIG\footnote{O \ac{SWIG} é um compilador destinado a integrar código
C/C++ com várias outras linguagens.} teria de ser efectuada).

Apesar destas limitações consideramos que tivemos sucesso no trabalho
desenvolvido pois está de acordo com os objectivos propostos inicialmente.
