Rebol Documentation Project

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 23 décembre 2009

REBOL Brainwasher

Salut,

Connaissez-vous Jerry Tsai ?

Jerry intervient souvent sur Altme, et dans divers posts sur le Net.

Son histoire est assez symbolique de REBOL : il programmait plutôt en JAVA. Un jour, son patron lui demande de faire un développement en urgence. Jerry réalise alors qu'en Java, il en a pour plusieurs jours. Se rappelant REBOL, il tente de réaliser la solution en REBOL ... et çà marche. Depuis, il fait partie des "switchers" qui comme vous (peut-être) et moi, ont réalisés un jour que REBOL était génial !

Jerry a publié son témoignage ici

Jerry est aussi l'auteur d'une présentation PowerPoint qui décoiffe !

A voir absolument : la présentation Rebol Brainwasher.pptx

===Philippe

vendredi 06 avril 2007

Le concept des Set-Functions

Le concept des Set-Functions

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 21:02 GMT Article #0019

Vous savez ce qu'est un set-word :

word: 10

C'est la syntaxe utilisée par REBOL pour définir la valeur d'un mot.

Une set-function est une fonction qui est appelée lorsque cette action de définition se produit. Une set-function dans l'exemple précédent aurait permis de controler le range, le datatype, de conserver la trace d'autres détails.

Le concept d'une set-function n'est pas nouveau. En fait, c'est l'un des éléments essentiels de l'un des aïeuls de REBOL : le langage Self (voir Self : The Power of Simplicity, l'un de mes livres préférés.)

Il y a longtemps, dans les premiers jours de création de Self, alors que j'étais chez Apple, je trainais avec David Ungar (concepteur de Self, à Standford actuellement) et je parlais de ce langage de communication. Je trouvais intéressant que David veuille retirer un état de Self en supprimant l'affectation. (L'affectation est l'une des cause d'ennuis classique dans les langages purement fonctionnels.) Il accomplissait toujours cela en utilisant des fonctions qui à la fois définissaient et récupéraient des valeurs au sein d'un contexte (objet).

L'idée me tentait toujours, mais je sentais que ce n'était pas exactement réalisable. L'état est un macro-composant par nature (je n'ai pas dit "composant" ici, parce que je ne veux pas entrer dans une discussion san fin). La suppression de l'état est une recherche mathématique, mais ce n'est pas nécessairement pratique. Il y a de nombreux aspects utiles à un état. Un journal est très utile, mais mathématiquement sans intérêt fonctionnel.

Lorsque vint le temps de reprendre cette approche dans REBOL (il y plus de 10 ans), j'ai décidé de conserver cela pratique. Cependant, en secret, j'ai toujours voulu conserver la méthode set-function, car elle a beaucoup de valeur. Une set-function peut précisément contrôler comment un mot est défini et ce qu'il définit.

Je devrais mentionner, cependant, qu'il n'est pas facile d'ajouter les set-functions. Si c'était vraiment facile, nous les aurions ajoutées. Le probléme réside dans le fait que les set-functions ajoute une nouvelle branche à l'arbre de la sémantique du langage REBOL.

Par exemple, comment sont définies les set-fonctions et comment sont-elles réflectives ?

Vous pouvez faire une sorte de set-function avec le code qui suit :

obj : make object ! [ value : 0 ; internal set-value : func [new] [value : new] ]

Et vous écririez :

obj/set-value 10

Mais ce que vous voulez réellement écrire, c'est :

obj/value : 10

à l'intérieur de la fonction pour définir cette valeur.

Mais là, la question se pose, comment faire référence à la set-function elle-même ?

OK, voilà quelque chose à méditer. Je ne suis pas sûr qu'il y ait une bonne réponse, ou aussi si nous avons besoin d'une. J'avais déjà parlé de cela autrefois, et sans suggérer que ceci soit ajouté à REBOL 3.0. (voir l'article précédent sur les extensions du langage.)

Je suppose que je suis en train de vous faire réfléchir à cela. Merci de me signaler vos commentaires.

(Traduction : Philippe Le Goff)

Les bonnes astuces du langage ne sont juste que cela.

Les bonnes astuces du langage ne sont juste que cela.

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 20:28 GMT Article #0018

REBOL est un langage pour les personnes créatives. A cause de cela, il existe une richesse infinie d'astuces pour le langage et de possibilités que chacun peut inventer — spécialement dans un langage flexible comme REBOL. Certaines de ces astuces sont utiles, beaucoup ne le sont pas.

Malheureusement, après avoir inventé une amélioration au langage, la première chose que beaucoup de développeurs veulent est de la voir ajouter au langage. Mais est-ce vraiment judicieux ? est-ce que le langage est juste un "civet" de petites caractéristiques ?

Pas vraiment. Un langage doit être plus grand que cela. C'est une manière de penser - un moyen de faire correspondre des actions et de la logique, pas une collection de petits morceaux collés ensemble.

Maitenant, il y a un bon nombre de logiques très banales, comme un boucle while, et il y a encore plus de logiques rares. Je suis certain que vous avez vos préférées. Le probléme est de décider quand une logique, une action, ou une fonction devrait être une part officielle du langage ? Ce processus doit être pris en compte sérieusement. Il y a des douzaines de langages "surgonflés" qui possèdent des milliers de fonctions et de caractéristiques, qui sont très peu utilisées.

C'est une affaire pratique, pas une affaire académique ou de conception. Ce n'est pas "peut-on ajouter une caractéristique ?", c'est "doit-on ajouter cette caractéristique ?". Si la caractéristique est utilisée par un programmeur une fois dans l'année, est-ce que cela a de la valeur de l'ajouter ? Si la caractéristique est vague à comprendre ou difficile à utiliser, doit-elle faire partie de nos standards ?

J'ai dit "Non". Laissons cela en dehors ou faisons-en un package particulier ou un module de composant additionnel. Je préfére que REBOL demeure compact et léger. (Et, je serais le premier à admettre que RT est souvent coupable de ne pas respecter cette régle... des choses seront supprimées dans REBOL 3.0.)

Bien sûr, que rien ne vous arrête d'utiliser votre propre package ou extension du langage. Et si vous trouvez des douzaines de programmeurs qui utilisent cette caractéristique, alors il sera probablement temps de songer à l'ajouter. Un bon exemple est la package Include de Ladislav. Beaucoup de personnes l'utilise, et encore plus l'utiliseraient si il était inclus dans REBOL (donc, oui, il le sera.)

S'il vous plaît, ne m'en voulez pas. Je n'ai pas dit d'arrêter d'inventer de nouvelles extensions au langage, et je n'ai pas dit d'arrêter de suggérer leur ajout dans REBOL. Ce que je dis, c'est de mesurer les mérites de chaque extension.

Trions les codes les plus utilisés en les publiant dans la communauté REBOL et en regardant s'ils deviennent populaires. Puis, si vous avez une foule de gens qui les utilisent, venez cogner à ma porte et mettez-moi au courant. Je garantis que je vous écouterais avec interêt.

(Traduction : Philippe Le Goff)

Usage de ! et != dans REBOL ?

Usage de ! et != dans REBOL ?

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 18:51 GMT Article #0017

Il existe de nombreuses et subtiles différences entre REBOL et d'autres langages. Certaines de ces différences sont importantes et d'autres non.

Dans leur grande majorité, les différences de REBOL ne sont issues d'un caprice. Par exemple, REBOL utilise les caractères "[]" pour les blocs, pour une raison et utilise le point-virgule " ;" des commentaires pour la même raison : ce sont des signes très faciles à saisir sur des claviers US (pour les claviers non-US, eh bien, désolé), et ils s'impriment correctement (les blocs ressemblent à des blocs avec []).

Mais une différence que les nouveaux utilisateurs n'apprécient pas est le symbole REBOL "<>", qui teste une inégalité. Ces caractères ont été choisis car < et > sont utilisés pour des comparaisons, de sorte que les mettre ensemble pour l'inégalité était logique.

Cependant, le langage C a établi la convention du " !=". C'est une combinaison du non " !" et du "=" (qui ne signifie pas réellement l'égalité en C, il indique une assignation, mais nous allons ignorer ce petit fait).

Actuellement en REBOL, " !" ou " !=" ne sont pas définis. Mais, nous essayons d'être plus amicaux dans REBOL 3.0, même si c'est juste un peu. Ainsi la question est donc : est-ce que nous devons faire de ceci une norme ? (pour la petite histoire, Python a été aussi modifié pour permettre ce changement entre <> et !=.)

Il est vraiment très facile de faire ce changement, et s'il rend quelques centaines de programmeurs plus heureux, bien, peut-être cela vaut-il le coup. Ce n'est pas la première fois que nous pensons à cette idée, mais dans REBOL 3,0 nous faisons des changements à grande échelle, de sorte que c'est une bonne idée de rediscuter quelques uns de ces petites problèmes.

Donc, faites moi remonter vos commentaires là-dessus.

(Traduction : Philippe Le Goff)

Variables typées d'objet

Variables typées d'objet.

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 16:47 GMT Article #0016

REBOL 3.0 a la capacité de garder des informations sur les types des champs (ou variables) d'un objet. Par exemple, si votre objet a un champ nom, et que vous voulez que ce nom soit du type string !, vous pouvez spécifier cela.

L'information indiquant le type pour les champs est manipulée dans la nouvelle structure de contexte de REBOL 3. C'est une valeur composite, de sorte que vous pouvez spécifier plusieurs types, comme c'est faisable avec les arguments des fonctions (en fait, on utilise le même mécanisme que les fonctions, ce qui réduit la taille de REBOL.)

La question est : quel est le meilleur moyen de spécifier les types de données des champs d'un objet ? C'est une question quelque peu difficile parce qu'en REBOL, les définitions d'un objet servent également à initialiser les champs de l'objet.

make object ! [ name : "Bob" age : 27 city : "Mendocino" ]

Le bloc de spécification de l'objet est un bloc REBOL valide qui est évalué, et les valeurs initiales sont définies.

Une solution pourrait être d'introduire un bloc d'attributs similaire aux attributs de fonctions. Si la première valeur dans la définition de l'objet est un bloc, elle prend une signification particulière :

make object ! [ [name : city : [string !] age : [integer !]] name : "Bob" age : 27 city : "Mendocino" ]

Bien sûr, nous allons aussi réfléchir sur les autres attributs que nous pourrions introduire pour les objets dans le futur, car nous ne voudrions pas ajouter cette fonctionnalité et nous apercevoir plus tard que nous ne pouvons plus ajouter d'autres attributs (comme la possibilité de fixer un champ, l'observation d'un changement, etc.)

Envoyez vos remarques. Merci.

(Traduction : Philippe Le Goff)

Réferencer une variable de série dans FOREACH

Réferencer une variable de série dans FOREACH

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 16:33 GMT Article #0015

Quelque chose que j'ai toujours voulu avec foreach : la possibilité d'accèder à la série, non seulement à ses valeurs. En d'autres mots, une sorte de mélange entre forall et foreach.

Une manière de réaliser cela serait de permettre à un mot du bloc de foreach d'inclure une sorte de notation indiquant que ce mot est censé se rapporter à la série, pas à une valeur de la série. Par exemple :

foreach [name count :] user-data [ change count length ? name ]

Cet exemple montre la puissance de cette méthode. Ici la variable count fait référence à la série, positionnée à cet index, de sorte que l'exemple modifie à cette position le bloc de la série courante. La notation "set-word" est cohérente avec celle utilisée dans le dialecte parse pour des raisons similaires.

Vous pouvez aussi l'utiliser comme un mot qui va vous donner la position de l'index sans avoir besoin d'incrémenter à part une variable dans la boucle foreach.

(Traduction : Philippe Le Goff)

Hash ! ou non

Hash ! ou non

Carl Sassenrath, CTO REBOL Technologies 2-May-2006 16:23 GMT Article #0014

Ok, j'ai entendu beaucoup de plaintes de personnes au sujet du datatype hash!, depuis qu'il a été ajouté. Je pense que le probléme est que ce type de données est très mal compris. C'est plus qu'une méthode pour faire des associations car il fournit une méthode séquentielle d'accès à des blocs cohérente avec le reste de REBOL. J'avais toujours pensé que c'était plus performant que les tableaux associatifs ou les dictionnaitres trouvés dans d'autres langages comme Python ou Perl. Mais, peut-être ai-je tort.

Maitenant, c'est l'heure pour votre décision. Si vous ne voulez pas du datatype hash, débarassons-nous de lui. Au lieu de cela, nous pouvons fournir divers genres d'associations simples "une à une" et trouver une manière facile de les mettre en série pour les entrées et sorties.

Vos commentaires seront appréciés.

(Traduction : Philippe Le Goff)

Assouplissement des alias pour les équivalences symboliques

Assouplissement des alias pour les équivalences symboliques

Carl Sassenrath, CTO REBOL Technologies 28-Apr-2006 23:33 GMT Article #0013

En REBOL 3.0, nous allons assouplir les conditions relatives aux alias.

Rappel : un alias est un équivalent symbolique pour un mot. Normalement, les alias sont utilisés pour mettre en majuscules ou minuscules l'équivalent des mots (ce qui est fait en interne et automatiquement dans REBOL).

Par exemple, vous pouvez écrire :

if time > now [...]

ou

IF Time > now [...]

Ces expressions sont identiques. La comparaison renvoie "true" :

'if = 'IF true

Dans les versions précédentes, si vous vouliez définir un alias pour un mot, vous deviez y faire attention. Le mot ne devait pas être déjà utilisé (de n'importe quelle manière). Vous pouviez créer l'alias d'un mot avec une ligne comme celle-ci :

alias 'if "fi"

Après cela, fi signifie la même chose que if. L'expression suivante est vraie :

'if = 'fi true

et vous pouvez écrire :

fi time > now [...]

Les débutants doivent noter que l'usage d'alias n'est pas la même chose que le partage de la la valeur des mots. L'exemple ci-dessus n'est pas la même chose que :

fi : :if

Voir le manuel pour plus d'information sur cela.

Comme les experts le savent, les équivalences avec des alias sont rarement nécessaires, mais c'est important dans certains cas, quand les mots sont utilisés symboliquement, comme avec :

'if = first [fi]

ou dans un path :

path/fi

REBOL 2.0 possède des restrictions sur la façon dont les alias doivent être définis. Un alias peut être refusé si le mot a déjà été utilisé.

En REBOL 3.0, nous allons assouplir ces contraintes et vous pourrez écrire :

alias 'if 'fi

même si fi est déjà apparu auparavant.

Notez, cependant, que vous devrez encore utiliser les alias avec beaucoup d'attention. Si vous définissez des contextes (modules,objects, fonctions) qui utilisent le mot avant que ne soit défini son alias, eh bien... alors, vous risquez d'avoir quelques problèmes parce que vous aurez changé quelque chose d'extrémement fondamental : le sens le plus basique du symbole.

Ce changement dans REBOL 3.0 n'est pas définitif. Nous allons observer comme cela fonctionne, et prévoir de revenir à la méthode de REBOL 2.0. Mais, je voulais pour le signaler. Faisons un essai.

(Traduction : Philippe Le Goff)

Les fonctions "closure"

Closure Functions

Carl Sassenrath, CTO REBOL Technologies 24-Apr-2006 16:32 GMT Article #0012

NdT : j'ai préféré laissé le terme anglais pour éviter les méprises.

Les fonctions closure seront fournies en standard dans REBOL 3.0.

Le concept des fonctions closure n'est pas neuf (au moins 30 ans d'âge), et peut être trouvé dans la plupart des types de langages fonctionnels. Une closure est un type particulier, ou une caractéristique, d'une fonction qui conserve "vivant" l'environnement local (arguments et variables locales) d'une fonction, même après que cette fonction ait terminé son exécution.

Avantages : l'environnement de la fonction (mots et données) reste valide après que la fonction ait retournée ses valeurs. (ce qui n'est pas vrai avec les fonctions normales). C'est pratique si vous voulez retourner des mots ou d'autres données de la fonction, et que vous voulez encore accéder à la valeur des mots.

Inconvénients : leur évaluation est plus lente que les fonctions normales car elles sont allouées et liées à l'exécution. Aussi, les fonctions closures requièrent souvent plus de mémoire (et provoquent plus de recyclage), selon l'usage que vous en faites et la façon dont vous stockez leurs résultats.

En REBOL 3.0, les fonctions closures seront implémentées avec le datatype closure ! et une nouvelle fonction mezzanine appelée closure. Voici un exemple qui définit une nouvelle fonction closure appelée has-name :

hash-name: closure [name [string!] /local hash] [ hash: checksum/secure name return [name hash] ; note: renvoie des mots, pas aux valeurs ]

Lorsqu'une fonction closure est définie, un objet REBOL est créé et le corps de la fonction est lié à cet objet. Lorsque la fonction est évaluée, l'objet de la fonction d'origine est cloné et le corps de la fonction copié complètement et relié à cet objet nouvellement cloné.

Vous appelez les fonctions closure de la même manière que vous le faites pour n'importe quelle fonction :

result: hash-name "Bob" print second result

Vous pouvez tester une fonction closure avec :

if closure? :hash-name [print "It is true"]

et, cette expression est aussi vraie :

 if any-function? :hash-name [print "It is true"]

Pour en savoir plus à propos du concept des fonctions closures, voir l'item "Function Closure" sur le site Wikipedia, et également les exemples et méthodes de fonctions closures REBOL fournies par Ladislav Mecir (qui travaille sur les versions courantes de REBOL) dans ses tutoriels et codes ("Bind a Function Yourself").

(Traduction : Philippe Le Goff)

Voulez vous un pointeur pour déboguer ?

Carl Sassenrath, CTO REBOL Technologies 12-Apr-2006 16:46 GMT Article #0011

Cet article concerne d'entre vous qui veulent plus de contrôle pour déboguer, pour créer des IDEs, etc. Voulez vous un pointeur de déboguage dans le mécanisme de gestion des erreurs ?

De quoi s'agit-il ? En REBOL 2, lorsqu'une erreur se produit, la pile retourne immédiatement au précédent état pré-déterminé de l'interpréteur, et tous les états entre l'erreur et l'endroit de la capture de l'erreur ("catch") sont effacés. Du fait de cela, il n'y a pas de moyens d'examiner les arguments de la fonction courante, de remonter la liste (backtrace) de fonctions, etc..

Avec REBOL 3, nous pouvons ajouter un pointeur (debug hook) de déboguage qui vous permettra de récupérer l'erreur interne, retardant le « throw » sur la pile, et permettant à du code spécialisé d'accéder à la pile de l'interpréteur.

(Notez que ceci n'a rien d'extraordinaire pour la plupart des interpréteurs. En fait, ce qui est curieux, c'est que nous avons fait ainsi avec REBOL sans le fournir.)

La pile manipule le contexte des fonctions, le bloc des arguments de la fonction, les références de mots (pour les fonctions nommées, ou celles appelées via un path), la référence précédente des fonctions (pour les libérer), et les traitements temporaires. Ce sont tous des datatypes REBOL valides, de sorte que vous pourriez en théorie accéder à la pile elle-même comme à un bloc. De la sorte, un IDE utilisant le mode débogage pourrait afficher toutes informations pertinentes, pour les programmeurs qui voudraient les voir durant une session de déboguage.

Bien sûr, nous devons aussi être prudents dans la manière d'accéder à cette information, afin qu'elle soit correctement extraite, pour éviter des problèmes de compatibilité futurs, peut être devrions-nous étendre le format de la pile. C'est une grosse préoccupation dont nous devons nous occuper. De plus, nous devrons faire attention aux cas d'erreurs qui placent la pile dans un état interrogeable, tels que les cas d'erreurs "not enough memory" ou "corruption" (qui ne devrait pas se produire).

Note : Je voudrais ajouter qu'il peut y avoir quelques problèmes de sécurité dans l'exécution, reliés à de tels pointeurs de déboguage (comme effectuer une recherche sur la pile pour des clés de cryptage, etc.), de sorte que cette caractéristique va induire un niveau de sécurité spécifique à la fonction secure pour les sessions de déboguage.

Il est trop tôt pour connaître précisément les détails ici, mais la sécurité est une priorité très importante.

(Traduction : Philippe Le Goff)

Le binding à la volée (Just-in-time (JIT))

Le binding à la volée

Carl Sassenrath, CTO REBOL Technologies 11-Apr-2006 16:39 GMT Article #0010

REBOL 3.0 va introduire un nouveau type de binding : le binding à la volée (Just-in-Time). C'est un article assez long, mais je pensais que vous seriez intéressés par des détails, et je sais que vous ne serez pas timides en me faisant vos commentaires

Actuellement, REBOL supporte deux sortes de binding :

Definitional Context Binding (DCB) C'est le binding qui se produit lorsque vous définissez un bloc de données comme le corps d'un datatype particulier ou un contexte. C'est le binding usuel tel qu'il est implémenté par la fonction bind. Par exemple, les variables de la fonction sont liées au corps de la fonction lorsque make function! est mis en oeuvre (ou les mezzanines comme func, function, etc.)

Late Path Binding (LPB) C'est le binding qui se produit lorsque vous utilisez un path contenant des champs symboliques. Ce binding très tardif se produit durant l'évalution du path lui-même. Cela arrive principalement quand vous accédez aux champs d'un objet, et il est effectué tardivement pour que les champs soient eux-mêmes des variables.

Ces méthodes de binding fonctionnent bien pour le code REBOL classique ; cependant, pour traiter des dialectes en REBOL, ils n'apportent aucun bénéfice car les mots du dialecte ne subissent jamais le processus de définition. Les dialectes sont juste des blocs, pas des datatypes spécialisés tels que les fonctions ou les objets.

Durant l'implémentation du projet Rebcode (qui a créé un modéle unique de machine virtuelle REBOL très performante), il est devenu évident qu'une méthode très rapide de consultation était nécessaire pour les op-codes de la machine virtuelle (VM). Lorsque vous indiquez un "add" ou un "sub", vous ne souhaitez pas que l'interpréteur dépense du temps en essayant d'imaginer ce que ces op-codes signifient.

Deux solution deviennent évidentes :

utiliser le DCB ou créer un nouveau type de binding "tardif", qu'en attente d'une définition plus convenable j'ai appelé "just-in-time binding (JIT)". Les deux méthodes seront à prende en compte ; cependant, parce que le Rebcode a été incorporé dans un wrapper de fonction, il a eu l'opportunité d'utiliser DCB. En outre, on ne permet pas la modification des blocs de Rebcode après leur définition. Ainsi le DCB était parfait pour cela et a amélioré la vitesse de Rebcode par trois ou quatre fois.

Bien, qu'en est-il à propos des dialectes REBOL ? Les performances des dialectes avec draw et avec parse peuvent-elles êtres améliorées ?

Oui, c'est possible. Prenez par exemple le dialecte draw. Les mots-clés (commandes) du dialecte sont évalués rapidement, mais pour des grands blocs (commme de grandes images SVG), les performances pourraient être meilleures. Une quantité significative de temps est nécessaire pour résoudre les mots-clés chaque fois que le bloc draw est évalué.

Rebcode a été implémenté en utilisant la technique dans laquelle un contexte pour le dialecte définit les mots du dialecte, et le DCB a été utilisé pour binder le bloc du dialecte à ce contexte. Il n'y a rien d'extraordinaire jusque là.

Cependant, cette méthode avec le DCB ne marche pas bien avec des dialectes comme draw, qui peuvent changer dynamiquement. Par exemple, durant une animation, le programmeur peut insérer ou supprimer des commandes dans ou depuis le bloc draw.

De tels changements diminueraient la raison d'être du travail effectué par le DCB, sachant qu'une alternative serait de forcer le programmeur à maintenir le binding manuellement pendant chaque insertion, mais que nous préférerions éviter cela.

C'est là qu'entre en scéne le "JIT binding", le binding à la volée. Avec le JIT, les mots d'un bloc sont liés au contexte qu'ils ont trouvé durant leur évaluation. Contrairement au LPB, les mots d'un bloc sont modifiés pour conserver leurs nouveaux bindings. Ils sont "collants". A l'évaluation suivante du bloc, un contrôle rapide du contexte des mots est exigé, et aucune autre action n'est nécessaire. Si un nouveau mot a été inséré, le contrôle échoue, et le binding JIT se produit.

Le résultat est que des dialectes avec draw et parse sont évalués plus rapidement, mais sans la nécessité de pre-binder les mots au bloc du dialecte. Et, si le bloc reste globalement peu modifié, la vitesse d'évaluation d'un dialecte est très proche du pur code REBOL (nécessitant seulement un contrôle de contexte pour chaque mot).

Y-a-t-il une contre-partie à cette méthode ? Oui. La bonne conception repose sur la gestion des différences. Cela prend une petite fraction de temps de définir la méthode JIT avant l'évaluation du dialecte. Pour des blocs de petite taille qui contiennnent moins de trois ou quatre mots-clés, le coût de la prise en compte de la JIT peut ralentir le traitement de ces blocs. C'est le genre de chose que nous devrons tester et évaluer. Il peut aussi y avoir quelques pénalisations légéres pour les exceptions (erreurs, break, retours, throwns) qui se produisent durant l'évaluation des dialectes en mode JIT ; cependant, ces évenements devraient être rares dans la plupart des codes de dialectes.

En conclusion : le binding à la volée (just-in-time) est juste une sorte de DCB effectué "à la volée". Il est possible que ce type de binding puisse conduire à des gains en performance pour les dialectes, qui utilisent draw, parse, etc. Il est aussi possible que nous utilision le JIT au lieu du LPB pour améliorer les performances sur les accès des champs des objets. Cela doit être étudié.

Note : ce concept est encore au tout début de la phase de conception, et nous en saurons plus bientôt. Si vous avez des commentaires sur cette idée, je sais que vous serez heureux de les poster sur le blog. Merci.

(Traduction : Philippe Le Goff)

La question du 64 bit

Carl Sassenrath, CTO REBOL Technologies 10-Apr-2006 20:00 GMT Article #0009

Cette question est dans un coin de ma tête depuis déjà quelques mois.

Pour le moment, REBOL 3.0 utilisera encore des nombres entiers sur 32 bits afin de le mettre en service et de le faire fonctionner aussi rapidement que possible.

Cependant, le temps va venir au cours des prochaines semaines de faire le grand saut à 64 bits. Bien sûr, l'intérêt est que les nombres entiers puissent avoir des valeurs beaucoup plus grandes, donc des tailles très grandes de fichiers , etc... L'inconvénient est que les valeurs 64 bits exigent plus de temps CPU pour les opérations d'accès mémoire et mathématiques. Elles prennent également deux fois plus d'espace mémoire, cependant REBOL assigne déjà cet espace, de sorte que la plupart des programmes ne verront pas cette augmentation.

Le changement vers le 64 bit affectera plus que les valeurs des nombres entiers. Par exemple, voulons nous permettre des séries (exemple : chaînes de caractères, binaires) plus grandes que 2/4GB ? Je ne suis pas en train de parler des fichiers (voir ci-dessous) ; je parle des séries courantes en mémoire. Si nous voulons cela, non seulement la structure de gestion (ex. la position de fin, tail) va grandir, mais le pointeur pour indexer la série aussi (pour être capable d'adresser des séries de grande taille). Bien que ce ne soit pas une grosse affaire pour les définitions de structure, c'est en une pour le code run-time ; REBOL est en effet complètement packagé avec des références à des choses comme la fin (tail) et l'index de série (pour du contrôle de limites, etc.).

Et finalement, il y a l'idée que peut-être, nous pourrions utiliser une compilation variable en 32 ou 64 bits pour produire des versions correspondantes. Une version 32 bits peut avoir plus de sens pour des choses comme des téléphones mobiles et des PDAs. Mais, cela soulève la question que ces versions de REBOL devront être étroitement compatibles, mais pas parfaitement compatibles. Peut-être pourraient-elles être améliorées en employant des nombres entiers sur 64 bit, mais des séries sur 32 bits.

Comme avec tout processus de conception, il y a diverses possibilités à considérer. Certainement, les besoins des utilisateurs de REBOL devraient nous aider à déterminer le meilleur compromis entre les choix. Personnellement, j'aime l'idée des maths avec des nombres entiers sur 64 bits, mais la restriction des séries sur 32 bits me va bien.

D'ores et déjà, j'avais l'habitude d'utiliser seek pour adresser les grands fichiers .

Et, en ce qui concerne les fichiers, je dois noter que j'envisage une nouvelle version du datatype port! qui autorise l'accès à des index sur 64 bits. Ces nouveaux ports ne stockeront plus leurs positions d'index dans leurs références, mais dans l'objet lui-même. L'objet system fonctionnera davantage comme dans l'accès traditionnel aux fichiers, qu'il ne l'a fait dans le passé.

(Traduction : Philippe Le Goff)

jeudi 04 mai 2006

Les fonctions ordinales des séries se comportent à présent comme PICK

Carl Sassenrath, CTO REBOL Technologies 9-Apr-2006 21:59 GMT Article #0008

Les fonctions ordinales (first, second, etc.) ont été à l'origine conçues pour être assez strictes - principalement pour les débutants.

Par exemple :


print first tail "abc"
** Script Error: Out of range or past end

provoque une erreur. Cependant, la fonction pick n'en provoque pas :


print pick tail "abc" 1
none

Je pensais que cette différence était Ok, car les experts n'utilisent pas first. Cependant, je ne crois plus cela. Les fonctions ordinales sont des fonctions très efficaces et je tends moi-même à les utiliser comme des "sélecteurs" rapides dans des bouts de code comme celui-ci :


the-name: :first
the-email: :second
the-message: :third

send the-email data the-message data

Pour du code "haute performance", cette méthode est aussi rapide qu'il est possible.

Lorsque elle est utilisée dans des grandes boucles, elle est plus efficace en rapidité que de sélectionner les champs d'objets ( qui nécessitent à la fois une interprétation des paths et le binding durant l'exécution). En fait, j'utilise si souvent cette méthode, que j'avais implémentée une fonction ordain pour définir dans mon code les relations ordinales précédentes.

Il y a seulement un problème. L'erreur "past end" n'est pas souhaitée.

En REBOL 3.0, les changement dans l'implémentation des fonctions ordinales (depuis les fonctions d'action spécifiques aux datatypes jusqu'aux natives génériques) rend leur comportement similaire à pick, par défaut. L'erreur "past end" est maintenant supprimée.

Cela semble préférable, et la modification devrait conserver la compatibilité, car le cas "past end" rconduisait à une erreur (une exception) dans les versions précédentes, de sorte qu'il n'était pas utilisé dans le code existant.

Notez que ceci nécessitera certaines mises à jour mineures dans la documentation.

(Traduction : Philippe Le Goff)

Les erreurs désarmées, la fonction "cause"

Carl Sassenrath, CTO REBOL Technologies 9-Apr-2006 19:13 GMT Article #0007

En REBOL 3.0, les valeurs d'erreur sont désarmées (disarmed) par défaut.

Les versions précédentes de REBOL utilisaient les erreurs "à chaud". Cependant, vous deviez traiter ces valeurs d'erreur de façon spécifique, ou elles déclenchaient automatiquement la gestion d'erreur. Ce comportement avait été implémenté à l'origine pour éviter que les erreurs se propagent trop loin de leurs origines (le principe était de préserver autant que possible la localisation d'une erreur).

Ces erreurs "à chaud" finissaient par être réduites à néant, et l'intérêt de pouvoir localiser une erreur était compensé par la difficulté de gérer les valeurs d'erreur en général. (Voir les articles de Ladislav Mecir qui a écrit d'excellentes notes sur ce sujet). C'était très souvent vraiment épineux.

Avec ceci à l'esprit, sachez que REBOL 3.0 supprimera les erreurs à chaud.

Les valeurs d'erreurs (objets) sont désarmées par défaut, et peuvent être traitées de la même manière que tous les autres objets. Les fonctions comme try peuvent être utilisées pour capturer les erreurs et les traiter comme des valeurs normales.

Dans les cas où il est nécessaire de ré-armer une erreur, et de forcer son retour dans l'état "à chaud", la fonction cause a été ajoutée. Vous "provoquez" la reconsidération de l'erreur pour être traitée. (voir la description de Ladislav sur "fire".)

Voici un simple exemple de manipulation d'une erreur spécifique :


result: try [... do something ...]
if all [
error? result
result/id = 'zero-divide
] [
cause result
]

L'exemple évalue un bloc et capture toutes les erreurs. Le résultat (erreur ou non) est stocké dans le mot result. Le code vérifie si l'erreur est celle d'une division par zéro (zero-divide), et si oui, renvoie l'erreur à un niveau de traitement supérieur (non montré). Remarquez que disarm n'est pas utilisée.

Pour la compatibilité avec REBOL 2.0, la fonction disarm sera encore fournie, mais elle ne fait plus grand chose. (renvoie l'objet error comme un object ! plutôt que comme une error !, c'est tout.)

Notes pour les experts :

En interne, la fonction cause provoque un "stack throw" (un long saut en C) qui est très rapide, mais des parties importantes du contexte d'exécution sont perdues dans ce processus.

Par comparaison, les fonctions REBOL break, return, et throw libèrent la pile d'une manière ordonnée, ce qui permet de rendre possible des options de déboguage durant le processus.

Plus d'informations sur la gestion des erreurs,bientôt.

(Traduction : Philippe Le Goff)

dimanche 30 avril 2006

"Copy or not copy", telle est la question.

Carl Sassenrath, CTO REBOL Technologies 9-Apr-2006 18:03 GMT Article #0006

Ok, ce sujet est profond et vaste, mais je veux vous faire réfléchir là dessus ...

Un problème que nous devons régler très bientôt est celui rencontré lorsqu'on copie ou lorsqu'on ne copie pas des séries REBOL (strings, blocks, etc.). Ce problème a un impact toutes les versions de REBOL et est important parce que les règles pour copier/ne-pas-copier doivent être fortement présentes dans votre esprit, tandis que vous programmez en REBOL.

Par exemple, voici le simple cas, où vous utilisez des chaînes de caractères littérales en REBOL, comme dans une fonction :


fun: func [str] [append "example " str]

La plupart d'entre vous reconnaisse ce problème. La première fois, nous appelons la fonction :


print fun "test"
example test

et la seconde fois :


print fun "this"
example testthis

La chaîne littérale a été modifiée. Pour prévenir cela, vous deviez écrire :


fun: func [str] [append copy "example " str]

C'est l'une des premières choses qu'un débutant apprend - et, habituellement, en s'étant fait avoir.

Mais, le problème devient vite vraiment important rapidement parce qu'il s'applique à toutes les séries de REBOL (series !) soit les blocs, des parens, des noms de fichier, des URLs, etc...

Par exemple, quand vous créez un objet de cette manière :


obj-body: [a: 10 b: [print a]]
obj1: make object! obj-body
obj2: make object! obj-body

Vous percevez notre problème si le bloc obj-body doit être copié avant qu'il soit lié (binding des variables attributs de l'objet). Le "obj-body" original est modifié par la fonction make. Si vous ne savez pas cela, vous pourriez être étonné. Surprise !

La même chose peut être dite à propos des spécifications ou du corps de fonctions, etc.

De sorte que ce problème vaut la peine d'être revu dans REBOL 3.0.

Il y a deux principes de REBOL qui sont opposés et à l'oeuvre :

1. Simplicité : nous voulons minimiser les effets de bords dans le code normal. Bon pour les débutants et bon probablement aussi pour les experts.

2. Optimisation : minimiser le coût mémoire et optimiser la performance. Si nous avons à copier des chaînes et des blocs à de nombreux endroits dans notre code, cela consomme du temps et de la mémoire.

Ainsi, il y a quelques problèmes auquel vous devriez réfléchir si vous voulez programmer finement en REBOL. Nous avons besoin d'une solution bien définie. Elle peut être n'importe laquelle de :

1. Ne rien faire. Laisser cela en l'état.

2. Modifier là où c'est le plus approprié et le plus optimal.

3. Modifier partout et ignorer le surcoût en mémoire et la diminution de performance.

Voici donc quelque chose à considérer la prochaine fois que vous vous relaxerez dans un bar, fumerez votre pipe dans votre fauteuil, ou escaladerez les montagnes dans votre coin.

Et, je vous invite à partager vos réflexions avec tout le monde, soit sur le blog dans la section "comments", ou via votre propre blog ou page web.

(Traduction : Philippe Le Goff)

Nommage : Typemap or Typeset ?

Carl Sassenrath, CTO REBOL Technologies 9-Apr-2006 17:54 GMT Article #0005

Information : La modification évoquée ci-dessous a déjà été faite. "Typemap" est maintenant appelé "typeset".

Comme vous le savez, je prends au sérieux le processus de nommage dans REBOL.

Ironiquement, proposer le meilleur nom pour une fonction ou toute autre structure peut prendre plus de temps qu'écrire cette fonction complète dans REBOL.

Le datatype typemap! est un bon exemple, et nous devrions en parler à présent.

A l'origine, je pensais que le meilleur nom était typeset! pour être cohérent avec le datatype bitset!.

Mais, j'ai été préoccupé par le fait que le mot "typeset" a déjà une signification technique concrète en anglais (encore plus pour ceux d'entre nous qui ont édité des livres avant, ce qui est mon propre cas). (NdT : il s'agit de la composition, pour l'édition littéraire.)

Cependant, ce conflit de nom n'est-il pas finalement sans intérêt ? Après tout, quelle est la probabilité que la composition de livres ait un jour un impact avec REBOL ?

Faites moi donc remonter vos commentaires sur ce point. Personnellement, je penche fortement pour changer le nom en typeset! et, à présent, il est temps de se décider.

(Traduction : Philippe Le Goff)

vendredi 28 avril 2006

Ajout des commentaires au Blog Rebol 3.0

Carl Sassenrath, CTO REBOL Technologies 9-Apr-2006 17:06 GMT Article #0004

Les commentaires sont à présent possibles pour le blog, merci aux services gratuits d'Haloscan.com.

Il n'y a pas de fantaisie, cela résout le besoin immédiat avec seulement 60 secondes de programmation REBOL requise de mon côté.

Faites-moi savoir si cela fonctionne, ou s'il y a des problèmes. Au besoin, nous pouvons ajouter un modérateur volontaire, ou deux, pour aider à gérer les commentaires.

Merci à ED et Chris pour la suggestion de Haloscan.

(Traduction : Philippe Le Goff)

Make Function ! doit changer

Carl Sassenrath, CTO REBOL Technologies 8-Apr-2006 22:39 GMT Article #0003

Il existe une contradiction, depuis longtemps, dans l'implémentation de la fonction make sous REBOL, qui sera modifiée dans REBOL 3.0. (Mais, cela n'aura que peu d'effet sur la plupart des programmes.)

Si j'interroge REBOL à propos de la fonction make, il répond quelque chose comme cela :


>> ? make
USAGE:
MAKE type spec

DESCRIPTION:
Constructs and returns a new value.
MAKE is an action value.

ARGUMENTS:
type -- The datatype or example value. (Type: any-type)
spec -- The attributes of the new value. (Type: any-type)

Donc, si ceci est exact, comment la ligne ci-dessous peut elle être valide ?


f: make function! [a] [print a]

Dans cet exemple, make prend trois arguments, mais la description de la fonction mentionne uniquement deux arguments : type et spec.

Ceci va être changé dans REBOL 3.0. Voici pourquoi :

1. Un programme doit pouvoir s'appuyer avec précision sur les caractéristiques d'interface de fonction. C'est important non seulement pour des choses comme des outils de déboguage, mais également pour la réflexion appropriée (du code vers des données qui renvoient du code).

2. L'ancienne approche nécessitait un hack dans l'implémentation de l'évaluation de REBOL pour "faire marcher" l'argument supplémentaire. Effacer cela simplifierait le code et augmenterait la rapidité de REBOL.

La nouvelle forme de la fonction make sera :


f: make function! [[a] [print a]]

Cela sera cohérent avec la spécification de l'interface de la fonction.

Comment ceci va-t-il affecter la compatibilité ? Très peu. La plupart des programmes n'utilisent pas cette forme de création de fonction ; ils utilisent les fonctions comme func, function, does, ou has.

(Traduction : Philippe Le Goff)

jeudi 27 avril 2006

Un nouveau datatype : Typeset !

Carl Sassenrath, CTO REBOL Technologies 8-Apr-2006 20:21 GMT Article #0002

“Cet article a été modifié depuis sa première version. Le mot "typemap" a été changé en "typeset".”

Dans REBOL 3.0, un typeset est essentiellement un ensemble de datatypes.

Par exemple, lorsque vous définissez une fonction, vous spécifiez de la manière suivante les types de données (datatypes) des arguments :


f: func [arg1 [integer! number!] arg2 [string! url!]] ...

Ce qui suit chaque mot définissant un argument (arg1, arg2,...) est un bloc de datatypes.

REBOL 3.0 ajoute un nouveau type de données appelé un typeset !. Un typeset est simplement une méthode compacte, efficace de stocker des ensembles de datatypes, comme une nouvelle sorte de type de données.

Les typesets sont importants car l'interpréteur les utilise pour valider rapidement les arguments des fonctions.

Le datatype typeset ! sait comment convertir un bloc contenant des noms de datatypes comme [integer ! decimal ! money !] en une représentation interne (similaire au datatype bitset !). Il peut aussi traduire ce format interne en un bloc compréhensible, en vue d'une édition ou de modifications.

L'ajout de ce datatype typeset ! élimine le recours aux pseudo-datatypes REBOL spéciaux que sont series ! et number !. Ils sont à présent implémentés comme des typesets, mais vous pouvez continuer à les utiliser de la même manière que précédemment.

Ils peuvent être utilisés dans les spécifications d'arguments de fonction :


f: func [arg1 [number!] arg2 [series!]] ...

et aussi pour des tests de datatypes :


if series? value [....]

Notez, cependant, cette différence avec REBOL 2.* :


type? series!
datatype!

qui devient dans REBOL 3.0 :


type? series!
typeset!

Pour les utilisateurs avertis, REBOL 3.0 fournira une méthode pour créer et gérer vos propres typesets.



tmp-type: make typeset! [time! money! percent!]

f: func [arg1 [tmp-type]] [...]

J'en dirai plus bientôt au sujet de quelques problèmes liés aux typesets.

(Traduction : Philippe Le Goff)

Bienvenue sur la ligne de front de REBOL 3.0...

Carl Sassenrath, CTO REBOL Technologies 8-Apr-2006 20:18 GMT Article #0001

Comme je l'ai mentionné dans mes notes publiées sur www.rebol.net/article/0263.html, j'ai cherché un moyen de poster mes notes relatives à REBOL 3.0. Mais, à la différence du fonctionnement mon blog actuel, il était aussi vraiment important pour moi de permettre aux utilisateurs de poster leurs remarques et idées.

J'ai demandé des contributions pour définir un bon outil de blog et reçu quelques réponses, mais jusqu'ici rien n'a été mis en place. Le programme n'était soit pas opérationnel, soit nécessitait une installation compliquée, ou comme avec blogger.com, pas vraiment utilisable comme je le voulais.

Mais, du temps a passé. Je dois permettre que mes notes soient publiées, de sorte que pour l'instant, j'utilise mon script blogger.r. Cela m'a pris seulement 30 secondes pour obtenir ce blog configuré et en ligne. "A présent, c'est de celui-ci que je parle."

Mais, bon, qu'en est-il de vos commentaires ? Pour le moment, je ne suis pas encore sûr. Je présenterai quelque chose très bientôt. Peut-être puis-je trouver une manière de lier ensemble blogger.r et le BBS de REBOL, partant de l'hypothèse que cela prendrait quelques heures pour avoir un résultat correct.

Notez que le lien RSS devrait fonctionner également, mais je ne l'ai pas testé. Merci de me contacter si vous avez un problème.

(traduction : Philippe Le Goff)