blaise: progetto per un nuovo compilatore pascal

[nomorelogic]

volevo segnalare che da qualche giorno è stato pubblicato un nuovo progetto per un compilatore pascal
blaise è il nome del progetto e lo trovate in
https://github.com/graemeg/blaise

l'autore è graemeg, autore di fpGui e PasBuild

si tratta di un progetto chiaramente ambizioso per un nuovo compilatore
la differenze sostanziali le potrete leggere nel link quì sopra

le più interessanti secondo me sono

• rottura con il vecchio codice con l'eliminazione di sintassi ereditate dagli anni 80
• un solo linguaggio (nessuna direttiva per attivare/disattivare un dialetto)
• un unico tipo di stringa UTF8
• oggetti e stringhe con conteggio automatico delle referenze

grazie all'ultimo punto, quando un puntatore esce dallo scope, c'è un decremento delle referenze con Free in automatico

si tratta di un progetto che è entrato in alfa da 1 giorno e c'è molto da fare
ma sembra già molto promettente

[xinyiman]

Caspita, davvero tanta roba.

[DragoRosso]

Non sò cosa pensare. Troppi linguaggi, troppi dialetti, troppa dispersione.

Io rimango con il mio buon vecchio Delphi.
Comunque il problema non sarà l'ennesimo linguaggio Pascal, sarà ovviamente la compatibilità con il preesistente e con il futuro.

E poi ? Mantenimento ?

Un conto è un pacchetto (per quanto importante possa essere) un conto è un linguaggio completo.

Non gioisco a questa notizia ... e spero di essere in torto.

[bonmario]

Concordo: si disperdono le forze, col rischio che alla fine ci perdano tutti i progetti

[Mimmo]

Più che un possibile rimpiazzo di fpc, mi pare più un divertissement per l'autore. Comunque forte come esperimento. Chissà che grado di compatibilità con i sorgenti attuali manterrà... certo che con il modello di gestione di memoria completamente rivisto sarà dura creare dei ponti. Peccato perchè sarebbe interessante se ce ne fossero.

[DragoRosso]

Il modello adottato (ARC) è stato implementato in modalità full in Delphi per un certo periodo. E' stato abbandonato velocemente nelle release successive a causa delle innumerevoli problematiche che creava.

In Delphi rimane ancora il "free" automatico di risorse come variabili locali anche durante il corpo begin ... end, ove il compilatore debba ottimizzare il tutto. Si può verificare durante un debugging dove alcune risorse sono disponibili in un punto X ma magari non più successivamente.
Ovviamente il tutto in piena sicurezza (o quasi  ).

Ovviamente rimane l'ARC con le interfacce, interfacce che il "Blaise" vuole ridiscutere.

Però, una bella discussione tra i core FPC e persone come "Graemeg" magari potrebbe avvenire per unire le forze ed evitare che vengano disperse.

Altra cosa, ma è un mio pensiero, FPC dovrebbe dividersi in due tronconi distinti: tutto ciò che è "vecchio e obsoleto" e tutto ciò che è corrente o nuovo.

Non ha molto senso fermare il mondo perchè una tecnologia non viene implementata in DOS (vado a caso ...). Tutto ciò dovrebbe avere un suo percorso legato alla disponibilità di persone che ci lavorano.

Inoltre sarebbe ora di fare una bella pulizia di tutti i "modificatori" e "define" che cambiano il comportamento del codice ... non penso che nella attualità moderna ci sia necessità di ciò.

Alcune cose interessanti in "Blaise" ci sono: l'unificazione delle stringhe in UTF-8 è una cosa positiva secondo me, ma come è successo a Delphi nel 2009 quando tutto cambiò in UNICODE (e ci furono addirittura due versioni concomitanti solo ANSI / solo UNICODE) prevedo lunghi anni di aggiustamenti.

Una cosa che non condivido, è l'uso di diversi strumenti come un compilatore C, PasBuild e GNU Make non distribuiti in bundle (oltre a dei binari primordiali, non quelli dei treni  ).

[nomorelogic]

capisco il discorso del risparmio di risorse e di unire le forze
resta il fatto che a volte è bene tirare una linea e fare qualcosa di evoluto senza portarsi dietro zavorre inutili
quanto sopra rispecchia i pregi ed i difetti dell'open source; il discorso "unire le forze" ha vari aspetti (leggere sotto)

per chiarire l'uso degli strumenti:

fpc
fpc serve per costruire il compilatore blaise
sembra arrivato il momento in cui blaise si compila da solo (!!!!) e fpc non serve più

PasBuild
PasBuild è l'alter-ego di "lazbuild", capisco che in ambienti GUI non sia troppo utile, ma in CD/CI è fondamentale.
Detto questo PasBuild è attualmente compilato con fpc e può essere usato sia con fpc che con blaise.
Credo che quando blaise avrà la maturità necessaria, vedremo un porting di PAsBuild a blaise.

C
il backend di blaise è QBE (e a seguire LLVM), quì arriva i discorso di unire le forze.
Nel senso che fpc ha innumerevoli target di compilazione ma anche QBE e LLVM, i quali hanno il loro team per le ottimizzazioni nella generazione di linguaggio macchina.
Il compilatore C serve per compilare verso QBE.
Può piacere o no ma questa è una scelta azzeccatissima: si lascia la generazione su più target ad uno strumento dedicato (diminuendo lo sforzo necessario e concentrandosi sul linguaggio da sviluppare).
Forse avrei preferito che venisse usato il backend di fpc però credo che QBE/LLVM siano meglio ottimizzati.

altre visioni di blaise
come già accennato l'autore è anche lo stesso di fpGui, ed anche questo prima o poi avrà il suo porting...
fpGUi non dipende da nessun widgetset di nessun OS: nèLinux, né MAC, né Windows...
Dialoga direttamente con X11 e GDI. Questo vuol dire che le app avranno lo stesso aspetto su tutti gli OS (può piacere o no) e vuole anche dire che le dipendenze eliminare sono.... numerose.


Di sicuro ci vorrà tempo, però a me sembra un ottimo progetto.

[DragoRosso]

Dialoga direttamente con X11 e GDI. Questo vuol dire che le app avranno lo stesso aspetto su tutti gli OS (può piacere o no) e vuole anche dire che le dipendenze eliminare sono.... numerose.

Quanto hai detto (oltre al citato) ha un qualche "link" di rimando di troppo, troppi strumenti usati per creare Blaise e da cui Blaise è totalmente diepndente, almeno in questo momento.
Rispetto al citato, X11 è in fase di smantellamento (OK, durerà ancora x(11) anni  ) e non è il caso di mantenerlo in opera per progetti nuovi (torno al mio precedente post, via la roba vecchia). GDI(+) per Windows è anche quello in fase di dismissione (già dichiarato a più fasi obsoleto da Microsoft) in favore di D2D (in primis, ma ci sono altre tecnologie all'orizzonte).
Quindi fpGUI è un progetto da rifare, non da importare ... sempre che si intenda avanzare. Ma tutto ciò è riferito anche a FPC ... anche questo dovrà avanzare prima o poi ... in alternativa c'è l'obsolescenza.
Da qui l'unione degli sforzi coordinati, verso la generazione di due prodotti ... ma coordinati.

Chi segue il forum internazionale o altre pubblicazioni vedrà che l'IA ha aumentato la proliferazione di progetti tra cui il famoso nuova compilatore C interamente creato (creato è un termine improprio secondo me, ma rende l'idea) dalla IA.

Oh, attenzione io parlo in termini "produttivi, ossia in termini che quello che si fà possa generare qualcosa da usare in produzione, sicuro, manutenibile, gestito e con garanzie futuribili (tra cui la rispondenza alle normative che stanno nascendo).

[nomorelogic]

GDI(+) per Windows è anche quello in fase di dismissione

certo, come ODBC... 


per il resto, sono punti di vista tuoi e li rispetto
ma che sia tutto condannato ad una fine inevitabile tranne Windows e Delphi mi pare esagerato no? 

[DragoRosso]

GDI(+) per Windows è anche quello in fase di dismissione

certo, come ODBC... 
per il resto, sono punti di vista tuoi e li rispetto
ma che sia tutto condannato ad una fine inevitabile tranne Windows e Delphi mi pare esagerato no? 

No, assolutamente nulla è condannato ad una fine. Non mi pare di avere espresso ciò.

Non è il mio modo di vedere, ma possiamo dire che la clava non si usa più per cacciare ? O che non si scrive più comunemente con scalpello e martello ?
Magari qualche essere ancora li usa, ma possiamo dire con assoluta certezza che quei modi sono non solo condannati ... ma ormai estinti dall'uso comune.

Quindi tutto sopravvive finchè viene usato, fatto salvo che non sia una clava ...

Poi chi ha detto che ODBC è stato deprecato ? E' normato dalla ISO e da quello che sò non è stato assolutamente deprecato. E non è un prodotto specifico o ideato da Microsoft (a differenza di quello che si crede). Java stesso usa un derivato diretto (JDBC) e il bridge JDBC-ODBC ove JDBC non "arriva".

[Lorenzo]

Anche io condivido le stesse perplessità di @DragoRosso.
Con tutti i suoi difetti,il Pascal ha anche pregi e punti di forza: uno di questi lo trovo nella parte di paradigma strutturato.
La sintassi Pascal non prevede le Go routine,ma anche i linguaggi più recenti hanno i loro colli di bottiglia.
Nessuna cosa umana è perfetta.
Tuttavia io vedo del futuro,incerto nel progetto FPC,ma sulla sua tecnologia;
è multipiattaforma,supporta vari piattaforme ed hardware che secondo me torneranno in pompa magna.

Per il resto credo che un aggiornamento del Pascal sia esattamente in linea con i progetti del professor Wirth.

Spero che non venga proposto una sorta di Pyscal,oppure un incrocio tra Pascal,Python e Java.

[nomorelogic]

Spero che non venga proposto una sorta di Pyscal,oppure un incrocio tra Pascal,Python e Java.

Pyscal o Jascal... spero proprio di no...

Comunque il mio post non era ovviamente una chiamata alle armi per cambiare compilatore, e ci mancherebbe pure 

Mi rendo conto che, nonostante le origini siano quelle di un linguaggio per imparare la programmazione, oggi, usare il pascal, non è proprio immediato e semplice.
Mi spiego meglio: devi scegliere tra non so quanti tipi di stringa, nell'RTL ce n'è uno, in console un'altro e poi non parliamo degli incroci con i sistemi operativi o, peggio, quando si usa JSON o XML...
Normalmente ci sono 3 o 4 {$DIRETTIVE} all'inizio di ogni unit che indicano come deve essere interpretato il codice in quella unit (!!!).
Senza contare la verbosità del tutto: la mancanza di un GC (sono contento che non ci sia!) e di un sistema di free automatico (ARC) ti porta a dover scrivere un 20% circa di codice inutile e scontato.

Insomma per me è un linguaggio (parlo sia di sia fpc che di Delphi) che, per necessità di retro-compatibilità, è un po' (?) alla deriva .
Che piaccia o no è difficile da usare per un neofita, ma anche per chi neofita non lo è più.

La visione di Blaise la vedo assolutamente più Pascal-like dei 2 citati e, secondo me, è l'evoluzione che questo linguaggio necessiterebbe.
Detto questo tra la sua nascita e l'uso in produzione... beh... diciamo che c'è ancora tempo. 

[DragoRosso]

Devo fare un appunto a quanto scritto da @nomorelogic.

Delphi a differenza di FPC non ha molti "modificatori" e tutto ciò a vantaggio della stabilità e della praticità: ad esempio per compilazioni di tutte le unità fornite in bundle nei due set fondamentali DEBUG (no ottimizzazione) e RELEASE (si ottimizzazione) per ogni piattaforma.

Inoltre ha due modificatori essenziali che modificano il comportamento del codice, gli altri sono ininfluenti e servono ad aggiungere solo elementi di controllo a runtime: sono DEBUG e RELEASE.

Solo il codice utente può variare, ad esempio con l'INLINE e le costanti scrivibili.
Quindi molto meno personalizzabile e forse meno ottimizzato, ma molto molto più stabile che FPC (in generale).

Inoltre, le stringhe sono di un tipo solo, ossia le UTF-16 (e non si può cambiare ciò). Poi l'adattamento automatico con le API (WIDESTRING Windows) e la possibilità di usare altri tipi di stirnghe come in FPC ossia AnsiString, UTF-8, ma in maniera esplicita.

Codice: [Seleziona]

var Pippo: string;
//Quella sopra è una stringa UNICODE. Non ci sono modificatori che consentono di cambiare ciò in Delphi.
//Se si vuole una stringa AnsiString allora si deve dichiararla esplicitamente:
Var Pluto: AnsiString;

[DragoRosso]

Senza contare la verbosità del tutto: la mancanza di un GC (sono contento che non ci sia!) e di un sistema di free automatico (ARC) ti porta a dover scrivere un 20% circa di codice inutile e scontato.

Il fatto che non ci sia un GC è una benedizione. E per quanto riguarda l'ARC .... non è proprio come pensi tu. Si innescano due processi che sono il "reference counting" e la "vita" della variabile.
Sulla vita della variabile interviene solo il compilatore, quindi già ora non è tutto scontato (ad esempio se si usano i "maledetti" puntatori ...).
Sull'ARC c'è un radicale cambio di prospettiva che gli utenti di FPC/LAzarus non sono assolutamente abituati: il "free", che attenzione non è che cessi di essere usata come si pensa normalmente, cambia aspetto e serve solo per "decrementare" il "ref count".
E la variabile quanto arriva a zero (il ref count), in un qualsiasi punto del programma, viene atutomaticamente liberata. Ed è indifferente quante volte la si usi a codice. Se in un punto il ref count và a zero, la variabile viene "liberata" e quindi anche se viene usata in un altro punto ... oops questa non esiste più generando un AV (quando và bene) o attingendo a dati casuali quando và male.

Credetemi sulla parola, molto meglio scrivere due righe in più di codice che rischiare l'ARC in generale. Poi l'ARC su qualche cosa ci stà (Delphi stesso usa l'ARC in diverse "cose") ma se viene applicato su tutto ... 

[nomorelogic]

Si fpc ha più stringhe di Delphi (che ne ha 4 mi sembra) in quanto non gestisce solo  UTF-16 ma anche  UTF-8 e  UTF-32 ed altre ancora.
Inoltre fpc ha molti target di compilazione: quindi una giungla di {$IFDEF} e molta confusione (più in fpc che in Delphi effettivamente).
Le potenzialità sono molte però, rovescio della medaglia, gestirle non è semplice (parlo solo di fpc).
Sviluppare con un solo target in mente è una cosa, ma voler fare qualcosa tipo "write once, compile everywhere" non è affatto facile.

Per questo affidarsi a QBE e LLVM può essere una svolta.

Per quanto riguarda GC la pensiamo ugualmente mi pare ma, per ARC, la pensiamo in modo differente.