jucimarjr/jaraki

Portar a linguagem Java para rodar na VM do Erlang

jaraki's Issues

Checar de método existe na classe atual ou referenciada

Em qualquer chamada de método, deve ser verificado de o método existe em tempo de análise semântica!

Checar tipo de retorno de função em atribuição

Quando é feita uma atribuição de variável com o retorno de uma função, o tipo deve ser checado e não deve ser gerado código!

exemplo:

float calculaArea(alt, larg){}

int a;
a = calculaArea(alt, larg);

deveria dar erro dizendo algo como:
found : float required: int a = area(); ....... ^

Mudar retorno dos nós da árvore sintática

Para capturar as informações dos métodos e campos estou tendo de fazer uma coisa meio feia, pq para dar pattern match para descobrir o que é que estou pegando, tenho que dar na tupla toda!

então proponho refatorarmos todo o sintático para seguir o seguinte formato:
{ o_que_é, Info }
onde Info contém a linha, etc, etc, etc..

---

por exemplo, declaração de variáveis está retornando assim:
{var_declaration, {var_type, '$1'}, {var_list, '$2'}}.

ficaria assim:
{var_declaration, {{var_type, '$1'}, {var_list, '$2'}}}.

ou seja:
VarInfo = { {var_type, '$1'}, {var_list, '$2'} }
{var_declaration, VarInfo}.

---

para dar um exemplo, na semântica, os match statement estão assim:

match_statement(
    {
        Line,
        attribution,
        {var, VarName},
        {var_value, VarValue}}
    ) ->
    create_attribution(Line, VarName, VarValue);

Isso tudo só para descobrir que é uma atribuição, quando a única informação que importa para o pattern match é o átomo "attribution"

poderia ser simplificado para:

match_statement({attribution, AttributionInfo}) ->
    {Line, {var, VarName}, {var_value, VarValue}}  = AttributionInfo,
    create_attribution(Line, VarName, VarValue);

de OITO linhas para apenas TRÊS!!!

ou ainda mais simples para:

match_statement({attribution, AttributionInfo}) ->
    create_attribution(AttributionInfo)

porém eu acho essa segunda opção muito cara para mudar agora...

---

ENFIM, acho que isso facilitaria muito os nossos trabalhos futuros!! e melhoraria bastante o código... afinal tem vários cases feios espalhados por ele, tudo por causa disso...
sei que teríamos de mudar mt coisa, daí por isso não seja viável, mas se algum dia desejar, taí a ideia! =)

na realidade é bem semelhante ao que os records nos permitem fazer, mas com eles a sixtaxe exigira muito mais linhas, ao invés de economizar...

Lib Vector

Agora o suporte a vetores está encapsulado na lib vector.
Basicamente essa lib cria um "endereço de memória" para cada vetor declarado.
Com isso resolvemos o problema do vetor ser passado como referência.

Lídia Lizziane

Não está parseando comentários

coloquei comentarios no Crivo.java e não está parseando

Rodem o make test

for deve ser no formato "for( int var = ... ; ...;...)"

Ao declarar um for, o compilador está obrigando que seja no formato a seguir:

for(int variavel = expressao;  expressao1; expressao2)

O mais correto seria:

for(expressao1;  expressao2; expressao3)

Onde expressao1 pode ser qualquer expressão válida, expressao2 pode ser qualquer expressão válida que retorne boolean e expressao3 qualquer statement válido (não podendo ser apenas um número, por exemplo)

isso não é uma coisa que trataremos agora, pois foi feito assim para facilitar a implementação, isso é uma MELHORIA (enhancement em inglês) apenas...

Scanner nos testes não executam

após fazer o make test, que compila normal, e rodar:

./jk test/ebin/sequencia3.erl

por exemplo, dá problema com o round()

Compilar classes dependentes simultaneamente e checar por erros

Em

class TestaFerramenta{
    public static void main(String[] args){
        Ferramentas.calculaArea();
    }
}

a classe TestaFerramenta depende de Ferramentas, pois usa o método calcularArea() dela.
É preciso saber o método de fato existe em Ferramentas, além de checar seu tipo, etc...
Para tanto, é preciso compilar essa dependência simultaneamente com a classe que a usa!

Todas as classes devem ser públicas

como os modificadores de classe ainda não foram implementados, o parser está obrigando a todas as classes serem públicas!!

Array Inicializado

Mudanças foram feitas na maneira de declarar o array inicializado.

Exemplo:
Em java: int[] vetor = {1, 2, 3};

Em Erlang:
Antes:
st:put_value({main, "vetor"},
{{array, int},
array:set(0, 1, array:new())}),
st:put_value({main, "vetor"},
{{array, int},
array:set(1, 2, st:get_value(main, "vetor"))}),
st:put_value({main, "vetor"},
{{array, int},
array:set(2, 3, st:get_value(main, "vetor"))}).

Agora:
st:put_value( {main, "vetor"},
{{array, int},
array:from_list([1, 2, 3])} )

Os testes de vetor falharam

vish

Fazer tratamento de modificadores de visibilidade

public, private, protected, etc. estão sendo ignorados por enquanto

segundo parâmetro do for deve retornar algo booleano

Como parte da checagem de tipos, o segundo parâmetro do for deve ter como resultado um valor booleano.
Por exemplo, ao fazer javac do seguinte código:

public class TestandoFor1 {
    public static int funcao() {return 1;}
    public static void main(String[] Args) {
        for (int i=0; funcao(); i++){
            System.out.println("Estou dentro do for :D");
        }
    }
}

o compilador do java retorna:

TestandoFor1.java:6: error: incompatible types
        for (int i=0; funcao(); i++){
                            ^
  required: boolean
  found:    int

ou seja, resolveu-se o tipo da expressão e verificou-se que não era boolean!

mais uma vez isso é apenas uma melhoria, não é para ser implementado agora...