Newsgroup: it.comp.lang.c
Titolo: Il fine ed il mezzo (lunghino)

 vuol dire nulla.
Mumble... abbi pazienza sono abbastanza ignorante in "c". C'e' comunque su ICOD
chi la pensa diversamente.
Del linguaggio non fanno parte solo keywords, definizioni varie, modalita' di
chiamata di funzioni, e compagnia bella?
"printf" non e' una keyword. D'accordo che faccia parte dello standard, che
definisce _anche_ un set di funzioni , senza il quale non ci sarebbe molta
portabilita' del sorgente, ma fa realmente parte del *nucleo* del linguaggio?
Se cosi' fosse, allora ogni funzione che mi definisco diventa una parola del
linguaggio? Ovvero, il discriminante per cui una funzione e' una keyword del
linguaggio, e' deciso dal fatto che sia una funzione standard del linguaggio,
oppure che sia una funzione definita dal programmatore? E tuttavia le due
funzioni vengono richiamate esattamente allo stesso modo?
bye G.L.

Gian Luca Sole wrote:
pardon... dimenticanza: x-post fra ICOD e ICLC.
bye G.L.

 linguaggio,
il concetto di "keyword" non esiste in teoria dei linguaggi, è solo un 
modo per definire quali sono le parole che NON si possono usare per 
altri scopi da quelli originariamente designati. In altre parole, posso 
senza problemi definire due funzioni con lo stesso nome che fanno cose 
diverse (ovviamente in contesti diversi), ma non posso ridefinire la 
parola "do".
Fabio Alemagna

 portabilita' del sorgente, ma fa realmente parte del *nucleo* del linguaggio?
I nomi di funzione, in C, non sono keyword, cosi' come non
lo sono in alcun linguaggio (in Pascal, Read o Write sono
nomi di funzioni, non annoverati tra le keyword).
Le parole chiave, lo dice la parola stessa, sono quella 
parte del linguaggio che identifica comandi particolari,
che non possono essere ridefinite.  In C, invece, tu
puoi scriverti la tua funzione printf().
Ma questo non vuol dire che le funzioni standard non siano
parte del linguaggio.  In C++, per esempio, e' stata
cambiata la forma di inclusione degli header standard con
una piu' generica (#include <iostream.h> e' diventato 
#include <iostream>) proprio perche', visto che e' una
libreria che contribuisce a costituire il linguaggio,
il compilatore puo' trattarla come vuole (teoricamente
potrebbe conservare i prototipi di funzione standard in un 
database e non come file di testo).  L'unica cosa che
il programmatore deve dare per scontato e' che in C
esista COMUNQUE E SEMPRE, SOTTO QUALSIASI PIATTAFORMA
la funzione printf(), la funzione scanf(), la funzione
sscanf(), ecc... proprio cosi' come assume che in Pascal,
esista comunque e sempre, sotto qualsiasi piattaforma,
la funzione read, la funzione write, ecc...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 da quando il linguaggio e' stato standardizzato.
D'accordo, le funzioni fanno standardizzate fanno parte del linguaggio in toto, ma
non del vocabolario definito nel C. Ecco qual'e' la (forse apparente)
contraddizione che colgo, nel discorso fra te e Alemagna: questo vale a dire che
forse esiste il windows C (come mi sembra disse Alemagna tempo fa, se non e' vero
mi riprenda), col suo standard (proprietario, d'accordo, ma pur sempre uno
standard) di funzioni per fare i/o tramite GUI? Oppure che esiste il linux-C,
sempre perche' comprende, oltre al set di funzioni ISO-C, funzioni di chiamata ad
API tipiche di gnu-linux, ed API contenute nelle libs di Xfree? Cioe', se e' vero
che le funzioni sono considerate parte del linguaggio, allora l'ISO-C sarebbe un
linguaggio gia' diverso dall'ipotetico windows-C (se le sue funzioni standard per
windows lo fanno gia' considerare un altro linguaggio, qualunque forma abbia un
compilatore per win32), e diverso dall'ipotetico linux-C?
Oppure fanno parte del linguaggio solo ed unicamente le funzioni standard
dell'ISO-C, e non le estensioni per particolari piattaforme che costituiscono lo
standard per un'altra piattaforma, standard che comprende comunque l'ISO-C?
Il problema a questo punto, dalla tua concezione di linguaggio e quella di
Alemagna, e' IMHO che bisognerebbe stabilire i termini nei quali si intende il
significato della parola "standard" in questi casi, non fosse altro per il fatto
che il confine che ci impedisce o ci consente di dire "windows-C" o "linux-C" (ma
ci consente magari di dire ISO-C), sarebbe forse un po' labile...
Questa non e' necessariamente una mia opinione, ritengo di avere una visione molto
aperta sull'informatica (non solo sui linguaggi), sono convinto che il C e' uguale
dappertutto, sulla falsariga dello standard ANSI-C o ISO-C, e che le altre librerie
di funzioni sono solo delle estensioni che ci consentono di usare le risorse
tipiche della particolare piattaforma (quindi non farebbero parte del linguaggio,
perche' non sono funzioni standard "esportabili" su qualunque piattaforma), e' solo
che cerco di capire qual'e' il vero punto di inciampo in questa discussione...
forse nessuno di voi due trasgredisce alle definizioni rigorose di linguaggio,
magari e' in effetti piu' una questione di opinioni che una questione
terico/tecnica...
bye G.L.

 ci consente magari di dire ISO-C), sarebbe forse un po' labile...
Il confine e' netto, chiaro, pulito e limpido.
E' la mente di chi si ostina a voler affermare il contrario che 
e' labile.  La parola "standard" non ha bisogno di ulteriori 
specificazioni, e' intuitivo capirne il significato.  Quando si
parla di standard del linguaggio si intende la formalizzazione 
(nero su carta) delle specifiche del linguaggio, che non comprendono
NULLA che riguardi una piattaforma specifica.


 compilatore per win32), e diverso dall'ipotetico linux-C?
   Con un minimo di infarinatura di teoria degli insiemi, la quale 
dovrebbe essere universalmente conosciuta, essendo materia di programma 
della scuola media inferiore, si potrebbe risolvere tutto molto 
semplicemente.
   Il linguaggio C, cosi` come codificato dall'ISO, e` un insieme di 
parole chiave, funzioni, regole sintattiche e semantica (e, se vogliamo, 
qualche regola sul collegamento dei simboli presenti in moduli 
differenti). E`, in poche parole, un linguaggio di programmazione. Altri 
contesti, come l'SDK di Microsoft Windows o le librerie POSIX o X 
Window, stabiliscono altri insiemi, differenti dal primo principalmente 
per le parti riguardanti le parole chiave e le funzioni (e, sempre se 
vogliamo, qualche regola sul collegamento dei simboli presenti in moduli 
differenti).
   Se una di queste estensioni, contiene interamente il linguaggio ISO 
C, allora puo` essere considerata /standard compliant/, e pertanto un 
programma scritto nel linguaggio codificato dall'ISO e` "portabile" su 
questa piattaforma. Se l'insieme dell'estensione, invece, interseca 
l'insieme del linguaggio codificato dall'ISO, ovvero non comprende una 
sua piu` o meno consistente parte, allora non e` /standard compliant/.
   Tale ragionamento, come e` facile osservare, non e` biunivoco, in 
quanto non e` fondato affermare che qualsiasi programma scritto per 
un'estensione sia poi "portabile" sulla piattaforma standard.
   Venendo al punto, un linguaggio di programmazione e` definito (a) da 
un organismo nazionale o internazionale (standard de jure) o (b) 
dall'azienda che ne produce i compilatori (standard de facto). Il 
linguaggio ISO C, le librerie POSIX e X Window sono standard de jure, 
l'SDK per Microsoft Windows e` uno standard de facto. Essi sono oggetti 
tra loro differenti nella misura derivante dall'analisi insiemistica dei 
loro componenti.
   Vale la pena, infine, di notare come il Manifesto di 
news:it.comp.lang.c preveda come /topic/ di discussione il solo 
linguaggio C codificato dall'ISO, salvo minime eccezioni a discrezione 
della coscienza dei partecipanti.
-- 
Veri pirati noi siamo       Ma cosa c'e` di male?
Contro il sistema lottiamo  Ma cosa c'e` di strano?
Ci esercitiamo a scuola     Facciamo un gran casino
A far la faccia dura        Ma in fondo lavoriamo
Per fare piu` paura         Per capitan Uncino

 standard NON COSTITUISCE un linguaggio A PARTE.
Ok. Prima la mia opinione era che il linguaggio non includesse le funzioni standard, e
che comunque le funzioni standard incluse e quelle definite dall'utente NON facessero
parte del linguaggio, e tuttavia ritenevo comunque che il linguaggio C fosse per
definizione sempre lo stesso linguaggio, indipendentemente dal compilatore e dalla
piattaforma sul quale e' implementato.
L'unica cosa che adesso cambia e' che lo standard ISO definisce le funzioni standard
come facenti parte del linguaggio, mentre le estensioni di ogni
compilatore/piattaforma, cosi' come le funzioni definite dall'utente, non costituiscono
una estensione del linguaggio, seppure il meccanismo di chiamata all'interno del
linguaggio sia identico a quello delle funzioni di libreria standard.
Il confine di tutto questo e' quindi lo standard ANSI-C e ISO-C, sbaglio?
bye G.L.

significato della parola "standard" 
Il significato della parola "standard" è chiaro. Lo standard definisce
il linguaggio e una serie di funzioni che il compilatore deve saper
compilare.  
Esiste la possibilità di estendere il "parco" di funzioni, lo posso
fare io come lo può fare la Microsoft. Questo non significa "andare
fuori dallo standard" ne creare un Marco-C... significa solo vincolare
i programmi che eventualmente fanno uso di quelle funzioni alla
disponibilità della libreria.
Poi il problema della portabilità è un'altro discorso. Se vuoi essere
certo che un programma possa essere compilato ed eseguito su tutte le
piattaforme e con tutti i compilatori non devi fare altro che NON
usare nessuna libreria esterna, quindi attenerti solo alle funzioni
definite dallo standard.
if(!spammer)
for(ptr=email;*ptr!='\0';ptr++) 
if(*ptr!='@' && *ptr!='.') *ptr -= 1;

 NULLA che riguardi una piattaforma specifica.
Quello che tu ti ostini a non voler capire - ed a questo punto mi viene da
pensare che tu non ne sia capace - e' che qui non si sta discutendo su
"cosa e' il C", ma sul fatto che il set di API di un determinato sistema
operativo costituisce un linguaggio a  se stante, se combinato con una
sintassi. L'API, infatti, definisce il vocabolario e la semantica.
Di conseguenza si puo' ben dire che il C che si usa per programmare
ESCLUSIVAMENTE linux ed il C che si usa per programmare eESCLUSIVAMENTE
windows sono DUE liguaggi che condividono la stessa sintassi, ma che
differiscono nelle altre due componnti FONDAMENTALI di un linguaggio
quanto tale, qualsiasi esso sia, di prorammazione  e non.
chiamalo come vuoi, se non vuoi chiamarlo WindowsC, non e' certo quello il
prolema. Di fatta sta che se io NON uso alcuna delle funzioni specifiche
del ISO-C, allora NON sto usando l'ISO-C, ma qualcosa d'altro.
In altre parole, volendo mettere in gioco il tuo caro standard, come si'
puo' non seguirlo ed ancora dichiarare di esservi conformi? Tu ti
contraddici con le tue stesse parole... in pratica con i fatti mi dai
pienamente ragione, ammettendo che le funzioni fanno parte del linguaggio,
ma poi ti tiri indietro dicendo che SOLO le funzioni definite dallo
standard fanno parte del linguaggio.. io ti do raginissima se ti limiti ad
affermare che fanno parte SOLO dell'ISO-C, e che quindi puo' esistere
qualcosa d'altro dall'ISO-C.
In ogni caso, il discorso prescindeva da qualsivoglia standard, ed era
atto a puntualizzare che esiste quello che si puo' definire "linguagio del
sistema operativo".
Poi tu continua andare er la tua strada, convinto di possedere la scienza
esatta, a me, di convincerti, frega poco e niente. :)
Saluti,
Fabio Alemagna

 dall'azienda che ne produce i compilatori (standard de facto).
Non e' esatto.  Non e' un aut... aut...
Il linguaggio e' definito dall'organismo internazionale.
L'organismo internazionale non apre, pero', bocca su quelle che
sono le implementazioni di ALCUNI aspetti nelle varie piattaforme.  
Traccia la linea gialla oltre la quale devono stare gli 
implementatori e questo gli basta.  
La definizione offerta dall'azienda e' solo per ALCUNI aspetti.
E' aggiuntiva, di completamento e prevista dallo standard.
Comunque, riassumendo il discorso, il succo e' che tutto cio' 
che riguarda il C e il C++ proviene da UNA ed UNA SOLA fonte:
l'organismo internazionale.  Gli implementatori possono solo
scegliere come implementare quegli aspetti che lo standard 
gli permette di implementare, avendoli classificati come
"undefined behavior" o "implementation-dependent".


 Il confine di tutto questo e' quindi lo standard ANSI-C e ISO-C, sbaglio?
Vedi la risposta a Capitan Uncino.


 Il confine di tutto questo e' quindi lo standard ANSI-C e ISO-C, sbaglio?
Vedi la risposta a Capitan Uncino.


 Non esiste nessun windows C.
[SNIP]
Si', su cio' che dici mi trovi d'accordo: cercavo semplicemente di capire il succo
della querelle fra Andrea e Fabio.
bye G.L.

Gian Luca Sole wrote:
A quanto mi sembra di capire, la situazione sarebbe questa:
Differenti opinioni in contrasto:
a) le funzioni, sia standard iso-C, sia funzioni estese per particolari
piattaforme/compilatori, sia definite dal programmatore, non fanno parte del
linguaggio.
b) SOLO le funzioni standard dell'iso-C fanno parte del linguaggio.
c) Tutte le funzioni, sia standard, sia estensioni per particolari
piattaforme/compilatori, sia funzioni definite dall'utente, fanno parte del
linguaggio, oppure sono un'estensione del linguaggio, oppure ancora costituiscono
un linguaggio a parte.
bye G.L.
p.s.: conosco poco di "c", propendevo per la a), la b) mi sembra ora piu'
verosimile, non fosse altro che non conoscevo le implicazioni dello standard ISO-C.

 Differenti opinioni in contrasto:
Non facciamo discussioni sterili, non si tratta di
opinioni, non c'e' nulla su cui essere d'accordo o
meno.  La realta' dei fatti e' quella che ti ho citato,
che non e' cio' che penso io, ma e' cio' che e' ben
formalizzato sui documenti dello standard internazionale.
Alla pagina seguente:
http://www.schweikhardt.net/identifiers.html
trovi l'elenco delle funzioni facenti parte
del ISO C, sia in versione C89, che C99 (per
ogni funzione e' specificato lo standard con
cui e' stata introdotta).
Lo standard, tra l'altro, prescrive delle 
regole da seguire, da parte del programmatore,
proprio perche' ha il compito di mantenere la
libreria standard.  Tanto per fare un esempio, 
il programmatore deve evitare di definire funzioni 
che inizino per "str", visto che questo prefisso e' 
riservato per le funzioni standard che lavorino 
sulle stringhe.


 Poi tu continua andare er la tua strada
Ci puoi contare e spero di non incontrarti.


 implementatori e questo gli basta. 
   Invero, non esiste alcun obbligo se non quello di un mercato che 
richieda la portabilita` per talune specie di programmi. In effetti, 
penso che ne` la locuzione "linguaggio C", ne` le sue traduzioni in 
altre lingue... umane, sia un marchio registrato (cosa che, invece, 
accade per Java).


 Non e' di certo parte del linguaggio.
Questo sempre perchè lo dici tu, ovviamente.
Fabio Alemagna

 formalizzato sui documenti dello standard internazionale.
Io, da parte, la chiuderei qui, continuate voi. ;-) Mi trovo d'accordo
con te, ti ringrazio per la esaustiva spiegazione che ha sciolto alcuni
miei dubbi (seppure all'epoca abbia studiato teoria dei linguaggi,
fortran pascal e lm/assembler, anche se non a livello universitario).
Semmai ho usato la parola "opinioni" perche', data la mia limitata
competenza, non volevo sbilanciarmi e offendere nessuno, ne tantomeno
alimentare flames.  :-)
bye G.L.

NULLA che riguardi una piattaforma specifica.
La parola "standard" e' chiarissima. E' la parola "linguaggio" che non pare
altrettanto chiara. Per quanto mi riguarda, "linguaggio" e' qualsiasi cosa
qualsiasi uno (o piu') parla (o parlano). Definizione in cui non entra la
parola "standard" e, per la verita', neppure la parola "condiviso da
altri": uno solo basta.
Ciao.

Non e' di certo parte del linguaggio.
Non e' parte di UN linguaggio. E' parte di un ALTRO linguaggio.
Ciao.

TUTTI i C, ma avere un subset in comune non significa essere uguali.
Tu usi l'ISO C perche' l'ISO C e' cio' che costituisce il
tuo linguaggio.  ISO C non vuol dire solo libreria di
sistema, vuol dire anche regole, semantica, proprie del
linguaggio.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it
"Meglio cieco che negro" (Stevie Wonder)

Un "mezzo di comunicazione" che non e' un linguaggio? Interessante.
Un mezzo di comunicazione non e' necessariamente un
linguaggio, spero che di questo te ne renda conto.


sono stati) prima di tutto standard de facto, come Java, C# o UBasic.
Si sta parlando di C e C++, e C e C++ sono definiti a
livello internazionale da un organismo chiamato ISO.


 linguaggio.
E che cavolo sto dicendo io?! Se NON uso le librerie dell'ISO-C non sto
usando il vocabolario nč la semantica dell'ISO-C.
Ok... mi sa che questa storia č andata anche troppo avanti... non č piů
divertente.
Fabio Alemagna

divertente.
Ok, divertiti da solo da adesso in poi.
La stupidita' va plonkata, non c'e' niente da fare.
*PLONK*


 Un "mezzo di comunicazione" che non e' un linguaggio? Interessante.
Si. Per esempio le OpenGL cosa sono? Un linguaggio?
E' semplicemente un "mezzo di comunicazione" o anche detto
interfaccia software per hardware grafico (nel caso di OpenGL)
non un linguaggio. Ad esempio un linguaggio e' formato da una sintassi
e non si puo estendere la sintassi del C ad esempio scrivendo un programma
in C, alcune volte addirittura non puoi nemmeno emulare la sintassi
del linguaggio di cui ti stai servendo ad esempio se il C o C++ non
avesse l'ellissi non potresti scrivere una printf e questo esempio
accade nel Pascal, prova a scrivere in Pascal qualche cosa
che si comporti come la writeln.
--
Ciao
Gaetano
--
#exclude <windows>
printf("\t\t\b\b\b\b\b\b");.
printf("\t\t\b\b\b\b\b\b");

 NULLA.
Ti dico io cosa vuol dire:
quando scrivi qualche cosa del tipo:
InetAddress group = InetAddress.getByName("228.5.6.7");
MulticastSocket s = new MulticastSocket(666);
 s.joinGroup(group);
stai programmando o in Java o in C++, (o non so io in quanti altri)
che di per se hanno sintassi diversa?
Puoi solo dire che in entrambi i casi stai usando lo stesso
"framework di interfaccia", mi vorrai dire che in questo caso Java e
C++ sono lo stesso linguaggio ?

 estendibile ad un insieme di funzioni.
Amico, so bene cosa è un framework, è l'espressione "framework di
interfaccia" che vuol dire poco e niente: come tu stesso riporti lì sopra,
"framework" già significa "interfaccia", o meglio, insieme di interfaccie.
Dire, invece, framework dell'interfaccia grafica, ad esempio, è totalmente
diverso in quanto stai specificando di che TIPO di interfacce stai parlando.
Saluti,
Fabio Alemagna

accade per Java).
Mi piacerebbe che per "linguaggio C" si intendesse l'insieme di tutte
le parole chiave, le funzioni e macro portabili (che qui chiamerò
semplicemente funzioni) scritte con le parole chiave del C ed anche
con le funzioni della libreria standard.
In tal caso non è detto che le funzioni della libreria standard (o le
parole chiave) non possano cambiare per essere sostituite con qualcosa
di più sintetico o generale. (sarà l'uso a mostrare quali sono i
costrutti migliori). In altre parole vedrei bene un linguaggio in
evoluzione verso la generalità.
Lo standard si dovrebbe occupare di aggiungere e levare le funzioni
del linguaggio (cosa che secondo me avviene troppo a rilento
limitatamente alle funzioni di libreria) e anche della descrizione
precisa e sintetica di dette funzioni.

No, costituisce un cetriolo, come tutti sanno.
Una libreria di funzioni è una libreria di funzioni e basta. Non è ne
un estensione del linguaggio, ne un linguaggio a parte e (mi spiace)
nemmeno un cetriolo.


 precisa e sintetica di dette funzioni.
   La creazione di uno standard "de jure" e` un processo lungo e 
difficile, in cui molti hanno diritto ad esprimere giudizi e consigli e, 
conseguentemente, faticoso e` il lavoro di riunificazione. D'altra 
parte, con il C89, lo standard precedente all'ultimo uscito, si e` 
campato agevolmente per anni e le modifiche dlla nuova versione non sono 
poi cosi` impressionanti e rivoluzionarie come si potrebbe credere.


 Un "mezzo di comunicazione" che non e' un linguaggio? Interessante.
Beh, chesso`, un telefono e` un mezzo di comunicazione,
ma non e` certo un linguaggio...
Lo so, lo so, sto un po' (ma non troppo) giocando con
le parole, forse pero` bisognerebbe girare la frase,
cioe`: un linguaggio e` un mezzo di comunicazione?
bye,
-- 
  Piergiorgio Sartor

Una libreria di funzioni è una libreria di funzioni e basta.
Una libreria di funzioni e' una libreria di funzioni e basta. Il linguaggio
che usi per accedervi e' un linguaggio. Se e' C, ci sono C diversi, perche'
ci sono librerie diverse; se non e' C e' un altro linguaggio.
Ciao.

linguaggio, spero che di questo te ne renda conto.
No. Se ci sono due (o anche uno) soggetti che comunicano, c'e' di mezzo un
linguaggio con cui comunicano. Se fra due soggetti che comunicano c'e' un
mezzo logico attraverso cui comunicano, questo mezzo e' un linguaggio.
Ciao.

Si. Per esempio le OpenGL cosa sono? Un linguaggio?
Si'.
Ciao.

 mezzo logico attraverso cui comunicano, questo mezzo e' un linguaggio.
Un protocollo e' un linguaggio?
bye G.L.

Gian Luca Sole wrote:

   Direi di si`.


    Direi di si`.
Le specifiche tecniche di un device che spiegano come leggere e scrivere i
registri e gestire gli interrupt, sono un linguaggio?
bye G.L.

Gian Luca Sole wrote:

   No, ma sono esprimibili in piu` di un linguaggio.


C standard.
[cut]
questa volta non mi hai convinto resto con le opinioni espresse prima.
(Cmq fossi al posto vostro non mi sentirei tanto sicuro sulle
definizioni di linguaggio o su "che cosa un linguaggio è"  :)))  )


La vedo dura programmare in OpenGL.
Non esiste al mondo nessun linguaggio che si chiami OpenGL.
Non sono nemmeno delle librerie. La definizione riportata dal libro:
Le OpenGL sono una interfaccia software per hardware grafico.


 Le OpenGL sono una interfaccia software per hardware grafico.
Anche, certo. In che modo questo è in contraddizione con lo status di 
"linguaggio" e "libreria"?
Fabio Alemagna

 definizioni di linguaggio o su "che cosa un linguaggio è"  :)))  )
   La definizione di "linguaggio" che ho dato io e` una semplificazione 
della definizione di Chomsky. Anche se potrebbe sembrare poco inerente 
alla /Information/ /Technology/, orami la linguistica... umana e lo 
studio dei linguaggi di programmazione hanno moltissimi punti in comune 
(basta leggere un qualsiasi libro di testo universitario sull'argomento).
   Ovviamente, come sempre quando si parla di concetti cosi` vasti, 
questo non mi rende *pienamente* sicuro ma *abbastanza* sicuro. ;)


 Le OpenGL sono una interfaccia software per hardware grafico.
   Quindi un "framework di interfaccia". :)


 Lo fai ogni volta che la  usi.
Peccato che sono solo delle interfacce alias free-function
e non mi sembra che ogni volta che uno fa una free-function
estenda il linguaggio.
Se in Java non ho la possibilita' di usare un idioma RAII non
ci sara' verso di usarlo anche se tu ne scrivessi 10000 di free-function.
Perche' c'e' distinzione tra nomi come Java, C++, C, C#, Python, Lisp
etc... e non una sola nomenclatura ?
Se a me dicessero di partecipare ad un proj scritto in Lisp farei una
fatica enorme ad adattarmi alla nuova sintassi, al fatto che non e'
imperativo, diverso sarebbe se dovessi partecipare ad un proj scritto
in C++ e dovessi usare un frame work specifico.
Riuscirei a compilare e linkare senza errori ( in Lisp avrei sicuramente
piu' problemi visto che non ne conosco la sintassi) ma non
vuol dire che ho generato programmi che semanticamente sono errati.
Scrivendo funzioni o classi non si cambia la sintassi. e non cambiando la
sintassi non si cambia linguaggio. Introdurre nuove parole (se per parola
intendi anche il nome di una funzione) non vuol dire cambiare linguaggio
diverso se cambi simboli privati, se in C riuscissi a scrivere:
per i uguale a 3 fino a 5 allora {
}
allora avresti fatto un nuovo linguaggio, ma per tua sfortuna non ci
riesci.


riesci.
#include <stdio.h>
#define per for(
#define uguale =
#define a
#define fino ;i <=
#define allora ;++i)
int main(){
    int i;
    per i uguale a 3 fino a 5 allora {
        printf("%d\n", i);
    }
    return 0;
}
;-)
-- 
Marco Barisione (ICQ 84277092)

 >}
Dovevo scrivere senza direttive per il compilatore ?



Anche un protocollo e' esprimibile in piu' di un linguaggio; il che porta
ad implicazioni interessanti. Che linguaggio e' un linguaggio che puo'
essere espresso solo tramite un altro linguaggio?
+--
I know you can't speak, I know you can't sign
So cry right here on the dotted line

 essere espresso solo tramite un altro linguaggio?
Un "metalinguaggio". Essendo un "metalinguaggio" un linguaggio esso 
stesso si crea il problema di qual'è il metalinguaggio che creai il 
metalinguaggio. Ebbene, la cosa si risolve facendo in modo che il 
metalinguaggio crei se stesso. Ad esempio, è possibile descrivere la BNF 
in BNF?
Fabio Alemagna

 ad implicazioni interessanti. 
   In piu`, il protocollo e` di per se un linguaggio, dato che ha la 
struttura "architetturale" di un linguaggio (vedi miei messaggi 
precedenti) ed e` utilizzato per scambiarsi informazioni.



sara' anche un linguaggio, ma non e' usabile se non attraverso
una implementazione in un altro linguaggio, quindi per me non
e' un linguaggio.


 e' un linguaggio.
   Fa come ti pare.



Aspettavo che me lo dicessi tu. Vi sono molte cose che possono essere considerate
linguaggi, che ne dici ad esempio dei segnali stradali? Uno potrebbe dire che si
tratta di un linguaggio 'read only', ma e' una questione estremamente oziosa.


 Aspettavo che me lo dicessi tu. 
   L'ho detto svariati messaggi fa. Se tu questo gruppo lo considerassi 
anche in lettura, oltre che in scrittura, lo avresti notato.



Tendo a dimenticare le cose irrilevanti :)


 Tendo a dimenticare le cose irrilevanti :)
   Te l'ho detto: fai come ti pare. Cuiusque artifex fortunae suae...



Ti ringrazio e ti invito a fare altrettanto; se uno ha il diritto
di fare certe affermazioni sugli "infiniti linguaggi C'' etc., anche 
io posso dire la mia, no?


 io posso dire la mia, no?
   Non mi sembra di averti negato questa possibilita`. Ove cosi` fosse, 
non era nelle mie intenzioni.


Un protocollo e' un linguaggio?
Si`, un protocollo e` un linguaggio.
Ciao.

riesci.
Basta molto meno:
   unsigned int quanti_anni_ho;
Se e` C, naturalmente "quanti_anni_ho = 50000" e` un'assegnazione legittima
e corretta; se non e` C, e` un'eta` assurda per un uomo. Il fatto e` che tu
quello che devi fare lo fai, te lo permetta o no il C, sicche' se non puoi
introdurre relazioni sintattiche con il C, lo farai in un altro modo; nella
documentazione (speriamo) o magari solo nella tua testa. Resta il fatto che
hai introdotto una relazione che prima non c'era.
Ciao.

Le OpenGL sono una interfaccia software per hardware grafico.
E quindi un linguaggio, se questo software lo vuoi in qualche modo usare. In
realta`, ovviamente, diversi linguaggi, giacche' si possono dare diverse
interfacce alla stessa libreria.
Facciamo cosi`, che si fa prima: quando fai una telefonata, usi un
linguaggio per metterti in comunicazione con il telefono; quando cambi
canale al televisore, usi un linguaggio per rapportarti al telecomando; il
comando della lavatrice presuppone un linguaggio (giacche' e` assolutamente
arbitrario che a "lavaggio 7" corrisponda, per esempio, un prelavaggio
leggero, un lavaggio a 60 gradi e una centrifuga).
Ciao.

cioe`: un linguaggio e` un mezzo di comunicazione?
Si`: "comunicazione" e "linguaggio" sono due termini in larga misura
intercambiabili.
Ciao.

 intercambiabili.
Uhm, la comunicazione necessita di un linguaggio, un
linguaggio e` un mezzo, o meglio un "layer", per la
comunicazione, ma non mi pare le cose sia intercambiabili.
Anzi, mi sembra descrivano due cose ben precise e diverse.
bye,
-- 
  Piergiorgio Sartor



Non so come lo intendi tu, ma nell'ambiente delle comunicazioni non ho
mai sentito nessuno definire un protocollo come un linguaggio. Nessuno
che sia competente, mi verrebbe da aggiungere. Un protocollo e' una 
specifica, non un linguaggio.


>Un protocollo e' una specifica, non un linguaggio.
un protocollo è una specifica ... di comunicazione.
Io posso comunicare con le parole, con lo sguardo, con i gesti (linguaggio
dei gesti).

 specifica, non un linguaggio.
Posso?  ;-)   IMHO, mentre un linguaggio umano ("conversativo", passatemi il
termine)  serve allo scambio di informazioni, un linguaggio di programmazione
per caso non e'... come dire... un linguaggio... sempre "imperativo"?   Cioe',
comando la macchina di fare qualcosa, e questa esegue, i/o compreso. La parola
"programmazione" non mi sembra ci sia riguardo un linguaggio umano od un
protocollo. Cioe', quando parlo con qualcuno, mica lo programmo, o lui programma
me...  :-))))
Non e' questo l'aspetto che forse distingue i linguaggi di programmazione per
elaboratori da altri linguaggi intesi in senso lato, e dai protocolli?
bye G.L.


Non sono un esperto di similitudini e differenze tra varie forme di linguaggi.
Ero intervenuto qui solo perche' la clsassificazione di un protocollo come un
linguaggio era troppo spinta per consentirmi di tacere.
