[zxspectrum] SpecLisp vs Campus LIsP

  • From: Stefano Bodrato <stefano_bodrato@xxxxxxxxxxx>
  • To: "zxspectrum@xxxxxxxxxxxxx" <zxspectrum@xxxxxxxxxxxxx>
  • Date: Wed, 29 Apr 2015 11:54:13 +0200

La risposta di Enrico mi ha ricordato del vecchio LISP per lo Spectrum del 1983
(Serious Software), e ho voluto approfondire.



La prima cosa che mi ha colpito sono alcune similitudini: entrambi hanno un
beve tempo di attesa all'avvio per impostare le parole chiave di base, entrambi
hanno un solo un editor di linea che supporta il solo tasto "DELETE", entrambi
gestiscono solo numeri interi e entrambi presentano delle curiose instabilità
(!).



Detto questo consiglio vivamente ai programmatori di approfondire: è un
linguaggio stupefacente. Ci sono purtroppo molte ragioni per cui non viene
preso sul serio, alcune molto valide, altre molto meno serie di quanto si creda.



Per fare un esempio: chi prenderebbe sul serio un linguaggio non provvisto di
funzionalità di editing e non in grado di riportare il listato delle istruzioni
già inserite ?

...in verità questa è solo una conseguenza dell'architettura del linguaggio:
una volta assimilata, l'istruzione è più listabile in quanto "trasformata" in
connessioni logiche, che probabilmente verranno ulteriormente modificate con le
prossime istruzioni.



Ho disassemblato lo SpecLisp ma al momento ne ho capite solo piccole parti.
Posso sicuramente sbagliare, ma credo che l'atomo nello speclisp sia costituito
da 3 byte, il primo dovrebbe essere il TAG che identifica il tipo e lo stato
dell'elemento (numero, binding, true/false, ecc..) e gli altri due dovrebbero
costituirne il contenuto (valore o puntatore). Campus LIsP invece si basa su
tipi LONG (4 byte) , con i primi 4 bit dedicati a tipo e stato (lo stato
dell'elemento comprende marcature simili a quelle che si fanno sui file system
con i comandi di "erase").







In breve ecco i vantaggi del Campus LIsP:



Editor più stabile, SpecLisp lascia passare codici di controllo strani come
INVERSE VIDEO e alcuni token (ad esempio AT), incasinando l'input e passando
all'interprete simboli che non comprende (con conseguenti errori, tipo "ILLEGAL
NUMBER FORMAT") difficili da capire.



Sintassi moderna, che ho ulteriormente aggiornato. Fatta eccezione per la
macro "while", la maggioranza dei comandi ricalca lo standard del "common
lisp", mentre SpecLisp si basa su una sotto-versione ormai dimenticata.



Possibilità di utilizzare molti più simboli in variabili e funzioni (ad esempio
è possibile utilizzare i simboli '+', '-', '>', '<' nei nomi funzione come da
standard)..



Supporto dell'apostrofo come abbreviazione di 'quote'.



Maggior estensione numerica (entrambi i LISP non supportano stringhe, floating
point o numeri di lunghezza infinita): -134217728..134217727 contro
-32768..32768 dello SpecLisp).



Scritto in C e personalizzabile facilmente (sto comunque pensando di ritoccare
SpecLisp per renderlo più compatibile con le sintassi recenti).







SpecLisp:



Turtle Graphics.. pare fosse una delle poche implementazioni del LISP con
supporto per la grafica !



(da verificare) maggiore spazio di memoria a disposizione per le applicazioni,
anche grazie all'atomo definito in 3 byte invece di 4: Campus LIsp usa una
quantità enorme di stack CPU, mi sembra che SpecLisp azzardi troppo e piazzi SP
alla locazione 381F (questo spiegherebbe le instabilità), ma non sono sicuro,
SP viene fatto ballare parecchio.



Supporto delle "property".. in teoria questo significa che il linguaggio è
Object Oriented.



Macro 'SET' (Common Lisp supporta solo la sua derivata 'SETQ').. questo
potrebbe permettere la definizione di liste circolari, ma non ho approfondito.



Echo sulla stampante ..credo che funzionerebbe anche con altre device aperte su
#3, ma resta il problema del poco spazio lasciato nell'area BASIC per aprire
altri canali con le shadow ROM.





Proverò a portare ELIZA sullo SpecLisp: se ci sta allora significa che per
molti versi è più potente.

Potrebbe a quel punto essere interessante metterci mano e potenziarlo, ho
alcune idee che non dovrebbero essere troppo difficili.


Other related posts: