Bonjour,
juste pour faire un peu de pub a mon projet.
Nosica est un nouveau langage oriente objet et aussi un compilateur.
Un paquet rpm a ete fraichement cree hier. v0.2
Non implemente :
- exceptions
- contraintes
- back end qui compile a la vollee le fichier c genere par Nosica
- toutes les features enhancement de Bugzilla
Si quelques personnes pouvaient installer le RPM et me dire ce qui ne vas pas ...
Merci !
David
PS : La syntaxe de Nosica a ete inspiree de celle de Java, sans les problemes de java :
- genericite
- surcharge d'operateur
- contraintes
- reference counting pour etre un peu plus "temps reel"
- analyse globale pour resoudre a la compilation les appels polymorphes
- plus d'autres trucs plus sympas que je n'ai pas la place de decrire ici.
Plus d'infos sur le site (qui aurait besoin d'etre remis a jour)
Journal Nosicalight version 0.2
18
mar.
2003
# Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
# Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 2.
Est-ce juste un Java++ ou y a-t-il un vrai concept derrière autre qu'un aglutinage de concepts de programmation de haut niveau (généricité, etc.) et de techniques de compilation (analyse de type, suppression de code mort, etc.) ?
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 5.
Le but de Nosica au debut etait de s'affranchir de certains problemes dus a ld pour la resolution des appels polymorphes.
La solution apportee est derivee de celle de SmartEiffel : l'analyse globale du code.
Nosica se veut
- simple de part sa syntaxe
- 1 feature 1 syntaxe : pas 36000 facons de faire comme en Perl
- coherent au niveau de la syntaxe (c'est a dire qu'on se prend la tete a trouver des mots clefs comprehensibles par tout le monde et coherent entre eux)
- souple (par exemple il y a la delegation automatique)
- portable
- optimise (on a des idees, nottamment celles apportees par Nico, voir le forum, mais pas encore implementees)
Sinon, le concept c'est l'objet, je vois pas trop ce que je pourrai dire d'autre.
Par contre, on a un vrai concept objet : plus comme Smaltalk que comme c++ ou Java : tous les objets (je dis bien tous, y compris int, float, ...) sont des objets (et pas des first class) et comme tel peuvent etre derives...
Vala, plus d'infos ?
[^] # Re: Nosicalight version 0.2
Posté par icyfemur . Évalué à 1.
Un truc a la QT (j'aime assez) ? à la Java listener (j'aime pas du tout) ?
C'est un truc qui est fondalementalement manquant dans bcp de langages, c'est de pouvoir utiliser/creer des évenmeent facilement sans avoir a utiliser des astuces ou des librairies tierces supplémentaires.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Donc le jour ou on trouve une syntaxe objet sympa, ca verra peut etre le jour ...
Pour l'instant on s'oriente plus vers des listener a la java.
Mais je dois dire que tout ca fait partie de la librarie, et que la librairie standard Nosica, soyons clair il n'y a rien dedans pour l'instant (ou presque : le strict minimum quoi)
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 2.
Simple de part sa syntaxe comme Perl ou simple de part sa syntaxe comme Eiffel ? Pour l'instant et pour moi, le langage le plus syntaxiquement clair est Ruby (ça en est même déconcertant).
"1 feature 1 syntaxe : pas 36000 facons de faire comme en Perl"
Arg ? ça veut dire un seul type de boucle comme Eiffel ? :p
"coherent au niveau de la syntaxe (c'est a dire qu'on se prend la tete a trouver des mots clefs comprehensibles par tout le monde et coherent entre eux)"
C'est pas un argument ça. Prend des programmeurs Fortran, Lisp, Eiffel ou C++, il auront un vocabulaire /= ne != <> différent pour un même concept.
Quoique GOTO++ est sans doute le plus fort pour le nom des mots clefs.
"souple (par exemple il y a la delegation automatique) "
délégation ? tu veux dire on peut redéfinir une méthode sans avoir à le déclarer au préalable ?
"portable"
Tout langage de haut niveau est portable par essence puisqu'il s'affranchit des contraintes des machines. Mais tu parles sans doute du compilateur officiel.
"optimisé"
Pareil, il s'agit ici du compilateur pas du langage, à moins que la spécification du langage ne soit guidé que par son implémentation (ce qui est MAL(tm))
Moi ce qui m'interesse (dans un premier temps) c'est le langage en lui même, pas le compilateur. :)
Pour l'Objet, en règle général il y a une définition par personne.
Quels sont les choix de ton langage ?
- Présence de classes ? (je pense que oui dans ton cas)
- Héritage ? (simple c'est marqué)
- Sous-typage ? par exemple présence d'interfaces à la java)
- Méta niveau et réflexivité ? (y a-t-il une classe Classe ?)
- Tout est objet ? (les types de base sont des objets)
- Covariance ?
- Langage de types utilisé ? (un type = une classe, types ancrés, etc..)
- Protection (les public/private et compagnie)
- Granularité de compilation (compilation globale) ?
- Introduction de nouveaux paradigmes complexes z'et inovants ?
- D'autres caractéristiques que j'oublie sans doute.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 3.
1 feature / 1 syntaxe : Non :-), pas pour les boucles du moins.
coherent au niveau de la syntaxe : ca n'a jamais ete voulu comme un argument. Il s'agissait de lister un peu les buts de la creation de Nosica. Pas de dire "il est cool mon language, viens-y l'essayer" !! :-)
Quand je dis coherent, ca veut dire que la notation tente d'etre uniforme..
Exemple :
class toto extend A implements B ...
Bon, ben clairement, vaut mieux ecrire
class toto extends A implements B
Ca veut dire aussi que les operateurs ont la meme semantique qu'ils soient utilises sur des types primitifs ou sur des types references.
Exemple :
infix ==() un operateur de comparaison de valeur
infix ~~() un operateur de comparaison d'instance (equals en java)
Souplesse :
En Nosica, tu peux heriter d'une classe et implementer N interfaces.
En java ca devient vite chiant parce que souvent tu es oblige de faire de la delegation a la main.
En Nosica tu peux ecrire :
class Toto implements A, B
{
private AImpl aImpl proxies A; // automatic delegation of interface A to aImpl
private BImpl bImpl proxies B;
public sub f() {
// do something
// and callback on aImpl
aImpl.f();
}
}
public interface A
{
sub g();
sub f();
}
C'est a dire que pour toutes les methodes de A et de B, si elles n'ont pas ete implementees dans Toto, on genere automatiquement les methodes manquantes comme des appels sur aImpl et bImpl.
C'est clair ?
Portable : oui, il s'agit du compilo
Optimise : encore pareil, il ne s'agissait pas d'un argument de vente , mais d'essayer de lister le pourquoi de Nosica : quels en sont les buts.
Au niveau du langage, on a pas vraiment de spec "ecrite". Il y a un vieux document completement obsolete appele Nosica's syntax (http://nosica.ng-market.net/LearningNosica.html(...)).
Il y a beaucoup d'idees qui nous viennent, que l'on etudie et lorsque l'on pense que theoriquement on peut le faire et que la syntaxe retenue est objet et sympa, on la met dans Bugzilla.
Donc, pour repondre a ta question :
- Nosica est un langage objet, et tout est objet.
- Heritage simple, implementation d'interface multiple, delegation automatique (a mon sens, plus sympa que l'heritage multiple, moins bloated, plus efficace, car pas de padding et d'indirection supplementaire)
Classes inner/nested/anonymes
- Pas de meta niveau, mais c'est dans les features enhancement, donc ca y sera un jour
Protection : oui : public/private/protected/package
Granularite : pas de compilation separee. On a un autre concept pour resoudre ce probleme appele NoCoMo. Grosso modo il s'agit d'un bus de communication intra/inter/remote processus. Avec une possibilite de pouvoir faire un link pour virer le bus ... Mais bon, ca c'est un delire qui n'est pas pret de voir le jour
- Nouveaux paradigmes : aliasing de methodes ? delegation automatique ? Auparavant on avait l'overloading sur le type retour(ca marchait bien, mais le plus gros probleme c'est le reporting d'erreur)
- Pas de types natifs dans le compilo. Les types "natifs" sont en fait des types primitifs dans la librairie native. C'est a dire qu'ils sont definis dans la librarie standard comme n'importe quel autre type (net.nosica.lang)
- Possibillite de faire de la genericite partielle et de surcharger une implementation generale par le mecanisme de load des classes.
- proprietes (faire passer un appel de methode pour un field)
- tableaux multi dimensionnels
- Garbage collecting tres simple mais efficace via un reference counting automatique
- Types primitifs (aka valeur : alloue sur la pile). Types references (aka dynamique :alloue sur le tas)
Plus d'autres que j'oublie certainement.
Pour ce qui est de la covariance. J'avoue que j'ai jamais su ce que ca voulait dire. Donc pour ma culture G et pour le prochain qui me posera la question, je veux bien que tu m'explique.
J'avoue qu'on a plus eu une approche pragmatique qu'une approche universitaire en ce qui concerne la creation du langage.
Langage de type utilise. Pareil je vois pas trop de quoi tu parle.
Une instance est un representation memoire d'une classe (qu'elle soit primitive ou reference). Tu peux agreger des classes. Tu peux faire de la genericite sur toutes les classes ...
Vala quelques eclaircissements. J'espere te lire pour que tu m'explique la covariance, et langage de type.
A+
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 2.
Diantre, ca s'est vu que je suis universitaire :p ?
Covariance : c'est le fait que dans le monde réel, le sens de spécialisation des objets est le même que celui des paramètres des méthodes.
class Nouriture {}
class Animal { mange(Nouriture) {} }
class Herbe extend Nouriture {}
class Vache extend Animal { mange(Herbe) {} }
Or la théorie des types dit que pour que le typage soit sûr (par d'erreur de types à l'execution) les types des paramètres doivent être Contravariants. En effet avec mes vaches et herbes je peux écrire un truc du genre
Animal a;
Nouriture b;
a = new Vache();
b = new Viande();
a.mange(b);
Le typage est correct mais je à terme vais faire avoir des vaches foles (ouais ! politisons l'explication !!!)
Sauf que les théoriciens Objets ont montré que comme la covariance était naturelle pour le monde réel et que le programmeur modélise ce monde réel, il est obligé de trichier au niveau des types. La triche porte un nom : la coercition.
En effet, comme son langage est Contravariant, il ne peut écrire que :
class Nouriture {}
class Animal { mange(Nouriture) {} }
class Herbe extend Nouriture {}
class Vache extend Animal { mange(Nouriture n) {
Herbe h;
h = (Herbe)n;
...
} }
Bref, le cast qu'il a introduit et un générateur potentiel d'erreur de types. Le typage n'est pas sûr malgré un typage fort :(
Les langages Objets un peu au courant des théories sont donc donc covariants (Eiffel) ou à typage dynamique.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Nous on fait comme C++ ou Java.
Donc on fait de la coercicion ... :-) : Nous sommes contravariant.
On avait essaye d'etre covariant au debut, mais ca posait pas mel de problemes ... (du genre Vache.mange(Viande))
A l'analyse globale on etait capable de le detecter mais c'etait pas tres cool ...
Il y a des solutions a ce probleme ?
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
Mais on peut toujours prévenir à la compilation via des méthodes globales :
- si l'erreur de type est systématique : signaler une erreur
- si des erreur de types sont potentielles : compiler un test de type, si ca passe pas, lever une exception au runtime
- si aucune erreur de type est possible : pas besoin de compiler un test de type
SmartEiffel à une bonne approche de la chose avec des options de compilation pour choisir un niveau de compilation entre sécurité et efficacité du code compilé.
Le 2nd probleme que pose la covariance et qu'elle est incompatible avec la surcharge statique (des methodes de meme nom mais de signature differente, foo(int) et foo(string) par exemple)
D'ailleurs, de nombreuse personnes n'aiment pas la surcharge statique car la sélection de la méthode a appliquer dépend du type statique des paramètre et non du type dynamique.
class A {
foo(Animal) {}
foo(Vache) {}
test() {
Animal a = new Vache;
foo(a);
}
}
et c'est un argument qui peut se valoir selon moi.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Pour l'overriding (surcharge statique), effectivement ca peut etre un probleme ... Ceci dit dans la vrai vie (pas la theorie) je n'ai encore jamais rencontre ce probleme ...
D'ailleurs en terme de pratique pure. C'est quoi le plus sympa : la covariance ou la contravariance ? (perso je ne connais que la contravariance avec C++/Java)
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 2.
Contravariance signifie que les paramètres se spécialisent dans le sens contraire du receveur. C'est vachement bien au niveau de la théorie des types mais ca n'a aucun interet :p
A propos, pour finir l'explication, la covariance du type de retour est type safe et est d'ailleurs dans la norme de C++ (mais pas en Java, pourtant en Java ca coute rien a implémenter à cause de l'héritage simple. En C++ c'est beaucoup plus difficile mais tu peux essayer avec g++ par exemple de redéfinir le type de retour d'une méthode pour avoir un résultat amusant (plus un message d'excuse qu'un message d'erreur))
Sinon, dans la pratique pure. ben, des fois c'est plutot pratique de pouvoir spécialiser les paramètres et surtout les attributs. Ca évite bien des casts inutiles et des déclarations de variables intermédiaires temporaires.
La surcharge statique est d'après certains le coté obscur de la force, plus facile, plus pratique, etc... mais c'est sur que cela rend plus difficile l'implementation de la covariance.
[^] # Re: Nosicalight version 0.2
Posté par Kriek . Évalué à 1.
surcharge => covariance
substitution => contravariance
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
la vrai implémentation de la contravariance pose les memes problemes que la covariance au niveau de la surcharge statique...
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
D'ailleurs c'est dans les features enhancement de notre bugzilla ( http://nosica.ng-market.net/bugzilla/(...) ) ...
(et oui je suis d'accord c'est pas tres complique a faire ... Encore faut t'il prendre le temps de le faire ... :-)
Par contre, pas encore pige le coup de la contravariance ...
Tu as un exemple ?
Question subsidiaire : si tu as assez d'infos sur Nosica, est ce que tu as des remarques a faire ? Des trucs qui te semblent important et que nous aurions oublie ... Des raffinements ...
Sinon, passe nous faire part de tes remarques sur le forum : http://nosica.ng-market.net/forum/index.php(...)
Merci pour toutes tes explications, ca me permet mettre des noms sur des features que je connaissais plus ou moins sans savoir les nommer ...
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
class Animal { foo(Nouriture) }
class Vache { foo(Herbe)}
Animal :> Vache et Nouriture :> Herbe d'ou covariance car le sens de :> est le meme
:> est le symbole du sous-typage. moyen memotechnique 1 : le sens de la flèche est inverse de celui des graphes UML. moyen memotechnique 2 : le sens est celui de l'intension (avec un s) c'est-a-dire le nombre d'instances (les instances de Vache sont aussi instances de Animal).
Contravariance (exemple pas réel car le monde réel ne l'est pas) :
class A { foo(Herbe) }
class B extend A { foo(Nouriture) }
On a A :> B mais Herbe <: Nouriture d'ou contravariance
Invariance
class Animal { foo(Nouriture) }
class Vache { foo(Nouriture) }
On a Animal :> Vache et Nouriture = Nouriture donc invariance
Euh, sinon mon avis sur nosica.
1) Eviter de faire la meme grosse erreur que Java : tableaux pas homogenes avec le reste du langage. les tableaux en java c'est ni un type primitif, ni un objet et en plus il est covariant (alors que le reste du langage ne l'est pas)
j'avais un exemple mais je le retrouve plus
2) Un truc qui est bien en general est d'unifier la syntaxe attribut / methode sans parametre.
ecrire a.foo au lieu de a.foo()
3) Eviter d'etre trop verbeux si l'objectif n'est pas de faire un langage de production (ada, eiffel)
Je veux dire ne pas devoir ecrire de choses redondantes ou de declarer des choses un peu inutiles
4) faire sauter le ; en fin d'instruction. c'est une honte de trainer encore ca.
5) avoir une reflection plus profonde pour que le langage ait quelque chose en plus. :)
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Il est possible de surcharger leurs methodes comme n'importe quel autre type ...
Les tableaux ne sont pas des types primitifs, ce sont des types references. Et ils sont invariants ...
2 - Non, on n'autorise pas a appeler une methode sans les () si elle n'a pas de parametres.(1 seule facon de faire c'est notre motto) Par contre l'utilisateur peut tres bien definir des proprietes ...
Ex :
class Toto
{
private A a;
public A propery a() const { return a; }
}
Toto toto = new Toto();
A a = toto.a; // call Toto.property a
3 - On a essaye d'etre le moins verbeux possible. (j'ai horreur de Eiffel a cause de ca)
4 - Le fameux ';' Effectivement on le traine, et je pense qu'on va le garder. C'est pas tres utile pour le langage effectivement, par contre c'est tres utile pour ce qui est du reporting d'erreur de la reprise sur erreur ...
5 - Quelque chose en plus... Et bien, il me semble que Nosica a deja quelque chose en plus :-) Bien sur, rien de revolutionnaire, mais pleins de petites choses qui en font je l'espere un langage sur, souple et efficace.
Pour ce qui est des trucs de killer, Nico a souleve pas mal de points importants pour ce qui est de l'optimisation. On espere un jour pouvoir faire du multithreading automatique pour accelerer les boucles ... (voir le forum pour plus de details)
[^] # Re: Nosicalight version 0.2
Posté par Kriek . Évalué à 1.
Hein?
Prenons la règle (vraie) de sous typage suivante
T1<=S1 S2>+T2 => T1->T2 <= S1->S2
Si j'ai une fonction de type T->U et T de forme flèche (T1->T2 par ex) alors la forme des expressions de type S que je peux substituer au type T alors S est de la forme S1->S2 avec S1>= T1 , j'ai donc la contravariance pour la substitution. Les arguments de type S seront bien substitués à ceux de type T dans le corps de la fonction.
[^] # Re: Nosicalight version 0.2
Posté par Kriek . Évalué à 1.
et => c'est ma représentation graphique de la barre dnas les règles de typage ;)
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
"substitution => contravariance "
Je suis d'accord avec toi. Mais je voulais éviter de tomber dans des regles de typages fonctionelles. Les fonctions n'etant pas des objets de premiere classes dans Nosica, je ne pense pas qu'il soit necessaire de sortir l'artillerie lourde :)
par contre je comprend plus le
"surcharge => covariance"
je vois pas le sens de "surcharge" au niveau des types... mais il est tard, ceci expliquant peut-etre cela.
[^] # Re: Nosicalight version 0.2
Posté par Kriek . Évalué à 1.
Oui (si j'ai bien suivi mes cours :)le "obj<: calculus" d'Abadi et Cardelli par exemple permet de gérer ça d'après ce que je sais...
cf http://research.microsoft.com/Users/luca/Papers/PrimObj2ndOrder.A4.(...)
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Bon, je vais essayer de comprendre ce qu'ils disent ...
Vu que tu as bien suivi tes cours, tu n'aurais pas un algo comprehensible par hasard ?? :-)
En tout cas, c'est mieux que rien, j'ai plus qu'a me replonger dans la theorie des langages !! :-)
Merci !
David
[^] # Re: Nosicalight version 0.2
Posté par Kriek . Évalué à 1.
Oui je sais ça me fait la même chose :)
J'ai pas d'algo là sous la main mais il doit se déduire des nombreuses règles équationnelles et de typage données en appendice.
Faudra que je demande si ça a déjà été implanté quelque part :)
En fait il vaut mieux, comme indiqué, commencer par leur premier papier sur le premier ordre je pense ...
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Si tu as des remarques supplementaires, vient nous passer un petit coucou sur le forum ... (voir les liens plus haut)
Merci
David
[^] # Re: Nosicalight version 0.2
Posté par Vivi (site web personnel) . Évalué à 1.
ben non, si tu mets des casts, c'est plus vraiment du typage fort ...
Les langages Objets un peu au courant des théories sont donc covariants (Eiffel) ou à typage dynamique.
Mouais. Et comment tu places OCaml là-dedans ?
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
OCaml est pas un langage tout objet il me semble (je ne le connais pas bien du tout). En regardant en diagonale j'ai juste vu une implementation des objets lourdingues et intégré à la va-vite. Il m'en est reste un impression de "Oui, nous aussi on fait des objets, on est Aware !" mais je peux (j'espere) me tromper.
[^] # Re: Nosicalight version 0.2
Posté par Vivi (site web personnel) . Évalué à 1.
sinon pour OCaml les objets ne sont pas intégrés "à la va-vite" : il cohabitent bien avec l'inférence de types et le système de type qui est (vraiment) fort et sûr.
Et pour ce qui est du "aware", c'est pas trop le genre ...
Mais la façon dont les objets sont implémentés est vraiment intéressante je trouve.
QQs URL :
Le manuel http://caml.inria.fr/ocaml/htmlman/manual005.html(...)
un tutorial http://caml.inria.fr/tutorials/objectdemo.html(...)
(Mais si tu ne connaîs pas du tout le langage ça va pas être trés clair).
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
En C++ le cast est sur a condition d'utiliser la bonne facon de faire (dynamic_cast)
En Nosica le cast est sur aussi...
Ca veut dire quoi ? Ca veut dire que dans les cas ambigus, il y a un test au runtime et le lancement d'une exception ...
Dans tous les cas tu ne pourras prendre un type B pour un type A s'il n'y a aucun rapport entre les deux. En plus s'il n'y a vraiment aucun rapport entre les deux, tu te fais jeter a la compil. Les cas un peu tendancieux sont ceux qui proviennent du downcasting ... Mais d'apres ce que j'en comprend, que tu fasses de l'invariance ou de la covariance il y aura forcement des cast (meme s'ils sont caches), et donc forcement des cas ou tu peux avoir un runtime failure.
Pour ce qui est de l'Ocaml, le peu que j'en connaisse ne m'a pas trop seduit. La plupart de la programmation objet en Ocaml est de la programmation generique (aka polymorphisme statique), et pas de la vrai programmation dynamique (aka polymorphisme dynamique).
De plus le systeme de variable unmutable impose un style de programmation que je n'aime pas du tout. Il est souvent obligatoire de passer par des algos recursifs a cause de ca.
Pour finir, si tu vas sur http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#polymorphisme(...) tu verras qu'il existe un certains nombre de limitations au langage.
[^] # Re: Nosicalight version 0.2
Posté par Vivi (site web personnel) . Évalué à 1.
OK. Tu vas donc garder des informations sur le type de tes objects pendant l'execution.
La plupart de la programmation objet en Ocaml est de la programmation generique (aka polymorphisme statique), et pas de la vrai programmation dynamique (aka polymorphisme dynamique).
Le problème avec le polymorphisme, c'est que chaque "groupe" (d'utilisateurs d'un langage) emploie des termes différents. Je n'ai jamais entendu de polymorphisme statique ou dynamique. Ça n'est sans doute pas trés adapté à OCaml de toutes façons vu que tout ce qui concerne les types est déterminé statiquement.
En ocaml il y a du polymorphisme paramétrique (par ex. la fonction "longueur d'une liste" est polymorphe car elle peut prend comme argument une liste de n'importe quel type : liste d'entier, de string, etc.) et pour les objet il y a du polymorphisme d'inclusion (une fonction qui accepte un certain type d'objet en argument accepte aussi les sous-types).
De plus le systeme de variable unmutable
huh ?
Enfin bref. Ce qui est intéressant en ocaml est que l'héritage (entre classes) est découplé du sous-typage (entre objets). (par ex. voir http://portal.acm.org/citation.cfm?id=96721&dl=ACM&coll=por(...) )
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
Utiliser la délégation à la place de l'héritage multiple à un impact très fort : il remplace la notion du "est un" par la notion du "contient un". Je ne dis pas que c'est mauvais ou non mais je pense que c'est à creuser.
"Nosica est un langage objet, et tout est objet."
Tout est vraiment objet ?... vraiment tout ? Les structures de controle aussi (à la SmallTalk) ? Le code ? les méthodes ? les classes sont-il des objets ? :)
"Garbage collecting tres simple mais efficace via un reference counting automatique"
Attention aux circuits :p
A
|
v
B <- C <- _D
\_______/|
count B = 2
count C = 1
count D = 1
si jamais on nettoie A, on décrémente le count de B
comme count B > 0, on s'arrete
résultat : on a un circuit BCD dans le tas accroché à rien.
Langage de type. Par exemple en Eiffel on peut écrire
foo(a: A; b: like Current): like A
comme prototype de méthode
"A", "like Current" et "like A" sont des types valides, le premier disignant un objet instance de la classe A, le second désigant un objet instance de la même classe que le receveur ("Current"en Eiffel = "this" en C++/Java = "monpingouin" en GOTO++ = "self" en les autres langages) et le troisième désignant un objet instance de la même classe que le premier argument
les interets sont multiples : rendre inutile la généricité dans la majorité des cas, profiter à fond de la covariance, éviter les perte d'information de types, etc.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
N'oublie pas que j'ai ecrit
class Toto implements A, B ...
Donc Toto est toujours un A et Toto est toujours un B.
Ce qui fait qu'on a l'avantage de l'heritage multiple : on peut heriter de N peres, mais sans les inconvenients : symboles multiples, implementation pas toujours terrible, perte de place a cause du padding, inneficacite a cause des tables a aller consulter ...
==> En fait la delegation permet a la fois de repondre au probleme "est un" (mais en terme d'implementation, pas d'interface), et de "contient un" (en terme d'implementation toujours)
Oui bon, effectivement, les methodes, les boucles ne sont pas objets. Quand je disais tout, je voulais dire les objets... Par exemple en Java et en C++ tu n'as pas la main sur les types natifs. En Nosica tu peux l'avoir.
Pour le ref counting : oui on est au courant des problemes de cycle !! :-) Ca fait parti des choses que les gens doivent savoir lorsqu'ils codent en Nosica. La plupart des implementation de Lisp dans le temps utilisaient aussi le ref count ... :-)
Sinon rien ne nous empeche (a part le temps) d'implementer un vrai gc un jour (si ce n'est que je n'aime pas trop les freeze intempestifs)
En Nosica, tu as This pour Current, mais tu n'a pas la notation "like" ...
par exemple :
class Toto<T implements A = AImpl>
{
This someFunction() { // some code }
}
C'est marrant parce que la raison d'etre de This dans Nosica c'est precisement d'eviter les notations lourdes pour aider a la programmation generique.
Ceci dit je ne vois pas trop pourquoi ca va rendre inutile la genericite ...
[^] # Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
Donc, tu veux dire pas la que tous les objets sont des objets... hum, je comprends :)
"Ceci dit je ne vois pas trop pourquoi ca va rendre inutile la genericite"
En Eiffel on peut ancrer les types sur des features (attribut ou retour de fonctions) ce qui fait des trucs du genre
class Pile {
public:
like element pop() {return i>0 ? tabl[i--] : NULL;}
void push(o: like element) {}
private:
Object element;
int i;
like element tab[12]
}
class PileDAssiettes extend pile {
private:
Assiette element;
}
Bon, c'est un exemple un peu moyen mais c'est pour montrer l'idée.
sinon ton argument pour la delegation est pas mal :p
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Nan, je voulais juste dire que int etait un objet au meme titre qu'une Factory. Ce qui n'est pas le cas dans la plupart des autres langages objets où int est juste un type primitif ...
OK... Effectivement ton exemple de pile demontre bien l'utilite de la covariance pour pouvoir faire ce genre d'implementation.
Ceci dit, c'est vrai qu'en terme de conception pure, je prefere largement les containers generiques ... Pour moi ca a plus de sens.
La notation "Assiette element;" ne me convient pas trop non plus.
Sinon pour regler le probleme de la covariance il y a des techniques connues ?
Parce que finalement, j'ai l'impression que ca deporte le probleme d'un endroit a un autre.
Typiquement tu vas etre oblige (que ce soit le compilo ou l'utilisateur) de faire un check avant d'appeler la methode non ?
Exemple : (pseudo notation)
Animal a = Vache;
Vector<Nourriture> v;
v.push(Herbe); v.push(viande);
foreach i in v
{
a.mange(i);
}
Dans le cas de la covariance, il va bien falloir a un moment donne qu'il y ait un check du style :
Dans le cas de la contravariance, le check repose il est vrai entierement sur le programmeur, ce qui est pas cool.
Donc, si tu me dis qu'il y a des solutions au probleme de check a la compilation je changerai bien Nosica pour l'inclure dedans...
Typiquement, quand on avait essaye de le mettre dans le langage, on avait ensuite l'analyse globale qui verifiait qu'on appelait pas de methodes "non definies".
Analyse des types possible de v ==> Viande, Herbe
Analyse des types possible de a ==> Vache
==> a{Vache}.mange(i{Viande, Herbe}) ==> Erreur de compilation
Je vois bien des algos qui permettent de determiner un sur ensemble des types possibles, mais pas l'ensemble stricte : je risque de detecter des erreurs qui n'existent pas...
Donc, quelles autres solutions ?
(a part le check au runtime bien sur ...)
David
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Va falloir que j'etudie ca ...
# Re: Nosicalight version 0.2
Posté par MrTout (site web personnel) . Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
M'enfin, quand on voit des truc genre Obelix/Mobilix on est jamais trop prudent ...
# Re: Nosicalight version 0.2
Posté par Sidoine de Wispelaere . Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . Évalué à 1.
Merci pour les felicitations, mais je crois qu'il est encore un peu tot pour se rejouir.
Alors pour les reponses :
1 - oui, il y a des iterateurs. Les iterateurs font parties de la librairie standard. Ils dérivent tous de l'interface Iterator.
2 - Tout a fait, au début, on voulait faire une sorte de Java++ ou de C++--. C'est a dire un langage avec une syntaxe simple a la Java. Et comblant certaines lacunes de Java par rapport a C++ (nottamment la généricité, la surcharge d'operateur, ...)
3 - Il faudrait que tu precises un peu. Nosica permet je pense de faire pas mal de chose par rapport a C++. Par contre, on ne peut pas faire de manipulations low-level : pas d'arithmetiques de pointeurs, pas d'IO dans le langage, pas d'assembleur inline ...
Maintenant que le site est relooke (et en Francais aussi), passe nous dire un bonjour sur le site !
David
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.