[zxspectrum] Re: SpecLISP bugfixed !
- From: Stefano Bodrato <stefano_bodrato@xxxxxxxxxxx>
- To: <zxspectrum@xxxxxxxxxxxxx>
- Date: Sun, 10 May 2015 17:19:44 +0200
Peccato aver fatto un lavoro così approfondito per poi "cadere" su qualcosa
che forse si poteva evitare collaborando con qualcuno in gamba come te :-).
Forse i tempi stringevano ed è stato costretto a farlo uscire così...
Si, è davvero un peccato. Il linguaggio è molto completo, forse troppo: le
strutture che permettono di associare proprietà agli elementi fanno si che la
memoria si riempa molto velocemente: la mia variante di ELIZA è veramente
ridotta all’osso ma si mangia 10K. L’elaborazione però è molto veloce, non ha
nulla a che vedere con le versioni in BASIC.
Perché ha qualche riserva?
La patch sarà facoltativa, credo, quindi chi vuole la usa/applica e chi non
vuole no...
La mia patch attuale si carica direttamente nello spazio degli UDG, si parte
con il lisp modificato con RANDOMIZE USR USR “r”. Non sevono CLEAR, basta
fare LOAD “” CODE 2 volte; Enrico mi ha fatto notare che un singolo blocco
bytes è però più managgevole e universale.
La prox patch non starà comunque nella UDG, quindi credo che potrei spostarla
temporaneamente in coda al blocco del LISP e inserire del codice che sistemi lo
stack e faccia la rilocazione della patch.
E' possibile rilasciare due tipi di patch? Intendo: una solo per correggere
i bug (mantenendo la compatibilità ) e una che potenzia anche il linguaggio.
Farò proprio così, la patch attuale è troppo carina per non renderla pubblica.
Inoltre certe caratteristiche avanzate dello SpecLisp vengono realizzate
in modo diverso dai LISP moderni e dovro’ fare delle scelte, probabilmente
dettate dal mio gusto.. :/
In che senso?
Questo mi sembra un buon esempio:
la moltiplicazione i LISP permette una lista di parametri infinita:
(* 3 4 5 6)
SpecLisp può fare solo:
(times (times 3 4) 5) ecc..
Al momento sono in grado di produrre una cosa simile:
(* (‘ (3 4 5 6))), che però è sempre diverso dallo standard.
A me sembra decisamente più decoroso (se si considera che lo SpecLisp invece di
‘' ‘ ” si aspetterebbe “quote”), ma forse è solo il mio gusto a guidare le mie
scelte.
Questi trucchi sono invece disponibili anche sullo SpecLisp senza patch:
Il comando “progression”, serve per eseguire una sequenza di istruzioni.
Nelle versioni moderne si usa la keyword “PROGN”, e se servono delle variabili
locali è disponibile “LET”.
Nei lisp più antichi si usava “PROG”, dove il primo parametro conteneva
l’elenco delle eventuali locali (o comunque una lista vuota, visto che il
parametro era obbligatorio).
SpecLisp si aspetta la keyword “PROGN” ma risponde alla sintassi di “PROG”,
come forse faceva anche una vecchia versione dello Stanford LISP (ma non tutti
gli altri, MIT, CMU, e neppure gli Stanford più recenti).
Possiamo supportare entrambe le sintassi, cambiando però il comportamento di
“progn” e perdendo la compatibilità con lo SpecLisp:
(putprop (quote prog) 25267 (quote subr))
(putprop (quote progn) 24632 (quote subr))
Allo stesso modo possiamo aggiungere “defun” alla contrazione “de”, molto poco
usata
(putprop (quote defun) 25144 (quote subr))
Come vedi le migliorie possono stravolgere lo SpecLisp, trasformandolo in
qualcosa di completamente diverso.
Possiamo aggiungere o ridefinire le keyword, ad esempio avvicinandosi alla
sintassi usata da EMACS, ecc ecc..
Other related posts:
