Matthieu Lemerre a écrit 38 commentaires

Justement, L est multi-paradigme. Les blocks peuvent retourner des valeurs, ainsi on peut faire:

let a = { let sum = 0;
for(i = 0; i <= 10; i++) { sum += i; }
sum }

(Sauf que ni for ni += n'existent pour l'instant, mais en transformant le code ci-dessus avec un loop et un if, ca marche)

La notion de block a la ruby m'interesse aussi beaucoup, et fait typiquement
partie des trucs que j'aimerait implementer. En fait, le mot cle foreach sera accompagne d'un block, par exemple; map aussi. Fini les iterateurs, qui sont sources de complexite pour le programmeur et d'inefficacite pour la machine.

La programmation par contrat pourra etre implementee dans une librairie.
Au debut, on pourra faire ca simplement, genre ajouter des asserts; mais graduellement, des analyses du code source pourront permettre des verifications statiques des assertions.

Je ne suis pas d'accord: le SIX syntax extension est bien une extension a la syntaxe de Scheme, mais cette extension me semble predefinie. Il me semble impossible de rajouter des nouvelles grammaires dynamiquement, comme je le fais en L dans l'exemple du XML.

Et puis l'interet de L n'est pas que dans sa syntaxe extensible: l'usage de macros a la common Lisp dans un language type statiquement n'est pas si courant (pour reprendre l'exemple donne plus haut, il faudrait utiliser Ocaml + Camlp4 + MetaOCaml pour reproduire mon exemple de compilateur d'automates a partir d'expressions rationnelles), surtout dans un langage pas uniquement fonctionnel .

J'ai dit rarement, pas jamais!

Pour Perl, je connaissais juste un module pour Perl5 qui reanalysais son code source, est-ce plus elabore sur Perl6?

Je ne connaissais pas Template Haskell ni savait que Dylan savait etendre sa syntaxe; en fait je n'etait au courant que de Camlp4. Je jetterai un oeil a tout ca, merci.

Ca va, le lien qu'il donne n'a plus l'air de marcher :)

Je me suis fait avoir par le bug de l'URL.

C'est donc: http://www.nongnu.org/l-lang

C'est parce qu'il s'agit de compilation depuis du code ecrit dans la machine virtuelle (ou dans le slim binaries) jusqu'au code natif (JIT compilation). Ce genre de compilation (sans les optimisations) est pas tres complique, se fait raisonnablement vite, et de toute facon ne peut se faire que sur la plateforme embarquee.

La quand je parle d'embarque c'est du gros "embarque" genre telephone portable java, pas du controle commande d'un four micro onde. Deja pour que ca aie un interet il faut telecharger du code dynamiquement sur la plateforme embarquee, c'est donc utile uniquement pour les "jouets" modernes.

Etch est la future version stable de debian qui est en phase terminale.

Moi au contraire je pense que Debian a encore de beaux jours devant elle ;)

Un truc que j'adore avec linuxfr c'est qu'on y rencontre des gens vraiment pointus !

Merci, merci :)

Sinon tu as fini par dire que sans vm le langage devait être sandbox-ready (dans la pratique), donc ce n'est pas l'OS qui assure tout seul le sandboxing (auquel cas le langage n'importerait pas).

Je dirais plutot : dans les OS "courants" que dans la pratique. Et ca permet d'avoir une solution generique, multi plateforme. Maintenant, la place logique de ce genre de mecanismee est l'OS, et le fait qu'il faille l'implementer dans le language est dommage, et moins sure.

(merci encore pour cette discussion fort intéressante)

Merci a toi, c'est toujours interessant de se repreciser.

Pareil pour le sandboxing : le faire de manière identique sur tous les OS, pour une portion de code (et pas un processus en entier) et à l'heure actuelle, sans java/.NET(/autre?), et bien c'est pas possible. Et que dans l'absolu, ça soit possible, ça ne change au final pas grand chose. Donc je maintiens que si on a besoin de sandboxing (c'est à dire pas souvent, je te l'accorde), pour l'instant la VM est le seul salut.

Et moi que non;) : il "suffit" de verifier que le code respecte certaines proprietes avant de le compiler. Ce n'est pas possible pour un language comme C, mais par exemple c'est assez simple de verifier un language comme Haskell comme etant sur avant de le compiler et de l'executer; donc pas de VM dans ces cas la.

Dans des cas extremes, tu as par exemple des OS extensibles qui verifient du code, le compilent eux meme avant de l'installer directement dans le noyau. SPIN fait ca par exemple.

Quant aux langages a la C ... Defi releve pour mon langage, L! (petit coup de pub: http://www.nongnu.org/l-lang )

Non c'est pas bien, ca empeche de pouvoir naviguer en mode texte.
Depuis qu'il y a du javascript partout, je n'utilise plus (trop) emacs-w3m.

D'ailleurs, qu'en est-il de l'accessibilite quand il y a du javascript?

C'est pourquoi, pour la portabilite, je conseille les slim binaries: il s'agit en fait
d'arbres de syntaxes abstraites compresses, qui portent plus d'information, et
sont plus denses que du code binaire compile pour une machine virtuelle.

Ils sont donc plus petits et permettent une compilation plus optimisee; par contre le temps de compilation est plus long, donc ca ne convient pas bien pour l'embarque.

Et utiliser l'OS pour chrooter toutes les applis, si c'est une solution viable. Enfin pas dit comme ca. Sous Linux/BSD ce genre de concept n'est pas vraiment bien integre (enfin avec SELinux ca s'arrange un peu), mais ca n'a rien de complique,
c'est fait depuis les annees 70 dans les capability machines, ou plus modernement dans OS.

L'idee c'est que plutot que de donner aux applications le droit de tout faire par defaut (open environnement), on leur donne le droit de ne rien faire, et on leur ajoute des droits au coup par coup. Du coup si on raisonne comme ca, faire du sandboxing c'est trivial: il suffit de donner peu d'acces aux services de l'OS, plutot que d'interdire plus.

Merci pour le remoting; je vois pas trop l'interet par rapport a CORBA. En C++ on peut tout aussi bien cacher le fait qu'un appel de methode se fasse a distance qu'en C# a mon avis.

Donc je me maintiens: les virtual machines, ca sert a rien (sauf dans qq cas, comme l'embarque). D'ailleurs si Microsoft ne faisait pas windowsCE /windowsphone/ou autre vision sur l'embarque, ils n'auraient surement pas fait .NET comme ca je pense.

Non, ca c'est le gros désavantage :
on perd la couche d'abstraction avec le matos,

Ce dont 99% du code ecris se moque royalement. Et pour le reste, ca concerne
la programmation systeme, justement impossible en C#/Java.

on perd tous les services de sécurité

De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.

les services d'introspection

Si tu penses a typeof/instanceof, il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux. Donc la machine virtuelle ne sert toujours a rien

la portabilité binaire

Les slims binaries sont une solution bien plus interessante que la compilation
dans une machine virtuelle pour ca.

les services de remoting

Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
du genre "pouvoir s'attacher a un programme en cours d'execution", tu peux faire ca sans machine virtuelle, c.f. Common Lisp, ou meme GDB.

L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.

Si on regarde un language comme Common Lisp, qui compile en code natif et a toutes les features dont tu parles, on s'apercoit vraiment de l'inutilite de la machine virtuelle.

Enfin c'est mon avis.

Dans les faits, c'est le systeme de protection tout entier (base sur AACS) qui est bien casse: avant longtemps des videos HD se baladeront sur internet.

Mais c'est effectivement un abus de langage.