LISP sur calculatrices RPL

[FLISZT]

Hello,

Vous êtes sans doute nombreux à savoir qu'un compilateur LISP (pseudo-LISP) avait été développé pour la HP-28S : le Crwth-Lisp v. 3.2
On peut le (re)découvrir à cette adresse : https://www.hpcalc.org/details/403

Une version directement téléchargeable (pour HP-48SX et modèles ultérieures) se trouve ici :
https://groups.google.com/g/comp.sys.hp ... fzcvhWLx8J

À titre indicatif, je mets le lien de cet outil (pour HP-49G et +) censé, à partir d'une liste RPL ou d'une expression algébrique RPL, renvoyer une expression LISP : https://www.hpcalc.org/details/3267

[badaze]

Sans vouloir troller.
Qui veut encore programmer dans ce langage ? Il est horrible !

PS: J’avais eu une très bonne note à l’exam final à la fac.

[casuffitdeschanel]

C'est quoi un langage horrible? Un langage c'est un outil,non?

[badaze]

C'est quoi un langage horrible? Un langage c'est un outil,non?

C’est un langage difficile à lire.

[casuffitdeschanel]

Comme du xml je dirais guere plus... pas comme du rpg en cycle...

[FLISZT]

Sans vouloir troller.
Qui veut encore programmer dans ce langage ? Il est horrible !

PS: J’avais eu une très bonne note à l’exam final à la fac.

Peut-être ceux qui n'en ont jamais fait ?

Plus sérieusement, je crois que c'est un peu comme les « goûts et les couleurs ».
Perso, je préfèrerais faire du LISP plutôt que du PHP, par exemple, même si ce n'est pas le même usage.
Disons du Python…

LISP (CommonLISP) semble avoir toujours ses "aficionados", sans même parler des successeurs du langage LISP (Racket, Scheme…).

« Elegant Lisp Programs1 - School of Computer Science - Why I Love (Pure) LISP » (PDF)
https://www.google.com/url?sa=t&rct=j&q ... GVGS5hG5nm

Et puis il y a les utilisateurs d'AutoCAD (AutoLISP), sans oublier les fans du Casio AI-1000. À l'époque, si j'en avais eu connaissance, je l'aurais acheté.

Le RPL, lui aussi, n'est pas forcément très simple à lire et à mon avis, ça tient à de nombreux facteurs.

Tout d'abord, je trouve qu'il a de trop nombreuses possibilités d'écrire la même chose voire de mélanger ces possibilités :
100% STACK, variables locales, expression algébrique…

Perso, j'aurais préféré que le RPL soit davantage LISP et beaucoup moins FORTH.
Le fait de devoir utiliser une fonction locale (ou une variable locale) uniquement après avoir ouvert une paire de chevrons est quelque peu lourd :

Code : Tout sélectionner

<<
	<< .......... >>
	-> maFonction
	
@ appel de la fonction
	<< paramètres maFonction >>

@ ou encore
	<< maFonction(paramètres) >> 

>>

Quand le programme est court / simple, ça va. Mais sinon…

J'aurais préféré quelque chose du genre :

Code : Tout sélectionner

<<
	def maFonction
		<< .......... >>

@ et pouvoir l'utiliser ainsi façon notation polonaise inversée chère à HP
	paramètre-1 ... paramètre-n maFonction

@ ou bien ainsi
	maFonction(paramètre-1, ..., paramètre-n)

>>

Mais plus fondamentalement, je crois que le (user)RPL a été créé trop tôt, je veux dire par rapport aux possibilités matérielles de l'époque.
Comme l'a dit Bill Wickes "Life is short and ROM is full".

Ensuite, partant de l'existant, les ingénieurs n'ont pu que rajouter différentes couches, différentes possibilités (surtout mathématiques au détriment du langage de programmation lui-même ; un genre de STRUCT façon langage C aurait été sympa) mais sans pouvoir modifier la base afin d'avoir un minimum de continuité entre les différents modèles.

Mais bon, le RPL est comme il est et n'est pas si mal, loin sans faut.

Dans le cas qui nous occupe ici, ce mini compilateur LISP est juste une manière de faire qq chose de différent avec une calculatrice RPL.
Bref de faire « joujou » !