Newsgroup: it.scienza.informatica
Titolo: ancora sul GOTO

Allora, a chi considera il GOTO come istruzione dei linguaggi di
programmazione di pari dignita` rispetto alle altre,
chi mi sa dire la semantica del GOTO?
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universitá di Pisa. 

G.Vecchiocattivi ha scritto nel messaggio ...

secondo Tarski o Kripke? =:-)
ciao da Giò.

chi mi sa dire la semantica del GOTO?
Il fatto che un linguaggio abbia un'istruzione come il Go To non significa
ASSOLUTAMENTE che il linguaggio non sia un buon linguaggio. In tantissimi
linguaggi (come il Basic ad esempio) l'istruzione c'č ma si puņ anche non
utilizzare e utilizzare delle sub o delle function...
Ciao
Dade
Davide Mastromatteo : [ 
mastr...@bigfoot.com
 ] - ICQ : 21746800
Mastrosoft [Sotto Costruzione ----> 
www.bigfoot.com/~mastrosoft
                                                         ***
" Nell'ozio, nel sonno, in battaglia, verrą senza darti avvisaglia
la morte va a colpo sicuro non suona il corno nč il tamburo. "

utilizzare e utilizzare delle sub o delle function...
La diatriba infinita ...
dipende di nuovo dalla metrica utilizzata per la definizione di "bontà"
del linguaggio. In questo caso Giorgio mette in evidenza la questione
della semantica del GOTO per alcuni scopi (IMHO): ad esempio non provate
a cimentarvi nella verifica formale della correttezza di un programma
che contenga dei GOTO...
Un linguaggio di programmazione è solo un artificio sintattico per
aumentare l'espressività della macchina a stack, che da sola è in
grado di calcolare tutte le funzioni calcolabili (ovvero gli insiemi
ricorsivamente
enumerabili).
Se non si accetta completamente questo fatto, si corre il
rischio di poter iterare la stessa considerazione su tutti gli
altri linguaggi ad alto livello, a partire dal C per passare
a Eiffel fino al Prolog e compagnia bella: sotto sotto c'è comunque
una macchina a stack...
Che poi ci siano programmatori che negli anni passati abbiano
sviluppato in Assembler delle grandi cose, lo sappiamo bene.
Ma la questione sul formalismo mi pare che coinvolga altri tipi
di considerazioni oltre quelle sul fatto che si possa programmare
comunque una applicazione funzionante (che non sempre è
sinonimo di una buona applicazione).
Se il Goto c'è ha senso usarlo, e per non usarlo perchè non
rivolgersi a linguaggi che non ce l'hanno (Lisp, Scheme,
Smalltalk, Prolog, Eiffel, Ops5, KL-1,...) ? (butto li la provocazione...;-)
Saluti,
Davide.

Certo. Io dicevo che non si può considerare un linguaggio 'non all'altezza'
un linguaggio solo perchè possiede il goto. Consideriamo non all'altezza i
programmatori!
Il Cobol ed il C hanno il goto. Io non l'ho mai usato in questi 2 linguaggi.
Il Cobol e il C sono linguaggi STUPENDI.
Ciao
Dade
Davide Mastromatteo : [ 
mastr...@bigfoot.com
 ] - ICQ : 21746800
Mastrosoft [Sotto Costruzione ----> 
www.bigfoot.com/~mastrosoft
                                                         ***
" Nell'ozio, nel sonno, in battaglia, verrà senza darti avvisaglia
la morte va a colpo sicuro non suona il corno nè il tamburo. "

Questa frase ha un senso solo se alla fine si aggiungono le parole
"non strutturati", tutta la scienza della verifica formale e' nata
usando linguaggi che contenevano il goto, non e' il goto che e' male,
e' il suo uso non strutturato-
Ancora una volta va anche osservato che un uso proprio dei goto e' una
delle componenti della buona programmazione, ma certamente non l'unica
Roberto Dadda
rob...@dadda.it
http://roberto.dadda.it
Davide <I....@office.now> wrote in message
news:77htqu$gqa$1...@menelao.polito.it...


 
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universita` di Pisa. 


scusa se non ti ho risposto prima, ma solo ora ho riletto il tuo post.
Si ricorre alla semantica di Kripke nel caso di teorie che facciano uso di
nozioni modali, ossia di operatori che non siano vero-funzionali. Nelle s.
di K. si fa riferimento a classi di strutture algebriche o "mondi
possibili", fra le quali vengono variamente definite delle relazioni di
"accessibilità".
ciao da Giò =:-)

 Il Cobol e il C sono linguaggi STUPENDI.
 Il C e il cobol stupendi??????? Hai fatto il test del palloncino? 
Il Cobol e' vecchiume, il C la negazione dell'umana intelligenza. 

>Il Cobol e' vecchiume, il C la negazione dell'umana intelligenza.
Il C è un linguaggio potente e funzionale.
Poi dire "Il cobol è vecchiume" dimostra che per poter negare l'umana
intelligenza ci vuole una cosa : " l'umana intelligenza" . Come ho già
spiegato, il Cobol possiede caratteristiche forti che ancora adesso lo
rendono il linguaggio di programmazione più usato su sistemi come l'AS 36 -
360 - 400. Viene ancora utilizzato in piccole reti di terminali in molti
centri pubblici e a tuttoggi, i programmatori cobol sono richiesti da
parecchie società di software.
Saluti
Dade
Davide Mastromatteo : [ 
mastr...@bigfoot.com
 ] - ICQ : 21746800
Mastrosoft [
www.bigfoot.com/~mastrosoft
 : OnlY 4 ProgrammerS
                                                         ***
"Alle cinque del pomeriggio tutto appare più complicato
                      di quanto in realtà non sia" (postulato di
Silkolhausen)"

 Il C e il cobol stupendi??????? Hai fatto il test del palloncino? 
Il Cobol e' vecchiume, il C la negazione dell'umana intelligenza. 
Può passare il commento sul Cobol, ma mi vuoi spiegare quale linguaggio si
può avvicinare all'umana intelligenza più di quanto faccia il C che per te
è la sua negazione?

 [..] il C la negazione dell'umana intelligenza.=20
Perche` queste affermazioni cosi` categoriche? Non riesci a
programmare in C o in Cobol?
Che ci siano linguaggi migliori e` sicuro... ma a da dire che 
e` la negazione dell'intelligenza umana ce ne passa.
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universita` di Pisa. 

 parecchie società di software.
E con questo? tutto cio' non implica che il Cobol sia un linguaggio
stupendo. La realta' italiana e' arretrata, e di molto. Il cobol e' uno
dei primi linguaggi, e il posto che merita e' quello vicino al PL/I
l'Algol: in un museo. Per fortuna i linguaggi sono (un poco) cambiati.  
Ciao, Francesco. 

 abbassi al suo livello. Io voglio la macchina vicino a me.
E come la costruisci la macchina che stia vicino a te?
Purtroppo è spesso *necessario* abbassarsi a quel livello, ed anche peggio,
visto che quegli antipatici dei transistori MOS non si autogenerano né si
autoorganizzano.
saluti,
	Denis

l'Algol: in un museo. Per fortuna i linguaggi sono (un poco) cambiati.
Per fortuna non tutti la pensano come te e per fortuna il Cobol è ancora
utilizzato. Effettivamente i linguaggi stanno cambiando,  e purtroppo con
l'avvento di Win si sono fatti strada linguaggi di programmazione per
eventi, che sono (sempre a mio parere) uno scempio. Hai presente il Visual
Basic? Faccio presente che lo utilizzo, dato che ormai l'interfaccia di
Windows è quasi uno standard, ma ad essere sinceri non è che sia un bel
linguaggio di programmazione. Solo disegnare i form mi sembra una cosa
particolarmente stupida (vuoi mettere con una maschera definita nella Screen
Section? :-) ) , se poi penso che il codice lo devo spezzare in tante
piccole parti, da mettere sotto i pulsanti, le immagini, nell'autoload del
form stesso o in un modulo staccato.... E poi hai un sorgente che per
salvarlo devi riempirti di files *.frm , *.bas , *.prj (nel migliore dei
casi). Ed il risultato? Interfaccia migliore, semplicità per l'inserimento
della grafica.....ma alla fine dei conti il programma è tanto efficace e
tanto efficente quanto un suo simile scritto in C. Mi dispiace ma non amo
questo tipo di programmazione, definitemi pure un folle legato al vecchiume
ma a me queste belle comodità non piacciono....


Il Cobol e' vecchiume, il C la negazione dell'umana intelligenza.
Mi piace la gente con le idee chiare! Ma tu sai programmare? E se si, con
cosa programmi? Dai, facci sapere in cosa dobbiamo scrivere il nostro codice
per farti contento! In Lisp? Fortran? Logo? o magari in Snobol? Che ne dici
dei ".BAT" del DOS? O magari.... ecco, ci sono! Dai, non dirmi che hai
inventato tu IL LINGUAGGIO del futuro: bello, agile, scattante (gia' che ci
sei fallo anche autocomponibile, cosi' si scrive da solo e noi facciamo
qualche cosa di piu' interessante, come corteggiare le colleghe....) e che
questa tua presa di posizione e' l'anteprima di una campagna pubblicitaria
ben piu' vasta, atta a cambiarci radicalmente la vita.
Siamo con te, illuminaci!


beh__adesso non mi toccate il VB_e con esso gli altri linguaggi di 4°
generazione.I linguaggi visuali sono nati per esigenze commerciali_per
produrre software in maniera piu' veloce_sfruttando le potenzialita'
dell'OOP.Poi come mai nessuno ha parlato di C++?Ecco_e' quello il
linguaggio ke si avvicina all'umana intelligenza hehe.
Dico per esigenze comerciali anke perke' Windowze e' ormai il S.O piu'
diffuso (purtroppo per alcuni:))).Come vorreste programmare per
win?L'OOP e' l'evoluzione naturale dei linguaggi di
programmazione_ormai si dovrebbero dimenticare Pascal e C.
Il cobol e altri linguaggi dedicati alla gestione sopravvivono per
motivi storici_ed e vero ke sono rikiesti ancora programmatori in
cobol_ma questo eprke' costa piu' dare una rinfrescata ai sistemi e
riscrivere codice ke assumere vekki volponi di cobol hehe.
Purtroppo il VB genera eseguibili molto pesanti_ke non hanno niente a
ke vedere con la leggerezza dei portable C,ma e' il rpezzo da pagare.

ke vedere con la leggerezza dei portable C,ma e' il rpezzo da pagare.
Perchè non impari a scrivere in italiano?
A parte questo (che non è poco) sono daccordo con te....
Ciao!
Christian Salvaneschi
Casarza Ligure, Genova, Italy
e.mail: 
cr...@geocities.com
   web: 
http://www.geocities.com/SiliconValley/Lakes/5139

dell'OOP.
Il Visual Basic non e' un linguaggio Object Oriented perche' non ha
l'ereditarieta' tra le classi. Nell'ultima versione hanno inserito
implements che ti permette una ereditarieta' cosiddetta di interfaccia ma
non e' paragonabile al C++. Il Visual Basic e' piu' orientato ai componenti:
vbx, ocx, activex, com.
Sul C++ sono d'accordo con te. Per me e' il miglior linguaggio perche'
associa una sintassi ed una semantica rigorose ad un'efficienza "by design".
Ciao
Antonio Donatiello

ke vedere con la leggerezza dei portable C,ma e' il rpezzo da pagare.
Il vb mi sembra soffra poi di altri problemi, se ci si lascia prendere la
mano, si riscia ad esempio di generare eseguibili poco mantenibili;
con linguaggi piu` rigorosi il problema esiste ancora ma e` piu` remoto
(e non di poco).
Personalmente imparai a programmare in basic, poi quando passai al
pascal capii che il basic aveva fatto piu` danni che altro. Quindi per
esperienza, pur sapendo dell'importanza commerciale del vb indirizzo
sempre verso altri linguaggi.
Paolo
----------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
----------------------------------------------------------

Ciao a tutti!
Per primo: scusate mio italiano, non l'ho parlato da anni.
Non vorrei iniziare un altro discorso infinito, ma parlando
di diversi linguaggi e di OO, fin'ora non e' stato mai detto
qualcosa su java, che -secondo me - e' un linguaggio
ormai matturo.
Anche la velocita' - coll' uscita della versione jdk2 (prima 1.2) -
e' aumentata di parecchio.
Martin
P.S: Potete rimandarmi una versione coretta di questa mail. ;-)

   web: 
http://www.geocities.com/SiliconValley/Lakes/5139
Ke ha il mio italiano ke non va?!?!?!opss__che non va?;))
(maledetto irc_fa prendere brutte abitudini hehe)

vbx, ocx, activex, com.
Beh_ti prego di corregermi se sbaglio_ma io credo ke,nella creazione
di una form,non si fa altro ke ereditare da un oggetto FORM,e lo
stesso vale per gli altri componenti.Guardando,per esempio, il codice
generato da un altro linguaggio visuale,cioe' dbase per windows,si
vede kiaramente ke ci sono delle istruzioni di ereditarieta',cioe' si
ereditano membri e metodi da un oggetto button per esempio.
Se sto scrivendo delle enormi    ?a%%at? vi prego,illuminatemi e non
siate aggressivi;))

Section? :-) ) ,
Beh tra una Screen Section e una form VB preferisco il secondo.
E tra il tasto Tab ed il mouse preferisco il secondo.
Max

ke vedere con la leggerezza dei portable C,ma e' il rpezzo da pagare.
Il prezzo da pagare per cosa? Per avere 3 finestrelle? No, grazie,
preferisco una bella interfaccia testuale.
Ciao
Dade
P.S. Comunque io dico la mia...spero di non scatenare flame inutili....


E luce sia.
Quando crei un bottone non erediti nulla, istanzi un tipo
bottone. Punto. L'ereditarieta' e' diversa. Se per esempio hai un
bottone particolare che ha delle proprieta' in piu' (
p.es
. un
immagine) allora si potrebbe fare un tipo bottone-con-immagine che
eridita tutte le proprieta' di un bottone ma ne ha altre in piu' (per
esempio quelle relative all'immagine). In vb un tipo bottone con
l'immagine non ha niente a che fare con il tipo bottone, sono due cose
distinte. Inoltre un sottotipo puo' essere usato In tutti i cosntesti
dove e' ammesso il tipo. Se ho una funzione che prende un bottone come
parametro, posso passargli anche un elemento del sottotipo.
Questo a grandi linee.


siate aggressivi;))
Quando crei un form crei un oggetto della classe form, una sua istanza.
 Il fatto che tu possa, poi, rispondere ad alcuni eventi messi a
disposizione da Visual Basic (e non altri) in effetti puo' generare
confusione ma si tratta solo di "punti di aggancio" nei quali inserire del
codice.
Se ci fosse l'ereditarieta' tu potresti creare partendo da Form una tua
classe MyForm nella quale potresti inserire tutto cio' che e' generale e che
vuoi avere in ogni form. In VB non lo puoi fare.
Puoi fare un activex ma di nuovo da un activex non puoi derivare (almeno non
semplicemente).
Non conosco bene dBase per Windows e quindi non ti so dire.
Ciao.
Antonio Donatiello

 associa una sintassi ed una semantica rigorose ad un'efficienza "by design".
Sull'efficienza non ci piove. Sul rigoroso avrei qualche dubbio: solo il fatto
che siano stati necessari svariati anni per definire lo standard (solo
recentemente approvato), mostra come non sia cosi' pulito. E non potrebbe
neanche esserlo, visto che puo' essere usato come estensione del C.
Gli ultimi studi sulla produttivita', riferiti ai linguaggi, mostrano
chiaramente come il C++ sia estremamente difficile da utilizzare senza farsi
male. I numeri parlavano di un numero di bug medi, a parita' di applicazione, 5
volte superiore del C++ rispetto al Java, e di una difficolta' di manutenzione
molto alta.
E poi, un linguaggio come il C++ che possiede il costrutto "friend", dovrebbe
nascondersi in un angolino e stare zitto quando si parla di OOP!
Lo stesso Ritchie, parlando del C++, lo interpreta come superset del C, con
tutti i problemi che ne derivano: per fare una cosa pulita, avrebbero dovuto
eliminare alcune parti del C, ma alla fine il risultato sarebbe stato un clone
di Java (detto sempre da Ritchie). Il vantaggio di aver mantenuto tutte le
possibilita' del C e' che i 'vecchi' programmatori possono sperare in un
cambiamento piu' progressivo verso una mentalita' OOP: un po come passare dal
DOS6.2 a win 95, la compatibilita' c'e' (+-), e puoi sfruttare le nuove
caratteristiche con calma.
Tutto questo secondo me (naturalmente).

caratteristiche con calma.
Anche Java ha mantenuto una sintassi simile al C++ per motivi analoghi.
Ciao
Antonio Donatiello

 caratteristiche con calma.
Bel paragone mi complimento. Hai fatto un complimento al C++ che non
finisce piu` :)
Comunque non capisco una cosa. Il linguaggio Java e` o non e` un
sottoinsieme del C++? Tutte le nuove caratteristiche del Java sono
soltanto o variazioni del C++ o "modifiche" a livello sintattico di questo.
Mah... comunque facessere un compilatore Java...


caratteristiche con calma.
Quella di dos-win3.x-win95-win98-winnt-win2000 e` la favoletta di M$ che continua
a sostenere la causa dei costi nel passaggio al software a 32 bit... cosa che poteva
essere vera prima, ma oggi? Come se poi la MS non avesse i mezzi per realizzare e
fornire un emulatore che invece Linux (che con il dos non ha niente a che fare) offre
di serie e pure gratis.
Stando alla MS ci ristroveremo presto con il problema di prima, perche` raggiunta
la totale migrazione ai 32 bit, ci ritroveremo a ricominciare per arrivare ai 64 bit.
Saluti,


Mah... comunque facessere un compilatore Java...
uh?


 soltanto o variazioni del C++ o "modifiche" a livello sintattico di questo.
non e' formalmente un sottoinsieme del C++, e certe modifiche sono sostanziali e non
solo sintattiche.
Pensa solo al GC, al bound checking .....
Bye

 la totale migrazione ai 32 bit, ci ritroveremo a ricominciare per arrivare ai 64 bit.
Vedremo con i nuovi processori, la Transmeta, l'E2k, linux e tutto il resto cosa succedera',
speriamo bene!
Bye

Boh, giusto, piu' da discussione sui sistemi operativi che altro. Un po off topic.
Quello che volevo fare notare e` che il paragone da te iniziato non mi sembra fosse
molto azzeccato.


Pensa solo al GC, al bound checking .....
Che paghi in prestazioni e che comunque puoi avere anche in C++.
Non mi sembra invece vero il contrario...


 [...]
Giusto una cosa, a questo proposito.. la gran parte degli studi di SE
(nelle sottospecie OOD/A :)) degli ultimi anni portano ad affermare
proprio il contrario!! :) I migliori risultati, in termini di
riusabilita' e flessibilita' di modelli, framework eccetera si ottiene
proprio specificando i "ruoli" degli oggetti, e non mediante
l'ereditarieta' funzionale. Addirittura, concetrandosi su questo
piuttosto che sulla creazione di gerarchie aggrovigliate, si ottiene
in genere un riuso *del codice* maggiore che se lo si fosse cercato
come obbiettivo principale. Se mi ricordo vi posto il titolo di un
paio di pubblicazioni su questo punto.
L'equivoco e' ancora presente perche' l'OOP e' *partita* dal riuso del
codice - mediante ereditarieta'... ma ha (parzialmente, e' ovvio)
lasciato quella strada da un po', ormai. Ci sono ancora un sacco di
libri e pubblicazioni varie pero' che non evidenziano minimamente la
cosa.
Incidentalemente, Java ha le interfacce proprio per questo. :)
Per sapene di piu', se gia' non gli conoscete, date un'occhiata a "OO
Analysis&Design" di Booch e "Design patterns" di Gamma, Vlissides&c.
Saluti,
	Cris

[..]
Ehi, questa del buon Bertrand non la sapevo! Hai mica l'aritcolo? :)


Be', giusto per portare il mio centesimo d'informazione - mi e'
capitato di fare degli screening su applicazioni scritte interamente
in Smalltalk 80. E - tenetevi forte - tutto tranne che *piccole*.
Sistemi grossi, venduti a caro prezzo e con diffusione
internazionale... scritti con un linguaggio (i cui pregi accademici e
di chiarezza concettuale sono, sia chiaro, indiscutibili) in cui hanno
dovuto costruire un framework giusto per metterci un certo typecheck!!
:)

Ehi, questa del buon Bertrand non la sapevo! Hai mica l'aritcolo? :)
Dovrebbe essere questo:
Bertrand Meyer,
"Genericity versus Inheritance"
Proceeding of OOPSLA '86
L'articolo comunque viene ripreso sul suo libro
Object Oriented Software Construction
A dire il vero non ho avuto modo di leggere l'articolo, ho saputo della
cosa indirettamente tramite un articolo di Carlo Pescio che piu` volte
a scritto in merito alla programmazione generica e alla OOP.


 Non mi sembra invece vero il contrario...
Sul GC non ci metterei la mano sul fuoco, e' una tecnologia molto meno famelica in termini di
risorse di quello che si creda, fai girare un tuo programma java con il verbosegc e vedrai che
resterai sorpreso.
Il bound checking e' esagerato, questo si che si paga. Possiamo fare come il MacOS che lascia
zone di memoria libere tra i programmi, in modo che se uno deborda non fa danni :)
Bye

 paio di pubblicazioni su questo punto.
Ecco, te ne sarei grato, in quanto questo tocca un'aspetto che mi interessa
molto, anche riguardo OO databases.
Bye

 che concede il privilegio e chi lo riceve, d'altronde non sempre le alternative sono migliori.
Esempio interessante, quasi quasi lo prendo come case study.. :)
Bye

internazionale...
Purtroppo conosco Smaltalk solo di fama (un vero paradosso per me che
sono quasi un fanatico di OOP e OOT in generale), e sono al corrente
dell'uso che se ne fa a livello commerciale, per cui non mi stupisco piu`
di tanto.


zone di memoria libere tra i programmi, in modo che se uno deborda non fa danni :)
Soluzione non accettabile, sforare i limiti e` comunque un errore che compromette la validita` di
un programma. Il Turbo Pascal adottava una soluzione migliore, consentiva di disabilitare
tale opzione (che quindi si usava solo in fase di debugging).
Saluti,


talmene rapide per gli utenti normali, che non vengono neanche prese in considerazione.
Questo e` vero, ma una macchina che non e` destinata ad un uso personale (tipicamente
un server) non e` mai abbastanza veloce...
Saluti,
Paolo
P.s.
   A proposito di uso di GC in sistemi RT non e` che avresti materiale da consigliarmi,
  potrebbe tornarmi utile anche per la tesi.


 calcolo numerico (tanto per citarne una...)
Uhm, mi sa che hai preso l'esempio sbagliato... :( C'e' lo STRAND, un
linguaggio logico con vincoli, usato per costruire applicazioni
distribuite di calcolo numerico e simbolico (soprattutto
algebrico). Abbastanza diffuso. (ovviamente in ambito accademico)


 con GC...
E fai bene... Usare il GC in ambienti RealTime mi sembra un errore
"assiomatico". Il GC per definizione non e` realtime.
Tra le altre cose pero` bisogna anche tenere in considerazione il
"target" di utenti che si vuole coprire. Ossia sviluppiamo
applicazioni Java per fare che? La maggiore tendenza mi pare che sia
quello della parte "client" di sistemi che prevedono anche una parte
"server". La parte server non e` obbligatorio che sia Java (o per lo
meno non interamente). 



Ah, ok. A me non era noto - nel senso che avendo lavorato in
progetti, fatto parecchie review, screening, reenginenering  eccetera
*non* mi era mai capitato. Comunque, il mondo e' bello perche' e'
vario... e in ogni caso, i signori di cui sopra vanno regolarmente
fuori tempo sulle consegne! ;)


Queste cose sono diffuse sempre negli ambienti accademici...
Chissa perche`?
Paolo


meno non interamente). 
Infatti generalmente sul server si preferisce avere un sistema quanto piu` performante
possibile in modo che possa gestire un carico maggiore...


povero gc interrverra', rallentandoti.
Nel mio caso, l'applicazione era piuttosto vorace sia in termini di cpu che di
ram (dovevo affrontare con euristiche un problema arduo) e la mancanza di
strumenti alternativi non mi ha permesso di utilizzare mezzi alternativi per
risparmiare sulla GC... Considerata la natura del problema, cio` non era
tanto grave, ma mi avrebbe permesso comunque di spingermi oltre nella
ricerca della soluzione.


 ----------------------------------------------------------
-- 


perche' in ambito commerciale non si sa che succede.
Insomma.. i giapponesi sul prolog (e cio` che ci sta dietro) ci hanno
investito (e in buona parte rimesso) una quantita` notevole di investimenti...
Per il resto non mi pare che in giro si parli molto di prolog.
