Tipos decimais

[FernandoTheDev]

Tipos "float" e "double" devem ser o equivalentes a "decimal" na linguagem ao invés de "numero" ou "numerico"
Assim como "int" deve ser um "inteiro", "string" deve ser "texto", etc.

[leonelsanchesdasilva]

A ideia de número e numero veio do próprio JavaScript, que usa esta nomenclatura. Delégua não busca mudar definições radicalmente, portanto, defendo que, caso seja necessário o tipo decimal, que seja um sinônimo de número, assim como a função real(), herdada originalmente de Égua, tenta converter um tipo qualquer para número.

[FernandoTheDev]

isso é algo no typescript que não gosto, essa generalização dos tipos numéricos, é o mesmo que chamar 'A' de string ao invés de char, generaliza de mais

[leonelsanchesdasilva]

Há várias coisas que eu particularmente não gosto em JS/TS, mas que elas atendem bem ergonomicamente alguns casos. Apesar de generalizado, o tipo número expressa muito bem a ideia geral do que representa. Cito a Wikipédia:

Número é um objeto abstrato da matemática usado para descrever a quantidade, ordem ou medida, o conceito de número provavelmente foi um dos primeiros conceitos matemáticos assimilados pela humanidade no processo de contagem.

Para isto, os números naturais eram um bom começo, o trabalho dos matemáticos nos levou a conceber outros tipos de números, os números inteiros são uma extensão dos números naturais que incluem os números inteiros negativos. Os números racionais, por sua vez, incluem frações de inteiros, os números reais são todos os números racionais mais os números irracionais.

Ou seja, o tipo número combina bem os conceitos de números naturais, inteiros, racionais e reais. Já o tipo decimal sempre supõe uma parte inteira e uma parte fracionária.

Remover um conceito poderoso como esse da linguagem seria uma grande perda, bem como um problema com as soluções que já o implementam.

[FernandoTheDev]

adicionar o tipo decimal não vai quebrar a linguagem, assim como existe o tipo caractere

[leonelsanchesdasilva]

Na verdade o tipo caractere não existe ainda em Delégua: apenas em dialetos, como o VisuAlg.

[FernandoTheDev]

foi um exemplo, adicionar esse tipo a mais não quebraria a linguagem, deixaria até mesmo mais seguro e melhor de entender os programas

[ItaloCobains]

@FernandoTheDev Quais ganhos Delégua teria adicionando isso, pensando na linguagem interpretada como é hoje?

[leonelsanchesdasilva]

Mas ele não é um alias de inteiro no começo do projeto: ele é um alias de número com parte decimal, e seria custoso mudar isso agora.

[ItaloCobains]

É que no contexto de Delégua numero não é tecnicamente um tipo primitivo já que pode ser inteiro e real ao mesmo tempo. Se eu fosse representar ele em uma compilador eu criaria uma estrutura a parte assim como o Ruby faz.

https://ruby-doc.org/core-2.5.2/Numeric.html

[FernandoTheDev]

É que no contexto de Delégua numero não é tecnicamente um tipo primitivo já que pode ser inteiro e real ao mesmo tempo. Se eu fosse representar ele em uma compilador eu criaria uma estrutura a parte assim como o Ruby faz.

https://ruby-doc.org/core-2.5.2/Numeric.html

é um pouco ruim mostrar ruby como exemplo já que ele é interpretado

[leonelsanchesdasilva]

é um pouco ruim mostrar ruby como exemplo já que ele é interpretado

Não é, porque Delégua é interpretada também. A ideia do compilador é que é nova, e ela deve se adaptar ao interpretador, e não o contrário.

[FernandoTheDev]

daria pra manter numero como int e double ao mesmo tempo mas seria custoso em tempo e adicionaria complexidade totalmente desnecessária, em D para uma variavel suportar ser varios tipos há algumas maneiras, as mais comuns seriam usando Variant e Algebraic, segue os exemplos:

Variant

import std.variant;
import std.stdio;

void main() {
    Variant v;

    v = 10;          // agora é int
    writeln("int? ", v.type, " => ", v.get!int);

    v = 3.14;        // agora é double
    writeln("double? ", v.type, " => ", v.get!double);
}

Algebraic

import std.variant;
import std.typecons; // Tuple
import std.stdio;

void main() {
    // Algebraic que pode ser int, double ou uma tupla contendo ambos
    alias MyType = Algebraic!(int, double, Tuple!(int, double));

    MyType x = tuple(10, 3.14); // guarda int e double juntos

    auto t = x.get!(Tuple!(int, double));
    writeln("int: ", t[0]);
    writeln("double: ", t[1]);

    x = 42;       // agora só int
    writeln("Novo int: ", x.get!int);
}

Isso porque o compilador está transpilando para D, se estivesse usando LLVM ou Assembly seria ainda mais insano implementar isso

Eu já cogito suportar multiplos tipos em argumentos de funções e ainda nem sei como vou introduzir

[FernandoTheDev]

O que quero dizer é que esse tipo abstrai de mais

[FernandoTheDev]

Não é atoa que outras linguagens com C, C++, Rust, D e outras não suportam isso, apenas trazem forma de contornar o problema

[FernandoTheDev]

São nesses nuances que a linguagem se destaca

[ItaloCobains]

Os propósitos dessas linguagens com Delégua são totalmente diferentes.

Tanto sua alternativa quanto a nossa estão correta, mas assim como @leonelsanchesdasilva falou o compilador é algo novo ele deve se adaptar ao o interpretador, hoje para mim essa mudança não me parece ter um ganho significativo para modificar o interpretador tendo em vista os atuais usuários de Delégua, com isso recomendo criar esse pequeno overhead que não me parece tão prejudicial.

Quando essa mudança for relevante para os usuário de Delégua fará todo sentido modificar o interpretador.

[FernandoTheDev]

como eu havia citado, é uma mudança pensando a longo prazo, pensando no futuro e não apenas no agora, essa adição de overhead e complexidade é extremamente desnecessária entendendo que a solução é extremamente simples

[FernandoTheDev]

novamente, minha idéia criando o compilador e ajudando no ecossistema é tornar a linguagem utilizavel de forma comercial, afinal de contas, qual o sentido de um iniciante aprender delégua se ele não consegue criar as coisas que ele mais quer? aprender a criar bots, apis, aplicativos, assim por diante, e o que os iniciantes mais buscam é uma forma de ganhar dinheiro.

quero tornar a linguagem madura de forma que os usuarios possam criar scripts e vender por exemplo, apps, sistemas inteiros sem se preocupar, aliás é por essa simplicidade que linguagens como python se destacam, ignorando a idade dos projetos, mesmo com a dificuldade da barreira linguistica os iniciantes acabam preferindo ela (python)

[FernandoTheDev]

e deixando claro, não quero tirar o propósito principal que é na educação

[JohnPetros]

De fato, a distinção entre inteiro e decimal torna o comportamento de dados mais previsível e robusto, o que é fundamental em aplicações que exigem alta exatidão, como em cálculos financeiros ou científicos.

Além disso, assim, Delégua se alinha mais à filosofia do Python do que à do JavaScript, o que parece ser a escolha ideal na minha visão. Ambas buscam ser linguagens versáteis, com uma sintaxe limpa e legível, permitindo o desenvolvimento de projetos de grande escala sem sacrificar a simplicidade.

[leonelsanchesdasilva]

O que proponho para pacificar a questão

• O CGD não suportar número, e suportar inteiro e decimal;
• Este núcleo suportar número, decimal e inteiro, e apontar na análise semântica, por configuração, que número precisa ser especializado para ser compilado (já há situações em que isso será exigido, especialmente variáveis do tipo qualquer);
• O núcleo terá em breve um estilizador (linter), que terá uma configuração recomendada para o uso com o CGD, fazendo as conversões recomendadas quando possível, convertendo número para decimal por padrão;
• Os respectivos manuais apontam o porquê de tudo isso.

Simplesmente descartar número é uma modificação radical demais para este núcleo. Como eu disse antes, o núcleo não deve se adequar ao compilador, mas sim o contrário.