Linguaggio per .NET
Noixe
avrei una curiosit� da porvi:
supponiamo che venga creato un linguaggio di programmazione (chiamiamolo L)
il cui compilatore genera codice IL, in modo da essere interpretabile dal
CLR facendo uso del framework DotNet.
Le specifiche da seguire, sono di pubblico dominio? So che .NET � uno
standard ECMA/ISO ma secondo quanto dice il seguente testo:
"Il Framework .NET si divide in due parti: le tecnologie coperte
dall'ECMA/ISO e le altre tecnologie sviluppate sopra di esse come ADO.NET,
ASP.NET e Windows.Forms. Mono implementa le parti ECMA/ISO, essendo questo
un progetto che permette l'implementazione di blocchi a livelli pi� alti
come ASP.NET, ADO.NET e Windows.Forms".
ci sono tecnologie che non appartengono allo standard e che ad esempio Mono
non supporta proprio per non violare i brevetti.
Di conseguenza, L non potrebbe fare uso di Windows.Forms, di ADO.NET e non
potrebbe essere usato sulla piattaforma ASP.NET come avviene con C# e
VB.NET?
Oppure, sarebbe fattibile solo se L non fosse usato per scopo di lucro e
fosse utilizzato solo su .NET e non su porting (come Mono)?
Microsoft potrebbe in qualunque momento decidere di integrarlo in Visual
Studio .NET (anche nelle versioni a pagamento) senza chiedere il permesso
agli sviluppatori di L?
Saluti
Raffaele Rialdi [MVP]
> Salve,
>
> avrei una curiositￜ da porvi:
>
> supponiamo che venga creato un linguaggio di programmazione (chiamiamolo L)
> il cui compilatore genera codice IL, in modo da essere interpretabile dal CLR
> facendo uso del framework DotNet.
>
> Le specifiche da seguire, sono di pubblico dominio?
Si sono le "CLI" Common Language Infrastructure (ECMA 335 [free] -
ISO/IEC 23271 [pay]) in cui ci sono alcune parti che sono mandatory
(obbligatorie) e altre che possono essere specifiche del linguaggio.
In pratica le specs descrivono il minimo set di caratteristiche che un
linguaggio deve supportare per poter essere compatibile con il runtime
engine (CLR nel caso di Microsoft). Il resto non ￜ obbligatorio perchￜ
non ￜ realistico pensare che tutti i linguaggi possano supportare
esattamente lo stesso set di specifiche.
> So che .NET ￜ uno
> standard ECMA/ISO ma secondo quanto dice il seguente testo:
>
> "Il Framework .NET si divide in due parti: le tecnologie coperte
> dall'ECMA/ISO e le altre tecnologie sviluppate sopra di esse come ADO.NET,
> ASP.NET e Windows.Forms. Mono implementa le parti ECMA/ISO, essendo questo un
> progetto che permette l'implementazione di blocchi a livelli piￜ alti come
Ma le librerie non c'entrano con le specifiche di un linguaggio...
>
> ci sono tecnologie che non appartengono allo standard e che ad esempio Mono
> non supporta proprio per non violare i brevetti.
Non ￜ cosￜ. Ado.net ￜ semplicemente una libreria di cui Microsoft non
ha rilasciato i sorgenti e quindi la copia per decompilazione sarebbe
una violazione di copyright, non di brevetti.
Questo non vieta (come nel caso delle winform di mono) di riscrivere
tutto da zero fornendo uguali funzionalitￜ.
> Di conseguenza, L non potrebbe fare uso di Windows.Forms, di ADO.NET e non
> potrebbe essere usato sulla piattaforma ASP.NET come avviene con C# e VB.NET?
Se tu crei "L" puoi usare le librerie a patto che siano installate come
richiede Microsoft, cioￜ con il package del Framework versione xyz
(quella che vuoi tu). Non puoi invece prenderti le dll di tuoi
piacimento e copiarle sulla macchina del tuo utente finale. In
quest'ultimo caso non avresti il CLR e quindi non ti funzionerebbe
comunque nulla.
> Oppure, sarebbe fattibile solo se L non fosse usato per scopo di lucro e
> fosse utilizzato solo su .NET e non su porting (come Mono)?
Il lucro non c'entra nulla.
> Microsoft potrebbe in qualunque momento decidere di integrarlo in Visual
> Studio .NET (anche nelle versioni a pagamento) senza chiedere il permesso
> agli sviluppatori di L?
Dipende dalla licenza con cui lo rilasci. Puoi fornirlo gratis per
l'utilizzo ma cmq prima che qualcuno lo possa redistribuire dovrebbe
sempre e comunque avere il tuo permesso (e tu potresti fartelo pagare
come meglio credi).
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
Noixe
> Ma le librerie non c'entrano con le specifiche di un linguaggio...
Non intendevo dire questo, intendevo un linguaggio che supportasse tutte le
librerie .NET fornite da Microsoft.
> Se tu crei "L" puoi usare le librerie a patto che siano installate come
> richiede Microsoft, cioￜ con il package del Framework versione xyz (quella
> che vuoi tu). Non puoi invece prenderti le dll di tuoi piacimento e
> copiarle sulla macchina del tuo utente finale. In quest'ultimo caso non
> avresti il CLR e quindi non ti funzionerebbe comunque nulla.
Sostanzialmente, si dovrebbe poter programmare in L facendo uso di tutte le
librerie .NET, e l'utente del programma creato, per poterlo utilizzare
dovrebbe fare uso del framework di Microsoft, come avviene con tutti gli
altri linguaggi. Immagina tutto quello che si puￜ fare in C# (dalle
applicazioni comuni, alla programmazione web tramite ASP.NET), solo che
sarebbe fatto in L. Nessuna nuova libreria, solo un nuovo linguaggio che usa
pari pari le librerie di .NET.
Mi chiedevo se questo fosse possibile tenendo conto della documentazione di
pubblico dominio e delle leggi vigenti in materia.
Raffaele Rialdi [MVP]
> Non intendevo dire questo, intendevo un linguaggio che supportasse tutte le
> librerie .NET fornite da Microsoft.
La forza del framework ￜ proprio quello di aver stabilito delle
specifiche che definisce i requisiti del runtime (sia lato linguaggio
che per gli implementatori di un nuovo runtime) e del type system che ￜ
il punto fondamentale e che storicamente ha dato piￜ problemi in
assoluto.
> Sostanzialmente, si dovrebbe poter programmare in L facendo uso di tutte le
> librerie .NET,
La creazione di un linguaggio non ha necessariamente bisogno delle
librerie.
D'altra parte se il linguaggio aderisce alle specifiche,
automaticamente puￜ usare tutte le librerie.
> e l'utente del programma creato, per poterlo utilizzare
> dovrebbe fare uso del framework di Microsoft, come avviene con tutti gli
> altri linguaggi.
ovviamente si
> Immagina tutto quello che si puￜ fare in C# (dalle
> applicazioni comuni, alla programmazione web tramite ASP.NET), solo che
> sarebbe fatto in L. Nessuna nuova libreria, solo un nuovo linguaggio che usa
> pari pari le librerie di .NET.
Questo ￜ stato lo scopo primario di dotnet quando sono state stese le
specifiche. ￜ proprio stato un requisito fortemente voluto.
> Mi chiedevo se questo fosse possibile tenendo conto della documentazione di
> pubblico dominio e delle leggi vigenti in materia.
Le leggi non c'entra nulla. Sei libero di fare quello che vuoi visto
che usi il framework.net cosￜ come viene redistribuito da MS che ￜ pure
totalmente free.
Non c'ￜ nulla di nuovo in tutto questo. Ci sono dozzine di casi di
nuovi linguaggi non-Microsoft.
Microsoft Research ha dato piￜ volte il "la" con linguaggi come ML,
spec#, C-Omega (poi inglobato in C# 3.0), F#, etc. etc.
Altri produttori hanno creato Cobol.net, Fortran.net, Eiffel.net, etc..
Piￜ recentemente molti altri linguaggi dinamici come Ruby, IronPython,
...
Non ricordo bene dove ma ci sono esempi da cui partire per costruire un
compilatore.
Il compilatore di C# di MS ￜ scritto in C++ perchￜ ￜ nato quando ancora
C# non esisteva :) mentre quello di Mono ￜ scritto in C#. Guardati i
sorgenti di Mono e fatti un idea
![Lorenzo Barbieri [MS]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjX3gtW6sACaBnHNp7W7kGwBSYwcDdLn50wp3hE3paGdae92XA=s40-c)
Lorenzo Barbieri [MS]
> Microsoft potrebbe in qualunque momento decidere di integrarlo in Visual
> Studio .NET (anche nelle versioni a pagamento) senza chiedere il permesso
> agli sviluppatori di L?
no. perchￜ dovrebbe?
--
Lorenzo Barbieri
Developer Evangelist - Microsoft Italia
www.lorenzobarbieri.info
Blog: http://www.geniodelmale.info
Noixe
> Non c'ￜ nulla di nuovo in tutto questo. Ci sono dozzine di casi di nuovi
> linguaggi non-Microsoft.
> Microsoft Research ha dato piￜ volte il "la" con linguaggi come ML, spec#,
> C-Omega (poi inglobato in C# 3.0), F#, etc. etc.
> Altri produttori hanno creato Cobol.net, Fortran.net, Eiffel.net, etc..
> Piￜ recentemente molti altri linguaggi dinamici come Ruby, IronPython,
Si, volevo solo avere dei chiarimenti in merito alla politica d'uso delle
librerie.
Noixe
"Lorenzo Barbieri [MS]" <lorenzo....@microsoft.com> ha scritto nel
messaggio news:mn.43687da56...@microsoft.com...
> Noixe presented the following explanation :
>> Microsoft potrebbe in qualunque momento decidere di integrarlo in Visual
>> Studio .NET (anche nelle versioni a pagamento) senza chiedere il permesso
>> agli sviluppatori di L?
>
> no. perchￜ dovrebbe?
Perchￜ dovrebbe importarlo o perchￜ dovrebbe chiedere il permesso?
Lorenzo Barbieri [MS]
perchￜ dovrebbe "impossessarsene"... non esiste una cosa del genere...
:-)
Raffaele Rialdi [MVP]
> avere dei chiarimenti in merito alla politica d'uso delle librerie
Una volta che queste sono installate ad opera dell'installer di
Microsoft, qualsiasi applicativo/framework/linguaggio puￜ usarle nei
termini di licenza (cioￜ sostanzialmente tutto fuorchￜ il decompiling)
Noixe
> perchￜ dovrebbe "impossessarsene"... non esiste una cosa del genere...
> :-)
Sai com'ￜ, magari il linguaggio comincia ad avere successo e Microsoft lo
inserisce nel pacchetto VS.NET :-)
Il che comunque non sarebbe male, dato che in tal modo si potrebbe usufruire
di tutti i vantaggi forniti da un RAD, usando il linguaggio che meglio
rispecchia i propri gusti (si suppone che almeno chi lo crea un linguaggio,
lo consideri tale :-))
Lorenzo Barbieri [MS]
> Sai com'ￜ, magari il linguaggio comincia ad avere successo e Microsoft lo
> inserisce nel pacchetto VS.NET :-)
Microsoft non prende il software altrui senza un accordo esplicito.
P.s. nessuno vieta a chi fa il linguaggio di aggiungere anche il
supporto per Visual Studio. non deve per forza farlo Microsoft
guarda ad esempio il cobol di Microfocus
Noixe
> Microsoft non prende il software altrui senza un accordo esplicito.
Ma non intendevo un impossessamento in senso negativo. Semplicemente un
supporto a tale linguaggio.
> P.s. nessuno vieta a chi fa il linguaggio di aggiungere anche il supporto
> per Visual Studio. non deve per forza farlo Microsoft
Si, ma se lo fa qualcuno tanto meglio ;-)
Noixe
> Non c'ￜ nulla di nuovo in tutto questo. Ci sono dozzine di casi di nuovi
> linguaggi non-Microsoft.
> Microsoft Research ha dato piￜ volte il "la" con linguaggi come ML, spec#,
> C-Omega (poi inglobato in C# 3.0), F#, etc. etc.
Per quanto riguarda l'assembly inline, ho visto che lo si puￜ usare con vari
linguaggi richiamando dll esterne, ma "nativamente" lo supporta solo C++?
Lorenzo Barbieri [MS]
>
>> Microsoft non prende il software altrui senza un accordo esplicito.
>
> Ma non intendevo un impossessamento in senso negativo. Semplicemente un
> supporto a tale linguaggio.
Il creatore di IronPython per .NET ￜ stato assunto da Microsoft per
lavorare su quel linguaggio... assieme a tanti altri.
>> P.s. nessuno vieta a chi fa il linguaggio di aggiungere anche il supporto
>> per Visual Studio. non deve per forza farlo Microsoft
>
> Si, ma se lo fa qualcuno tanto meglio ;-)
Bella la vita... :-D
Noixe
> Il creatore di IronPython per .NET ￜ stato assunto da Microsoft per
> lavorare su quel linguaggio... assieme a tanti altri.
Beh, in tal caso... ;-)
> Bella la vita... :-D
Il punto ￜ che sviluppare un ambiente completo come quello Microsoft sarebbe
un lavoro enorme che richiede molte conoscenze e molto tempo.
O forse intendevi dire che si puￜ creare qualche sorta di add-on per Visual
Studio .NET al fine di fargli supportare un nuovo linguaggio (completamento
automatico del codice, sintassi colorata, generazione automatica del codice
relativo agli eventi dei componenti, etc...)?
Lorenzo Barbieri [MS]
> O forse intendevi dire che si puￜ creare qualche sorta di add-on per Visual
> Studio .NET al fine di fargli supportare un nuovo linguaggio (completamento
> automatico del codice, sintassi colorata, generazione automatica del codice
> relativo agli eventi dei componenti, etc...)?
esatto... :-)
Noixe
> esatto... :-)
Ah, tramite tool o tramite pestaggio tasti della tastiera?
Lorenzo Barbieri [MS]
> "Lorenzo Barbieri [MS]" <lorenzo....@microsoft.com> ha scritto:
>
>> esatto... :-)
>
> Ah, tramite tool o tramite pestaggio tasti della tastiera?
pestaggio... naturalmente molte cose di vs le ricicli... ma devi
scrivere del codice...
anche se... se devi inventare un linguaggio sicuramente dovrai pestare
a dovere i tuoi tasti... :-)
Noixe
> anche se... se devi inventare un linguaggio sicuramente dovrai pestare a
> dovere i tuoi tasti... :-)
Eh eh, in questi casi serve la tastiera di scorta.
Visto che si parla di linguaggi, posto un'altra domanda (a dire il vero
l'avevo giￜ chiesto ma l'orologio al momento era settato male e forse non ￜ
arrivato).
Per quanto riguarda l'assembly inline, ho visto che lo si puￜ usare con vari
linguaggi richiamando dll esterne, ma "nativamente" lo supporta solo C++?
Sarebbe un problema fare in modo che "L" supporti anche l'assembly inline?
Raffaele Rialdi [MVP]
> Per quanto riguarda l'assembly inline, ho visto che lo si puￜ usare con vari
> linguaggi richiamando dll esterne, ma "nativamente" lo supporta solo C++?
Non ha senso inserire assembly inline dentro un linguaggio managed.
Da una parte nel linguaggio managed hai accesso a memoria che ￜ sotto
il controllo del garbage collector, dall'altra la direttiva _asm ti
permette di giocare direttamente con qualsiasi parte di memoria e dei
registri della cpu.
ￜ estremamente piￜ alta la possibilitￜ di fare disastri rispetto alla
presunta efficienza che potresti introdurre con _asm.
Tieni presente che:
- a livello di compilazione di un algoritmo, C# ha poco da invidare a
C++ (intendo per performance)
- a livello di allocazione di memoria, il GC ￜ molto piￜ veloce
rispetto ad una tradizionale malloc/free (o equivalenti)
In C++ guadagni tantissimo quando devi fare interoperabilitￜ (chiamare
Win32 api, lavorare in modo non tipizzato con della memoria, etc.)
Ma _asm non ti serve per l'interop perchￜ lo scambio dati (aka
marshalling) con la parte managed la devi fare comunque.
Infine scrivere a mano assembler oggi ￜ molto inefficiente perchￜ il
livello di ottimizzazione dei compilatori (C++ per primo ma anche il
jit non scherza) ￜ tale da rendere quasi impossibile per un umano fare
(a mano) di meglio.
Noixe
> Non ha senso inserire assembly inline dentro un linguaggio managed.
> Da una parte nel linguaggio managed hai accesso a memoria che ￜ sotto il
> controllo del garbage collector, dall'altra la direttiva _asm ti permette
> di giocare direttamente con qualsiasi parte di memoria e dei registri
> della cpu.
> ￜ estremamente piￜ alta la possibilitￜ di fare disastri rispetto alla
> presunta efficienza che potresti introdurre con _asm.
Ma tuttora mi pare che ci siano dei casi in cui assembly sia l'unica scelta.
Forse in quei casi semplicemente lo si usa all'interno di linguaggi non
managed, possibilmente con compilatori che generano codice macchina invece
che bytecode? Oppure DotNet ￜ stato studiato per far sￜ che si possa usare
asm solo con C++?
> Infine scrivere a mano assembler oggi ￜ molto inefficiente perchￜ il
> livello di ottimizzazione dei compilatori (C++ per primo ma anche il jit
> non scherza) ￜ tale da rendere quasi impossibile per un umano fare (a
> mano) di meglio.
Non dicevo di usare asm per guadagnare prestazioni, ma di usarlo in quei
casi in cui fosse necessario, o forse non ￜ piￜ cosￜ?
Raffaele Rialdi [MVP]
> Ma tuttora mi pare che ci siano dei casi in cui assembly sia l'unica scelta.
tolte le prestazioni, quali ?
> Forse in quei casi semplicemente lo si usa all'interno di linguaggi non
> managed, possibilmente con compilatori che generano codice macchina invece
> che bytecode? Oppure DotNet ￜ stato studiato per far sￜ che si possa usare
> asm solo con C++?
quello che scrivevo prima ￜ che ￜ inutile generare assembler se quel
codice che scrivi non puￜ collaborare con tutto il runtime che lo
circonda.
Prima poniti il problema di dove useresti asm e poi vedi come potresti
risolverlo. ￜ inutile ricorrere ad asm senza avere le idee chiare ...
> Non dicevo di usare asm per guadagnare prestazioni, ma di usarlo in quei casi
> in cui fosse necessario, o forse non ￜ piￜ cosￜ?
Tolti i motivi di performance, non ci sono molti altri motivi
Noixe
> tolte le prestazioni, quali ?
Ad esempio nella scrittura di driver per periferiche, o di applicazioni che
devono essere eseguite prima del sistema operativo, o di sistemi operativi
stessi, anche se credo che...
> quello che scrivevo prima ￜ che ￜ inutile generare assembler se quel
> codice che scrivi non puￜ collaborare con tutto il runtime che lo
> circonda.
...in quei casi non si pensa nemmeno a fare uso di macchine virtuali.
> Prima poniti il problema di dove useresti asm e poi vedi come potresti
> risolverlo. ￜ inutile ricorrere ad asm senza avere le idee chiare ...
Ma C++/CLI supporta l'assembly inline?
Sto chiedendo info in merito, proprio perchￜ mi sembra poco adatto ad
un'architettura che lavora cosￜ ad alto livello.
Raffaele Rialdi [MVP]
> Ad esempio nella scrittura di driver per periferiche, o di applicazioni che
> devono essere eseguite prima del sistema operativo, o di sistemi operativi
> stessi, anche se credo che...
Se scarichi il wdk vedrai che la quasi totalitￜ dei driver in esempio
sono scritti in C.
Il C assicura la portabilitￜ su platform diverse altrimenti dovresti
riscrivere il driver.
La HAL di Windows ￜ in assembler, ma qui si parla del cuore dell'OS.
Inoltre non vedo come la faccenda driver possa toccare il discorso di
un linguaggio managed. Con l'attuale architettura di Windows non c'ￜ
modo di scrivere driver con .net.
> ...in quei casi non si pensa nemmeno a fare uso di macchine virtuali.
ￜ ancora una cosa diversa. Il sw che gira dentro la VM il piￜ delle
volte non si rende conto di essere in una VM
> Ma C++/CLI supporta l'assembly inline?
ni ... C++/CLI puￜ essere compilato in modo mixed (nativo + managed) o
in modo safe o pure che generano solo IL.
Quindi ￜ possibile inserire assembler solo nella modalitￜ mixed.
> Sto chiedendo info in merito, proprio perchￜ mi sembra poco adatto ad
> un'architettura che lavora cosￜ ad alto livello.
C++/CLI ￜ un caso molto particolare proprio perchￜ estende il
linguaggio nativo e permette di mixare codice con quello managed
evitando PInvoke.
Noixe
>> ...in quei casi non si pensa nemmeno a fare uso di macchine virtuali.
>
> ￜ ancora una cosa diversa. Il sw che gira dentro la VM il piￜ delle volte
> non si rende conto di essere in una VM
Si, in generale dico, nei casi in cui si lavora molto a basso livello come
per la scrittura della HAL non si ricorre a VM.
> ni ... C++/CLI puￜ essere compilato in modo mixed (nativo + managed) o in
> modo safe o pure che generano solo IL.
> Quindi ￜ possibile inserire assembler solo nella modalitￜ mixed.
Ecco, allora entra in gioco una forma diversa di compilazione.
Raffaele Rialdi [MVP]
> Si, in generale dico, nei casi in cui si lavora molto a basso livello come
> per la scrittura della HAL non si ricorre a VM.
non capisco dove vuoi arrivare
> Ecco, allora entra in gioco una forma diversa di compilazione.
niente di diverso, dentro il compilato c'ￜ sia codice nativo (x86 ad
esempio) che IL.
Noixe
> non capisco dove vuoi arrivare
Era solo una considerazione. Mi chiedevo come venisse tradotto il codice
assembly in IL, ma invece viene tradotto in codice nativo.
> niente di diverso, dentro il compilato c'ￜ sia codice nativo (x86 ad
> esempio) che IL.
Per diverso volevo dire che appunto era misto e non puro IL.
Noixe
> niente di diverso, dentro il compilato c'ￜ sia codice nativo (x86 ad
> esempio) che IL.
Un file puￜ contenere sia codice macchina che IL?
Raffaele Rialdi [MVP]
> Era solo una considerazione. Mi chiedevo come venisse tradotto il codice
> assembly in IL, ma invece viene tradotto in codice nativo.
non avrebbe senso tradurre l'assembler in IL ...
Raffaele Rialdi [MVP]
> Un file puￜ contenere sia codice macchina che IL?
Si:
- gli assembly compilati da VC++ con /clr possono avere sia codice
nativo che IL.
- il linker di VC++ puￜ unire in un assembly piￜ .netmodule provenienti
da vari linguaggi managed come C# e VB.NET e codice nativo proveniente
da VC++
Noixe
> non avrebbe senso tradurre l'assembler in IL ...
Appunto, ma siccome pensavo che il compilatore producesse unicamente IL, da
qui il dubbio :-)