robinHood (./5244) :
intéressant sur les switch, que réfère le "as" ?
Cast "safe"
uint16 foo = bar as uint16
robinHood (./5244) :
preserve et hardware c'est de la sémantique
Comme a peu pret tous les mots clefs
robinHood (./5244) :
bits est sympa, change t'il l'ordre seul suivant l'architecture ?
L'ordre est defini suivant l'architecture, mais peux aussi etre forcé a la declaration de la structure (comme l'endianess), utile pour les format binaires et protocoles.
robinHood (./5244) :
pourquoi pas mettre des soupçons de classes dans les structures, mais alors les fonctions sont externes à la déclaration ?
C'est le cas
struct foo
{
private:
int8 bar;
}
int8 foo:get()
{
return self->bar;
}
void foo:set(int8 v)
{
self->bar = v;
}
[...]
foo a;
a:set(42);
Uther (./5245) :
C'est un langage que tu as fait toi même ?
Oui, j'ai defini le language, je suis en train de travailler sur le parser pour l'instant.
Quand au nom j'ai aussi trouvé le meme que toi, et j'ai du changer pour eviter une confusion.
Caudex est le nouveau nom.
Uther (./5245) :
Je suis pas sur que je l'utiliserai, le Rust couvrant plus ou moins toutes les fonctionnalités (à part l'ABI custom qui est un besoin que je n'ai pas) et en offrant d'autres en plus. De plus il commence a avoir un écosystème conséquent ce qui est plus rassurant pour une utilisation pro. Mais je comprend tout a fait l'envie de rester sur un scope de fonctionnalité plus limité que Rust et avec moins de contraintes.
Apres je ne cherche pas a forcer qui que ce soit a l'utiliser, chacun ses preferences, perso le coté "zero overhead" et ABI sont les parties les plus importantes, ce language en theorie peux etre utilisé avec le 6502 car il peux cibler une machine avec aucune pile (ou presque) et quand c'est utilisé ainsi il y a bien sur des restrictions, il peux aussi en theorie supporter les pointeurs type far/near qu'on trouve avec le x86, mais tout ca sera lié a l'implementation du backend.
Sinon "transpiler" (je trouve ce terme est vraiment stupide et il n'aurais jamais du sortir hors du javascript) c'est vrai pour n'importe quel language. Tu peux convertir du java en C++, et meme tiens le C++ a la base c'est juste une surcouche du C.
Quand a l'optimisation c'est 100% dependant du compilateur pas du language.
Sinon un backend LLVM est prevu des que le frontend et le backend 6502 sont fait (le 6502 est la cible de base) car j'espere pouvoir arriver au moins au self-host.
Une des idée est de limiter voir supprimer toutes les UB du C/C++. Apporter du confort d'utilisation au C en lui meme, ce n'est PAS un language objet, meme si certains choses peuvent etre faites, on peux attacher des methodes a une structure, on peux avoir une forme de polymorphisme, et le language laisse acces a tout ce qui est "unsafe" mais tu doit simplement l'indiquer clairement, genre
uninitialized int8 array[128];
Indique au compilateur qu'on sait que ce tableau n'est pas initialisé par default, et que c'est le comportement voulu. Si le mot clef uninitialized n'est pas mis et que des acces avant initialisation sont fait le compilateur produira une erreur.
La majorite des choses que propose ce language sont "zero cost" dans le sens ou c'est lors de la compilation pas lors de l'execution. Ca limite certain points de securité mais ca permet un minimum.
Un des autres points est cette horreur du C sur les mots clefs pour la definition des variables. Je n'ai pas gardé un seul des mots clefs du C sur ce domaine pour que ca soit clair.
Un autre point est sur les types, pas d'horreur tel que char, int, long, long long long, unsigned, signed, ....
char existe, mais il est reservé au characters, tu ne peux pas ecrire
char c = 42;
les types sont aussi explicite, int8, uint32, etc..
bool existe par default et aussi un type "string", oui en interne ce n'est qu'un tableau (avec en bonus alapascal, la taille de la chaine)
Idem les {} sont obligatoire, pas de
if (foo) bar();
pour eviter certaines classes de bugs a la con comme on a pu voir il y a pas si longtemps.
Idem pour switch(), break est en theorie optionel, mais pas le fallthrough. Contrairement a ce que fait le C.
C'est l'idee de ce language: avoir quelque chose qui est portable, assez bas niveau pour faire du system, portable sur des cibles limité (coucou 6502 et grace a zero-cost), et qui cherche a supprimer toutes les sources d'ambiguité du C classique, et un confort qu'on peux trouver avec certains language de plus haut niveau (genre les methodes associé a une structure), casting plus clair et les casting "dangeureux" utilisent un mot clef particulier etc..
Exemple du "zero-cost"
l'exemple plus haut de la structure foo,
Si on devait convertir en C, la fonction
int8 foo:get()
{
return self->bar;
}
reviendrait a ecrire en C:
int8 foo_get(foo *self)
{
return self->bar;
}
et l'appel de fonction:
a:set(42);
->
foo_set(&a, 42);
Et pour finir, si personne ne l'utilise a vrai dire je m'en fout, j'ai 3 raisons pour ce language
1 - J'ai besoin d'un language qui soit utilisable avec le 6502
2 - Idem mais avec le 80(1)86, le C est plus utilisable sur cette cible que le 6502, mais le support des pointeurs far/near est inexistant, et c'est un problem enrome.
3 - Ca m'amuse et j'ai un projet de compilateur depuis des lustres donc c'est une bonne occasion.
Il est aussi possible que j'etende le support du language au banking memoire.
Oh et j'oubliait, il est de base capable de supporter au besoin suivant les cibles les flotant a virgule fixe, les flottant classiques (float/double), juste un des deux, les deux ou aucun.
Edit dernier: Sinon oui le code d'exemple a ete genere par Gemini parceque c'est un bon moyen de savoir si il y a des choses qui clochent ou pas.
