Índice
Informações
Sintaxe & Semântica e as linguagens de programação
O texto que se segue é do tipo "enriqueça o seu vocabulário", nada muito importante, explicando a sintaxe e a semantica em linguagens de programação. Dedico àqueles que, como eu, são autodidatas. Lembrando que o texto está escrito em português de Portugal.
Livro: Introdução ao Pascal
Autor: Boris Allan
Editora: Verbo (Portugal)
Ano: 1984
"SINTAXE E SEMÂNTICA
Muitas pessoas que falam linguagens vulgares produzem expressões gramaticalmente incorretas, mas mesmo assim as outras pessoas compreende-nas. Em linguagens de programação, havendo uma expressão (digamos, uma linha de programa) gramaticalmente incorreta, o computador não entenderá o significado dessa linha.
Entre *significado* e *gramática* existe uma distinção crucial para linguagens de computador, mas não tão importante para linguagens de comunicação vulgares. Por vezes, nestas linguagens, a diferença entre sintaxe e semântica é o elemento fundamental de certo tipo de humor. Um trocadilho, um jogo de palavras e certas anedotas dependem da habilidade para extrair mais de um significado de uma mesma expressão.
O estudo do significado de uma expressão num discurso vulgar e do significado de uma linha num programa de computador recebe o nome de *semântica*. Assim, o estudo de uma linguagem de computador é o conjunto do estudo da sintaxe e da sua semântica.
Podemos considerar *naturais* as linguagens faladas, vulgares. Com linguagens naturais, as regras nem sempre são são explicitas (como o são no Pascal) e não existe uma forma obrigatória de inglês, por exemplo. As linguagens naturais não são planeadas (como as linguagens de computador) e evoluem. Uma das poucas linguagens humanas que teve de ser planeada (em vez de evoluir, simplesmente) foi o esperanto. A sintaxe do esperanto é tão regular e fixa que esta é talvez a única linguagem humana facilmente computadorizável. Não se considera o esperanto uma boa linguagem, quanto a flexibilidade de significados, e isto possivelmente devido à sua rígida sintaxe.
Muitos programas para computador são mal escritos porque o programador usa bastantes vezes na escrita de programas as fórmulas que emprega ao falar a sua língua nativa. É notório que a habilidade para *inventar* e a falta de precisão, aceitáveis numa linguagem oral, já não o são tanto para programar um computador.
Dado que o estudo da gramática se está a tornar cada vez menos importante no ensino actual das línguas, inúmeras vezes os pragramadores novatos, iniciados, não compreendem a importância da sintaxe na sua própria linguagem falada, quanto mais uma linguagem de programação. Na fala é possível usar a linguagem de modo impreciso (facto especialmente notável na língua inglesa) e, mesmo assim, ser entendido, mas isto já não acontece com um computador.
Existem, pelo menos, cinco razões principais para que um computador tenha dificuldades em entender uma linguagem natural, e cada uma destas razões explica porque é que as linguagens de computador, para serem eficazes, devem ser tão difentes. As cinco razões também explicam porque não é factível a programação de um computador em *inglês* (e também noutras linguas humanas) e porque é que as linguagens de computador que sejam do tipo da língua inglesa estão, provavelmente, condenadas ao fracasso.
Razão 1. O problema do tamanho e complexidade da sintaxe das linguagens naturais (assumindo que conhecemos essa sintaxe).
Razão 2. O problema da ambiqüidade já mencionado.
Razão 3. A necessidade de possuir uma grande dose de *senso comum* para entender mesmo o mais simples dos textos. Cada pedaço do texto deve ser colocado num dado contexto, embora alguns ramos da crítica literária digam que isso não é necessario. Valerá a pena considerar a quantidade de *senso comum* necessária para entender uma história contada por uma criança.
Razão 4. O problema de número de frases que podem ser analisadas em termos de *significado* de partes da frase e, mas ainda, como instruir o computador para entender o significado dos *significados*. Esta razão é importante, por isso lembremo-nos dela.
Razão 5. O problema de tempo e memória. Para que um computador entenda o conteúdo e arranjo mesmo do parágrafo mais pequeno que se refira à razão 4, é preciso grande quantidade de memória e muito tempo para escrever o programa que o vai fazer. É muito difícil de escrever um programa de computador para desempenhar estas tarefas, dado que requer técnicas de pesquisa e codificação bastante complicadas e inteligentes."
Alinhamento de dados na memória
Se estiver se perguntando pra que serve alinhamentos de dados (que é uma daquelas opções disponíveis nos compiladores):
"Intel Architecture Software Developer’s Manual Volume 1: Basic Architecture
5.1.1. Alignment of Words, Doublewords, and Quadwords Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. (The natural boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by four, and addresses evenly divisible by eight, respec-tively.) However, to improve the performance of programs, data structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is that the processor requires two memory accesses to make an unaligned memory access; whereas, aligned accesses require only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles to access it; a word that starts on an odd address but does not cross a word boundary is considered aligned and can still be accessed in one bus cycle."
Obs.: a partir dos Pentiums entra em jogo o cache, também.
Automato de estados finitos
Caso já saiba o que são Expressões Regulares mas não saiba o que é autômato de estados finitos, o texto refere-se ao programa Lex.
Livro: lex & yacc - First Edition
Autores: Tony Mason and Doug Brown
Editora: O'Reilly & Associates, Inc.
Ano: 1991
"FINITE AUTOMATA
Lex takes a set of regular expressions and a description of what todo when the regular expression is detected; from this, it builds a finite automaton in C. A finite automaton is a good model for programmers, because such a machine is very simple to describe and understand and, most importantly, can be implemented on a real computer to run quickly and efficiently.
A finite automaton is an abstract machine consisting of a finite set of states and transitions from state to state, based upon the input symbols. There are exactly one starting state and a set of terminal states. Each state is either an accepting state or a nonaccepting state. The finite automaton begins in the initial state and examines the first input token. For Lex, a token corresponds to the next character. The machine then moves to the next state based upon that token.
To demonstrate a finite automaton graphically, we have constructed a state diagram (in figure 1-5) of a simple finite state machine designed to accept a real number without an expoent. Using regular expression sintax, such a number can be expressed as follows.
[0-9]*(\.[0-9]+)?
The machine to tokenize this input has four states and six transitions. We will call the four states s0, s1, s2 and s3. Now we can define the transition function to be the function that maps the current state, plus the current input token, to a new state. Thus, to traverse the machine, we continue to feed new tokens, along with the current state, into the transition function to determine the next state. If there are no transitions out of the current state with the current input (say, for instance, an extra decimal point is seen, rather than a digit), the finite automaton does not accept the input. If there is no more input and the finite automaton is in an accepting statem, the finite automaton accepts the input. If there is no more input and the finite automaton is not in an accepting statem, the finite automaton does not accept the input.
Figure 1-5. Model of a finite automaton
In figure 1-5, the finite automaton's transition function can be described as a set of triples (initial_state, input_token, new_state), as follows:
(s0, [0-9], s1)
(s0, '.', s2)
(s1, [0-9], s1)
(s1, '.', s2)
(s2, [0-9], s3)
(s3, [0-9], s3)
when the accepting states are s1 and s3. The figure, as well as the formal state description, is equivalent to the regular expression. One reason finite state machines, such as the one above, are important is that they are equivalent to regular expressions. That is, any regular expression can be property that allows lex to take the regular-expression -based lexical analyzer description and build a finite state machine in C. Finite state machines are less powerful than Turing machines (the type of machine all computer languagens can "implement"), so the task is possible (although still not trivial).
Aside from explaining why lex can even work, the description of the state machine is very useful tool. State machines, independent of lex, appear in many places: communications protocols, device drivers, and even applications programs. For the lex userm, the visual model of the finite state machine is an invaluable debugging tool, as well as an aid for gaining an insight into what the specific lex grammar is doing.
Of course, it is not necessary to construct the finite state machine for each lex input file, but when the lex input file has become quite complex, it can be useful to provide an alternative model of what precisely is happening inside. In fact, it is possible to use lex and yacc to generate a program which will create the finite state model (visually, or as a mathematical description) of the lexical analyzer.
Lex relies upon our understanding of finite automata to create its lexical analyzers. Because of this, it is occasionally possible to make lex "blow up" if the language is unusually ambiguous (really "non-deterministic") and hence the warning in the original lex paper:
'There are pathological expressions which produce exponential growth of the tables when converted to deterministic machines; fortunately, they are rare.' "
O que é uma WORD
Livro: Guia Prático para Programadores 80386
Autor: Ross P. Nelson
Editora: Makron Books
Ano: 1991
Introdução página XIV
"TIPOS DE DADOS
O 80386 pode operar com diversos tipos de dados. Os tipos mais comuns são as quantidades em 8 bits, 16 bits e 32 bits. Neste livro, uma quantidade de 8 bits é chamada byte, em 16 bits é chamada palavra, e em 32, palavra dupla (doubleword), ou dword. Esta nomenclatura não é usual, já que a dimensão dos dados-padrão de um computador é o que comunmente denominamos palavra (word). Nos computadores VAX, da Digital Equipment, a quantidade em 32 bits é uma palavra, e a de 16 bits é uma meia palavra (halfword); isto também é verdadeiro para a família 68000 da Motorola e os computadores de grande porte (mainframes) IBM 370.
Embora a dimensão-padrão de operando do 80386 seja de 32 bits, a Intel manteve as convenções de nomenclatura dos antigos processadores, pelo fato de que o 80386 é um descendente do 8086 e do 80286 (processadores de 16 bits). Isto simplifica a execução de software do 8086 e 80286 e permite usar o mesmo montador (assembler) para gerar o código para qualquer um destes três processadores.
(...)"
Convenção de chamadas PASCAL
Convenção de chamada Pascal (que não é compatível com a norma ANSI): uma dúvida que ocorreu quando comecei a programar para Windows em C: o que são aquelas convenções de chamada WINAPI? Que li não sei onde é equivalente à convenção de chamada Pascal.
No livro 'Programando em Windows 95' Herbert Schildt diz que é por "razões técnicas". Mas quais são estas razões técnicas?
A resposta encontrei no livro "Guia Prático para Programadores 80386 - Programação Assembly 80386" páginas 4 e 5: "... Acreditando que uma linguagem como PL/M ou PASCAL viesse a tornar-se a linguagem dominante no desenvolvimento dos microcomputadores, a Intel dedicou muito dos registradores do 8086 a finalidades específicas, ..."
Estes registradores entre outros propósitos melhoram a manipulação da pilha ("stack"), e se já não sabe, a chamada de funções em C e em Pascal envolve o armazenamento de variáveis na pilha.
Resumindo a convenção de chamada PASCAL existe para otimizar o desempenho de sistemas com processadores Intel (Talvez de outros também).
Iterativo e interativo
Não confunda iterativo com interativo!
Iterativo: caracterizado por ou envolver repetição, recorrência, reiteração, ou repetividade.
Interativo: de ou relativo a um dispositivo eletrônico ou sistema de comunicação no qual a resposta é direta e contínua.
(Alguns anos atrás vi um marmanjo se atrapalhando com as duas palavras e dia desses vi um professor fazendo o mesmo)
Índice