Un langage à pile très intéressant
alain
J'ai commenc� � d�couvrir un langage � pile tr�s puissant et tr�s
int�ressant.
Il s'appelle factor.
J'ai t�l�charg� la derni�re version en version binaire tgz.
Cela donne un gros fichier.
D�compression -> cr�ation d'un dossier factor, en cliquant sur l'ic�ne
"factor" contenu dans ce dossier, on lance "le truc" et on obtient un
environnement interactif qui ressemble, fonctionnellement au mode
interpr�t� de forth.
Exemples :
1.
( scratchpad ) 12 36 56 + * .
1104
Pour ce qui est de la division, le langage est assez subtil.
Si je veux diviser (en mode "interpr�t� � la forth") deux entiers...
2.
( scratchpad ) 123 5 / .
24+3/5
Autrement dit 135 divis� par 5 donne 24 et 3/5
Mais comment faire pour avoir une r�ponse d�cimale ?
Il semble qu'il suffit que le dividende soit d�cimal.
3.
Exemples calcul de Pi � partir du rapport 23 / 7 :
( scratchpad ) 23 7 / .
3+2/7
( scratchpad ) 23.0 7 / .
3.285714285714286
Ici, le dividende est d�cimal : 23.0 et le r�sultat l'est aussi.
En premi�re approche, le programme comprend deux fen�tres principales :
1. le listener qui correspond au mode interpr�t� de Forth
2. le browser qui permet d'acc�der � des ressources sur le langage.
En premi�re conclusion :
- grosse chose (le dossier install� fait 152 Mo, quand m�me), loin de la
compacit� d'un forth ou d'un basic d'autrefois.
- mode interpr�t� permettant d'exp�rimenter en particulier en lisant le
browser
- adaptation intelligente aux types num�riques, m�me non d�clar�s
explicitement.
A+
Alain
frederic
Bonjour,
Factor est sans doute le langage "ￜ pile" le plus connu en dehors des
sphï¿œres de Forth.
Dans l'esprit, il est plus un langage concatï¿œnatif qu'un Forth: typage
dynamique, gestion auto de la mï¿œmoire (GC). Cela en fait l'incarnation
parfaite de l'idￜe de "Lisp inversￜ" que se font habituellement ￜ tort les
dilettantes de Forth (cf. PLT Scheme - maintenant nommￜ Racket - par
exemple).
Mais bon, on a le droit de s'amuser diffï¿œremment ;-).
Dans le mï¿œme ordre d'idï¿œes il y a le langage "Thyrd" qui reprend Forth et
l'adapte ￜ la programmation visuelle et rￜactive
(http://thyrd.org/thyrd/). Je ne l'ai a vrai dire pas essayￜ, mais il
semble avoir fait sa petite impression lors de la confï¿œrence sur les
langages ï¿œmergents qui s'est tenue derniï¿œrement.
Bernard alain
> Bonjour,
>
> J'ai commencé à découvrir un langage à pile très puissant et très
> intéressant.
> Il s'appelle factor.
> J'ai téléchargé la dernière version en version binaire tgz.
> Cela donne un gros fichier.
> environnement interactif qui ressemble, fonctionnellement au mode
> Exemples :
> 1.
> ( scratchpad ) 12 36 56 + * .
> 1104
> Pour ce qui est de la division, le langage est assez subtil.
> 2.
> ( scratchpad ) 123 5 / .
> 24+3/5
>
> Mais comment faire pour avoir une réponse décimale ?
> Il semble qu'il suffit que le dividende soit décimal.
> 3.
> Exemples calcul de Pi à partir du rapport 23 / 7 :
> ( scratchpad ) 23 7 / .
> 3+2/7
>
> ( scratchpad ) 23.0 7 / .
> 3.285714285714286
>
> En première approche, le programme comprend deux fenêtres principales :
> 1. le listener qui correspond au mode interprété de Forth
> 2. le browser qui permet d'accéder à des ressources sur le langage.
>
> En première conclusion :
> - grosse chose (le dossier installé fait 152 Mo, quand même), loin de la
> compacité d'un forth ou d'un basic d'autrefois.
> - mode interprété permettant d'expérimenter en particulier en lisant le
> browser
> - adaptation intelligente aux types numériques, même non déclarés
> explicitement.
>
>
> A+
> Alain
>
Je ne sais pas comment j'ai reçu ce message, mais j'ai cherché des infos
et ça me parait intéressant. L'idée des combinators pour alléger les
mouvements de pile et rendre plus lisible le programme est quelque chose
de fort et un progrès sensible par rapport au Forth.
Je vais creuser.
Donc merci et à suivre.
Alain
alain
> Je ne sais pas comment j'ai re�u ce message, mais j'ai cherch� des infos
> et �a me parait int�ressant. L'id�e des combinators pour all�ger les
> mouvements de pile et rendre plus lisible le programme est quelque chose
> de fort et un progr�s sensible par rapport au Forth.
> Je vais creuser.
> Donc merci et � suivre.
Tant mieux.
Et � suivre... :-)
Alain
alain
Content d'avoir de tes nouvelles...
> Factor est sans doute le langage "� pile" le plus connu en dehors des
> sph�res de Forth.
>
> Dans l'esprit, il est plus un langage concat�natif qu'un Forth: typage
> dynamique, gestion auto de la m�moire (GC). Cela en fait l'incarnation
> parfaite de l'id�e de "Lisp invers�" que se font habituellement � tort
> les dilettantes de Forth (cf. PLT Scheme - maintenant nomm� Racket - par
> exemple).
>
> Mais bon, on a le droit de s'amuser diff�remment ;-).
Je sens un peu d'acidit� dans ce commentaire :-)
Est-ce li� au fait que Factor install� "p�se" 150 Mo ?
> Dans le m�me ordre d'id�es il y a le langage "Thyrd" qui reprend Forth
> et l'adapte � la programmation visuelle et r�active
> (http://thyrd.org/thyrd/). Je ne l'ai a vrai dire pas essay�, mais il
> semble avoir fait sa petite impression lors de la conf�rence sur les
> langages �mergents qui s'est tenue derni�rement.
La pr�sentation - graphique - est assez d�routante.
En fait son auteur est dans l'air du temps : il r�alise ses outils de
communication en m�me temps qu'il fait progresser son id�e de langage.
Ce qui n'est pas idiot : c'est un moyen d'avoir un bon impact sur le
public de passage.
Ceci �tant, une des forces de Factor r�side dans sa documentation.
Tr�s �tonnant...
Il y a aussi le fait d'avoir d�velopp� un vocabulaire XML : je connais
quelqu'un qui y vient � cause de cela.
Bien aussi : le mode interpr�t� � la Forth, qui permet d'exp�rimenter
sans avoir � compiler "lourdement".
La logique objet m'agace, mais il est difficile d'y �chapper.
Je vais essayer quelques temps, au moins pour deux raisons :
- le copain avec qui je vais pouvoir �changer
- la documentation (� l'usage, que vaudra-telle ?)
Et puis aussi � cause du mode interpr�t�.
Et toi, tu continues dans quelle voie ?
A+
Alain
frederic
> Je sens un peu d'aciditￜ dans ce commentaire :-)
> Est-ce liￜ au fait que Factor installￜ "pￜse" 150 Mo ?
>
:-) C'est vraiment curieux, je voulais pourtant pas l'ï¿œtre. Pour moi,
Factor
est un peu l'union des contraires: d'un cￜtￜ Forth, un langage
ultra-simple pour
une implï¿œmentation ultra-lï¿œgï¿œre, et de l'autre... Une gestion de mï¿œmoire
automatique,
un typage dynamique en coulisses, un compilateur super-optimiseur, etc.
C'est une chimï¿œre pour le moins ï¿œtrange.
> Et toi, tu continues dans quelle voie ?
>
Je travaille toujours sur mon nouveau langage, Lama, dont j'ai donnￜ un
aperï¿œu presque fidï¿œle dans mon mail prï¿œcï¿œdent, et qui est pour ainsi dire
ￜ l'opposￜ de Forth: gestion mￜmoire automatique, types forts, etc. Ce
langage doit permettre de jouer le rï¿œle de mortier pour faciliter
l'assemblage de librairies ï¿œcrites en C. Sous 4IM, j'avais fait ce genre
de liaisons avec de grosses librairies C, notamment le moteur graphique 3D
"Irrlicht".
Ces librairies sont assez simples ￜ utiliser quand on connait C ou Forth;
si bien que le langage est en fait le principal obstacle pour que
(presque) tout un chacun puisse les assembler et les combiner. Pour des
programmeurs non-professionnels ou des "bidouilleurs" (sans ï¿œtre
pï¿œjoratif), C ou Forth (ou d'autres langages comme Python ou Lua) sont de
sï¿œrieux obstacles. Avec Lama, j'essaie de faire un langage simple comme
Basic, mais en plus rigoureux (avec cette idï¿œe qu'imposer un peu de
rigueur aidera ￜ dￜvelopper les ￜchanges entre utilisateurs).
Le projet est pas mal avancￜ; les exemples dans mon autre mail
fonctionnent rï¿œellement. Mais il faut encore que j'ï¿œlimine les nombreux
bugs qui trainent dans les coins, que je dï¿œveloppe les librairies, et que
je documente sï¿œrieusement le tout (trï¿œs important!).
alain
> ... et
> que je documente s�rieusement le tout (tr�s important!).
Et tellement lourd !
Et par ailleurs in�vitable.
A+
Alain
Bernard alain
> Bonjour,
>
> > ... et
>
> Et tellement lourd !
> Et par ailleurs inévitable.
>
> A+
> Alain
>
>
Pour la doc., j'ai vu un truc intéressant dans Eiffel:
Un outil extrait du fichier source les signatures et les commentaires
ainsi que d'autres bricoles définissant les conditions d'utilisations
des définitions et qui sont aussi utilisées par le débogueur et le
compilateur (notion de contrat).
Bref on documente au fur et à mesure de l'écriture des définitions. Cela
permet de rester en phase plus facilement entre la doc et le source.
Alain
frederic
wrote:
> Le mardi 03 aoￜt 2010 ￜ 20:15 +0200, alain a ￜcrit :
>> Bonjour,
>>
>> > ... et
>> > que je documente sï¿œrieusement le tout (trï¿œs important!).
>>
>> Et tellement lourd !
>> Et par ailleurs inï¿œvitable.
>>
>> A+
>> Alain
>>
>>
>
> Pour la doc., j'ai vu un truc intï¿œressant dans Eiffel:
> Un outil extrait du fichier source les signatures et les commentaires
> ainsi que d'autres bricoles dï¿œfinissant les conditions d'utilisations
> des dï¿œfinitions et qui sont aussi utilisï¿œes par le dï¿œbogueur et le
> compilateur (notion de contrat).
> Bref on documente au fur et ￜ mesure de l'ￜcriture des dￜfinitions. Cela
> permet de rester en phase plus facilement entre la doc et le source.
>
Effectivement. Dans "The mythical man-month" publiￜ en 1986, Brooks
arrivait dￜjￜ ￜ la conclusion que l'intￜgration de la documentation au
code, plutï¿œt que la maintenance d'une documentation sï¿œparï¿œe, est l'option
la plus raisonnable. C'est assez ï¿œtonnant de constater que dans un livre
publiￜ il y a vingt ans, oￜ on parle constamment de cartes perforￜes, de
sauvegardes sur rubans, etc., en un mot pour un livre publiￜ au moyen-ￜge
de l'informatique, l'auteur fait des observations et tire des conclusions
qui restent trï¿œs actuelles. C'est sans doute pour cela que c'est un
classique de la littï¿œrature informatique.
Brooks distingue trois types de documentation selon les diffï¿œrentes
audiences visￜes; l'une d'entre-elles, celle destinￜe ￜ la maintenance
(donc pour les programmeurs), prend la forme de commentaires dans le
source, exactement pour les raisons invoquï¿œes.
Aujourd'hui, il existe des outils permettant d'extraire ces commentaires
pour former une documentation sï¿œparï¿œe. "Doxygene" est sans doute le plus
connu pour C/C++ et d'autres languages; certains languages ont leur propre
outil.
Certains poussent le "vice" encore plus loin: Scribble est un language de
documentation pour PLT Scheme (alias Racket):
http://vimeo.com/6630691 [video, en anglais]
En fait, celui qui a poussￜ cette logique jusqu'au bout est Knuth avec sa
"programmation littï¿œraire", qui est restï¿œe toutefois assez confidentielle.
L'idï¿œe est d'inverser le rapport code/documentation: le programme est
principalement une documentation de laquelle on extrait via un outil
similaire ￜ Doxygene le code pour le compilateur.
Cela me rappelle qu'il n'y a pas ￜ chercher bien loin une idￜe de premier
"vrai" programme pour un nouveau language...
--
Using Opera's e-mail client: http://www.opera.com/mail/
alain
> Pour la doc., j'ai vu un truc int�ressant dans Eiffel:
Je suis all� voir un peu Eiffel.
La syntaxe est tout sauf une partie de plaisir (en premi�re approche).
A l'usage, cela se confirme ?
Est bugg� ?
A+
Alain
Bernard alain
> Bonjour,
>
>
> Je suis allé voir un peu Eiffel.
> La syntaxe est tout sauf une partie de plaisir (en premičre approche).
> A l'usage, cela se confirme ?
>
> A+
> Alain
>
La syntaxe est particulière notamment sur les boucles et les assertions
ou les débogages mais il y a peu de mots en fait ( 60/70) et leur emploi
est défini de façon précise et sans exception.
Le langage est conçu pour pousser à un style de programmation par
contrat, pour pousser à la réutilisation et est destiné à des projets en
équipes d'ou l'importance d'avoir la doc. à jour.
Son ambition est l'ingéniérie informatique: appli vite conçu, facilement
exploitable, simple à maintenir.
Cela dit, je m'y suis mis rapidement. La difficulté est dans le
foisonnement des classes fournies avec le langage.
Le concepteur bertrand Meyer a développé un IDE (StudioEiffel) qui
facilite l'écriture et l'utilisation des classes et il existe une
version étudiante gratuite ( c'est un monument).
L'IDE pratique une compilation en 2 temps: rapide en bytecode pendant la
conception avec une finalisation par un compilateur C quand un morceau
de l'application est mure. La souplesse est proche du langage
interprété.
Coté bug: L'IDE fonctionne sous Linus Mandriva 2010 avec un "Pick and
Drop" qui ne démarre pas à la souris mais dans le menu contextuel. Il
s'agit peut être de réglage interne de la souris mais je n'ai pas trouvé
de solution.
L'université de Nancy a développé un outil SmartEiffel plus léger, sans
interface graphique, assez agréable à prendre en main que j'ai utilisé
il y a quelques années.
Je n'arrive plus à l'installer sous Linux ou Windows depuis quelques
temps. Il semble que les acteurs de son développement soient moins
actifs.
Alain Bernard
Bernard alain
> Le jeudi 05 août 2010 à 11:48 +0200, alain a écrit :
> > Bonjour,
> >
> > > Pour la doc., j'ai vu un truc intéressant dans Eiffel:
> >
> > Je suis allé voir un peu Eiffel.
> > La syntaxe est tout sauf une partie de plaisir (en premičre approche).
> > A l'usage, cela se confirme ?
> > Est buggé ?
> >
> > A+
> > Alain
> >
> Drop" qui ne démarre pas à la souris mais dans le menu contextuel. Il
> s'agit peut être de réglage interne de la souris mais je n'ai pas trouvé
> de solution.
>
bouton droit, le simple clic droit ouvre traditionnellement un menu
contextuel.
Le pick and drop permet de sélectionner un élément graphique représenté
par une icone "bubble" à la souris puis de relacher le bouton et
d'amener la souris sur un "hole" icone représentant une action à
paramètrer avec l'élément sélectionné et de finir la connexion par un
clic droit.
L'intérêt est de déplacer la souris sans avoir de bouton enfoncé donc de
façon plus décontractée et surtout avec moins d'erreur que le glisser
classique. Ce serait une fonctionnalité "ISE Eiffel".
alain Bernard