Lisp et Ti - Page 1

Existe-t-il un interpreteur Lisp pour ti89 ???
Si oui, ou le trouver.
Ou sinon, ou trouver des sources C suceptibles d'être recompiler pour Ti89/92+/V200 ???
(G pas trouvé sur google)

PiNGoO
a écrit : Existe-t-il un interpreteur Lisp pour ti89 ???

(à (de connaissance moi) (non (exister (pour (de interpréteur LISP) TI-89))))
Traduction: À ma connaissance, il n'existe pas d'interpréteur LISP pour TI-89.

Ou sinon, ou trouver des sources C suceptibles d'être recompiler pour Ti89/92+/V200 ??? (G pas trouvé sur google)

Ce n'est pas un interpréteur, mais peut-être que tu peux adapter ce convertisseur LISP->C: http://www.gnu.org/software/gcl/gcl.html. Mais il risque d'y avoir besoin d'implémenter plein de fonctions système qui ne sont pas disponibles dans TIGCCLIB.
Il y a aussi un interpréteur LISP dans Emacs, mais là c'est carrément le programme lourd par excellence, donc bonne chance pour le porter...

G trouvé des sources en C pas trés grosses (il y a 5 ou 6 fichiers) , je vais voir si j'arrive a le porter pour Ti
Sinon, Ca serait un travail enorme de faire un interpreteur (au moins avec CAR, CDR, CADDR, QUOTE, eveluation des liste et atomes...etc) Sans plus, juste avec le "minimum" vital ????

Aucune idée.

Kevin Kofler a écrit :
(à (de connaissance moi) (non (exister (pour (de interpréteur LISP) TI-89))))
Traduction: À ma connaissance, il n'existe pas d'interpréteur LISP pour TI-89.

notation préfixée... pour avoir un maximum de parenthèses... le contraire de ce qu'il faut faire

Baa le lisp c null

Vive le COBOL

lol
(non pas taper pas taper !!)

Non se qui m'enerve par contre, c'est qu'on ne peut pas utiliser des outils comme lex ou yacc pour faire des choses sur TI... (génére un code bcp trop lourd un simple truc avec lex : 90Ko une fois compilé...)

CACAML POWA !!!!!!!!!!!!!

Beurk le C_asioA_ddictM_arkupL_anguage

Caml Powaaa!!!!!!!!!!!!!!!

le chameau est bien à l'image de ce langage de merde ...
une gueule de con et hideux

hideux toi même

le caml est l'un des langages les plus moches qu'il m'ai été donné de voir

C'est le langage le plus beau et le plus pur qui existe!

tu parles de toutes façons le caml a été programmé en C++ dc C++ powa !

Vertyos a écrit :

C'était une démonstration de la notation LISP.

tu parles de toutes façons le caml a été programmé en C++ dc C++ powa !

Le C/C++, comme cochonnerie on fait pas mieux.
syntaxe moche et illisible, gestion de la mémoire archaïque, un empilage d'options lourdes et mal foutues, une compilation niveau maternelle, avec beaucoup trop de tolérance envers les codes crades, et des risques de sécurité ; des abus de macros, de inline, etc...

Le C++ c'est un truc batard, le mélange mal fait d'un langage super-impératif avec l'objet

Par contre c'est efficace et ça permet de pisser du code...

le C c une grande souplesse et un controle presque total

le caml c mal foutu, lourd et immonde !

Je vois les choses autrement que telchar (HIPPOPOTAME), moi:

HIPPOPOTAME
a écrit : syntaxe moche et illisible,

syntaxe simple à apprendre et rapide à taper,

gestion de la mémoire archaïque,

gestion de la mémoire flexible,

un empilage d'options lourdes et mal foutues,

un grand nombre d'options permettant d'optimiser le programme sur mesure,

une compilation niveau maternelle,

une compilation qui ne rejette pas du code inutilement quand un simple warning suffit,

avec beaucoup trop de tolérance envers les codes crades,

avec beaucoup de flexibilité dans le style de code, permettant ainsi d'obtenir le code le plus efficace possible,

et des risques de sécurité ;

et la possibilité de supprimer les tests de bornes pour obtenir du code plus efficace en taille et en vitesse;

des abus de macros, de inline, etc...

des possibilités de donner une syntaxe lisible à des expressions très compliquées par l'intermédiaire de macros, etc...

A notre époque on s'en fout du contrôle «presque total».

En dehors de la programmation d'un OS (où le C est encore indispensable), ça ne sert qu'à faire des trucs crades et dangereux. Le programmeur n'a plus à suivre les micro-détails d'implémentation, les CPU sont trop compliqués et trop variés pour s'y attacher. C'est en algorithmie que se font les vrais progrès, et le caml est tellement plus souple que le C dans ce domaine..

le caml c'est un compilateur à la volée superpuissant, super efficace, et c'est un langage extrêmement beau, ce qui ne gâche rien.

On dirait que tu n'as jamais programmé sur une calculatrice (ou d'autres environnements "embarqués" du même style, il n'y a pas que les calculatrices!). Rappel: processeur Motorola 68000 à 12 MHz... (Et on ne parle pas du Saturn de la HP-49G.)

Et personnellement, même sur PC, je préfère de loin un programme en C de 100 KO qui finit son travail en 1 seconde par rapport à un programme en un langage "protégé" qui prend 10 MO et qui finit son travail en 1 minute...

hummm moi je dit ya qu'un truc pour vous départager

Squeak powaaaaaa (Smalltalk) c'est le pere de quasi tout les langages objets

Meme mieux Squeak est ecrit en Squeak (meme la machine virtuelle)

syntaxe simple à apprendre

c'est faux.
ou alors, à ce compte là, tous les langages sont faciles à apprendre. Le C ne ressemble à rien d'autre, et pour quelqu'un qui ne connaît pas, c'est un OVNI.

et rapide à taper,

Les programmes C sont systématiquement plus longs que les programmes caml.

gestion de la mémoire flexible,

Surtout chiante pour l'utilisateur. Le simple fait de voir comment on doit gérer les chaînes de caractère en C me fait doucement rigoler...

Tiens, ça me fait penser à un truc que je n'avait pas cité : les descripteurs de type (les cochonneries du style **(*char*) ) sont TRES TRES TRES mal faits, chiants, nuls.
Par rapport au beau systématisme camélien...

un grand nombre d'options permettant d'optimiser le programme sur mesure,

Sur une Ti on peut vouloir optimiser du code sur mesure.
Sur un PC c'est contre productif.

une compilation qui ne rejette pas du code inutilement quand un simple warning suffit,

Une compilation qui laisse passer beaucoup trop de choses...
Enfin, ce n'est pas la compilation qui est tolérante, c'est le langage...

avec beaucoup de flexibilité dans le style de code,

alors là d'accord
au point d'inventer l'IOCCC... la belle affaire...

permettant ainsi d'obtenir le code le plus efficace possible,

Non c'est faux.
Sur un PC, à moins de potasser les spécifications techniques du processeur pendant des heures, on ne trouve pas le code le plus efficace, seul le compilateur est à même de faire les bons choix pour les petites questions d'implémentation.

et la possibilité de supprimer les tests de bornes pour obtenir du code plus efficace en taille et en vitesse;

et alors? tu crois que ce n'est pas le cas en caml?

des possibilités de donner une syntaxe lisible à des expressions très compliquées par l'intermédiaire de macros, etc...

trop d'abus!
On ne sait jamais si une fonction classique style printf est une macro ou pas! Macros + effets de bord(++) => piège à cons



Tiens ça me fait encore penser à deux autres cochonneries du C :

- l'abus d'effets de bord.

- l'abus de surcharge des opérateurs (je ne me souviens même plus du nombre d'usages différents de *...)

Et personnellement, même sur PC, je préfère de loin un programme en C de 100 KO qui finit son travail en 1 seconde par rapport à un programme en un langage "protégé" qui prend 10 MO et qui finit son travail en 1 minute...

Caml est aussi rapide que C et pas plus lourd.

Vive le squeak

Vive le Unlambda!!

HIPPOPOTAME a écrit :
c'est faux. ou alors, à ce compte là, tous les langages sont faciles à apprendre. Le C ne ressemble à rien d'autre, et pour quelqu'un qui ne connaît pas, c'est un OVNI.

Le C ressemble quand-même pas mal au BASIC et au Pascal. Il y a un peu moins de mots-clés et un peu plus de symboles, mais c'est pour qu'on puisse les taper plus vite.

Les programmes C sont systématiquement plus longs que les programmes caml.

Je parlais de la syntaxe. Et puis tout dépend des librairies utilisées. On peut certainement avoir une librairie C qui offre une grande partie des fonctionnalités du runtime CAML.

Surtout chiante pour l'utilisateur. Le simple fait de voir comment on doit gérer les chaînes de caractère en C me fait doucement rigoler...

Ce n'est pas si compliqué que ça, ça permet du code plus efficace, et puis il y a moyen d'écrire assez facilement des librairies de chaînes de caractères qui réallouent automatiquement les buffers au fur et à mesure (mais c'est lent, évidemment, tout comme ça l'est dans les langages qui font ça automatiquement).

Tiens, ça me fait penser à un truc que je n'avait pas cité : les descripteurs de type (les cochonneries du style **(*char*) ) sont TRES TRES TRES mal faits, chiants, nuls.
Par rapport au beau systématisme camélien...

Il n'est pas trop dur d'y prendre l'habitude. Et on peut souvent utiliser des parenthèses redondantes pour expliciter, par exemple:
char (*x)[20]; contre char *(x[20]);. Dans le deuxième cas, la parenthèse n'est pas nécessaire, mais améliore nettement la lisibilité.

Sur une Ti on peut vouloir optimiser du code sur mesure. Sur un PC c'est contre productif.

Pas nécessairement. On peut optimiser sur mesure pour un processeur bien particulier (par exemple parce qu'on veut faire une version pour chaque processeur, comme le fait Littleboy pour ses binaires de GCC pour TIGCC optimisés en vitesse). On peut aussi optimiser pour avoir du code compact (comme je le fais pour mes binaires de GCC à moi), ce qui est nettement plus simple que d'optimiser en vitesse.

Une compilation qui laisse passer beaucoup trop de choses... Enfin, ce n'est pas la compilation qui est tolérante, c'est le langage...

C'est quelque chose de bien, ça! Si tu fais quelque chose de sale, tu auras un warning. Tu es libre de corriger ton code pour éviter les warnings (GCC connaît même un switch pour toi: -Werror). Mais je ne vois pas pourquoi un compilateur doit forcer le programmeur à programmer de la manière qu'il juge propre. Un compilateur n'est pas un être intelligent, et il trouve souvent des saletés là où il n'y en a pas. Donc il fait bien mieux d'accepter le code avec un warning que de le rejeter juste parce qu'il pourrait y avoir une saleté.

alors là d'accord au point d'inventer l'IOCCC... la belle affaire...

Les programmes de l'IOCCC abusent de la flexibilité du langage C. Ça existera toujours, ce genre de trucs.

Non c'est faux. Sur un PC, à moins de potasser les spécifications techniques du processeur pendant des heures, on ne trouve pas le code le plus efficace, seul le compilateur est à même de faire les bons choix pour les petites questions d'implémentation.

Tu n'as pas compris. Il y a des cas où ça peut donner du code généralement plus efficace. Par exemple, un compilateur qui, en cas de doûte, accepte du code où il juge (à tord) qu'une variable pourrait ne pas avoir été initialisée (ça m'est déjà arrivé), permettra ainsi au programmeur de ne pas initialiser sa variable inutilement, ce qui donnera à coup presque sûr du code plus efficace (en taille et en vitesse) quel que soit le processeur de destination.

et alors? tu crois que ce n'est pas le cas en caml?

Ben alors le CAML n'est pas si sûr que tu le prétends...

trop d'abus! On ne sait jamais si une fonction classique style printf est une macro ou pas! Macros + effets de bord(++) => piège à cons

Vive les macros GNU ({ ... }), qui permettent de déclarer des variables temporaires à l'intérieur des macros et ainsi éviter les problèmes avec les effets de bords! On l'utilise à pas mal d'endroits dans TIGCCLIB, ld-tigcc et même le portage TIGCC de GCC.

Tiens ça me fait encore penser à deux autres cochonneries du C :
- l'abus d'effets de bord.

C'est très pratique de pouvoir écrire *(x++)=...; en une seule ligne. Et en plus, ça correspond exactement au mode d'adressage (an)+ qu'on retrouve sur pas mal de processeurs.

- l'abus de surcharge des opérateurs (je ne me souviens même plus du nombre d'usages différents de *...)

Il n'y a pas de surcharge d'opérateurs en C (pas ++). Il n'y a que les sens définis par le langage:
* sous forme d'opérateur binaire: multiplication
* sous forme d'opérateur unaire: déréférencement dans une expression, déclaration d'un pointeur dans une déclaration (cette "ambiguité" est là exprès parce que les déclarations miment le code utilisé par la suite pour accéder à la variable qu'on vient de déclarer; cette correspondance est très pratique à connaître quand il s'agit de lire une déclaration C)
Je ne vois pas de grande ambiguité ici.

HIPPO> Si on va par la GROLEK powaaaaa

La je te bat

Le C ressemble quand-même pas mal au BASIC et au Pascal.

Non.
(enfin tu peux donner le sens que tu veux à « pas mal »)

Et puis tout dépend des librairies utilisées. On peut certainement avoir une librairie C qui offre une grande partie des fonctionnalités du runtime CAML.

1) Les réponse style « on peut », c'est pas des réponse quand, dans la pratique, « on a pas ».

2) Mais de toute façon, les runtime de C et de caml sont tout à fait équivalents.
La différence de taille ne vient pas de là.

Ce n'est pas si compliqué que ça,

C'est plus compliqué que si c'était moins compliqué.

ça permet du code plus efficace,

Caml est aussi efficace que le C, la complication en moins.

et puis il y a moyen d'écrire assez facilement des librairies de chaînes de caractères qui réallouent automatiquement les buffers au fur et à mesure

Elles ne sont pas écrites, ou pas connues, ou pas standard. Bref.

Il n'est pas trop dur d'y prendre l'habitude.

Plus dur que si c'était fait intelligemment.

Et on peut souvent utiliser des parenthèses redondantes pour expliciter, par exemple: char (*x)[20]; contre char *(x[20]);.Dans le deuxième cas, la parenthèse n'est pas nécessaire, mais améliore nettement la lisibilité.

Il faut tuer les parenthèses.
Les parenthèses sont un fléau de l'informatique. D'ailleurs, dans caml, on en met le moins possible. Pourquoi écrire f(x) quand on peut se contenter de f x ? Un charme de plus de caml

Pas nécessairement. On peut optimiser sur mesure pour un processeur bien particulier (par exemple parce qu'on veut faire une version pour chaque processeur, comme le fait Littleboy pour ses binaires de GCC pour TIGCC optimisés en vitesse).

C'est plus efficace d'utiliser un compilateur rapide, comme caml, plutôt que de se faire ch*er à bidouiller pour chaque proc!

C'est quelque chose de bien, ça! Si tu fais quelque chose de sale, tu auras un warning. Tu es libre de corriger ton code pour éviter les warnings (GCC connaît même un switch pour toi: -Werror). Mais je ne vois pas pourquoi un compilateur doit forcer le programmeur à programmer de la manière qu'il juge propre. Un compilateur n'est pas un être intelligent, et il trouve souvent des saletés là où il n'y en a pas. Donc il fait bien mieux d'accepter le code avec un warning que de le rejeter juste parce qu'il pourrait y avoir une saleté.

Non.
L'informatique actuelle est ravagée aussi bien au niveau hard qu'au niveau soft par des programmeurs porcs qui n'en font qu'à leur tête et ne respectent pas les standards. Sur PC, le programmeur doit faire les choses proprement pour assurer la compatibilité, et parce que les processeurs sont conçus pour optimiser l'exécution des codes propres.
Le C est trop permissif, il faut sévir.

(Sur une calculatrice, la situation est différente)

Les programmes de l'IOCCC abusent de la flexibilité du langage C. Ça existera toujours, ce genre de trucs.

Parce que c'est dans la nature du C d'être sale.
Essaie un peu de faire ça en caml...

Tu n'as pas compris. Il y a des cas où ça peut donner du code généralement plus efficace. Par exemple, un compilateur qui, en cas de doûte, accepte du code où il juge (à tord) qu'une variable pourrait ne pas avoir été initialisée (ça m'est déjà arrivé), permettra ainsi au programmeur de ne pas initialiser sa variable inutilement, ce qui donnera à coup presque sûr du code plus efficace (en taille et en vitesse) quel que soit le processeur de destination.

qu'entends tu par "variable initialisée"?
(Je ne vois pas vraiment le rapport)

Ben alors le CAML n'est pas si sûr que tu le prétends...

1) On a le choix entre utiliser la librairie "sûre" et la librairie "rapide".

2) Je n'ai pas dit du tout que c'était un langage "sûr" (bien qu'il soit incontestablement *infiniment* plus sûr que le C). J'ai dit que c'était un langage PROPRE.
Mais comme tous les langages rapides et puissants, il est bien sûr possible de faire des choses non sûres. C'est assez difficile.

Vive les macros GNU ({ ... }), qui permettent de déclarer des variables temporaires à l'intérieur des macros et ainsi éviter les problèmes avec les effets de bords! On l'utilise à pas mal d'endroits dans TIGCCLIB, ld-tigcc et même le portage TIGCC de GCC.

moué, pourquoi pas...
c'est standard, en dehors de GNU?

C'est très pratique de pouvoir écrire *(x++)=...; en une seule ligne.

C'est pratique, inutile, et peu lisible.

Et en plus, ça correspond exactement au mode d'adressage (an)+ qu'on retrouve sur pas mal de processeurs.

Un compilateur digne de ce nom trouve tout seul le meilleur mode d'adressage. Le programmeur qui programme en langage TRUC n'a pas à s'occuper du hardware sous jacent (qu'il ne connait pas) mais à programmer en TRUC, point!

Il n'y a pas de surcharge d'opérateurs en C (pas ++). Il n'y a que les sens définis par le langage:
* sous forme d'opérateur binaire: multiplication
* sous forme d'opérateur unaire: déréférencement dans une expression, déclaration d'un pointeur dans une déclaration (cette "ambiguité" est là exprès parce que les déclarations miment le code utilisé par la suite pour accéder à la variable qu'on vient de déclarer; cette correspondance est très pratique à connaître quand il s'agit de lire une déclaration C) Je ne vois pas de grande ambiguité ici.

Passons sur l'utilisation de * dans les types, qui est normale uisque ce n'est pas le même contexte.
En C, la ou plutôt les fonctions * servent de multiplication entière, de multiplication réelle, de déréférencement. Trois usages différents, donc deux de trop.
Du point de vue du programmeur, c'est malpropre.
Du point de vue du compilateur, ce n'est pas très bon pour l'efficacité.
Sans compter les conneries du genre *=