Commits

Anonymous committed c177fd7

Typography.

Comments (0)

Files changed (5)

 <style>
 body{counter-reset:h1 11}
 </style>
-<!--
 <script>_gaq=[['_setAccount','UA-10482652-1'],['_trackPageview']];(function(){var g=document.createElement('script');g.src='//www.google-analytics.com/ga.js';g.setAttribute('async','true');document.documentElement.firstChild.appendChild(g);})();</script>
--->
+
 <div id=book>
 <p>Voi siete qui: <a href=index.html>Inizio</a> <span class=u>&#8227;</span> <a href=indice.html#cap-11>Programmare in Scala</a> <span class=u>&#8227;</span>
 
 
 <p>Un <em>linguaggio domain-specific</em> è un linguaggio di programmazione che imita i termini, gli idiomi e le espressioni usate dagli esperti di un particolare dominio. Il codice scritto in un <abbr>DSL</abbr> si legge come prosa strutturata per il dominio. Idealmente, un esperto di dominio con poca esperienza di programmazione può leggere, capire e convalidare questo codice. A volte, un esperto di dominio potrebbe essere in grado di scrivere codice in un <abbr>DSL</abbr> anche se non è un programmatore di professione.
 
-<p>I <abbr>DSL</abbr> sono un argomento vasto. Sfioreremo solo la superficie dei <abbr>DSL</abbr> e dell'impressionante supporto fornito per loro da Scala. Per maggiori informazioni sui <abbr>DSL</abbr> in generale, si vedano <a href=apa.html#Fowler2009>[Fowler2009]</a>, <a href=apa.html#Ford2009>[Ford2009]</a> e <a href=apa.html#Deursen>[Deursen]</a>. Lo strumento <kbd>sake</kbd>, usato per assemblare gli esempi del libro, adopera un <abbr>DSL</abbr> simile al venerabile <kbd>make</kbd> e al suo cugino Ruby <kbd>rake</kbd>. (Si veda il file <span class=file>README</span> nell'archivio di codice scaricabile per i dettagli.) Per altri esempi di <abbr>DSL</abbr> &#8220;interni&#8221; ed &#8220;esterni&#8221; in Scala, si vedano <a href=apa.html#Ghosh2008a>[Ghosh2008a]</a> e <a href=apa.html#Ghosh2008b>[Ghosh2008b]</a>. Per quanto riguarda il materiale avanzato sui <abbr>DSL</abbr> che usano Scala, <a href=apa.html#Hofer2008>[Hofer2008]</a> esamina la sostituzione polimorfica di implementazioni alternative per le astrazioni di un <abbr>DSL</abbr>, utilizzabile per attività di analisi, ottimizzazione, composizione, <i class=baa>&amp;</i>c.
+<p>I <abbr>DSL</abbr> sono un argomento vasto. Sfioreremo solo la superficie dei <abbr>DSL</abbr> e dell&#8217;impressionante supporto fornito per loro da Scala. Per maggiori informazioni sui <abbr>DSL</abbr> in generale, si vedano <a href=apa.html#Fowler2009>[Fowler2009]</a>, <a href=apa.html#Ford2009>[Ford2009]</a> e <a href=apa.html#Deursen>[Deursen]</a>. Lo strumento <kbd>sake</kbd>, usato per assemblare gli esempi del libro, adopera un <abbr>DSL</abbr> simile al venerabile <kbd>make</kbd> e al suo cugino Ruby <kbd>rake</kbd>. (Si veda il file <span class=file>README</span> nell&#8217;archivio di codice scaricabile per i dettagli.) Per altri esempi di <abbr>DSL</abbr> &#8220;interni&#8221; ed &#8220;esterni&#8221; in Scala, si vedano <a href=apa.html#Ghosh2008a>[Ghosh2008a]</a> e <a href=apa.html#Ghosh2008b>[Ghosh2008b]</a>. Per quanto riguarda il materiale avanzato sui <abbr>DSL</abbr> che usano Scala, <a href=apa.html#Hofer2008>[Hofer2008]</a> esamina la sostituzione polimorfica di implementazioni alternative per le astrazioni di un <abbr>DSL</abbr>, utilizzabile per attività di analisi, ottimizzazione, composizione, <i class=baa>&amp;</i>c.
 
 <p>I <abbr>DSL</abbr> ben progettati offrono diversi vantaggi.
 
 <dt>Efficienza
 <dd>Dato che i dettagli di implementazione sono incapsulati, un <abbr>DSL</abbr> ottimizza lo sforzo richiesto per creare o modificare le funzionalità di una applicazione.
 <dt>Comunicazione
-<dd>Un <abbr>DSL</abbr> aiuta gli sviluppatori a capire il dominio, e gli esperti di dominio a verificare che l'implementazione soddisfi i requisiti.
+<dd>Un <abbr>DSL</abbr> aiuta gli sviluppatori a capire il dominio, e gli esperti di dominio a verificare che l&#8217;implementazione soddisfi i requisiti.
 <dt>Qualità
-<dd>Un <abbr>DSL</abbr> minimizza il &#8220;disadattamento di impedenza&#8221; tra i requisiti funzionali, nel modo in cui vengono espressi dagli esperti del dominio, e il codice sorgente dell'implementazione, limitando così i potenziali errori.
+<dd>Un <abbr>DSL</abbr> minimizza il &#8220;disadattamento di impedenza&#8221; tra i requisiti funzionali, nel modo in cui vengono espressi dagli esperti del dominio, e il codice sorgente dell&#8217;implementazione, limitando così i potenziali errori.
 </dl>
 
 <p>Tuttavia, i <abbr>DSL</abbr> hanno anche diversi svantaggi.
 
 <dl>
 <dt>Difficoltà nel creare un buon <abbr>DSL</abbr>
-<dd>Un buon <abbr>DSL</abbr> è più difficile da progettare rispetto alle <abbr>API</abbr> tradizionali, anche se le difficoltà nel progettare una <abbr>API</abbr> elegante, efficace e facile da usare non mancano. Le <abbr>API</abbr> tendono a seguire gli idiomi del linguaggio di programmazione allo scopo di favorire l'uniformità, che per una <abbr>API</abbr> è una caratteristica importante. Al contrario, ogni <abbr>DSL</abbr> dovrebbe riflettere gli idiomi linguistici specifici del proprio dominio. Il progettista di <abbr>DSL</abbr> gode di una maggiore libertà di azione, ma questo significa anche che è molto più difficile determinare le scelte di progettazione &#8220;migliori&#8221;.
+<dd>Un buon <abbr>DSL</abbr> è più difficile da progettare rispetto alle <abbr>API</abbr> tradizionali, anche se le difficoltà nel progettare una <abbr>API</abbr> elegante, efficace e facile da usare non mancano. Le <abbr>API</abbr> tendono a seguire gli idiomi del linguaggio di programmazione allo scopo di favorire l&#8217;uniformità, che per una <abbr>API</abbr> è una caratteristica importante. Al contrario, ogni <abbr>DSL</abbr> dovrebbe riflettere gli idiomi linguistici specifici del proprio dominio. Il progettista di <abbr>DSL</abbr> gode di una maggiore libertà di azione, ma questo significa anche che è molto più difficile determinare le scelte di progettazione &#8220;migliori&#8221;.
 <dt>Manutenzione di lungo termine
 <dd>I <abbr>DSL</abbr> possono richiedere una manutenzione più frequente nel lungo termine per tenere conto dei cambiamenti nel dominio. Inoltre, gli sviluppatori avranno bisogno di più tempo per imparare a usare e a mantenere un <abbr>DSL</abbr>.
 </dl>
 
-<p>Tuttavia, quando l'impiego di un <abbr>DSL</abbr> in un'applicazione è appropriato, come nel caso in cui venga usato frequentemente per implementare e modificare funzionalità, un <abbr>DSL</abbr> ben progettato può rivelarsi uno strumento potente per costruire applicazioni flessibili e robuste.
+<p>Tuttavia, quando l&#8217;impiego di un <abbr>DSL</abbr> in un&#8217;applicazione è appropriato, come nel caso in cui venga usato frequentemente per implementare e modificare funzionalità, un <abbr>DSL</abbr> ben progettato può rivelarsi uno strumento potente per costruire applicazioni flessibili e robuste.
 
-<p>Dal punto di vista dell'implementazione, i <abbr>DSL</abbr> vengono spesso classificati come <em>interni</em> ed <em>esterni</em>.
+<p>Dal punto di vista dell&#8217;implementazione, i <abbr>DSL</abbr> vengono spesso classificati come <em>interni</em> ed <em>esterni</em>.
 
 <p>Un <abbr>DSL</abbr> <em>interno</em> (a volte detto <em>integrato</em>) è uno stile idiomatico di scrittura del codice in un linguaggio di programmazione generico come Scala. I <abbr>DSL</abbr> interni non necessitano di alcun riconoscitore specifico, ma vengono riconosciuti proprio come qualsiasi altro programma scritto nel linguaggio generico. Al contrario, un <abbr>DSL</abbr> <em>esterno</em> è un linguaggio personalizzato con la propria grammatica e il proprio riconoscitore.
 
-<p>I <abbr>DSL</abbr> interni sono più facili da creare perché non richiedono un riconoscitore speciale. D'altra parte, i vincoli del linguaggio sottostante limitano le modalità con cui esprimere i concetti del dominio. I <abbr>DSL</abbr> esterni rimuovono questo vincolo: potete progettare il linguaggio come preferite, purché siate in grado di scriverne un riconoscitore affidabile. Lo svantaggio di un <abbr>DSL</abbr> esterno è la necessità di creare e usare un riconoscitore personalizzato.
+<p>I <abbr>DSL</abbr> interni sono più facili da creare perché non richiedono un riconoscitore speciale. D&#8217;altra parte, i vincoli del linguaggio sottostante limitano le modalità con cui esprimere i concetti del dominio. I <abbr>DSL</abbr> esterni rimuovono questo vincolo: potete progettare il linguaggio come preferite, purché siate in grado di scriverne un riconoscitore affidabile. Lo svantaggio di un <abbr>DSL</abbr> esterno è la necessità di creare e usare un riconoscitore personalizzato.
 
-<p>I <abbr>DSL</abbr> esistono da molto tempo: per esempio, i <abbr>DSL</abbr> interni scritti in Lisp sono vecchi quanto lo stesso Lisp. L'interesse per i <abbr>DSL</abbr> si è recentemente intensificato, in parte grazie alla comunità Ruby perché i <abbr>DSL</abbr> sono molto facili da implementare in quel linguaggio. Come vedremo, Scala offre un supporto eccellente per la creazione di <abbr>DSL</abbr> interni ed esterni.
+<p>I <abbr>DSL</abbr> esistono da molto tempo: per esempio, i <abbr>DSL</abbr> interni scritti in Lisp sono vecchi quanto lo stesso Lisp. L&#8217;interesse per i <abbr>DSL</abbr> si è recentemente intensificato, in parte grazie alla comunità Ruby perché i <abbr>DSL</abbr> sono molto facili da implementare in quel linguaggio. Come vedremo, Scala offre un supporto eccellente per la creazione di <abbr>DSL</abbr> interni ed esterni.
 
 <h2 id=InternalDSLs><abbr>DSL</abbr> interni</h2>
 
-<p>Creiamo un <abbr>DSL</abbr> interno per un'applicazione di contabilità che calcola la busta paga di un impiegato per ogni periodo di retribuzione quindicinale. La busta paga conterrà lo stipendio <em>netto</em> dell'impiegato, che è lo stipendio <em>lordo</em> meno le <em>ritenute</em> per le tasse, i premi di assicurazione (almeno in alcuni paesi), i contributi per la pensione, <i class=baa>&amp;</i>c.
+<p>Creiamo un <abbr>DSL</abbr> interno per un&#8217;applicazione di contabilità che calcola la busta paga di un impiegato per ogni periodo di retribuzione quindicinale. La busta paga conterrà lo stipendio <em>netto</em> dell&#8217;impiegato, che è lo stipendio <em>lordo</em> meno le <em>ritenute</em> per le tasse, i premi di assicurazione (almeno in alcuni paesi), i contributi per la pensione, <i class=baa>&amp;</i>c.
 
-<p>Per capire meglio le differenze tra il codice che usa i <abbr>DSL</abbr> e il codice che non li usa, proviamo a risolvere il problema con entrambe le tecniche. Ecco come si potrebbe calcolare la busta paga di due impiegati senza l'aiuto di un <abbr>DSL</abbr>.
+<p>Per capire meglio le differenze tra il codice che usa i <abbr>DSL</abbr> e il codice che non li usa, proviamo a risolvere il problema con entrambe le tecniche. Ecco come si potrebbe calcolare la busta paga di due impiegati senza l&#8217;aiuto di un <abbr>DSL</abbr>.
 
 <pre><code>// <a href=esempi/cap-11/payroll/api/payroll-api-script.scala>esempi/cap-11/payroll/api/payroll-api-script.scala</a>
 
 
 <p>Per ogni impiegato, lo script calcola lo stipendio lordo per il periodo di retribuzione, le ritenute e il risultato netto. Questi valori vengono memorizzati in un oggetto <code>Paycheck</code>, che poi viene stampato. Prima di descrivere i tipi che stiamo usando, esaminiamo alcune caratteristiche del ciclo <code>foreach</code> che svolge le operazioni.
 
-<p>Per prima cosa, si noti che c'è molto &#8220;rumore&#8221;: il ciclo cita continuamente <var>employee</var> e <var>biweeklyGross</var>, per esempio. Un <abbr>DSL</abbr> ci aiuterà a minimizzare questa rumorosità e a concentrarci su ciò che sta realmente accadendo.
+<p>Per prima cosa, si noti che c&#8217;è molto &#8220;rumore&#8221;: il ciclo cita continuamente <var>employee</var> e <var>biweeklyGross</var>, per esempio. Un <abbr>DSL</abbr> ci aiuterà a minimizzare questa rumorosità e a concentrarci su ciò che sta realmente accadendo.
 
-<p>Secondo, il codice è imperativo: dice &#8220;dividi questo, aggiungi quello&#8221; e così via. Vedremo che i nostri <abbr>DSL</abbr> sembrano simili, ma il loro stile è più dichiarativo, in quanto nascondono le modalità operative all'utente.
+<p>Secondo, il codice è imperativo: dice &#8220;dividi questo, aggiungi quello&#8221; e così via. Vedremo che i nostri <abbr>DSL</abbr> sembrano simili, ma il loro stile è più dichiarativo, in quanto nascondono le modalità operative all&#8217;utente.
 
 <p>Ecco la semplice classe <code>Paycheck</code> usata nello script.
 
 
 case class Employee(name: Name, annualGrossSalary: Money)</code></pre>
 
-<p>Il tipo <code>Money</code> gestisce i calcoli, l'arrotondamento a quattro posti decimali, <i class=baa>&amp;</i>c. Ignora la valuta, tranne che nel metodo <code>toString</code>. I calcoli finanziari appropriati sono notoriamente difficili da eseguire correttamente per le transazioni reali. Questa implementazione non è perfettamente accurata, ma lo è abbastanza per i nostri scopi. <a href=apa.html#MoneyInJava>[MoneyInJava]</a> offre informazioni utili su come effettuare calcoli monetari reali.
+<p>Il tipo <code>Money</code> gestisce i calcoli, l&#8217;arrotondamento a quattro posti decimali, <i class=baa>&amp;</i>c. Ignora la valuta, tranne che nel metodo <code>toString</code>. I calcoli finanziari appropriati sono notoriamente difficili da eseguire correttamente per le transazioni reali. Questa implementazione non è perfettamente accurata, ma lo è abbastanza per i nostri scopi. <a href=apa.html#MoneyInJava>[MoneyInJava]</a> offre informazioni utili su come effettuare calcoli monetari reali.
 
 <pre><code>// <a href=esempi/cap-11/payroll/money.scala>esempi/cap-11/payroll/money.scala</a>
 
   implicit def int2Money(i: Int)                 = Money(i)
 }</code></pre>
 
-<p>Notate l'uso di <code>scala.BigDecimal</code>, che avvolge <code>java.math.BigDecimal</code>, come tipo per memorizzare le cifre finanziarie.
+<p>Notate l&#8217;uso di <code>scala.BigDecimal</code>, che avvolge <code>java.math.BigDecimal</code>, come tipo per memorizzare le cifre finanziarie.
 
 <p>Le ritenute vengono calcolate usando quattro metodi di utilità contenuti in <code>payroll.api.DeductionsCalculator</code>.
 
   def retirementFundContributions(empl: Employee, gross: Money) = gross * .10
 }</code></pre>
 
-<p>Ogni metodo potrebbe usare le informazioni sull'impiegato e lo stipendio lordo per il periodo di retribuzione, ma in questo caso usiamo algoritmi molto semplici basati solo sullo stipendio lordo, tranne che per i premi di assicurazione, qui trattati come un valore fisso.
+<p>Ogni metodo potrebbe usare le informazioni sull&#8217;impiegato e lo stipendio lordo per il periodo di retribuzione, ma in questo caso usiamo algoritmi molto semplici basati solo sullo stipendio lordo, tranne che per i premi di assicurazione, qui trattati come un valore fisso.
 
-<p>L'esecuzione dello script per la <abbr>API</abbr> del libro paga produce l'uscita seguente.
+<p>L&#8217;esecuzione dello script per la <abbr>API</abbr> del libro paga produce l&#8217;uscita seguente.
 
 <pre><samp>(665) $ scala -cp ... payroll-api-script.scala
 Buck Trends: Paycheck($3076.92,$1346.15,$1730.77)
 
 <h3 id=APayrollInternalDSL>Un <abbr>DSL</abbr> interno per il libro paga</h3>
 
-<p>Il codice precedente funziona abbastanza bene, ma supponiamo di volerlo mostrare all'Ufficio Contabilità per confermare che stiamo calcolando correttamente le buste paga. Molto probabilmente, i contabili si perderanno negli idiomi di Scala. Supponiamo anche che sia necessario personalizzare frequentemente questo algoritmo, per esempio per adeguarlo a differenti tipi di impiegato (salariato, a ore, <i class=baa>&amp;</i>c.) o per modificare il calcolo delle ritenute. Idealmente, vorremmo mettere i contabili in grado di effettuare da soli queste personalizzazioni senza ricorrere al nostro aiuto.
+<p>Il codice precedente funziona abbastanza bene, ma supponiamo di volerlo mostrare all&#8217;Ufficio Contabilità per confermare che stiamo calcolando correttamente le buste paga. Molto probabilmente, i contabili si perderanno negli idiomi di Scala. Supponiamo anche che sia necessario personalizzare frequentemente questo algoritmo, per esempio per adeguarlo a differenti tipi di impiegato (salariato, a ore, <i class=baa>&amp;</i>c.) o per modificare il calcolo delle ritenute. Idealmente, vorremmo mettere i contabili in grado di effettuare da soli queste personalizzazioni senza ricorrere al nostro aiuto.
 
-<p>Potremmo raggiungere i nostri scopi se riuscissimo a esprimere l'algoritmo in un <abbr>DSL</abbr> sufficientemente intuitivo per un contabile. Siamo in grado di trasformare il nostro esempio di <abbr>API</abbr> in un <abbr>DSL</abbr> di questo tipo?
+<p>Potremmo raggiungere i nostri scopi se riuscissimo a esprimere l&#8217;algoritmo in un <abbr>DSL</abbr> sufficientemente intuitivo per un contabile. Siamo in grado di trasformare il nostro esempio di <abbr>API</abbr> in un <abbr>DSL</abbr> di questo tipo?
 
-<p>Tornando allo script per la <abbr>API</abbr> del libro paga, cosa succede se nascondiamo la maggior parte dei riferimenti espliciti a informazioni di contesto, come l'impiegato, lo stipendio lordo e il valori delle ritenute? Considerate il testo seguente.
+<p>Tornando allo script per la <abbr>API</abbr> del libro paga, cosa succede se nascondiamo la maggior parte dei riferimenti espliciti a informazioni di contesto, come l&#8217;impiegato, lo stipendio lordo e il valori delle ritenute? Considerate il testo seguente.
 
 <pre>Rules to calculate an employee's paycheck:
   employee's gross salary for 2 weeks
 
 <p>Queste righe si leggono come normale inglese,<sup id=fnn-1><a href=#fn-1>1</a></sup> non come codice. Abbiamo incluso alcune parole &#8220;superflue&#8221; (chiamate <em>bubble words</em> in <a href=apa.html#Ford2009>[Ford2009]</a>) che aumentano la leggibilità ma non corrispondono necessariamente a qualcosa di essenziale, come <code>to</code>, <code>an</code>, <code>is</code>, <code>for</code>, <code>of</code> e <code>which</code>. Nel nostro <abbr>DSL</abbr> in Scala elimineremo alcune di queste parole superflue e ne manterremo altre.
 
-<p>Confrontando questa versione con lo script della <abbr>API</abbr> del libro paga, il rumore che nasconde le parti essenziali dell'algoritmo è molto inferiore, in quanto abbiamo minimizzato i riferimenti espliciti alle informazioni di contesto: menzioniamo <code>employee</code> solo due volte; menzioniamo <code>gross</code> cinque volte, ma sperabilmente in modi &#8220;intuitivi&#8221;.
+<p>Confrontando questa versione con lo script della <abbr>API</abbr> del libro paga, il rumore che nasconde le parti essenziali dell&#8217;algoritmo è molto inferiore, in quanto abbiamo minimizzato i riferimenti espliciti alle informazioni di contesto: menzioniamo <code>employee</code> solo due volte; menzioniamo <code>gross</code> cinque volte, ma sperabilmente in modi &#8220;intuitivi&#8221;.
 
 <p>Potremmo costruire molti <abbr>DSL</abbr> interni in Scala che somigliano a questo <abbr>DSL</abbr> <em>ad hoc</em>. Eccone uno, sempre contenuto in uno script, che produce la stessa uscita di prima.
 
   format("%s %s: %s\n", employee.name.first, employee.name.last, check)
 }</code></pre>
 
-<p>Analizzeremo l'implementazione passo per passo, ma prima riassumiamo le caratteristiche di Scala che ci permettono di implementare questo <abbr>DSL</abbr>.
+<p>Analizzeremo l&#8217;implementazione passo per passo, ma prima riassumiamo le caratteristiche di Scala che ci permettono di implementare questo <abbr>DSL</abbr>.
 
 <h3 id=InternalDSLs-InfixOperatorNotation>Notazione infissa per gli operatori</h3>
 
 
 <pre><code>employee.salary_for(2.weeks).minus_deductions_for { gross =&gt;</code></pre>
 
-<p>Ora potete capire perché prima abbiamo scritto <code>2.weeks</code>, dato che il risultato di questa espressione viene passato a <code>salary_for</code>. Senza il punto, l'espressione infissa verrebbe riconosciuta come <code>employee.salary_for(2).weeks&#8230;</code>; ma non c'è alcun metodo <code>weeks</code> in <code>Int</code>, naturalmente. Rivisiteremo questa espressione fra un momento.
+<p>Ora potete capire perché prima abbiamo scritto <code>2.weeks</code>, dato che il risultato di questa espressione viene passato a <code>salary_for</code>. Senza il punto, l&#8217;espressione infissa verrebbe riconosciuta come <code>employee.salary_for(2).weeks&#8230;</code>; ma non c&#8217;è alcun metodo <code>weeks</code> in <code>Int</code>, naturalmente. Rivisiteremo questa espressione fra un momento.
 
-<p>La concatenazione di metodi viene spesso impiegata in casi come questo, dove ogni metodo restituisce <code>this</code> in modo che possiate continuare a invocare metodi sulla stessa istanza. Notate che la restituzione di <code>this</code> consente alle invocazioni di metodo di avvenire in qualsiasi ordine. Se avete bisogno di imporre un ordine particolare, allora restituite un'istanza di tipo differente. Per esempio, se <code>minus_deductions_for</code> deve essere invocato dopo <code>salary_for</code>, allora <code>salary_for</code> dovrebbe restituire una nuova istanza.
+<p>La concatenazione di metodi viene spesso impiegata in casi come questo, dove ogni metodo restituisce <code>this</code> in modo che possiate continuare a invocare metodi sulla stessa istanza. Notate che la restituzione di <code>this</code> consente alle invocazioni di metodo di avvenire in qualsiasi ordine. Se avete bisogno di imporre un ordine particolare, allora restituite un&#8217;istanza di tipo differente. Per esempio, se <code>minus_deductions_for</code> deve essere invocato dopo <code>salary_for</code>, allora <code>salary_for</code> dovrebbe restituire una nuova istanza.
 
-<p>Dato che la concatenazione è così facile, avremmo potuto creare metodi separati per <code>salary</code>, <code>for</code>, <code>minus</code> e <code>deductions</code>, prendendoci la libertà di scrivere l'espressione seguente.
+<p>Dato che la concatenazione è così facile, avremmo potuto creare metodi separati per <code>salary</code>, <code>for</code>, <code>minus</code> e <code>deductions</code>, prendendoci la libertà di scrivere l&#8217;espressione seguente.
 
 <pre><code>employee salary for 2.weeks minus deductions for { gross =&gt;</code></pre>
 
 <p>Notate che le invocazioni di <code>for</code> sono precedute da invocazioni differenti con significati molto diversi. Quindi, se durante tutto il procedimento venisse usata la stessa istanza, essa dovrebbe tenere traccia del &#8220;flusso&#8221; internamente. Concatenare istanze differenti eliminerebbe questo problema. Tuttavia, dato che non deve avvenire nessuna computazione tra queste parole, abbiamo scelto la forma più semplice in cui le parole sono unite tra loro da un trattino basso <code>_</code>.
 
-<h3 id=InternalDSLs-ImplicitConversions-UserDefinedTypes>Conversioni implicite e tipi definiti dall'utente</h3>
+<h3 id=InternalDSLs-ImplicitConversions-UserDefinedTypes>Conversioni implicite e tipi definiti dall&#8217;utente</h3>
 
-<p>Tornando a <code>2.weeks</code>, dato che <code>Int</code> non ha un metodo <code>weeks</code>, impieghiamo una conversione implicita verso un'istanza di <code>Duration</code> che racchiude un intero usato per specificare una quantità.
+<p>Tornando a <code>2.weeks</code>, dato che <code>Int</code> non ha un metodo <code>weeks</code>, impieghiamo una conversione implicita verso un&#8217;istanza di <code>Duration</code> che racchiude un intero usato per specificare una quantità.
 
 <pre><code>// <a href=esempi/cap-11/payroll/dsl/duration.scala>esempi/cap-11/payroll/dsl/duration.scala</a>
 
 
 <h3 id=InternalDSLs-Apply>Metodi <code>apply</code></h3>
 
-<p>Nella nostra implementazione, un certo numero di oggetti usa <code>apply</code> per invocare un determinato comportamento. L'oggetto <code>rules</code> incapsula il processo di costruzione delle regole per il calcolo dei pagamenti. Il metodo <code>apply</code> di questo oggetto accetta un letterale funzione <code>Employee =&gt; Paycheck</code>.
+<p>Nella nostra implementazione, un certo numero di oggetti usa <code>apply</code> per invocare un determinato comportamento. L&#8217;oggetto <code>rules</code> incapsula il processo di costruzione delle regole per il calcolo dei pagamenti. Il metodo <code>apply</code> di questo oggetto accetta un letterale funzione <code>Employee =&gt; Paycheck</code>.
 
 <h3 id=_payroll_rules_dsl_implementation>Implementazione delle regole di pagamento come <abbr>DSL</abbr></h3>
 
-<p>Ora esploriamo l'implementazione, attraversandola a partire dall'oggetto <code>rules</code>.
+<p>Ora esploriamo l&#8217;implementazione, attraversandola a partire dall&#8217;oggetto <code>rules</code>.
 
 <pre><code>// <a href=esempi/cap-11/payroll/dsl/payroll.scala>esempi/cap-11/payroll/dsl/payroll.scala</a>
 
 import rules._
 &hellip;</code></pre>
 
-<p>Il letterale funzione passato come argomento a <code>rules.apply</code> viene usato per costruire un oggetto <code>PayrollBuilderRules</code> che elaborerà le regole specificate. Questo avviene proprio all'inizio del <abbr>DSL</abbr>.
+<p>Il letterale funzione passato come argomento a <code>rules.apply</code> viene usato per costruire un oggetto <code>PayrollBuilderRules</code> che elaborerà le regole specificate. Questo avviene proprio all&#8217;inizio del <abbr>DSL</abbr>.
 
 <pre><code>val payrollCalculator = rules { employee =&gt; &hellip;</code></pre>
 
-<p>L'oggetto <code>rules</code> definisce anche i metodi di conversione implicita. Il primo viene usato dall'espressione <code>2.weeks</code> e converte <code>2</code> in un'istanza di <code>Duration</code>, come abbiamo detto in precedenza. L'altro metodo viene usato più avanti nel <abbr>DSL</abbr> per abilitare la conversione trasparente di <code>Double</code>, <code>Employee</code>, <i class=baa>&amp;</i>c. in istanze avvolgenti che descriveremo tra breve.
+<p>L&#8217;oggetto <code>rules</code> definisce anche i metodi di conversione implicita. Il primo viene usato dall&#8217;espressione <code>2.weeks</code> e converte <code>2</code> in un&#8217;istanza di <code>Duration</code>, come abbiamo detto in precedenza. L&#8217;altro metodo viene usato più avanti nel <abbr>DSL</abbr> per abilitare la conversione trasparente di <code>Double</code>, <code>Employee</code>, <i class=baa>&amp;</i>c. in istanze avvolgenti che descriveremo tra breve.
 
-<p>Notate che l'oggetto <code>rules</code> viene importato in modo che queste conversioni siano visibili nel resto del file corrente. &Egrave; necessario importarlo anche nei file che usano il <abbr>DSL</abbr>.
+<p>Notate che l&#8217;oggetto <code>rules</code> viene importato in modo che queste conversioni siano visibili nel resto del file corrente. &Egrave; necessario importarlo anche nei file che usano il <abbr>DSL</abbr>.
 
-<p><code>PayrollBuilderRules</code> è la prima delle nostre istanze avvolgenti. Si occupa di valutare il letterale funzione per l'intero insieme di regole all'interno di un blocco <code>try</code>/<code>catch</code>.
+<p><code>PayrollBuilderRules</code> è la prima delle nostre istanze avvolgenti. Si occupa di valutare il letterale funzione per l&#8217;intero insieme di regole all&#8217;interno di un blocco <code>try</code>/<code>catch</code>.
 
 <pre><code>// <a href=esempi/cap-11/payroll/dsl/payroll.scala>esempi/cap-11/payroll/dsl/payroll.scala</a>
 &hellip;
 }
 &hellip;</code></pre>
 
-<p>La protezione dell'accesso a <code>PayrollBuilderRules</code> è necessaria per evitare che i clienti lo usino direttamente. Tuttavia, l'eccezione rimane pubblica in modo da usarla nelle clausole <code>catch</code>. (&Egrave; possibile scegliere se avvolgere un'eccezione lanciata in un'eccezione &#8220;domain-specific&#8221;, come si vede dal codice.)
+<p>La protezione dell&#8217;accesso a <code>PayrollBuilderRules</code> è necessaria per evitare che i clienti lo usino direttamente. Tuttavia, l&#8217;eccezione rimane pubblica in modo da usarla nelle clausole <code>catch</code>. (&Egrave; possibile scegliere se avvolgere un&#8217;eccezione lanciata in un&#8217;eccezione &#8220;domain-specific&#8221;, come si vede dal codice.)
 
-<p>Notate che dobbiamo passare l'impiegato come un'istanza di &#8220;contesto&#8221; all'interno del letterale funzione. Abbiamo detto che è preferibile rendere quanto più possibile implicito il contesto. Le nostre classi di implementazione, come <code>PayrollBuilderRules</code>, sono accomunate dall'idea di conservare l'informazione di contesto in istanze avvolgenti minimizzandone la visibilità nel <abbr>DSL</abbr>. In alternativa sarebbe possibile memorizzare il contesto in oggetti singleton utilizzabili anche da altre istanze, ma sfortunatamente questo approccio si espone a problemi di sicurezza con i thread.
+<p>Notate che dobbiamo passare l&#8217;impiegato come un&#8217;istanza di &#8220;contesto&#8221; all&#8217;interno del letterale funzione. Abbiamo detto che è preferibile rendere quanto più possibile implicito il contesto. Le nostre classi di implementazione, come <code>PayrollBuilderRules</code>, sono accomunate dall&#8217;idea di conservare l&#8217;informazione di contesto in istanze avvolgenti minimizzandone la visibilità nel <abbr>DSL</abbr>. In alternativa sarebbe possibile memorizzare il contesto in oggetti singleton utilizzabili anche da altre istanze, ma sfortunatamente questo approccio si espone a problemi di sicurezza con i thread.
 
 <p>Per capire cosa vogliamo dire riguardo al contesto, considerate il punto del nostro script che usa il <abbr>DSL</abbr> del libro paga in cui vengono specificate le ritenute.
 
   retirementFundContributions are (10.  percent_of gross)
 }</code></pre>
 
-<p>Considerate i premi assicurativi, per i quali viene ritenuta una quota fissa pari a <code>Money(500)</code>. Perché non abbiamo semplicemente scritto <code>insurancePremiums are 500.</code>? A quanto pare, dobbiamo &#8220;intrufolare&#8221; l'istanza <var>gross</var> nell'espressione, in qualche modo. Il nome <var>gross</var> la identifica come un'istanza di <code>Money</code> che rappresenta lo stipendio dell'impiegato per il periodo di retribuzione. <em>DSL birichini!!!</em> In realtà è un'istanza della classe di utilità <code>DeudctionsBuilder</code> a memorizzare l'intera busta paga, incluso lo stipendio lordo e l'istanza dell'impiegato. Il nome <var>gross</var> viene usato semplicemente perché aumenta la leggibilità delle frasi in cui è presente.
+<p>Considerate i premi assicurativi, per i quali viene ritenuta una quota fissa pari a <code>Money(500)</code>. Perché non abbiamo semplicemente scritto <code>insurancePremiums are 500.</code>? A quanto pare, dobbiamo &#8220;intrufolare&#8221; l&#8217;istanza <var>gross</var> nell&#8217;espressione, in qualche modo. Il nome <var>gross</var> la identifica come un&#8217;istanza di <code>Money</code> che rappresenta lo stipendio dell&#8217;impiegato per il periodo di retribuzione. <em>DSL birichini!!!</em> In realtà è un&#8217;istanza della classe di utilità <code>DeudctionsBuilder</code> a memorizzare l&#8217;intera busta paga, incluso lo stipendio lordo e l&#8217;istanza dell&#8217;impiegato. Il nome <var>gross</var> viene usato semplicemente perché aumenta la leggibilità delle frasi in cui è presente.
 
-<p>Questo blocco calcola le ritenute e le trattiene dallo stipendio lordo per determinare lo stipendio netto. L'istanza <var>gross</var> gestisce questo processo. Non c'è &#8220;comunicazione&#8221; tra le quattro righe del letterale funzione. Inoltre, <var>federalIncomeTax</var>, <var>insurancePremiums</var>, <i class=baa>&amp;</i>c. sono oggetti senza alcuna relazione con <code>DeductionsBuilder</code> (come vedremo fra breve). Sarebbe fantastico se potessero essere membri di <code>DeductionsBuilder</code> o magari di qualche altra istanza avvolgente che incapsula questo ambito, perché allora ogni riga rappresenterebbe una chiamata di metodo su una o sull'altra classe avvolgente. Sfortunatamente questo non è possibile, quindi ogni riga deve specificare l'istanza <var>gross</var> per mantenere continuità. Abbiamo fatto i salti mortali per supportare la sintassi e rendere disponibile <var>gross</var> allo stesso tempo, come necessario.
+<p>Questo blocco calcola le ritenute e le trattiene dallo stipendio lordo per determinare lo stipendio netto. L&#8217;istanza <var>gross</var> gestisce questo processo. Non c&#8217;è &#8220;comunicazione&#8221; tra le quattro righe del letterale funzione. Inoltre, <var>federalIncomeTax</var>, <var>insurancePremiums</var>, <i class=baa>&amp;</i>c. sono oggetti senza alcuna relazione con <code>DeductionsBuilder</code> (come vedremo fra breve). Sarebbe fantastico se potessero essere membri di <code>DeductionsBuilder</code> o magari di qualche altra istanza avvolgente che incapsula questo ambito, perché allora ogni riga rappresenterebbe una chiamata di metodo su una o sull&#8217;altra classe avvolgente. Sfortunatamente questo non è possibile, quindi ogni riga deve specificare l&#8217;istanza <var>gross</var> per mantenere continuità. Abbiamo fatto i salti mortali per supportare la sintassi e rendere disponibile <var>gross</var> allo stesso tempo, come necessario.
 
-<p>Quindi, abbiamo escogitato la convenzione per cui i numeri &#8220;grezzi&#8221;, come le ritenute assicurative, devono essere qualificati dalla particolare valuta usata per lo stipendio lordo. Tra un attimo vedremo come funziona l'espressione <code>500. in gross.currency</code>. &Egrave; una specie di &#8220;hack&#8221;, ma si legge bene e risolve il nostro problema di progettazione.
+<p>Quindi, abbiamo escogitato la convenzione per cui i numeri &#8220;grezzi&#8221;, come le ritenute assicurative, devono essere qualificati dalla particolare valuta usata per lo stipendio lordo. Tra un attimo vedremo come funziona l&#8217;espressione <code>500. in gross.currency</code>. &Egrave; una specie di &#8220;hack&#8221;, ma si legge bene e risolve il nostro problema di progettazione.
 
 <p>Ecco una possibile forma alternativa che avrebbe evitato il problema.
 
   builder retirementFundContributions (10.  percent_of gross)
 }</code></pre>
 
-<p>Ora l'utilizzo di <var>builder</var> è più esplicito, e <code>federalIncomeTax</code>, <code>insurancePremiums</code>, <i class=baa>&amp;</i>c. sono metodi dell'assemblatore. Abbiamo optato per uno stile più leggibile, venendo penalizzati da un'implementazione più difficile da realizzare. A volte sentirete l'espressione <em>interfaccia fluida</em> per fare riferimento a <abbr>DSL</abbr> che enfatizzano la leggibilità.
+<p>Ora l&#8217;utilizzo di <var>builder</var> è più esplicito, e <code>federalIncomeTax</code>, <code>insurancePremiums</code>, <i class=baa>&amp;</i>c. sono metodi dell&#8217;assemblatore. Abbiamo optato per uno stile più leggibile, venendo penalizzati da un&#8217;implementazione più difficile da realizzare. A volte sentirete l&#8217;espressione <em>interfaccia fluida</em> per fare riferimento a <abbr>DSL</abbr> che enfatizzano la leggibilità.
 
 <p>Ecco la nostra classe <code>GrossPayBuilder</code>.
 
 }
 &hellip;</code></pre>
 
-<p>Ricordatevi che <code>rules</code> definisce un metodo di conversione implicita da <code>Employee</code> verso questo tipo. La conversione viene operata dall'espressione <code>employee salary_for</code>, in modo che il metodo <code>GrossPayBuilder.salary_for</code> possa essere invocato. <code>GrossPayBuilder</code> inizializza <var>gross</var> e gli aggiunge nuovi valori ogni volta che <code>salary_for</code> viene invocato; il metodo presume di accumulare lo stipendio lordo a incrementi di giorni. Infine, <code>salary_for</code> restituisce <code>this</code> per supportare la concatenazione.
+<p>Ricordatevi che <code>rules</code> definisce un metodo di conversione implicita da <code>Employee</code> verso questo tipo. La conversione viene operata dall&#8217;espressione <code>employee salary_for</code>, in modo che il metodo <code>GrossPayBuilder.salary_for</code> possa essere invocato. <code>GrossPayBuilder</code> inizializza <var>gross</var> e gli aggiunge nuovi valori ogni volta che <code>salary_for</code> viene invocato; il metodo presume di accumulare lo stipendio lordo a incrementi di giorni. Infine, <code>salary_for</code> restituisce <code>this</code> per supportare la concatenazione.
 
 <p>Il calcolo delle ritenute è la parte più complessa. Quando <code>minus_deductions_for</code> viene usato nel <abbr>DSL</abbr>, innesca la conversione implicita da <code>GrossPayBuilder</code> a <code>DeductionsBuilder</code> definita in <code>rules</code>.
 
 }
 &hellip;</code></pre>
 
-<p><code>DeductionsBuilder</code> salva l'impiegato dell'istanza di <code>GrossPayBuilder</code> ricevuta, che non lo memorizza come campo, e inizializza anche il valore di <var>paycheck</var> usando lo stipendio lordo calcolato.
+<p><code>DeductionsBuilder</code> salva l&#8217;impiegato dell&#8217;istanza di <code>GrossPayBuilder</code> ricevuta, che non lo memorizza come campo, e inizializza anche il valore di <var>paycheck</var> usando lo stipendio lordo calcolato.
 
 <p>Notate che il metodo <code>currency</code> restituisce semplicemente <code>this</code>. Non abbiamo bisogno di fare nulla con la valuta effettiva quando questo metodo viene invocato. Invece, esso viene usato per supportare un idioma di progettazione che discuteremo più avanti.
 
-<p><code>minus_deductions_for</code> svolge il lavoro importante: invoca il letterale funzione con le singole regole e poi restituisce l'istanza di <code>Paycheck</code> completata, che in definitiva è quanto viene restituito da <code>rules.apply</code>.
+<p><code>minus_deductions_for</code> svolge il lavoro importante: invoca il letterale funzione con le singole regole e poi restituisce l&#8217;istanza di <code>Paycheck</code> completata, che in definitiva è quanto viene restituito da <code>rules.apply</code>.
 
 <p>I nostri due metodi rimanenti sono usati per calcolare le singole ritenute. Vengono invocati da <code>DeductionsBuilderDeductionHelper</code>, come mostrato nel codice seguente.
 
   }
 }</code></pre>
 
-<p>Ora vediamo che <code>federalIncomeTax</code> <i class=baa>&amp;</i>c. sono oggetti singleton. Notate i metodi &#8220;sinonimi&#8221; <code>is</code> e <code>are</code>: abbiamo usato <code>is</code> per gli oggetti con un nome singolare, come <code>federalIncomeTax</code>, e <code>are</code> per gli oggetti con un nome plurale, come <code>insurancePremiums</code> . In effetti, dato che entrambi i metodi delegano le proprie funzioni ad <code>apply</code>, le parole <code>is</code> e <code>are</code> sono effettivamente &#8220;superflue&#8221; e l'utente potrebbe ometterle. In altre parole, le due righe seguenti sono equivalenti nel nostro <abbr>DSL</abbr>.
+<p>Ora vediamo che <code>federalIncomeTax</code> <i class=baa>&amp;</i>c. sono oggetti singleton. Notate i metodi &#8220;sinonimi&#8221; <code>is</code> e <code>are</code>: abbiamo usato <code>is</code> per gli oggetti con un nome singolare, come <code>federalIncomeTax</code>, e <code>are</code> per gli oggetti con un nome plurale, come <code>insurancePremiums</code> . In effetti, dato che entrambi i metodi delegano le proprie funzioni ad <code>apply</code>, le parole <code>is</code> e <code>are</code> sono effettivamente &#8220;superflue&#8221; e l&#8217;utente potrebbe ometterle. In altre parole, le due righe seguenti sono equivalenti nel nostro <abbr>DSL</abbr>.
 
 <pre><code>federalIncomeTax is (25. percent_of gross)
 federalIncomeTax    (25. percent_of gross)</code></pre>
 
-<p>Il metodo <code>apply</code> prende <code>DeductionsBuilder</code> e non ci fa nulla! In effetti, nel momento in cui <code>apply</code> viene invocato, le ritenute sono già state calcolate e considerate nella busta paga. Questo implica che le espressioni come <code>federalIncomeTax is</code> sono effettivamente zucchero sintattico (almeno per il modo in cui questo <abbr>DSL</abbr> è stato implementato), una forma elaborata di commento che se non altro ha il vantaggio di controllare il tipo dei vari &#8220;generi&#8221; di ritenute consentite. Naturalmente, con l'evolversi dell'implementazione, queste istanze potrebbero svolgere un lavoro reale.
+<p>Il metodo <code>apply</code> prende <code>DeductionsBuilder</code> e non ci fa nulla! In effetti, nel momento in cui <code>apply</code> viene invocato, le ritenute sono già state calcolate e considerate nella busta paga. Questo implica che le espressioni come <code>federalIncomeTax is</code> sono effettivamente zucchero sintattico (almeno per il modo in cui questo <abbr>DSL</abbr> è stato implementato), una forma elaborata di commento che se non altro ha il vantaggio di controllare il tipo dei vari &#8220;generi&#8221; di ritenute consentite. Naturalmente, con l&#8217;evolversi dell&#8217;implementazione, queste istanze potrebbero svolgere un lavoro reale.
 
-<p>Per capire perché <code>DeductionCalculator.apply</code> è vuoto, consideriamo <code>DeductionsBuilderDeductionHelper</code>. Ricordatevi che l'oggetto <code>rules</code> è dotato di un metodo di conversione che trasforma un <code>Double</code> in un <code>DeductionsBuilderDeductionHelper</code>. Una volta che abbiamo un'istanza di questo tipo possiamo invocare il metodo <code>in</code> o il metodo <code>percent_of</code>. Ogni riga nel letterale funzione delle ritenute sfrutta questa istanza.
+<p>Per capire perché <code>DeductionCalculator.apply</code> è vuoto, consideriamo <code>DeductionsBuilderDeductionHelper</code>. Ricordatevi che l&#8217;oggetto <code>rules</code> è dotato di un metodo di conversione che trasforma un <code>Double</code> in un <code>DeductionsBuilderDeductionHelper</code>. Una volta che abbiamo un&#8217;istanza di questo tipo possiamo invocare il metodo <code>in</code> o il metodo <code>percent_of</code>. Ogni riga nel letterale funzione delle ritenute sfrutta questa istanza.
 
 <p>Per esempio, <code>(25. percent_of gross)</code> è pressappoco equivalente ai passi seguenti.
 
 <li><code>gross.addDeductionsPercentageOfGross(factor)</code>
 </ol>
 
-<p>In altre parole, abbiamo usato <code>DeductionsBuilderDeductionHelper</code> per convertire un'espressione della forma <code>Double metodo DeductionsBuilder</code> in un'espressione della forma <code>DeductionsBuilder metodo2 Double</code>. <code>DeductionsBuilder</code> accumula tutte le ritenute nella busta paga che stiamo assemblando.
+<p>In altre parole, abbiamo usato <code>DeductionsBuilderDeductionHelper</code> per convertire un&#8217;espressione della forma <code>Double metodo DeductionsBuilder</code> in un&#8217;espressione della forma <code>DeductionsBuilder metodo2 Double</code>. <code>DeductionsBuilder</code> accumula tutte le ritenute nella busta paga che stiamo assemblando.
 
-<p>L'espressione <code>500. in gross.currency</code> funziona quasi allo stesso modo. <code>DeductionsBuilder.currency</code> è in effetti un'altra parola superflua; restituisce semplicemente <code>this</code>, ma fornisce un idioma leggibile per il <abbr>DSL</abbr>. Il metodo <code>in</code> converte semplicemente l'istanza di <code>Double</code> in un'istanza di <code>Money</code> e la passa a <code>DeductionsBuilder.addDeductions</code>.
+<p>L&#8217;espressione <code>500. in gross.currency</code> funziona quasi allo stesso modo. <code>DeductionsBuilder.currency</code> è in effetti un&#8217;altra parola superflua; restituisce semplicemente <code>this</code>, ma fornisce un idioma leggibile per il <abbr>DSL</abbr>. Il metodo <code>in</code> converte semplicemente l&#8217;istanza di <code>Double</code> in un&#8217;istanza di <code>Money</code> e la passa a <code>DeductionsBuilder.addDeductions</code>.
 
 <p>Quindi <code>DeductionCalculator.apply</code> non fa nulla, perché nel momento in cui <code>apply</code> viene invocato tutto il lavoro è già stato fatto.
 
 <h3 id=InternalDSLsFinalThoughts><abbr>DSL</abbr> interni: considerazioni conclusive</h3>
 
-<p>In definitiva, è meglio l'implementazione originale sotto forma di <abbr>API</abbr> o l'implementazione sotto forma di <abbr>DSL</abbr>? L'implementazione del <abbr>DSL</abbr> è complessa. Come ogni linguaggio, verificarne la robustezza può essere complicato. Gli utenti proveranno molte combinazioni di espressioni e probabilmente non capiranno i messaggi di errore del compilatore che si riferiscono ai meccanismi interni nascosti dietro il <abbr>DSL</abbr>.
+<p>In definitiva, è meglio l&#8217;implementazione originale sotto forma di <abbr>API</abbr> o l&#8217;implementazione sotto forma di <abbr>DSL</abbr>? L&#8217;implementazione del <abbr>DSL</abbr> è complessa. Come ogni linguaggio, verificarne la robustezza può essere complicato. Gli utenti proveranno molte combinazioni di espressioni e probabilmente non capiranno i messaggi di errore del compilatore che si riferiscono ai meccanismi interni nascosti dietro il <abbr>DSL</abbr>.
 
 <p>Progettare un <abbr>DSL</abbr> di qualità è difficile. Con una <abbr>API</abbr>, potete seguire le convenzioni della libreria Scala per i tipi, i nomi dei metodi, <i class=baa>&amp;</i>c. Tuttavia, con un <abbr>DSL</abbr>, state provando a imitare il linguaggio di un nuovo dominio: farlo correttamente non è facile.
 
-<p>Ne vale la pena, però. Un <abbr>DSL</abbr> ben progettato minimizza lo sforzo di tradurre i requisiti in codice, migliorando così le comunicazioni sui requisiti con i soggetti interessati. I <abbr>DSL</abbr> agevolano anche il cambiamento rapido delle funzionalità e nascondono i dettagli di implementazione che potrebbero creare confusione. Come sempre, dovreste effettuare un'analisi costi/benefici quando decidete se usare o meno un <abbr>DSL</abbr>.
+<p>Ne vale la pena, però. Un <abbr>DSL</abbr> ben progettato minimizza lo sforzo di tradurre i requisiti in codice, migliorando così le comunicazioni sui requisiti con i soggetti interessati. I <abbr>DSL</abbr> agevolano anche il cambiamento rapido delle funzionalità e nascondono i dettagli di implementazione che potrebbero creare confusione. Come sempre, dovreste effettuare un&#8217;analisi costi/benefici quando decidete se usare o meno un <abbr>DSL</abbr>.
 
-<p>Supponendo che abbiate preso la decisione di &#8220;procedere&#8221;, un problema comune nella progettazione di un <abbr>DSL</abbr> è il <em>problema della conclusione</em> <a href=apa.html#Ford2009>[Ford2009]</a>. Come fate a sapere quando l'assemblaggio dello stato di un'istanza si è concluso, e che tale istanza è pronta per essere usata?
+<p>Supponendo che abbiate preso la decisione di &#8220;procedere&#8221;, un problema comune nella progettazione di un <abbr>DSL</abbr> è il <em>problema della conclusione</em> <a href=apa.html#Ford2009>[Ford2009]</a>. Come fate a sapere quando l&#8217;assemblaggio dello stato di un&#8217;istanza si è concluso, e che tale istanza è pronta per essere usata?
 
-<p>Noi abbiamo risolto il problema in due modi. Per prima cosa, abbiamo annidato i passi di computazione in un letterale funzione. Nel momento in cui <code>rules(employee)</code> viene chiamato, la costruzione della busta paga è completa. In più, tutti i passi vengono valutati in maniera &#8220;avida&#8221;: non è necessario inserire tutte le regole e poi eseguirle alla fine. L'unico requisito di ordinamento era la necessità di calcolare lo stipendio lordo come prima cosa, dato che è il valore su cui si basano le ritenute. Abbiamo imposto l'ordine di invocazione corretto usando istanze di tipi differenti.
+<p>Noi abbiamo risolto il problema in due modi. Per prima cosa, abbiamo annidato i passi di computazione in un letterale funzione. Nel momento in cui <code>rules(employee)</code> viene chiamato, la costruzione della busta paga è completa. In più, tutti i passi vengono valutati in maniera &#8220;avida&#8221;: non è necessario inserire tutte le regole e poi eseguirle alla fine. L&#8217;unico requisito di ordinamento era la necessità di calcolare lo stipendio lordo come prima cosa, dato che è il valore su cui si basano le ritenute. Abbiamo imposto l&#8217;ordine di invocazione corretto usando istanze di tipi differenti.
 
 <p>Ci sono casi in cui non potete valutare i passi di assemblaggio in maniera avida. Per esempio, un <abbr>DSL</abbr> che costruisce una query SQL non può eseguire una query dopo ogni singolo passo del processo di costruzione. In questo caso, la valutazione deve attendere fino a quando la query non è costruita completamente.
 
-<p>Al contrario, se i passi di computazione del vostro <abbr>DSL</abbr> sono privi di stato, l'invocazione di metodi concatenati funziona alla perfezione; in questo caso, non è importante sapere quando l'invocazione dei metodi concatenati si conclude. Se concatenate metodi che assemblano uno stato, dovrete aggiungere una qualche sorta di metodo conclusivo e contare sul fatto che gli utenti lo usino sempre alla fine.
+<p>Al contrario, se i passi di computazione del vostro <abbr>DSL</abbr> sono privi di stato, l&#8217;invocazione di metodi concatenati funziona alla perfezione; in questo caso, non è importante sapere quando l&#8217;invocazione dei metodi concatenati si conclude. Se concatenate metodi che assemblano uno stato, dovrete aggiungere una qualche sorta di metodo conclusivo e contare sul fatto che gli utenti lo usino sempre alla fine.
 
 <h2 id=ExternalDSLsWithCombinatorParsers><abbr>DSL</abbr> esterni con la combinazione di riconoscitori</h2>
 
 
 <p>Gli operatori di riconoscimento (anche detti <em>combinatori</em>) sono blocchi di costruzione per riconoscitori. I riconoscitori che gestiscono specifici tipi di ingresso, come per esempio numeri in virgola mobile, numeri interi, <i class=baa>&amp;</i>c., possono essere combinati insieme per formare altri riconoscitori per espressioni più grandi. Un framework di combinazione rende più facile comporre i riconoscitori per gestire le sequenze di termini, i casi alternativi, la ripetizione, i termini opzionali, <i class=baa>&amp;</i>c.
 
-<p>Impareremo di più sulle tecniche di riconoscimento e la relativa terminologia man mano che procediamo. Una esposizione completa delle tecniche di riconoscimento esula dall'ambito di questo libro, ma i nostri esempi dovrebbero esservi utili come punto di partenza. In <a href=apa.html#Spiewak2009b>[Spiewak2009b]</a>, <a href=apa.html#Ghosh2008a>[Ghosh2008a]</a> e <a href=apa.html#Odersky2008>[Odersky2008]</a> potete trovare ulteriori esempi di riconoscitori scritti usando la libreria di operatori di riconoscimento di Scala.
+<p>Impareremo di più sulle tecniche di riconoscimento e la relativa terminologia man mano che procediamo. Una esposizione completa delle tecniche di riconoscimento esula dall&#8217;ambito di questo libro, ma i nostri esempi dovrebbero esservi utili come punto di partenza. In <a href=apa.html#Spiewak2009b>[Spiewak2009b]</a>, <a href=apa.html#Ghosh2008a>[Ghosh2008a]</a> e <a href=apa.html#Odersky2008>[Odersky2008]</a> potete trovare ulteriori esempi di riconoscitori scritti usando la libreria di operatori di riconoscimento di Scala.
 
 <h3 id=APayrollExternalDSL>Un <abbr>DSL</abbr> esterno per il libro paga</h3>
 
-<p>Per illustrare la combinazione di riconoscitori, riutilizzeremo il caso appena discusso per i <abbr>DSL</abbr> interni alterandone leggermente la grammatica, dato che il nostro <abbr>DSL</abbr> esterno non deve rispettare la sintassi di Scala. Altre modifiche semplificheranno la costruzione del riconoscitore. Ecco un esempio d'uso scritto usando il <abbr>DSL</abbr> esterno.
+<p>Per illustrare la combinazione di riconoscitori, riutilizzeremo il caso appena discusso per i <abbr>DSL</abbr> interni alterandone leggermente la grammatica, dato che il nostro <abbr>DSL</abbr> esterno non deve rispettare la sintassi di Scala. Altre modifiche semplificheranno la costruzione del riconoscitore. Ecco un esempio d&#8217;uso scritto usando il <abbr>DSL</abbr> esterno.
 
 <pre><samp>paycheck for employee "Buck Trends" is salary for 2 weeks minus deductions for {
   federal income tax            is  25.  percent of gross,
 }
 &hellip;</code></pre>
 
-<p>Nel nostro nuovo <abbr>DSL</abbr>, inseriamo uno specifico impiegato nello script. Non pretendiamo che un utente effettui una copia di questo script per ogni impiegato: una naturale estensione che non perseguiremo permetterebbe all'utente di effettuare un ciclo su tutti gli impiegati stipendiati contenuti in un database, per esempio.
+<p>Nel nostro nuovo <abbr>DSL</abbr>, inseriamo uno specifico impiegato nello script. Non pretendiamo che un utente effettui una copia di questo script per ogni impiegato: una naturale estensione che non perseguiremo permetterebbe all&#8217;utente di effettuare un ciclo su tutti gli impiegati stipendiati contenuti in un database, per esempio.
 
-<p>Alcune differenze sono &#8220;gratuite&#8221;; avremmo potuto usare la stessa sintassi vista in precedenza. Questi cambiamenti includono la rimozione del trattino basso tra le parole in alcune espressioni e l'espansione delle parole in <em>camel-case</em> in parole separate da spazi; cioè, abbiamo trasformato alcune parole singole in espressioni con più parole. Grazie a queste modifiche l'implementazione basata sugli operatori di riconoscimento risulterà più semplice, ma le stesse espressioni con più parole avrebbero reso molto più complessa l'implementazione del <abbr>DSL</abbr> interno.
+<p>Alcune differenze sono &#8220;gratuite&#8221;; avremmo potuto usare la stessa sintassi vista in precedenza. Questi cambiamenti includono la rimozione del trattino basso tra le parole in alcune espressioni e l&#8217;espansione delle parole in <em>camel-case</em> in parole separate da spazi; cioè, abbiamo trasformato alcune parole singole in espressioni con più parole. Grazie a queste modifiche l&#8217;implementazione basata sugli operatori di riconoscimento risulterà più semplice, ma le stesse espressioni con più parole avrebbero reso molto più complessa l&#8217;implementazione del <abbr>DSL</abbr> interno.
 
 <p>Le &#8220;variabili locali&#8221; come <var>employee</var> e <var>gross</var> non servono più. Queste parole compaiono ancora nel <abbr>DSL</abbr>, ma il nostro riconoscitore terrà traccia internamente delle istanze corrispondenti.
 
 
 <p>Non abbiamo precisato i dettagli per i numeri decimali, i numeri in virgola mobile e le lettere consentite nel nome degli impiegati, elidendo semplicemente quelle definizioni. Gestiremo questi dettagli più avanti.
 
-<p>Ogni riga nella grammatica definisce una <em>regola di produzione</em>. La fine di una definizione viene segnalata con un punto e virgola. Sul lato sinistro del segno di uguale compare un simbolo <em>non terminale</em>. Il lato destro è composto da simboli terminali (per esempio le stringhe letterali e i caratteri appena menzionati) che non richiedono un'analisi ulteriore, da altri simboli non terminali (tra cui è possibile includere un riferimento ricorsivo al simbolo non terminale presente sul lato sinistro) e da operatori che esprimono relazioni tra le entità. Si noti che le forme della grammatica possono essere decomoposte in maniera gerarchica; pur non essendo un grafo diretto aciclico, generalmente parlando, una grammatica di questo tipo può contenere cicli.
+<p>Ogni riga nella grammatica definisce una <em>regola di produzione</em>. La fine di una definizione viene segnalata con un punto e virgola. Sul lato sinistro del segno di uguale compare un simbolo <em>non terminale</em>. Il lato destro è composto da simboli terminali (per esempio le stringhe letterali e i caratteri appena menzionati) che non richiedono un&#8217;analisi ulteriore, da altri simboli non terminali (tra cui è possibile includere un riferimento ricorsivo al simbolo non terminale presente sul lato sinistro) e da operatori che esprimono relazioni tra le entità. Si noti che le forme della grammatica possono essere decomoposte in maniera gerarchica; pur non essendo un grafo diretto aciclico, generalmente parlando, una grammatica di questo tipo può contenere cicli.
 
-<p>La nostra è una grammatica libera da contesto perché ogni regola di produzione ha un singolo simbolo non terminale sul lato sinistro del segno di uguale, cioè non è necessaria alcuna informazione di contesto aggiuntiva per specificare l'applicabilità e il significato della produzione.
+<p>La nostra è una grammatica libera da contesto perché ogni regola di produzione ha un singolo simbolo non terminale sul lato sinistro del segno di uguale, cioè non è necessaria alcuna informazione di contesto aggiuntiva per specificare l&#8217;applicabilità e il significato della produzione.
 
 <p>Le regole di produzione come <code>toBe = "is" | "are"</code> indicano una corrispondenza con la produzione <code>is</code> (un simbolo terminale, in questo caso) <em>oppure</em> con la produzione <code>are</code>. Questo è un esempio di <em>composizione alternativa</em>.
 
-<p>Quando le produzioni sul lato destro di un'altra produzione sono separate da spazi bianchi, come per esempio <code>prod1 prod2</code>, tutte le produzioni devono apparire sequenzialmente per ottenere una corrispondenza. (La maggior parte dei formati <abbr>EBNF</abbr> richiede una virgola per separare queste entità.) Quindi, queste espressioni sono simili a &#8220;congiunzioni&#8221;, ma la <em>composizione sequenziale</em> è talmente comune che non viene usato nessun operatore <code>&amp;</code> come analogo di <code>|</code> per la composizione alternativa.
+<p>Quando le produzioni sul lato destro di un&#8217;altra produzione sono separate da spazi bianchi, come per esempio <code>prod1 prod2</code>, tutte le produzioni devono apparire sequenzialmente per ottenere una corrispondenza. (La maggior parte dei formati <abbr>EBNF</abbr> richiede una virgola per separare queste entità.) Quindi, queste espressioni sono simili a &#8220;congiunzioni&#8221;, ma la <em>composizione sequenziale</em> è talmente comune che non viene usato nessun operatore <code>&amp;</code> come analogo di <code>|</code> per la composizione alternativa.
 
-<p>La regola di produzione che contiene <code>"{" deductItem { "," deductItem } "}"</code> mostra come specificare ripetizioni opzionali (zero o più). Questa espressione corrisponde a un carattere letterale <code>{</code>, seguito da <code>deductItem</code> (un'altra produzione), seguita da zero o più espressioni che consistono in una virgola letterale e in un'altra produzione <code>deductItem</code>, terminando infine con un carattere letterale <code>}</code>. A volte si usa un asterisco per indicare elementi ripetuti zero o più volte, come per esempio in <code>prod *</code>. Per gli elementi ripetuti almeno una volta, si può usare <code>prod +</code>.
+<p>La regola di produzione che contiene <code>"{" deductItem { "," deductItem } "}"</code> mostra come specificare ripetizioni opzionali (zero o più). Questa espressione corrisponde a un carattere letterale <code>{</code>, seguito da <code>deductItem</code> (un&#8217;altra produzione), seguita da zero o più espressioni che consistono in una virgola letterale e in un&#8217;altra produzione <code>deductItem</code>, terminando infine con un carattere letterale <code>}</code>. A volte si usa un asterisco per indicare elementi ripetuti zero o più volte, come per esempio in <code>prod *</code>. Per gli elementi ripetuti almeno una volta, si può usare <code>prod +</code>.
 
 <p>Infine, se la nostra grammatica contenesse entità opzionali, potremmo racchiuderle tra parentesi quadre. Ci sono altri tipi di possibili operatori di composizione (supportati dalla libreria Scala), alcuni dei quali verranno discussi più avanti. Si veda la voce <code>Parsers</code> in <a href=apa.html#ScalaAPI2008>[ScalaAPI2008]</a> per maggiori dettagli.
 
 
 <pre><code>def paycheck = empl ~ gross ~ deduct</code></pre>
 
-<p>Si usa un altro combinatore di composizione sequenziale <code>&#8764;&gt;</code> quando non è più necessario conservare il risultato della produzione sulla <em>sinistra</em>. Per esempio, quando elaboriamo la produzione <code>empl</code>, vogliamo tenere solo il risultato del riconoscimento dell'ultima produzione, <code>employeeName</code>.
+<p>Si usa un altro combinatore di composizione sequenziale <code>&#8764;&gt;</code> quando non è più necessario conservare il risultato della produzione sulla <em>sinistra</em>. Per esempio, quando elaboriamo la produzione <code>empl</code>, vogliamo tenere solo il risultato del riconoscimento dell&#8217;ultima produzione, <code>employeeName</code>.
 
 <pre><code>def empl = "paycheck" ~&gt; "for" ~&gt; "employee" ~&gt; employeeName</code></pre>
 
 
 <pre><code>def tax = fedState &lt;~ "income" &lt;~ "tax"</code></pre>
 
-<p>L'uso pesante che facciamo del combinatore sequenziale <code>&lt;&#8764;</code> nelle varie produzioni relative alle ritenute indica che non stiamo tenendo traccia della natura di ogni ritenuta, ma solo della quantità. Un'applicazione reale per il calcolo delle buste paga stamperebbe questa informazione, naturalmente, ma qui noi miriamo alla semplicità. Come esercizio, riflettete su come modificare <code>PayrollParserCombinatorsV1</code> e le sue versioni successive, che vedremo più avanti, per tenere traccia di questa informazione: conservereste necessariamente le stringhe riconosciute oppure impieghereste una strategia diversa?
+<p>L&#8217;uso pesante che facciamo del combinatore sequenziale <code>&lt;&#8764;</code> nelle varie produzioni relative alle ritenute indica che non stiamo tenendo traccia della natura di ogni ritenuta, ma solo della quantità. Un&#8217;applicazione reale per il calcolo delle buste paga stamperebbe questa informazione, naturalmente, ma qui noi miriamo alla semplicità. Come esercizio, riflettete su come modificare <code>PayrollParserCombinatorsV1</code> e le sue versioni successive, che vedremo più avanti, per tenere traccia di questa informazione: conservereste necessariamente le stringhe riconosciute oppure impieghereste una strategia diversa?
 
 <p>La &#8220;disgiunzione&#8221; viene espressa con il metodo <code>|</code>, proprio come nella grammatica.
 
 
 <p>Come per le ripetizioni, esiste un metodo <code>opt</code> per i termini opzionali, che però non stiamo usando.
 
-<p><code>PayrollParserCombinatorsV1</code> estende <code>JavaTokenParsers</code>, che estende <code>RegexParsers</code>, che estende il tratto radice <code>Parsers</code> per i riconoscitori. &Egrave; risaputo che ogni tentativo di riconoscere grammatiche non banali usando solo le espressioni regolari tende a fallire piuttosto velocemente. Tuttavia, le espressioni regolari possono essere molto efficaci per riconoscere i singoli termini all'interno di un framework di analisi sintattica. Nel nostro esempio, sfruttiamo le produzioni di <code>JavaTokenParsers</code> per riconoscere le stringhe tra virgolette (usate per il nome dell'impiegato), i letterali decimali e i letterali in virgola mobile.
+<p><code>PayrollParserCombinatorsV1</code> estende <code>JavaTokenParsers</code>, che estende <code>RegexParsers</code>, che estende il tratto radice <code>Parsers</code> per i riconoscitori. &Egrave; risaputo che ogni tentativo di riconoscere grammatiche non banali usando solo le espressioni regolari tende a fallire piuttosto velocemente. Tuttavia, le espressioni regolari possono essere molto efficaci per riconoscere i singoli termini all&#8217;interno di un framework di analisi sintattica. Nel nostro esempio, sfruttiamo le produzioni di <code>JavaTokenParsers</code> per riconoscere le stringhe tra virgolette (usate per il nome dell&#8217;impiegato), i letterali decimali e i letterali in virgola mobile.
 
 <p>Facciamo una prova! Ecco una specifica che esercita il riconoscitore in due casi, con e senza le ritenute.
 
 
 <p>Il metodo <code>parseAll</code> è definito in una classe genitore. Invochiamo il metodo di produzione a livello radice, <code>paycheck</code>, poi passiamo a <code>parseAll</code> il suo valore di ritorno come primo argomento e la stringa da riconoscere come secondo argomento.
 
-<p>Se il processo di riconoscimento ha successo, il suo risultato viene restituito come un'istanza di tipo <code>p.Success[+T]</code>, una classe <code>case</code> dichiarata nel tratto <code>Parsers</code>. Il prefisso <code>p.</code> indica che <code>p.Success</code> è un <em>tipo dipendente dal percorso</em>, di cui parleremo nella sezione <a href=cap-12.html#PathDependentTypes>Tipi dipendenti dal percorso</a> del capitolo 12. Per ora vi basti sapere che, anche se <code>Success</code> è definito nel tratto <code>Parsers</code>, il tipo reale dell'istanza dipende dall'istanza di <code>PayrollParserCombinatorsV1</code> che abbiamo creato. In altre parole, se avessimo un altro riconoscitore <code>p2</code> di tipo <code>MyOtherParser</code>, allora <code>p2.Success[String]</code> sarebbe differente da <code>p.Success[String]</code> e non sarebbe possibile sostituire l'uno con l'altro.
+<p>Se il processo di riconoscimento ha successo, il suo risultato viene restituito come un&#8217;istanza di tipo <code>p.Success[+T]</code>, una classe <code>case</code> dichiarata nel tratto <code>Parsers</code>. Il prefisso <code>p.</code> indica che <code>p.Success</code> è un <em>tipo dipendente dal percorso</em>, di cui parleremo nella sezione <a href=cap-12.html#PathDependentTypes>Tipi dipendenti dal percorso</a> del capitolo 12. Per ora vi basti sapere che, anche se <code>Success</code> è definito nel tratto <code>Parsers</code>, il tipo reale dell&#8217;istanza dipende dall&#8217;istanza di <code>PayrollParserCombinatorsV1</code> che abbiamo creato. In altre parole, se avessimo un altro riconoscitore <code>p2</code> di tipo <code>MyOtherParser</code>, allora <code>p2.Success[String]</code> sarebbe differente da <code>p.Success[String]</code> e non sarebbe possibile sostituire l&#8217;uno con l&#8217;altro.
 
-<p>L'istanza di <code>Success</code> contiene due campi: il risultato del riconoscimento, che è un'istanza di tipo <code>T</code> (assegnata a <var>r</var> nella clausola <code>case</code>), e la parte rimanente della stringa in ingresso da riconoscere, che sarà vuota dopo un riconoscimento avvenuto con successo (a quel punto abbiamo riconosciuto l'intera stringa). Questa stringa viene assegnata a <code>_</code>.
+<p>L&#8217;istanza di <code>Success</code> contiene due campi: il risultato del riconoscimento, che è un&#8217;istanza di tipo <code>T</code> (assegnata a <var>r</var> nella clausola <code>case</code>), e la parte rimanente della stringa in ingresso da riconoscere, che sarà vuota dopo un riconoscimento avvenuto con successo (a quel punto abbiamo riconosciuto l&#8217;intera stringa). Questa stringa viene assegnata a <code>_</code>.
 
-<p>Se il riconoscimento fallisce, l'istanza restituita è di tipo <code>p.Failure</code> oppure <code>p.Error</code>, che il nostro esempio gestisce con una clausola <code>case</code> generica. Entrambi i tipi derivano da <code>p.NoSuccess</code>, che contiene campi per un messaggio di errore e per l'ingresso non consumato al momento del fallimento. Un risultato di tipo <code>p.Failure</code> in un riconoscitore innescherà il <em>backtracking</em> in modo che il framework di riconoscimento provi un riconoscitore differente, se è possibile. Un risultato di tipo <code>p.Error</code> non innesca il backtracking e viene usato per segnalare problemi più gravi.
+<p>Se il riconoscimento fallisce, l&#8217;istanza restituita è di tipo <code>p.Failure</code> oppure <code>p.Error</code>, che il nostro esempio gestisce con una clausola <code>case</code> generica. Entrambi i tipi derivano da <code>p.NoSuccess</code>, che contiene campi per un messaggio di errore e per l&#8217;ingresso non consumato al momento del fallimento. Un risultato di tipo <code>p.Failure</code> in un riconoscitore innescherà il <em>backtracking</em> in modo che il framework di riconoscimento provi un riconoscitore differente, se è possibile. Un risultato di tipo <code>p.Error</code> non innesca il backtracking e viene usato per segnalare problemi più gravi.
 
 <p>Per completezza, sia <code>p.Success</code> sia <code>p.NoSuccess</code> derivano da <code>p.ParseResult</code>.
 
-<p>Rimangono due grandi domande ancora senza risposta: cosa restituiscono effettivamente i metodi delle produzioni, e qual è il tipo dell'istanza restituita come risultato in <code>p.Success</code>?
+<p>Rimangono due grandi domande ancora senza risposta: cosa restituiscono effettivamente i metodi delle produzioni, e qual è il tipo dell&#8217;istanza restituita come risultato in <code>p.Success</code>?
 
 <p>I metodi di produzione restituiscono riconoscitori. Nel nostro esempio, la maggior parte dei metodi restituisce <code>p.Parser[String]</code> (ancora una volta, un tipo dipendente dal percorso). Tuttavia, dato che il metodo <code>deduct</code> gestisce la ripetizione (invocando il metodo <code>repsep</code>), in effetti esso restituisce <code>p.Parser[List[String]]</code>. Quando questo riconoscitore viene usato restituisce <code>List[String]</code>, che contiene una stringa per ogni corrispondenza nella ripetizione.
 
-<p>Quindi, l'invocazione di <code>p.parseAll(p.paycheck, input)</code> che abbiamo visto riconosce la stringa <var>input</var> usando il riconoscitore restituito da <code>p.paycheck</code>. Questo ci porta alla seconda domanda: qual è il risultato di un riconoscimento riuscito?
+<p>Quindi, l&#8217;invocazione di <code>p.parseAll(p.paycheck, input)</code> che abbiamo visto riconosce la stringa <var>input</var> usando il riconoscitore restituito da <code>p.paycheck</code>. Questo ci porta alla seconda domanda: qual è il risultato di un riconoscimento riuscito?
 
-<p>Per vedere ciò che viene restituito, compilate il file che contiene <code>PayrollParserCombinatorsV1</code> indicato all'inizio di questa sezione, e invocate l'interprete <kbd>scala</kbd> con l'opzione <code>-cp</code> per includere la directory dove sono stati creati i file di classe (questa directory si chiamerà <tt>build</tt> se avete usato il processo di assemblaggio definito nell'archivio degli esempi di codice).
+<p>Per vedere ciò che viene restituito, compilate il file che contiene <code>PayrollParserCombinatorsV1</code> indicato all&#8217;inizio di questa sezione, e invocate l&#8217;interprete <kbd>scala</kbd> con l&#8217;opzione <code>-cp</code> per includere la directory dove sono stati creati i file di classe (questa directory si chiamerà <tt>build</tt> se avete usato il processo di assemblaggio definito nell&#8217;archivio degli esempi di codice).
 
-<p>Una volta nell'interprete, digitate le seguenti espressioni dopo il prompt <code>scala&gt;</code>. (Potete anche trovare queste espressioni nel file <span class=file>payroll-parser-comb-script.scala</span> incluso nell'archivio degli esempi di codice.)
+<p>Una volta nell&#8217;interprete, digitate le seguenti espressioni dopo il prompt <code>scala&gt;</code>. (Potete anche trovare queste espressioni nel file <span class=file>payroll-parser-comb-script.scala</span> incluso nell&#8217;archivio degli esempi di codice.)
 
 <pre><samp>scala&gt; import scala.util.parsing.combinator._
 import scala.util.parsing.combinator._
 
 scala&gt;</samp></pre>
 
-<p>Importiamo i tipi necessari e creiamo un'istanza di <code>PayrollParserCombinatorsV1</code>. Poi invochiamo diversi metodi di produzione per vedere che tipo di <code>Parser</code> restituiscono. I primi tre, cioè <code>empl</code>, <code>weekDays</code> e <code>doubleNumber</code>, restituiscono <code>p.Parser[String]</code>.
+<p>Importiamo i tipi necessari e creiamo un&#8217;istanza di <code>PayrollParserCombinatorsV1</code>. Poi invochiamo diversi metodi di produzione per vedere che tipo di <code>Parser</code> restituiscono. I primi tre, cioè <code>empl</code>, <code>weekDays</code> e <code>doubleNumber</code>, restituiscono <code>p.Parser[String]</code>.
 
-<p>Notate ciò che viene scritto sul lato destro dell'uscita per i primi tre riconoscitori: <code>empl</code>, <code>weeksDays</code> e <code>doubleNumber</code> mostrano rispettivamente <code>Parser (&#8764;&gt;)</code>, <code>Parser (|)</code> e <code>Parser ()</code>. I riconoscitori restituiti riflettono le definizioni delle regole di produzione, dove <code>empl</code> termina con un combinatore della forma <code>prod1 &#8764;&gt; prod2</code> e <code>weeksDays</code> termina con un combinatore della forma <code>prod1 | prod2</code>, mentre <code>doubleNumber</code> restituisce un riconoscitore per una singola produzione.
+<p>Notate ciò che viene scritto sul lato destro dell&#8217;uscita per i primi tre riconoscitori: <code>empl</code>, <code>weeksDays</code> e <code>doubleNumber</code> mostrano rispettivamente <code>Parser (&#8764;&gt;)</code>, <code>Parser (|)</code> e <code>Parser ()</code>. I riconoscitori restituiti riflettono le definizioni delle regole di produzione, dove <code>empl</code> termina con un combinatore della forma <code>prod1 &#8764;&gt; prod2</code> e <code>weeksDays</code> termina con un combinatore della forma <code>prod1 | prod2</code>, mentre <code>doubleNumber</code> restituisce un riconoscitore per una singola produzione.
 
-<p>Dato che <code>deduct</code> consiste di operatori che gestiscono la ripetizione, il riconoscitore restituito da <code>deduct</code> è di tipo <code>p.Parser[List[String]]</code>, come avevamo detto in precedenza. Il lato destro dell'uscita è <code>Parser (&lt;&#8764;)</code>, perché la definizione di <code>deduct</code> termina con <code>prod1 &lt;&#8764; prod2</code>.
+<p>Dato che <code>deduct</code> consiste di operatori che gestiscono la ripetizione, il riconoscitore restituito da <code>deduct</code> è di tipo <code>p.Parser[List[String]]</code>, come avevamo detto in precedenza. Il lato destro dell&#8217;uscita è <code>Parser (&lt;&#8764;)</code>, perché la definizione di <code>deduct</code> termina con <code>prod1 &lt;&#8764; prod2</code>.
 
 <p>Le cose si fanno più interessanti quando esaminiamo la produzione a livello radice, <code>paycheck</code>. Cosa dovrebbe significare <code>p.Parser[p.&#8764;[p.&#8764;[String,p.&#8764;[String,String]],List[String]]] = Parser (&#8764;)</code>? Dunque, il lato destro dovrebbe essere facile da capire ora; la definizione di <code>paycheck</code> termina con <code>prod1 &#8764; prod2</code>. Che cosa rappresenta il parametro di tipo di <code>p.Parser</code> sul lato sinistro del segno di uguale?
 
   override def toString = "(" + _1 + "~" + _2 + ")"
 }</code></pre>
 
-<p>Nel nostro esempio, l'effettivo tipo dipendente dal percorso è <code>p.&#8764;[+a,+b]</code>. Quindi, il parametro di tipo <code>T</code> in <code>p.Parser[T]</code> è <code>p.&#8764;[p.&#8764;[String,p.&#8764;[String,String]],List[String]]</code>, che rappresenta un albero gerarchico di tipi.
+<p>Nel nostro esempio, l&#8217;effettivo tipo dipendente dal percorso è <code>p.&#8764;[+a,+b]</code>. Quindi, il parametro di tipo <code>T</code> in <code>p.Parser[T]</code> è <code>p.&#8764;[p.&#8764;[String,p.&#8764;[String,String]],List[String]]</code>, che rappresenta un albero gerarchico di tipi.
 
-<p>Suddividiamolo in parti e leggiamolo dall'interno verso l'esterno. Notate che ci sono tre <code>p.&#8764;</code>. Cominceremo con il tipo più interno, <code>p.&#8764;[String,String]</code>, e ne tracceremo una corrispondenza con la dichiarazione di tipo che abbiamo visto in uscita nella sessione di <kbd>scala</kbd>, <code>"Buck Trends"&#8764;(2&#8764;weeks&#8764;List())</code>.
+<p>Suddividiamolo in parti e leggiamolo dall&#8217;interno verso l&#8217;esterno. Notate che ci sono tre <code>p.&#8764;</code>. Cominceremo con il tipo più interno, <code>p.&#8764;[String,String]</code>, e ne tracceremo una corrispondenza con la dichiarazione di tipo che abbiamo visto in uscita nella sessione di <kbd>scala</kbd>, <code>"Buck Trends"&#8764;(2&#8764;weeks&#8764;List())</code>.
 
-<p>Il tipo <code>p.&#8764;[String,String]</code> corrisponde al riconoscitore che gestisce espressioni come <code>2 weeks</code>. Quindi, l'istanza creata quando analizziamo la nostra stringa di esempio è l'istanza <code>p.&#8764;("2", "weeks")</code>. L'invocazione del metodo <code>p.&#8764;.toString</code> produce l'uscita <code>(2~weeks)</code>.
+<p>Il tipo <code>p.&#8764;[String,String]</code> corrisponde al riconoscitore che gestisce espressioni come <code>2 weeks</code>. Quindi, l&#8217;istanza creata quando analizziamo la nostra stringa di esempio è l&#8217;istanza <code>p.&#8764;("2", "weeks")</code>. L&#8217;invocazione del metodo <code>p.&#8764;.toString</code> produce l&#8217;uscita <code>(2~weeks)</code>.
 
-<p>Muovendoci di un livello verso l'esterno, abbiamo <code>p.&#8764;[String,p.&#8764;[String,String]]</code>. Questa combinazione riconosce <code>paycheck for employee "Buck Trends" is salary for 2 weeks</code>. Ricordatevi che scartiamo <code>paycheck for employee</code> e <code>is salary for</code>, tenendo solo le parti <code>"Buck Trends"</code> e <code>2 weeks</code>. Quindi l'istanza creata è <code>p.&#8764;("Buck Trends", p.&#8764;("2", "weeks"))</code>. Una nuova invocazione di <code>toString</code> produce come risultato la stringa <code>("Buck Trends"&#8764;(2&#8764;weeks))</code>.
+<p>Muovendoci di un livello verso l&#8217;esterno, abbiamo <code>p.&#8764;[String,p.&#8764;[String,String]]</code>. Questa combinazione riconosce <code>paycheck for employee "Buck Trends" is salary for 2 weeks</code>. Ricordatevi che scartiamo <code>paycheck for employee</code> e <code>is salary for</code>, tenendo solo le parti <code>"Buck Trends"</code> e <code>2 weeks</code>. Quindi l&#8217;istanza creata è <code>p.&#8764;("Buck Trends", p.&#8764;("2", "weeks"))</code>. Una nuova invocazione di <code>toString</code> produce come risultato la stringa <code>("Buck Trends"&#8764;(2&#8764;weeks))</code>.
 
-<p>Infine, al livello più esterno, abbiamo <code>p.&#8764;[p.&#8764;[String,p.&#8764;[String,String]],List[String]]</code>, di cui abbiamo già esaminato tutto tranne l'ultimo <code>List[String]</code>, che proviene dalla produzione <code>deduct</code>.
+<p>Infine, al livello più esterno, abbiamo <code>p.&#8764;[p.&#8764;[String,p.&#8764;[String,String]],List[String]]</code>, di cui abbiamo già esaminato tutto tranne l&#8217;ultimo <code>List[String]</code>, che proviene dalla produzione <code>deduct</code>.
 
 <pre><code>def deduct = "minus" ~&gt; "deductions" ~&gt; "for" ~&gt;
              "{" ~&gt; repsep(deductItem, "," ) &lt;~ "}"</code></pre>
 
-<p>Scartiamo tutto tranne la lista di zero o più <code>deductItem</code>. Nel nostro esempio non ce ne sono, quindi otteniamo una lista vuota per la quale <code>toString</code> restituisce <code>List()</code>. Di conseguenza, l'invocazione di <code>p.&#8764;.toString</code> sul nostro tipo più esterno, quello che parametrizza <code>p.Parser</code>, restituisce la stringa <code>"Buck Trends"&#8764;(2&#8764;weeks&#8764;List())</code>. Abbiamo finito!
+<p>Scartiamo tutto tranne la lista di zero o più <code>deductItem</code>. Nel nostro esempio non ce ne sono, quindi otteniamo una lista vuota per la quale <code>toString</code> restituisce <code>List()</code>. Di conseguenza, l&#8217;invocazione di <code>p.&#8764;.toString</code> sul nostro tipo più esterno, quello che parametrizza <code>p.Parser</code>, restituisce la stringa <code>"Buck Trends"&#8764;(2&#8764;weeks&#8764;List())</code>. Abbiamo finito!
 
-<p>Be', non proprio. Non abbiamo ancora calcolato un vero stipendio per la retribuzione del vecchio Buck. Ora completeremo la nostra implementazione.
+<p>Be&#8217;, non proprio. Non abbiamo ancora calcolato un vero stipendio per la retribuzione del vecchio Buck. Ora completeremo la nostra implementazione.
 
 <h3 id=_generating_paychecks_with_the_external_dsl>Generare le buste paga con un <abbr>DSL</abbr> esterno</h3>
 
-<p>Durante il riconoscimento del <abbr>DSL</abbr> vogliamo cercare l'impiegato per nome, recuperare il suo stipendio lordo per il periodo di retribuzione specificato e poi calcolare le ritenute man mano che procediamo. Quando il riconoscitore restituito da <code>paycheck</code> termina le proprie operazioni, desideriamo restituire un'istanza di <code>Pair</code> che contenga l'istanza di <code>Employee</code> e l'istanza di <code>Paycheck</code> completa.
+<p>Durante il riconoscimento del <abbr>DSL</abbr> vogliamo cercare l&#8217;impiegato per nome, recuperare il suo stipendio lordo per il periodo di retribuzione specificato e poi calcolare le ritenute man mano che procediamo. Quando il riconoscitore restituito da <code>paycheck</code> termina le proprie operazioni, desideriamo restituire un&#8217;istanza di <code>Pair</code> che contenga l&#8217;istanza di <code>Employee</code> e l&#8217;istanza di <code>Paycheck</code> completa.
 
-<p>Riutilizzeremo classi &#8220;di dominio&#8221; come <code>Employee</code>, <code>Money</code>, <code>Paycheck</code>, <i class=baa>&amp;</i>c. dalle sezioni precedenti di questo capitolo. Per effettuare i calcoli su richiesta, creeremo una seconda iterazione di <code>PayrollParserCombinatorsV1</code> che chiameremo <code>PayrollParserCombinators</code>. Modificheremo i riconoscitori restituiti da alcuni metodi di produzione per restituire nuovi tipi di riconoscitore. Svolgeremo anche alcune attività di ordinaria amministrazione come memorizzare i dati di contesto durante l'esecuzione, nel caso ce ne sia bisogno. La nostra implementazione non sarà thread-safe; vorrete assicurarvi che un solo thread possa accedere a un dato <code>PayrollParserCombinators</code>. Potremmo renderla più robusta, ma farlo non rientra tra gli scopi di questo esercizio.
+<p>Riutilizzeremo classi &#8220;di dominio&#8221; come <code>Employee</code>, <code>Money</code>, <code>Paycheck</code>, <i class=baa>&amp;</i>c. dalle sezioni precedenti di questo capitolo. Per effettuare i calcoli su richiesta, creeremo una seconda iterazione di <code>PayrollParserCombinatorsV1</code> che chiameremo <code>PayrollParserCombinators</code>. Modificheremo i riconoscitori restituiti da alcuni metodi di produzione per restituire nuovi tipi di riconoscitore. Svolgeremo anche alcune attività di ordinaria amministrazione come memorizzare i dati di contesto durante l&#8217;esecuzione, nel caso ce ne sia bisogno. La nostra implementazione non sarà thread-safe; vorrete assicurarvi che un solo thread possa accedere a un dato <code>PayrollParserCombinators</code>. Potremmo renderla più robusta, ma farlo non rientra tra gli scopi di questo esercizio.
 
 <p>Ecco la versione finale del nostro <code>PayrollParserCombinators</code>.
 
 
 <p>Per semplicità useremo una mappa di impiegati &#8220;noti&#8221;, in cui le chiavi sono istanze di <code>Name</code>, che abbiamo salvato in un campo di <code>PayrollParserCombinators</code>. Una implementazione reale userebbe probabilmente un database di qualche tipo.
 
-<p>Ci sono altri due campi: <code>currentEmployee</code>, che memorizza l'impiegato su cui stiamo lavorando, e <code>grossAmount</code>, che memorizza lo stipendio lordo dell'impiegato per il periodo di retribuzione. Entrambi i campi hanno un <em>odore di cattiva progettazione</em>. Sono mutabili; e sono impostati solo una volta durante ogni riconoscimento, ma non nel momento in cui vengono dichiarati, bensì solo quando analizziamo l'ingresso che ci permette di calcolarli. Potreste avere anche notato che, se la stessa istanza di <code>PayrollParserCombinators</code> viene usata più di una volta, quei campi non vengono riportati ai loro valori predefiniti. Senza dubbio sarebbe possibile usare il <abbr>DSL</abbr> per scrivere programmi maliziosi che sfruttano questo difetto.
+<p>Ci sono altri due campi: <code>currentEmployee</code>, che memorizza l&#8217;impiegato su cui stiamo lavorando, e <code>grossAmount</code>, che memorizza lo stipendio lordo dell&#8217;impiegato per il periodo di retribuzione. Entrambi i campi hanno un <em>odore di cattiva progettazione</em>. Sono mutabili; e sono impostati solo una volta durante ogni riconoscimento, ma non nel momento in cui vengono dichiarati, bensì solo quando analizziamo l&#8217;ingresso che ci permette di calcolarli. Potreste avere anche notato che, se la stessa istanza di <code>PayrollParserCombinators</code> viene usata più di una volta, quei campi non vengono riportati ai loro valori predefiniti. Senza dubbio sarebbe possibile usare il <abbr>DSL</abbr> per scrivere programmi maliziosi che sfruttano questo difetto.
 
-<p>Queste debolezze non sono inerenti alla combinazione di riconoscitori, ma riflettono le semplificazioni che abbiamo adottato per i nostri scopi. Come esercizio, potreste provare a migliorare l'implementazione eliminandole.
+<p>Queste debolezze non sono inerenti alla combinazione di riconoscitori, ma riflettono le semplificazioni che abbiamo adottato per i nostri scopi. Come esercizio, potreste provare a migliorare l&#8217;implementazione eliminandole.
 
 <p>Abbiamo aggiunto annotazioni <code>@return</code> nello stile Javadoc alla maggior parte delle produzioni per chiarire che cosa restituiscono ora. In alcuni casi, le produzioni sono rimaste inalterate, in quanto le istanze originali dei riconoscitori vanno bene così come sono. La maggior parte delle modifiche riflette il nostro desiderio di calcolare la busta paga man mano che procediamo.
 
   case e ~ g ~ d =&gt; (e, Paycheck(g, g - d, d))
 }</code></pre>
 
-<p>Ora restituiamo un'istanza di <code>Pair</code> con l'impiegato e la busta paga calcolata. La combinazione <code>empl &#8764; gross &#8764; deduct</code> restituirebbe ancora <code>Parser[String]</code> (trascureremo il prefisso dipendente dal percorso per ora), ma abbiamo aggiunto un nuovo operatore <code>^^</code>, usato seguendo lo schema <code>prod1 ^^ func1</code>, dove <code>func1</code> è una funzione. Se <code>prod1</code> ha successo, allora viene restituito il risultato dell'applicazione di <code>func1</code> al risultato di <code>prod1</code>; cioè, restituiamo <code>func1(prod1)</code>.
+<p>Ora restituiamo un&#8217;istanza di <code>Pair</code> con l&#8217;impiegato e la busta paga calcolata. La combinazione <code>empl &#8764; gross &#8764; deduct</code> restituirebbe ancora <code>Parser[String]</code> (trascureremo il prefisso dipendente dal percorso per ora), ma abbiamo aggiunto un nuovo operatore <code>^^</code>, usato seguendo lo schema <code>prod1 ^^ func1</code>, dove <code>func1</code> è una funzione. Se <code>prod1</code> ha successo, allora viene restituito il risultato dell&#8217;applicazione di <code>func1</code> al risultato di <code>prod1</code>; cioè, restituiamo <code>func1(prod1)</code>.
 
-<p>In <code>paycheck</code>, diamo all'operatore un letterale funzione che esegue il pattern matching per estrarre i tre risultati da <code>empl</code>, <code>gross</code> e <code>deduct</code>, rispettivamente. Creiamo una tupla di due elementi (un'istanza di <code>Pair</code>) che contiene l'istanza <code>e</code> di <code>Employee</code> e l'istanza di <code>Paycheck</code> calcolata a partire dallo stipendio lordo per il periodo di retribuzione (in <code>g</code>) e dalla somma di tutte le ritenute (in <code>d</code>).
+<p>In <code>paycheck</code>, diamo all&#8217;operatore un letterale funzione che esegue il pattern matching per estrarre i tre risultati da <code>empl</code>, <code>gross</code> e <code>deduct</code>, rispettivamente. Creiamo una tupla di due elementi (un&#8217;istanza di <code>Pair</code>) che contiene l&#8217;istanza <code>e</code> di <code>Employee</code> e l&#8217;istanza di <code>Paycheck</code> calcolata a partire dallo stipendio lordo per il periodo di retribuzione (in <code>g</code>) e dalla somma di tutte le ritenute (in <code>d</code>).
 
-<p>&Egrave; importante mettere in chiaro che la funzione anonima passata come argomento a <code>^^</code> restituisce una tupla <code>(Employee, Paycheck)</code>, ma che il metodo di produzione <code>paycheck</code> restiuisce <code>Parser[(Employee, Paycheck)]</code>. In effetti, questo è stato vero fin dall'inizio, quando la nostra prima versione lavorava su istanze di <code>String</code>, e rimarrà vero per tutte le regole di produzione in <code>PayrollParserCombinators</code>.
+<p>&Egrave; importante mettere in chiaro che la funzione anonima passata come argomento a <code>^^</code> restituisce una tupla <code>(Employee, Paycheck)</code>, ma che il metodo di produzione <code>paycheck</code> restiuisce <code>Parser[(Employee, Paycheck)]</code>. In effetti, questo è stato vero fin dall&#8217;inizio, quando la nostra prima versione lavorava su istanze di <code>String</code>, e rimarrà vero per tutte le regole di produzione in <code>PayrollParserCombinators</code>.
 
-<p>La produzione <code>empl</code> presume che il nome e il cognome dell'impiegato siano dati. (Ovviamente, questo non sarebbe adeguato per un'applicazione reale.)
+<p>La produzione <code>empl</code> presume che il nome e il cognome dell&#8217;impiegato siano dati. (Ovviamente, questo non sarebbe adeguato per un&#8217;applicazione reale.)
 
 <pre><code>/** @return Parser[Employee] */
 def empl = "paycheck" ~&gt; "for" ~&gt; "employee" ~&gt; employeeName ^^ { name =&gt;
    currentEmployee
 }</code></pre>
 
-<p>Per costruire il nome le virgolette incluse devono essere rimosse, perciò il metodo comincia estraendo la sottostringa che elimina il primo e l'ultimo carattere. Il nome viene usato per cercare l'istanza di <code>Employee</code> nella mappa, salvando il valore corrispondente nel campo <code>currentEmployee</code>. In generale, la gestione degli errori in <code>PayrollParserCombinators</code> non è &#8220;elegante&#8221;. Tuttavia, il metodo <code>empl</code> gestisce il caso in cui non venga trovato alcun impiegato con il nome specificato, lanciando all'occorrenza una eccezione di tipo <code>UnknownEmployee</code>.
+<p>Per costruire il nome le virgolette incluse devono essere rimosse, perciò il metodo comincia estraendo la sottostringa che elimina il primo e l&#8217;ultimo carattere. Il nome viene usato per cercare l&#8217;istanza di <code>Employee</code> nella mappa, salvando il valore corrispondente nel campo <code>currentEmployee</code>. In generale, la gestione degli errori in <code>PayrollParserCombinators</code> non è &#8220;elegante&#8221;. Tuttavia, il metodo <code>empl</code> gestisce il caso in cui non venga trovato alcun impiegato con il nome specificato, lanciando all&#8217;occorrenza una eccezione di tipo <code>UnknownEmployee</code>.
 
-<p>Il resto delle produzioni funziona in modo simile. A volte, un riconoscitore converte una stringa in ingresso in un numero <code>Int</code> (per esempio, <code>duration</code>) o in un'istanza di <code>Money</code> (per esempio, <code>gross</code>). Un caso interessante è quello di <code>deduct</code>: il riconoscitore ripiega la lista di ritenute in una singola ritenuta usando l'addizione. Il metodo <code>foldLeft</code> prende due liste di argomenti: la prima contiene un singolo argomento che specifica il valore iniziale, in questo caso l'istanza di <code>Money</code> che rappresenta zero; la seconda lista di argomenti contiene un singolo letterale funzione che accetta come argomenti il valore accumulato dall'operazione di ripiegamento e un elemento della lista. In questo caso, vogliamo restituire la somma degli argomenti, perciò <code>foldLeft</code> itera sulla collezione <code>items</code>, sommando insieme ogni elemento. Si veda la sezione <a href=cap-8.html#TraversingMappingFilteringFolding>Operazioni comuni sulle strutture dati funzionali</a> nel capitolo 8 per maggiori informazioni su <code>foldLeft</code> e sulle operazioni correlate.
+<p>Il resto delle produzioni funziona in modo simile. A volte, un riconoscitore converte una stringa in ingresso in un numero <code>Int</code> (per esempio, <code>duration</code>) o in un&#8217;istanza di <code>Money</code> (per esempio, <code>gross</code>). Un caso interessante è quello di <code>deduct</code>: il riconoscitore ripiega la lista di ritenute in una singola ritenuta usando l&#8217;addizione. Il metodo <code>foldLeft</code> prende due liste di argomenti: la prima contiene un singolo argomento che specifica il valore iniziale, in questo caso l&#8217;istanza di <code>Money</code> che rappresenta zero; la seconda lista di argomenti contiene un singolo letterale funzione che accetta come argomenti il valore accumulato dall&#8217;operazione di ripiegamento e un elemento della lista. In questo caso, vogliamo restituire la somma degli argomenti, perciò <code>foldLeft</code> itera sulla collezione <code>items</code>, sommando insieme ogni elemento. Si veda la sezione <a href=cap-8.html#TraversingMappingFilteringFolding>Operazioni comuni sulle strutture dati funzionali</a> nel capitolo 8 per maggiori informazioni su <code>foldLeft</code> e sulle operazioni correlate.
 
 <p>Le produzioni <code>weeks</code> e <code>days</code> ci ricordano che stiamo usando operatori di riconoscimento basati su espressioni regolari. (Stiamo anche usando <code>stringLiteral</code>, <code>decimalNumber</code> e <code>floatingPointNumber</code>, forniti da <code>JavaTokenParsers</code>). Notate che <code>weeks</code> e <code>days</code> ignorano la stringa riconosciuta e restituiscono semplicemente un fattore moltiplicativo usato per determinare i giorni totali del periodo di retribuzione nella regola di produzione <code>duration</code>.
 
   }
 }</code></pre>
 
-<p>Se calcolate a mano quali dovrebbero essere i risultati dalle stringhe di ingresso, vedrete che l'implementazione calcola correttamente la busta paga.
+<p>Se calcolate a mano quali dovrebbero essere i risultati dalle stringhe di ingresso, vedrete che l&#8217;implementazione calcola correttamente la busta paga.
 
-<p>Oltre ai numerosi piccoli dettagli che differiscono tra questa implementazione del <abbr>DSL</abbr> esterno e l'implementazione precedente del <abbr>DSL</abbr> interno, c'è una notevole differenza concettuale tra le due implementazioni. Qui stiamo calcolando la busta paga man mano che riconosciamo il codice scritto nel <abbr>DSL</abbr> esterno. Nel caso del <abbr>DSL</abbr> interno, generiamo un oggetto per calcolare gli stipendi quando riconosciamo il <abbr>DSL</abbr>, dopodiché lo usiamo per un impiegato alla volta. Qui avremmo potuto fare la stessa cosa, ma abbiamo scelto un approccio più semplice allo scopo di concentrarci sul riconoscitore. In più, come abbiamo già detto, non siamo stati altrettanto attenti alla sicurezza per i thread e ad altri problemi di implementazione.
+<p>Oltre ai numerosi piccoli dettagli che differiscono tra questa implementazione del <abbr>DSL</abbr> esterno e l&#8217;implementazione precedente del <abbr>DSL</abbr> interno, c&#8217;è una notevole differenza concettuale tra le due implementazioni. Qui stiamo calcolando la busta paga man mano che riconosciamo il codice scritto nel <abbr>DSL</abbr> esterno. Nel caso del <abbr>DSL</abbr> interno, generiamo un oggetto per calcolare gli stipendi quando riconosciamo il <abbr>DSL</abbr>, dopodiché lo usiamo per un impiegato alla volta. Qui avremmo potuto fare la stessa cosa, ma abbiamo scelto un approccio più semplice allo scopo di concentrarci sul riconoscitore. In più, come abbiamo già detto, non siamo stati altrettanto attenti alla sicurezza per i thread e ad altri problemi di implementazione.
 
 <h3 id=ExternalDSLsFinalThoughts><abbr>DSL</abbr> interni vs. esterni: considerazioni finali</h3>
 
-<p>Scala vi offre un ricco supporto per creare <abbr>DSL</abbr> interni ed esterni. Tuttavia, un <abbr>DSL</abbr> non banale può essere difficile da implementare e correggere. Per gli esempi in questo capitolo, l'implementazione con gli operatori di riconoscimento è stata più facile da progettare e scrivere rispetto all'implementazione per il <abbr>DSL</abbr> interno, ma abbiamo visto che correggere il <abbr>DSL</abbr> interno era più semplice.
+<p>Scala vi offre un ricco supporto per creare <abbr>DSL</abbr> interni ed esterni. Tuttavia, un <abbr>DSL</abbr> non banale può essere difficile da implementare e correggere. Per gli esempi in questo capitolo, l&#8217;implementazione con gli operatori di riconoscimento è stata più facile da progettare e scrivere rispetto all&#8217;implementazione per il <abbr>DSL</abbr> interno, ma abbiamo visto che correggere il <abbr>DSL</abbr> interno era più semplice.
 
-<p>Dovete anche considerare quanto deve essere robusto il riconoscitore quando riceve un ingresso non valido. A seconda del livello di sofisticatezza degli utenti del <abbr>DSL</abbr>, potreste aver bisogno di fornire messaggi molto informativi quando avviene un errore, specialmente se i vostri utenti non sono programmatori. La libreria di operatori di riconoscimento di Scala 2.8 offrirà un supporto migliorato per segnalare gli errori e riprendere l'esecuzione rispetto alla libreria inclusa nelle versioni 2.7.X.
+<p>Dovete anche considerare quanto deve essere robusto il riconoscitore quando riceve un ingresso non valido. A seconda del livello di sofisticatezza degli utenti del <abbr>DSL</abbr>, potreste aver bisogno di fornire messaggi molto informativi quando avviene un errore, specialmente se i vostri utenti non sono programmatori. La libreria di operatori di riconoscimento di Scala 2.8 offrirà un supporto migliorato per segnalare gli errori e riprendere l&#8217;esecuzione rispetto alla libreria inclusa nelle versioni 2.7.X.
 
-<p>La libreria di Scala 2.8 fornirà anche un supporto per scrivere riconoscitori &#8220;spazzino&#8221; (in inglese, <em>packrat</em>) in grado di implementare <em>grammatiche di espressioni analitiche</em> (o <abbr>PEG</abbr>, dall'inglese <em>parsing expression grammars</em>) non ambigue. L'implementazione dei riconoscitori spazzino in Scala 2.8 supporta anche la <em>memoizzazione</em>, che vi aiuta a migliorare le prestazioni, tra gli altri benefici. Se avete bisogno di un riconoscitore veloce, un riconoscitore spazzino vi permetterà di fare maggiori progressi prima che abbiate bisogno di considerare strumenti più specializzati come i generatori automatici di riconoscitori.
+<p>La libreria di Scala 2.8 fornirà anche un supporto per scrivere riconoscitori &#8220;spazzino&#8221; (in inglese, <em>packrat</em>) in grado di implementare <em>grammatiche di espressioni analitiche</em> (o <abbr>PEG</abbr>, dall&#8217;inglese <em>parsing expression grammars</em>) non ambigue. L&#8217;implementazione dei riconoscitori spazzino in Scala 2.8 supporta anche la <em>memoizzazione</em>, che vi aiuta a migliorare le prestazioni, tra gli altri benefici. Se avete bisogno di un riconoscitore veloce, un riconoscitore spazzino vi permetterà di fare maggiori progressi prima che abbiate bisogno di considerare strumenti più specializzati come i generatori automatici di riconoscitori.
 
 <h2 id=_recap_and_what_s_next_3>Riepilogo, e poi?</h2>
 
 </ol>
 
 <p class=v><a rel=prev href=cap-10.html title='indietro a &#8220;Assemblare XML in Scala&#8221;'><span class=u>&#x261C;</span></a> <a rel=next href=cap-12.html title='avanti a &#8220;Il sistema di tipi di Scala&#8221;'><span class=u>&#x261E;</span></a>
-<p class=c>&copy; 2008&ndash;9 O'Reilly Media<br>
+<p class=c>&copy; 2008&ndash;9 O&#8217;Reilly Media<br>
 &copy; 2009&ndash;10 Giulio Piancastelli per la traduzione italiana
 </div>
 
 <p>Scala è un linguaggio staticamente tipato con un sistema di tipi annoverabile tra i più sofisticati, in parte grazie alla combinazione di concetti essenziali provenienti dalla programmazione funzionale e da quella orientata agli oggetti. Il sistema di tipi di Scala cerca di essere logicamente esaustivo, completo e coerente, superando le limitazioni di Java e allo stesso tempo presentando innovazioni mai apparse prima in un linguaggio di programmazione.
 
-<p>Tuttavia, il sistema di tipi può intimidire alla prima occhiata, in particolare chi è abituato a programmare in un linguaggio dinamicamente tipato come Ruby o Python. Per fortuna, l'inferenza di tipo nasconde la maggior parte della complessità in modo che non sia necessario conoscere i particolari, quindi è possibile usare Scala in maniera efficace anche senza padroneggiare il sistema di tipi. I lettori alla prima esperienza con Scala possono decidere di scorrere rapidamente questo capitolo, in modo da sapere almeno dove guardare nell'eventualità che in futuro incontrino problemi relativi ai tipi.
+<p>Tuttavia, il sistema di tipi può intimidire alla prima occhiata, in particolare chi è abituato a programmare in un linguaggio dinamicamente tipato come Ruby o Python. Per fortuna, l&#8217;inferenza di tipo nasconde la maggior parte della complessità in modo che non sia necessario conoscere i particolari, quindi è possibile usare Scala in maniera efficace anche senza padroneggiare il sistema di tipi. I lettori alla prima esperienza con Scala possono decidere di scorrere rapidamente questo capitolo, in modo da sapere almeno dove guardare nell&#8217;eventualità che in futuro incontrino problemi relativi ai tipi.
 
 <p>In ogni caso, maggiore è la conoscenza del sistema di tipi, maggiori saranno le capacità di sfruttarne le caratteristiche nella scrittura di un programma. Questa considerazione è valida soprattutto per gli sviluppatori di librerie, ai quali tornerà utile sapere quando usare i tipi parametrici anziché i tipi astratti, quali parametri di tipo dovrebbero essere covarianti, controvarianti o invarianti in caso di ereditarietà, e così via. In generale, una certa comprensione del sistema di tipi si rivelerà un aiuto prezioso nel capire e correggere gli occasionali errori di compilazione relativi ai tipi e nel dare un senso alle informazioni di tipo incluse nei sorgenti e nella documentazione <em>Scaladoc</em> delle librerie Scala.
 
 <p>Se ignorate il significato di alcuni dei termini usati nei paragrafi precedenti, non preoccupatevi: li spiegheremo, e spiegheremo perché sono utili. Anziché esaminare nei dettagli il sistema di tipi di Scala ci concentreremo sui suoi aspetti pratici, puntando a farvi acquisire la conoscenza delle caratteristiche disponibili e dello scopo per cui sono state progettate, nonché la capacità di leggere e capire le dichiarazioni di tipo.
 
-<p>Metteremo anche in evidenza le somiglianze con il sistema di tipi di Java, che potrebbe essere un punto di riferimento familiare per buona parte dei lettori, in modo che la comprensione delle differenze tra i due sistemi faciliti l'interazione con le librerie di quella piattaforma. Circoscriveremo la discussione evitando di parlare del sistema di tipi di .NET, tranne che per mettere in rilievo alcune discrepanze degne di nota che i programmatori .NET vorranno conoscere.
+<p>Metteremo anche in evidenza le somiglianze con il sistema di tipi di Java, che potrebbe essere un punto di riferimento familiare per buona parte dei lettori, in modo che la comprensione delle differenze tra i due sistemi faciliti l&#8217;interazione con le librerie di quella piattaforma. Circoscriveremo la discussione evitando di parlare del sistema di tipi di .NET, tranne che per mettere in rilievo alcune discrepanze degne di nota che i programmatori .NET vorranno conoscere.
 
 <h2 id=ReflectingOnTypes>La riflessione sui tipi</h2>
 
 
 <p>Si noti che questi metodi sono disponibili solo per i sottotipi di <code>AnyRef</code>.
 
-<p>Il metodo <code>classOf[T]</code> restituisce la rappresentazione di un tipo Scala a tempo di esecuzione, analogamente alla espressione Java <code>T.class</code>. L'uso di <code>classOf[T]</code> si rivela conveniente quando si desidera estrarre informazioni su un tipo a partire dal tipo stesso, mentre <code>getClass</code> è comodo per recuperare le stesse informazioni da un'istanza di quel tipo.
+<p>Il metodo <code>classOf[T]</code> restituisce la rappresentazione di un tipo Scala a tempo di esecuzione, analogamente alla espressione Java <code>T.class</code>. L&#8217;uso di <code>classOf[T]</code> si rivela conveniente quando si desidera estrarre informazioni su un tipo a partire dal tipo stesso, mentre <code>getClass</code> è comodo per recuperare le stesse informazioni da un&#8217;istanza di quel tipo.
 
 <p>Tuttavia <code>classOf[T]</code> e <code>getClass</code> restituiscono valori leggermente differenti, a causa della <em>cancellazione di tipo</em> operata dalla <abbr>JVM</abbr> nel caso di <code>getClass</code>.
 
 
 <p>Scala fornisce anche metodi per verificare che un oggetto corrisponda a un certo tipo e anche per convertire un oggetto in un certo tipo.
 
-<p><code>x.isInstanceOf[T]</code> restituirà <code>true</code> se l'istanza <var>x</var> è di tipo <code>T</code>. Tuttavia, questa verifica è soggetta alla cancellazione di tipo: per esempio, <code>List(3.14159).isInstanceOf[List[String]]</code> restituirà <code>true</code> perché il parametro di tipo di <code>List</code> non viene conservato a livello di bytecode; in questo caso, otterrete comunque un messaggio di avvertimento sull'operazione &#8220;non controllata&#8221; (in inglese, <em>unchecked</em>) da parte del compilatore.
+<p><code>x.isInstanceOf[T]</code> restituirà <code>true</code> se l&#8217;istanza <var>x</var> è di tipo <code>T</code>. Tuttavia, questa verifica è soggetta alla cancellazione di tipo: per esempio, <code>List(3.14159).isInstanceOf[List[String]]</code> restituirà <code>true</code> perché il parametro di tipo di <code>List</code> non viene conservato a livello di bytecode; in questo caso, otterrete comunque un messaggio di avvertimento sull&#8217;operazione &#8220;non controllata&#8221; (in inglese, <em>unchecked</em>) da parte del compilatore.
 
 <p><code>x.asInstanceOf[T]</code> convertirà <var>x</var> nel tipo <code>T</code> o lancerà una <code>ClassCastException</code> se <code>T</code> e il tipo di <var>x</var> sono incompatibili. Ancora una volta è necessario considerare la cancellazione di tipo per i tipi parametrici: infatti, la conversione <code>List(3.14159).asInstanceOf[List[String]]</code> avrà successo.
 
 <p>Si noti che queste due operazioni coinvolgono metodi anziché parole chiave del linguaggio, e i loro nomi sono deliberatamente piuttosto prolissi. Di solito, i controlli sui tipi e le conversioni come queste dovrebbero essere evitate: al posto dei primi è possibile usare il pattern matching; per quanto riguarda le seconde, è consigliabile considerare i motivi che le rendono necessarie e determinare se possono essere eliminate tramite una riorganizzazione del codice.
 
 <blockquote class=note>
-<p><span class=u>&#x261E;</span>Al momento della scrittura, Scala contiene alcune funzionalità sperimentali nella versione 2.8 del package <code>scala.reflect</code>, progettate per semplificare l'ispezione e l'invocazione di codice tramite riflessione rispetto ai metodi Java corrispondenti.
+<p><span class=u>&#x261E;</span>Al momento della scrittura, Scala contiene alcune funzionalità sperimentali nella versione 2.8 del package <code>scala.reflect</code>, progettate per semplificare l&#8217;ispezione e l&#8217;invocazione di codice tramite riflessione rispetto ai metodi Java corrispondenti.
 </blockquote>
 
 <h2 id=ParameterizedTypes>Capire i tipi parametrici</h2>
 
 <h3 id=Manifests>Manifesti</h3>
 
-<p>A partire dalla versione 2.7.2, Scala è dotato di una funzione sperimentale chiamata <em>Manifest</em> che cattura le informazioni di tipo cancellate nel bytecode. Questa funzione non è documentata nelle pagine <em>Scaladoc</em>, ma potete esaminare il codice sorgente del tratto <code>scala.reflect.Manifest</code> per saperne di più. <a href=apa.html#Ortiz2008>[Ortiz2008]</a> analizza i manifesti e ne offre alcuni esempi d'uso.
+<p>A partire dalla versione 2.7.2, Scala è dotato di una funzione sperimentale chiamata <em>Manifest</em> che cattura le informazioni di tipo cancellate nel bytecode. Questa funzione non è documentata nelle pagine <em>Scaladoc</em>, ma potete esaminare il codice sorgente del tratto <code>scala.reflect.Manifest</code> per saperne di più. <a href=apa.html#Ortiz2008>[Ortiz2008]</a> analizza i manifesti e ne offre alcuni esempi d&#8217;uso.
 
-<p>Un <code>Manifest</code> va dichiarato come un argomento implicito di un metodo o di un tipo di cui si vogliono catturare le informazioni di tipo cancellate. A differenza della maggior parte degli argomenti impliciti, l'utente non ha bisogno di implementare un valore o un metodo <code>Manifest</code> che sia visibile nell'ambito in cui viene usato, perché il compilatore ne genera uno automaticamente. Ecco un esempio che illustra alcuni punti di forza e di debolezza dei manifesti.
+<p>Un <code>Manifest</code> va dichiarato come un argomento implicito di un metodo o di un tipo di cui si vogliono catturare le informazioni di tipo cancellate. A differenza della maggior parte degli argomenti impliciti, l&#8217;utente non ha bisogno di implementare un valore o un metodo <code>Manifest</code> che sia visibile nell&#8217;ambito in cui viene usato, perché il compilatore ne genera uno automaticamente. Ecco un esempio che illustra alcuni punti di forza e di debolezza dei manifesti.
 
 <pre><code>// <a href=esempi/cap-12/manifest-script.scala>esempi/cap-12/manifest-script.scala</a>
 
   WhichList(_)
 }</code></pre>
 
-<p><code>WhichList</code> cerca di determinare il tipo della lista passata come argomento sfruttando il valore restituito dal metodo <code>toString</code> del manifesto. Si noti che questo uso del manifesto funziona quando la lista viene costruita all'interno della invocazione di <code>WhichList.apply</code>, ma <em>non</em> funziona quando quel metodo riceve una lista precedentemente costruita. Nel primo caso, il compilatore sfrutta le informazioni di tipo che conosce per costruire il <code>Manifest</code> implicito con il tipo <code>B</code> corretto. Tuttavia, quando il metodo <code>WhichList</code> riceve liste precostruite, le informazioni di tipo cruciali sono già andate perse.
+<p><code>WhichList</code> cerca di determinare il tipo della lista passata come argomento sfruttando il valore restituito dal metodo <code>toString</code> del manifesto. Si noti che questo uso del manifesto funziona quando la lista viene costruita all&#8217;interno della invocazione di <code>WhichList.apply</code>, ma <em>non</em> funziona quando quel metodo riceve una lista precedentemente costruita. Nel primo caso, il compilatore sfrutta le informazioni di tipo che conosce per costruire il <code>Manifest</code> implicito con il tipo <code>B</code> corretto. Tuttavia, quando il metodo <code>WhichList</code> riceve liste precostruite, le informazioni di tipo cruciali sono già andate perse.
 
 <p>Perciò, i manifesti non possono &#8220;riesumare&#8221; le informazioni di tipo dal bytecode, ma possono essere usati per catturare e sfruttare le informazioni di tipo prima che vengano cancellate.
 
 
 <p>Anche i singoli metodi possono essere parametrici. Un buon esempio di metodo parametrico è il metodo <code>apply</code> degli oggetti associati a classi parametriche. Se ricordate, gli oggetti associati sono oggetti singleton con una classe associata. Esiste una sola istanza di un oggetto singleton, come indica il nome, quindi i parametri sul tipo non avrebbero senso.
 
-<p>Consideriamo <code>object List</code>, l'oggetto associato a <code>class List[+A]</code>. Ecco la definizione del metodo <code>apply</code> di <code>object List</code>.
+<p>Consideriamo <code>object List</code>, l&#8217;oggetto associato a <code>class List[+A]</code>. Ecco la definizione del metodo <code>apply</code> di <code>object List</code>.
 
 <pre><code>def apply[A](xs: A*): List[A] = xs.toList</code></pre>
 
 
 <p>La colonna &#8220;Equivalente Java&#8221; è leggermente fuorviante; spiegheremo il perché più avanti, approfondendo il confronto tra Java e Scala.
 
-<p>La classe <code>List</code> è dichiarata come <code>List[+A]</code>, indicando che <code>List[String]</code> è una sottoclasse di <code>List[AnyRef]</code> e quindi che le liste sono covarianti nel parametro di tipo <code>A</code>. Quando un tipo come <code>List</code> ha un solo parametro di tipo covariante, si sente spesso usare l'espressione abbreviata &#8220;le liste sono covarianti&#8221;, così come per i tipi con un singolo parametro di tipo controvariante.
+<p>La classe <code>List</code> è dichiarata come <code>List[+A]</code>, indicando che <code>List[String]</code> è una sottoclasse di <code>List[AnyRef]</code> e quindi che le liste sono covarianti nel parametro di tipo <code>A</code>. Quando un tipo come <code>List</code> ha un solo parametro di tipo covariante, si sente spesso usare l&#8217;espressione abbreviata &#8220;le liste sono covarianti&#8221;, così come per i tipi con un singolo parametro di tipo controvariante.
 
 <p>I tratti <code>FunctionN</code> per <code>N</code> che va da <code>0</code> a <code>22</code> vengono usati da Scala per implementare i valori funzione come veri oggetti. Consideriamo <code>Function1</code> come esempio rappresentativo: è dichiarato come <code>trait Function1[-T, +R]</code>.
 
-<p><code>+R</code> è il tipo di ritorno e presenta l'annotazione covariante <code>+</code>. Il tipo del singolo argomento presenta l'annotazione <em>controvariante</em> <code>-</code>. Per le funzioni con più di un argomento, tutti i tipi degli argomenti presentano l'annotazione controvariante. Quindi, per esempio, usando i nostri tipi <code>T</code>, <code>T<sup>sup</sup></code> e <code>T<sub>sub</sub></code>, la definizione seguente sarebbe legale.
+<p><code>+R</code> è il tipo di ritorno e presenta l&#8217;annotazione covariante <code>+</code>. Il tipo del singolo argomento presenta l&#8217;annotazione <em>controvariante</em> <code>-</code>. Per le funzioni con più di un argomento, tutti i tipi degli argomenti presentano l&#8217;annotazione controvariante. Quindi, per esempio, usando i nostri tipi <code>T</code>, <code>T<sup>sup</sup></code> e <code>T<sub>sub</sub></code>, la definizione seguente sarebbe legale.
 
 <p><code>val f: Function1[T, T] = new Function1[T<sup>sup</sup>, T<sub>sub</sub>] { &hellip; }</code>
 
 <p>Perciò, i tratti funzione sono covarianti nel parametro del tipo di ritorno <code>R</code> e controvarianti nei parametri degli argomenti <code>T<sub>1</sub></code>, <code>T<sub>2</sub></code>, &hellip;, <code>T<sub>N</sub></code>.
 
-<p>Per capire il reale comportamento della varianza, esaminiamo un esempio completo. Se avete già esperienza nella <em>progettazione per contratto</em> <a href=apa.html#DesignByContract>[DesignByContract]</a>, di cui parleremo brevemente nella sezione <a href=cap-13.html#DesignByContractExample>Una progettazione migliore con la progettazione per contratto</a> del capitolo 13, potrebbe esservi d'aiuto ricordarne i principi di funzionamento, che sono molto simili a quelli su cui si basa il meccanismo della varianza. Questo script illustra il comportamento della varianza in caso di ereditarietà.
+<p>Per capire il reale comportamento della varianza, esaminiamo un esempio completo. Se avete già esperienza nella <em>progettazione per contratto</em> <a href=apa.html#DesignByContract>[DesignByContract]</a>, di cui parleremo brevemente nella sezione <a href=cap-13.html#DesignByContractExample>Una progettazione migliore con la progettazione per contratto</a> del capitolo 13, potrebbe esservi d&#8217;aiuto ricordarne i principi di funzionamento, che sono molto simili a quelli su cui si basa il meccanismo della varianza. Questo script illustra il comportamento della varianza in caso di ereditarietà.
 
 <pre><code>// <a href=esempi/cap-12/func-script.scala>esempi/cap-12/func-script.scala</a>
 // Non verrà compilato!
     f         = (c: C)      =&gt; new CSub    // #4
     f         = (c: CSub)   =&gt; new CSuper  // #5: ERRORE!</code></pre>
 
-<p>Lo script non produce alcuna uscita: se provate a eseguirlo, genererà un errore di compilazione relativo all'ultima riga.
+<p>Lo script non produce alcuna uscita: se provate a eseguirlo, genererà un errore di compilazione relativo all&#8217;ultima riga.
 
 <p>Cominciamo definendo una gerarchia molto semplice di tre classi: <code>C</code>, la sua superclasse <code>CSuper</code> e il suo sottotipo <code>CSub</code>. Ognuna di esse definisce un metodo, che sfrutteremo tra breve.
 
 
 <p>Ora assegniamo differenti valori funzione anonimi a <code>f</code>, usando gli spazi per sottolineare le somiglianze e le differenze nel confrontare la dichiarazione originale di <code>f</code> e i riassegnamenti successivi. Stiamo continuando a riassegnare valori a <code>f</code> perché desideriamo semplicemente verificare cosa verrà o non verrà compilato a questo punto. In particolare, desideriamo sapere quali valori funzione possiamo assegnare legalmente a <code>f: (C) =&gt; C</code>.
 
-<p>L'assegnamento sulla riga con il commento <code>#2</code> usa <code>(x:CSuper) =&gt; new CSub</code> come valore funzione. Anche questo è accettabile, perché l'argomento di <code>Function1</code> è <em>controvariante</em>, quindi possiamo sostituirlo con il <em>supertipo</em>, mentre il tipo di ritorno di <code>Function1</code> è <em>covariante</em>, quindi il nostro valore funzione può restituire un'istanza del <em>sottotipo</em>.
+<p>L&#8217;assegnamento sulla riga con il commento <code>#2</code> usa <code>(x:CSuper) =&gt; new CSub</code> come valore funzione. Anche questo è accettabile, perché l&#8217;argomento di <code>Function1</code> è <em>controvariante</em>, quindi possiamo sostituirlo con il <em>supertipo</em>, mentre il tipo di ritorno di <code>Function1</code> è <em>covariante</em>, quindi il nostro valore funzione può restituire un&#8217;istanza del <em>sottotipo</em>.
 
-<p>Anche gli assegnamenti nelle due righe successive sono validi. Sulla terza riga, usiamo <code>CSuper</code> come argomento, che viene accettato come è accaduto nella seconda riga, e restituiamo un'istanza di <code>C</code>, che non crea problemi, proprio come ci aspettiamo. Similmente, sulla quarta riga usiamo <code>C</code> come argomento e <code>CSub</code> come tipo di ritorno, entrambi già convalidati dal loro impiego nelle righe precedenti.
+<p>Anche gli assegnamenti nelle due righe successive sono validi. Sulla terza riga, usiamo <code>CSuper</code> come argomento, che viene accettato come è accaduto nella seconda riga, e restituiamo un&#8217;istanza di <code>C</code>, che non crea problemi, proprio come ci aspettiamo. Similmente, sulla quarta riga usiamo <code>C</code> come argomento e <code>CSub</code> come tipo di ritorno, entrambi già convalidati dal loro impiego nelle righe precedenti.
 
-<p>L'ultima riga, con il commento <code>#5</code>, non viene compilata perché stiamo tentando di usare un argomento covariante in una posizione controvariante, e stiamo anche tentando di usare un valore di ritorno controvariante dove sono permessi solo valori covarianti.
+<p>L&#8217;ultima riga, con il commento <code>#5</code>, non viene compilata perché stiamo tentando di usare un argomento covariante in una posizione controvariante, e stiamo anche tentando di usare un valore di ritorno controvariante dove sono permessi solo valori covarianti.
 
 <p>Per capire qual è il comportamento corretto in questo caso, possiamo ricorrere a un ragionamento in termini di <em>progettazione per contratto</em>. Analizziamo il modo in cui un cliente potrebbe usare alcune di queste definizioni di <code>f</code>.
 
 useF((c: CSuper) =&gt; new CSub)     // #6
 useF((c: CSub)   =&gt; {println(c.msub); new CSuper})   // #7: ERRORE!</code></pre>
 
-<p>Il metodo <code>useF</code> accetta una funzione <code>C =&gt; C</code> come argomento; ora stiamo semplicemente passando letterali funzione anziché assegnarli a <code>f</code>. Il metodo crea un'istanza di <code>C</code> (riga con il commento <code>#1</code>) e la passa alla funzione in ingresso per creare una nuova istanza di <code>C</code> (riga <code>#2</code>) su cui poi usa le operazioni di <code>C</code>, invocando i metodi <code>msuper</code> e <code>m</code> (righe con i commenti <code>#3</code> e <code>#4</code>, rispettivamente).
+<p>Il metodo <code>useF</code> accetta una funzione <code>C =&gt; C</code> come argomento; ora stiamo semplicemente passando letterali funzione anziché assegnarli a <code>f</code>. Il metodo crea un&#8217;istanza di <code>C</code> (riga con il commento <code>#1</code>) e la passa alla funzione in ingresso per creare una nuova istanza di <code>C</code> (riga <code>#2</code>) su cui poi usa le operazioni di <code>C</code>, invocando i metodi <code>msuper</code> e <code>m</code> (righe con i commenti <code>#3</code> e <code>#4</code>, rispettivamente).
 
-<p>Si potrebbe dire che il metodo <code>useF</code> specifica un <em>contratto</em> di comportamento: si aspetta che gli venga passata una funzione capace di accettare un'istanza di <code>C</code> come argomento e di restituire un'altra istanza di <code>C</code>. Perciò, il metodo invocherà la funzione che gli viene passata, passandole un'istanza di <code>C</code>, e si aspetterà di ricevere come valore di ritorno un'istanza di <code>C</code>.
+<p>Si potrebbe dire che il metodo <code>useF</code> specifica un <em>contratto</em> di comportamento: si aspetta che gli venga passata una funzione capace di accettare un&#8217;istanza di <code>C</code> come argomento e di restituire un&#8217;altra istanza di <code>C</code>. Perciò, il metodo invocherà la funzione che gli viene passata, passandole un&#8217;istanza di <code>C</code>, e si aspetterà di ricevere come valore di ritorno un&#8217;istanza di <code>C</code>.
 
-<p>Sulla riga con il commento <code>#5</code>, a <code>useF</code> viene passata una funzione che accetta un'istanza di <code>C</code> e restituisce un'istanza di <code>C</code>. L'istanza di <code>C</code> restituita non avrà problemi a funzionare con le righe <code>#3</code> e <code>#4</code>, per definizione. Non ci sono intoppi.
+<p>Sulla riga con il commento <code>#5</code>, a <code>useF</code> viene passata una funzione che accetta un&#8217;istanza di <code>C</code> e restituisce un&#8217;istanza di <code>C</code>. L&#8217;istanza di <code>C</code> restituita non avrà problemi a funzionare con le righe <code>#3</code> e <code>#4</code>, per definizione. Non ci sono intoppi.
 
-<p>Infine, arriviamo al punto cruciale di questo esempio. Sulla riga <code>#6</code> viene passata una funzione che è &#8220;disposta&#8221; ad accettare un'istanza di <code>CSuper</code> e &#8220;promette&#8221; di restituire un'istanza di <code>CSub</code>, in altre parole una funzione il cui tipo inferito è <code>Function1[CSuper,CSub]</code>. In effetti, questa funzione allarga il ventaglio delle istanze permesse accettando un supertipo. Si noti che <code>useF</code> non le passerà mai un'istanza di <code>CSuper</code>, ma solo un'istanza di <code>C</code>; tuttavia, dato che la funzione accetta un insieme più ampio di valori, opera altrettanto bene anche se le vengono passate solo istanze di <code>C</code>.
+<p>Infine, arriviamo al punto cruciale di questo esempio. Sulla riga <code>#6</code> viene passata una funzione che è &#8220;disposta&#8221; ad accettare un&#8217;istanza di <code>CSuper</code> e &#8220;promette&#8221; di restituire un&#8217;istanza di <code>CSub</code>, in altre parole una funzione il cui tipo inferito è <code>Function1[CSuper,CSub]</code>. In effetti, questa funzione allarga il ventaglio delle istanze permesse accettando un supertipo. Si noti che <code>useF</code> non le passerà mai un&#8217;istanza di <code>CSuper</code>, ma solo un&#8217;istanza di <code>C</code>; tuttavia, dato che la funzione accetta un insieme più ampio di valori, opera altrettanto bene anche se le vengono passate solo istanze di <code>C</code>.
 
-<p>Similmente, &#8220;promettendo&#8221; di restituire un'istanza di <code>CSub</code>, questa funzione anonima restringe i valori possibili restituiti a <code>useF</code>. Ma anche questo è un comportamento ancora valido, perché <code>useF</code> accetterà qualsiasi istanza di <code>C</code> come valore di ritorno e il suo contratto sarà soddisfatto pure ottenendo solo un'istanza di <code>CSub</code>. Le righe <code>#3</code> e <code>#4</code> continueranno a fare il loro dovere.
+<p>Similmente, &#8220;promettendo&#8221; di restituire un&#8217;istanza di <code>CSub</code>, questa funzione anonima restringe i valori possibili restituiti a <code>useF</code>. Ma anche questo è un comportamento ancora valido, perché <code>useF</code> accetterà qualsiasi istanza di <code>C</code> come valore di ritorno e il suo contratto sarà soddisfatto pure ottenendo solo un&#8217;istanza di <code>CSub</code>. Le righe <code>#3</code> e <code>#4</code> continueranno a fare il loro dovere.
 
-<p>Seguendo la stessa linea di ragionamento, è possibile capire perché l'ultima riga dello script, indicata dal commento <code>#7</code>, genera un errore di compilazione. Ora la funzione anonima può solo accettare un'istanza di <code>CSub</code>, ma <code>useF</code> le passerà un'istanza di <code>C</code>: il corpo della funzione anonima invocherebbe il metodo <code>c.msub</code> che non esiste in <code>C</code>. Similmente, la restituzione di un'istanza di <code>CSuper</code> al posto di un'istanza di <code>C</code> provocherebbe un problema nella riga <code>#4</code> in <code>useF</code>, perché <code>CSuper</code> non dispone del metodo <code>m</code>.
+<p>Seguendo la stessa linea di ragionamento, è possibile capire perché l&#8217;ultima riga dello script, indicata dal commento <code>#7</code>, genera un errore di compilazione. Ora la funzione anonima può solo accettare un&#8217;istanza di <code>CSub</code>, ma <code>useF</code> le passerà un&#8217;istanza di <code>C</code>: il corpo della funzione anonima invocherebbe il metodo <code>c.msub</code> che non esiste in <code>C</code>. Similmente, la restituzione di un&#8217;istanza di <code>CSuper</code> al posto di un&#8217;istanza di <code>C</code> provocherebbe un problema nella riga <code>#4</code> in <code>useF</code>, perché <code>CSuper</code> non dispone del metodo <code>m</code>.
 
 <p>Argomentazioni identiche a queste vengono usate per spiegare come i contratti possono cambiare in caso di ereditarietà nella <em>progettazione per contratto</em>.
 
 <p>Si noti che le annotazioni di varianza hanno senso solamente sui parametri di tipo per i tipi parametrici ma non per i metodi parametrici, perché le annotazioni influenzano il comportamento dei sottotipi e i metodi non possono essere estesi, a differenza dei tipi che li contengono.
 
 <blockquote class=note>
-<p><span class=u>&#x261E;</span>L'annotazione di varianza <code>+</code> significa che il tipo parametrico è <em>covariante</em> nel parametro di tipo. L'annotazione di varianza <code>-</code> significa che il tipo parametrico è <em>controvariante</em> nel parametro di tipo. L'assenza di qualsiasi annotazione di varianza significa che il tipo parametrico è <em>invariante</em> nel parametro di tipo.
+<p><span class=u>&#x261E;</span>L&#8217;annotazione di varianza <code>+</code> significa che il tipo parametrico è <em>covariante</em> nel parametro di tipo. L&#8217;annotazione di varianza <code>-</code> significa che il tipo parametrico è <em>controvariante</em> nel parametro di tipo. L&#8217;assenza di qualsiasi annotazione di varianza significa che il tipo parametrico è <em>invariante</em> nel parametro di tipo.
 </blockquote>
 
-<p>Infine, il compilatore controlla l'uso effettuato delle annotazioni di varianza per evitare problemi come quello che abbiamo appena descritto nelle ultime righe degli esempi. Supponete di provare a definire un vostro tipo funzione in questo modo.
+<p>Infine, il compilatore controlla l&#8217;uso effettuato delle annotazioni di varianza per evitare problemi come quello che abbiamo appena descritto nelle ultime righe degli esempi. Supponete di provare a definire un vostro tipo funzione in questo modo.
 
 <pre><code>trait MyFunction2[+T1, +T2, -R] {
   def apply(v1:T1, v2:T2): R = { &hellip; }
 println(new ContainerPlus("Ciao mondo!"))
 println(new ContainerMinus("Ciao mondo!"))</code></pre>
 
-<p>L'esecuzione di questo script provoca i seguenti errori.
+<p>L&#8217;esecuzione di questo script provoca i seguenti errori.
 
 <pre><samp>&hellip; 4: error: covariant type A occurs in contravariant position in type A of parameter of setter value_=
 class ContainerPlus[+A](var value: A)      // ERRORE
 
 <p>Questi errori si possono comprendere ricordando la discussione sulla varianza di tipo in caso di ereditarietà per i tratti <code>FunctionN</code>, dove i tipi degli argomenti della funzione sono <em>controvarianti</em> (cioè, <code>-T1</code>) e il tipo del valore di ritorno è <em>covariante</em> (cioè, <code>+R</code>).
 
-<p>Il problema con un tipo mutabile è che almeno uno dei suoi campi è dotato dell'equivalente delle operazioni di lettura <em>e</em> scrittura, tramite l'accesso diretto o attraverso metodi per impostare e restituire il valore.
+<p>Il problema con un tipo mutabile è che almeno uno dei suoi campi è dotato dell&#8217;equivalente delle operazioni di lettura <em>e</em> scrittura, tramite l&#8217;accesso diretto o attraverso metodi per impostare e restituire il valore.
 
 <p>Il primo errore è dovuto al tentativo di usare un tipo covariante come argomento di un metodo di scrittura, ma dalla discussione sui tipi funzione si è visto che i tipi degli argomenti di un metodo devono essere controvarianti. Un tipo covariante può essere utilizzato per un metodo di lettura.
 
 <p>Similmente, il secondo errore è dovuto al tentativo di usare un tipo controvariante come tipo di ritorno per un metodo di lettura, che deve essere covariante. Un tipo controvariante può essere utilizzato per un metodo di scrittura.
 
-<p>Perciò, il compilatore non ci permetterà di usare un'annotazione di varianza su un tipo usato per un campo mutabile. Per questo motivo, tutti i tipi parametrici mutabili nella libreria Scala sono <em>invarianti</em> nei loro parametri di tipo. Alcuni hanno un tipo immutabile corrispondente che possiede parametri covarianti o controvarianti.
+<p>Perciò, il compilatore non ci permetterà di usare un&#8217;annotazione di varianza su un tipo usato per un campo mutabile. Per questo motivo, tutti i tipi parametrici mutabili nella libreria Scala sono <em>invarianti</em> nei loro parametri di tipo. Alcuni hanno un tipo immutabile corrispondente che possiede parametri covarianti o controvarianti.
 
 <h3 id=VarianceInScalaVsJava>Un confronto tra la varianza in Scala e in Java</h3>
 
-<p>Come è già stato detto, in Scala il comportamento di varianza è definito nel <em>punto di dichiarazione</em>. In Java, al contrario, è definito nel <em>punto di invocazione</em>: è il <em>cliente</em> di un tipo a definire il comportamento di varianza desiderato <a href=apa.html#Naftalin2006>[Naftalin2006]</a>. In altre parole, quando si usa un tipo generico Java e si specifica il parametro di tipo, si indica anche il comportamento di varianza (compresa l'invarianza, che è il comportamento predefinito). Non è possibile specificare il comportamento di varianza nel punto della dichiarazione in Java, sebbene sia consentito usare espressioni simili, che però definiscono i <em>limiti del tipo</em>, come vedremo più avanti.
+<p>Come è già stato detto, in Scala il comportamento di varianza è definito nel <em>punto di dichiarazione</em>. In Java, al contrario, è definito nel <em>punto di invocazione</em>: è il <em>cliente</em> di un tipo a definire il comportamento di varianza desiderato <a href=apa.html#Naftalin2006>[Naftalin2006]</a>. In altre parole, quando si usa un tipo generico Java e si specifica il parametro di tipo, si indica anche il comportamento di varianza (compresa l&#8217;invarianza, che è il comportamento predefinito). Non è possibile specificare il comportamento di varianza nel punto della dichiarazione in Java, sebbene sia consentito usare espressioni simili, che però definiscono i <em>limiti del tipo</em>, come vedremo più avanti.
 
-<p>Nelle specifiche di varianza in Java, compare sempre una wildcard <code>?</code> prima delle parole chiave <code>super</code> o <code>extend</code>, come mostrato nella tabella precedente. Quando abbiamo affermato, dopo la tabella, che la colonna &#8220;Equivalente Java&#8221; era leggermente fuorviante, ci stavamo riferendo alla differenza tra le specifiche nel punto di dichiarazione o nel punto di invocazione. Esiste un'ulteriore differenza tra il comportamento di Scala e quello di Java che illustreremo più avanti nella sezione <a href=#ExistentialTypes>Tipi esistenziali</a>.
+<p>Nelle specifiche di varianza in Java, compare sempre una wildcard <code>?</code> prima delle parole chiave <code>super</code> o <code>extend</code>, come mostrato nella tabella precedente. Quando abbiamo affermato, dopo la tabella, che la colonna &#8220;Equivalente Java&#8221; era leggermente fuorviante, ci stavamo riferendo alla differenza tra le specifiche nel punto di dichiarazione o nel punto di invocazione. Esiste un&#8217;ulteriore differenza tra il comportamento di Scala e quello di Java che illustreremo più avanti nella sezione <a href=#ExistentialTypes>Tipi esistenziali</a>.
 
-<p>Le specifiche di varianza nel punto di invocazione hanno lo svantaggio di obbligare chi usa i generici Java a una comprensione più completa del sistema di tipi rispetto a quanto è necessario per chi usa i tipi parametrici di Scala, che non ha bisogno di indicare questo comportamento nei punti in cui li impiega. I programmatori Scala vengono anche grandemente avvantaggiati dall'inferenza di tipo.
+<p>Le specifiche di varianza nel punto di invocazione hanno lo svantaggio di obbligare chi usa i generici Java a una comprensione più completa del sistema di tipi rispetto a quanto è necessario per chi usa i tipi parametrici di Scala, che non ha bisogno di indicare questo comportamento nei punti in cui li impiega. I programmatori Scala vengono anche grandemente avvantaggiati dall&#8217;inferenza di tipo.
 
 <p>Esaminiamo un esempio Java di una versione semplificata dei tipi Scala <code>Option</code>, <code>Some</code> e <code>None</code>.
 
   }
 }</code></pre>
 
-<p>L'esecuzione di <code>OptionExample</code> tramite il comando <kbd>scala -cp &hellip; variances.OptionExample</kbd> produce il risultato seguente.
+<p>L&#8217;esecuzione di <code>OptionExample</code> tramite il comando <kbd>scala -cp &hellip; variances.OptionExample</kbd> produce il risultato seguente.
 
 <pre><samp>Rettangolo? Option(Rectangle(Point(0.0,0.0),2.0,5.0))
 Cerchio? Option(Circle(Point(0.0,0.0),2.0))
 Triangolo? Option(Triangle(Point(0.0,0.0),Point(2.0,0.0),Point(0.0,2.0)))
 Sconosciuto? None</samp></pre>
 
-<p>Tra le altre cose, questo esempio illustra anche l'interoperabilità tra Scala e Java, di cui riparleremo nella sezione <a href=cap-14.html#JavaInterop>Interoperabilità con Java</a> del capitolo 14.
+<p>Tra le altre cose, questo esempio illustra anche l&#8217;interoperabilità tra Scala e Java, di cui riparleremo nella sezione <a href=cap-14.html#JavaInterop>Interoperabilità con Java</a> del capitolo 14.
 
 <p><code>OptionExample.main</code> invoca il metodo factory statico <code>makeShape</code>, i cui argomenti sono il nome di una forma geometrica e una lista a lunghezza variabile di parametri da passare ai costruttori di <code>Shape</code>.
 
-<p>Si noti che <code>makeShape</code> restituisce <code>Option&lt;? extends Shape&gt;</code> e che, quando <code>Shape</code> viene istanziata, <code>makeShape</code> restituisce un'istanza di <code>Some</code> parametrizzata con il sottotipo di <code>Shape</code> che racchiude. Se il metodo factory riceve un nome di forma geometrica sconosciuto, allora restituisce un'istanza di <code>None&lt;Shape&gt;</code>. Qui è necessario parametrizzare un'istanza di <code>None</code> con <code>Shape</code>, laddove Scala, che definisce un sottotipo di <em>tutti</em> i tipi, chiamato <code>Nothing</code>, può permettersi di definire <code>None</code> come <code>case object None extends Option[Nothing]</code>.
+<p>Si noti che <code>makeShape</code> restituisce <code>Option&lt;? extends Shape&gt;</code> e che, quando <code>Shape</code> viene istanziata, <code>makeShape</code> restituisce un&#8217;istanza di <code>Some</code> parametrizzata con il sottotipo di <code>Shape</code> che racchiude. Se il metodo factory riceve un nome di forma geometrica sconosciuto, allora restituisce un&#8217;istanza di <code>None&lt;Shape&gt;</code>. Qui è necessario parametrizzare un&#8217;istanza di <code>None</code> con <code>Shape</code>, laddove Scala, che definisce un sottotipo di <em>tutti</em> i tipi, chiamato <code>Nothing</code>, può permettersi di definire <code>None</code> come <code>case object None extends Option[Nothing]</code>.
 
-<p>Il sistema di tipi di Java non offre alcun idioma per implementare l'equivalente di <code>None</code> in modo simile. La possibilità di definire <code>None</code> come oggetto singleton ha un certo numero di vantaggi, compresa una maggior efficienza, perché evita la creazione di una moltitudine di piccoli oggetti, e un comportamento non ambiguo di <code>equals</code>, perché rende superfluo definire la semantica di uguaglianza tra diverse istanziazioni del tipo Java <code>None&lt;?&gt;</code>, per esempio per confrontare <code>None&lt;String&gt;</code> e <code>None&lt;Shape&gt;</code>.
+<p>Il sistema di tipi di Java non offre alcun idioma per implementare l&#8217;equivalente di <code>None</code> in modo simile. La possibilità di definire <code>None</code> come oggetto singleton ha un certo numero di vantaggi, compresa una maggior efficienza, perché evita la creazione di una moltitudine di piccoli oggetti, e un comportamento non ambiguo di <code>equals</code>, perché rende superfluo definire la semantica di uguaglianza tra diverse istanziazioni del tipo Java <code>None&lt;?&gt;</code>, per esempio per confrontare <code>None&lt;String&gt;</code> e <code>None&lt;Shape&gt;</code>.
 
 <p>Infine, si noti che <code>OptionExample</code>, in quanto cliente di <code>Option</code>, deve specificare la varianza di tipo <code>Option&lt;? extends Shape&gt;</code> in diversi punti. In Scala, invece, il cliente non deve assumersi questo onere.
 
 <h3 id=ImplementationNotes>Note di implementazione</h3>
 
-<p>L'implementazione dei tipi e dei metodi parametrici merita alcune considerazioni. Le diverse implementazioni sono generate quando il file sorgente che contiene le definizioni viene compilato. Per ogni parametro di tipo, l'implementazione presume che possano essere specificati i sottotipi di <code>Any</code> (nei generici Java viene usato <code>Object</code>). Questi aspetti hanno implicazioni sulle prestazioni di cui riparleremo esaminando l'annotazione <code>@specialized</code> nella sezione <a href=cap-13.html#Annotations>Annotazioni</a> del capitolo 13.
+<p>L&#8217;implementazione dei tipi e dei metodi parametrici merita alcune considerazioni. Le diverse implementazioni sono generate quando il file sorgente che contiene le definizioni viene compilato. Per ogni parametro di tipo, l&#8217;implementazione presume che possano essere specificati i sottotipi di <code>Any</code> (nei generici Java viene usato <code>Object</code>). Questi aspetti hanno implicazioni sulle prestazioni di cui riparleremo esaminando l&#8217;annotazione <code>@specialized</code> nella sezione <a href=cap-13.html#Annotations>Annotazioni</a> del capitolo 13.
 
 <h2 id=TypeBounds>Limiti sui tipi</h2>
 
 
 <h3 id=UpperTypeBounds>Limiti superiori sui tipi</h3>
 
-<p>Considerate i metodi <code>apply</code> sovraccaricati di <code>object.scala.Array</code> usati per creare nuovi array. Ne esistono implementazioni ottimizzate per ogni tipo derivato da <code>AnyVal</code>, ma esiste un'altra implementazione di <code>apply</code> parametrizzata per qualsiasi sottotipo di <code>AnyRef</code>. Ecco come si presenta questa implementazione in Scala 2.7.5.
+<p>Considerate i metodi <code>apply</code> sovraccaricati di <code>object.scala.Array</code> usati per creare nuovi array. Ne esistono implementazioni ottimizzate per ogni tipo derivato da <code>AnyVal</code>, ma esiste un&#8217;altra implementazione di <code>apply</code> parametrizzata per qualsiasi sottotipo di <code>AnyRef</code>. Ecco come si presenta questa implementazione in Scala 2.7.5.
 
 <pre><code>object Array {
   &hellip;
   &hellip;
 }</code></pre>
 
-<p>Il parametro di tipo <code>A &lt;: AnyRef</code> significa &#8220;qualsiasi tipo <code>A</code> che sia un <em>sottotipo</em> di <code>AnyRef</code>&#8221;. Si noti che un tipo è sempre sottotipo e supertipo di se stesso, quindi <code>A</code> potrebbe anche essere uguale ad <code>AnyRef</code>. L'operatore <code>&lt;:</code> indica che il tipo alla sua sinistra deve essere derivato dal tipo alla sua destra, o che i due tipi devono essere uguali. Come abbiamo detto nella sezione <a href=cap-2.html#ReservedWords>Parole riservate</a> del capitolo 2, in realtà questo operatore è una parola riservata del linguaggio.
+<p>Il parametro di tipo <code>A &lt;: AnyRef</code> significa &#8220;qualsiasi tipo <code>A</code> che sia un <em>sottotipo</em> di <code>AnyRef</code>&#8221;. Si noti che un tipo è sempre sottotipo e supertipo di se stesso, quindi <code>A</code> potrebbe anche essere uguale ad <code>AnyRef</code>. L&#8217;operatore <code>&lt;:</code> indica che il tipo alla sua sinistra deve essere derivato dal tipo alla sua destra, o che i due tipi devono essere uguali. Come abbiamo detto nella sezione <a href=cap-2.html#ReservedWords>Parole riservate</a> del capitolo 2, in realtà questo operatore è una parola riservata del linguaggio.
 
 <p>Questi limiti sono chiamati <em>limiti superiori sul tipo</em>, seguendo la convenzione <em>de facto</em> per cui i diagrammi delle gerarchie di tipi collocano i sottotipi al di sotto dei loro supertipi. Abbiamo seguito questa convenzione nel diagramma mostrato nella sezione <a href=cap-7.html#ScalaTypeHierarchy>La gerarchia di tipi di Scala</a> del capitolo 7.
 
 
 <pre><samp>List(3.14, Scala, Java, Ruby, C#, C++, Python)</samp></pre>
 
-<p>La nuova lista è di tipo <code>List[Any]</code>, dato che <code>Any</code> è il supertipo comune più vicino di <code>String</code> e <code>Double</code>. La lista di partenza era una lista di stringhe, con <code>A</code> uguale a <code>String</code>; in seguito all'aggiunta di un numero di tipo <code>Double</code> in testa alla lista, il compilatore ha inferito <code>Any</code> come valore di <code>B</code>, cioè il supertipo comune più vicino (e, in realtà, l'unico).
+<p>La nuova lista è di tipo <code>List[Any]</code>, dato che <code>Any</code> è il supertipo comune più vicino di <code>String</code> e <code>Double</code>. La lista di partenza era una lista di stringhe, con <code>A</code> uguale a <code>String</code>; in seguito all&#8217;aggiunta di un numero di tipo <code>Double</code> in testa alla lista, il compilatore ha inferito <code>Any</code> come valore di <code>B</code>, cioè il supertipo comune più vicino (e, in realtà, l&#8217;unico).
 
 <blockquote class=note>
-<p><span class=u>&#x261E;</span>La firma di tipo <code>B &gt;: A</code> dice che <code>B</code> deve essere un <em>supertipo</em> di <code>A</code>. Non esiste caso analogo in Java: l'espressione <code>B super A</code> non è valida.
+<p><span class=u>&#x261E;</span>La firma di tipo <code>B &gt;: A</code> dice che <code>B</code> deve essere un <em>supertipo</em> di <code>A</code>. Non esiste caso analogo in Java: l&#8217;espressione <code>B super A</code> non è valida.
 </blockquote>
 
-<h3 id=ACloserLookAtLists>Un'occhiata ravvicinata alle liste</h3>
+<h3 id=ACloserLookAtLists>Un&#8217;occhiata ravvicinata alle liste</h3>
 
-<p>L'implementazione della classe <code>List</code> nella libreria Scala merita di essere analizzata nel dettaglio, dato che combina tutte le caratteristiche appena viste e illustra diversi idiomi utili per realizzare strutture dati immutabili in stile funzionale pienamente type-safe e comunque flessibili. Non mostreremo l'implementazione completa, omettendo <code>object List</code>, numerosi metodi della classe <code>List</code> e i commenti usati per generare la documentazione <em>Scaladoc</em>, ma incoraggiamo il lettore a esaminarla per proprio conto, scaricando la distribuzione del codice sorgente dal sito web del linguaggio <a href=apa.html#Scala>[Scala]</a> oppure visitando la pagina <em>Scaladoc</em> di <code>List</code>. Per evitare confusione con <code>scala.List</code>, useremo nomi diversi per la classe (che chiameremo <code>AbbrevList</code>) e per il package.
+<p>L&#8217;implementazione della classe <code>List</code> nella libreria Scala merita di essere analizzata nel dettaglio, dato che combina tutte le caratteristiche appena viste e illustra diversi idiomi utili per realizzare strutture dati immutabili in stile funzionale pienamente type-safe e comunque flessibili. Non mostreremo l&#8217;implementazione completa, omettendo <code>object List</code>, numerosi metodi della classe <code>List</code> e i commenti usati per generare la documentazione <em>Scaladoc</em>, ma incoraggiamo il lettore a esaminarla per proprio conto, scaricando la distribuzione del codice sorgente dal sito web del linguaggio <a href=apa.html#Scala>[Scala]</a> oppure visitando la pagina <em>Scaladoc</em> di <code>List</code>. Per evitare confusione con <code>scala.List</code>, useremo nomi diversi per la classe (che chiameremo <code>AbbrevList</code>) e per il package.
 
 <pre><code>// <a href=esempi/cap-12/abbrev-list.scala>esempi/cap-12/abbrev-list.scala</a>
 // Adattato da scala/List.scala nella distribuzione di Scala 2.7.5
   def tail : AbbrevList[B] = tl
 }</code></pre>
 
-<p>Si noti che, sebbene <code>AbbrevList</code> sia immutabile, l'implementazione interna usa variabili mutabili, per esempio nel metodo <code>foreach</code>.
+<p>Si noti che, sebbene <code>AbbrevList</code> sia immutabile, l&#8217;implementazione interna usa variabili mutabili, per esempio nel metodo <code>foreach</code>.
 
-<p>Il package contiene le definizioni di tre tipi che formano una gerarchia sigillata. Il primo è <code>AbbrevList</code> (l'analogo di <code>List</code>), un tratto astratto che dichiara i tre metodi astratti <code>isEmpty</code>, <code>head</code> e <code>tail</code> e definisce anche l'operatore <code>::</code> e un metodo <code>foreach</code>. Sarebbe possibile implementare tutti gli altri metodi di <code>List</code> a partire da questi metodi, sebbene alcuni (come <code>List.length</code>) siano realizzati in maniera differente per ragioni di efficienza.
+<p>Il package contiene le definizioni di tre tipi che formano una gerarchia sigillata. Il primo è <code>AbbrevList</code> (l&#8217;analogo di <code>List</code>), un tratto astratto che dichiara i tre metodi astratti <code>isEmpty</code>, <code>head</code> e <code>tail</code> e definisce anche l&#8217;operatore <code>::</code> e un metodo <code>foreach</code>. Sarebbe possibile implementare tutti gli altri metodi di <code>List</code> a partire da questi metodi, sebbene alcuni (come <code>List.length</code>) siano realizzati in maniera differente per ragioni di efficienza.
 
-<p><code>AbbrevNil</code>, l'analogo di <code>Nil</code>, è un <code>object case</code> che estende <code>AbbrevList[Nothing]</code> restituendo <code>true</code> da <code>isEmpty</code> e lanciando un'eccezione dai metodi <code>head</code> e <code>tail</code>. Dato che <code>AbbrevNil</code> (come <code>Nil</code>) essenzialmente non ha stato né comportamento, implementarlo sotto forma di un oggetto anziché di una classe elimina le copie non necessarie, rende <code>equals</code> veloce e semplice, <i class=baa>&amp;</i>c.
+<p><code>AbbrevNil</code>, l&#8217;analogo di <code>Nil</code>, è un <code>object case</code> che estende <code>AbbrevList[Nothing]</code> restituendo <code>true</code> da <code>isEmpty</code> e lanciando un&#8217;eccezione dai metodi <code>head</code> e <code>tail</code>. Dato che <code>AbbrevNil</code> (come <code>Nil</code>) essenzialmente non ha stato né comportamento, implementarlo sotto forma di un oggetto anziché di una classe elimina le copie non necessarie, rende <code>equals</code> veloce e semplice, <i class=baa>&amp;</i>c.
 
-<p>La classe <code>::</code>, dichiarata <code>final</code>, è l'analogo di <code>scala.::</code> derivata da <code>List</code>. I suoi argomenti sono l'elemento che diventerà la testa della nuova lista e una lista esistente che diventerà la coda della nuova lista. Si noti che questi valori vengono memorizzati direttamente come campi. I metodi <code>head</code> e <code>tail</code> definiti in <code>AbbrevList</code> sono semplicemente metodi di lettura per questi campi. Non sono richieste altre strutture dati per rappresentare la lista.
+<p>La classe <code>::</code>, dichiarata <code>final</code>, è l&#8217;analogo di <code>scala.::</code> derivata da <code>List</code>. I suoi argomenti sono l&#8217;elemento che diventerà la testa della nuova lista e una lista esistente che diventerà la coda della nuova lista. Si noti che questi valori vengono memorizzati direttamente come campi. I metodi <code>head</code> e <code>tail</code> definiti in <code>AbbrevList</code> sono semplicemente metodi di lettura per questi campi. Non sono richieste altre strutture dati per rappresentare la lista.
 
-<p>Questo è il motivo per cui aggiungere in testa un nuovo elemento per creare una nuova lista è un'operazione di complessità temporale O(1). La classe <code>List</code> possiede anche un metodo <code>+</code> deprecato che crea una nuova lista aggiungendo un elemento in coda a una lista esistente: questa operazione è di complessità O(N), dove N è la lunghezza della lista.
+<p>Questo è il motivo per cui aggiungere in testa un nuovo elemento per creare una nuova lista è un&#8217;operazione di complessità temporale O(1). La classe <code>List</code> possiede anche un metodo <code>+</code> deprecato che crea una nuova lista aggiungendo un elemento in coda a una lista esistente: questa operazione è di complessità O(N), dove N è la lunghezza della lista.
 
-<p>Man mano che vengono costruite nuove liste aggiungendo elementi in testa ad altre liste, si forma una gerarchia annidata di istanze di <code>::</code>. Dato che le liste sono immutabili, non è necessario premunirsi contro l'alterazione accidentale di questa catena nel caso in cui una delle istanze di <code>::</code> venisse modificata in qualche modo.
+<p>Man mano che vengono costruite nuove liste aggiungendo elementi in testa ad altre liste, si forma una gerarchia annidata di istanze di <code>::</code>. Dato che le liste sono immutabili, non è necessario premunirsi contro l&#8217;alterazione accidentale di questa catena nel caso in cui una delle istanze di <code>::</code> venisse modificata in qualche modo.
 
 <p>&Egrave; possibile vedere questa struttura annidata stampando una lista tramite il metodo <code>toString</code> che viene generato automaticamente a causa della parola chiave <code>case</code>. Ecco una sessione <kbd>scala</kbd> di esempio.
 
 scala&gt; 1 :: 2 :: 3 :: AbbrevNil
 res1: bounds.abbrevlist.AbbrevList[Int] = ::(1,::(2,::(3,AbbrevNil)))</samp></pre>
 
-<p>Si noti il risultato sull'ultima riga, che mostra gli elementi <code>(head,tail)</code> annidati.
+<p>Si noti il risultato sull&#8217;ultima riga, che mostra gli elementi <code>(head,tail)</code> annidati.
 
 <p>Si veda <a class=url href="http://www.scala-lang.org/node/129">http://www.scala-lang.org/node/129</a> per un altro esempio che definisce in modo simile una struttura dati a pila.
 
 
 <p>Abbiamo visto molti casi in cui un metodo implicito viene usato per una conversione di tipo, per esempio allo scopo di far sembrare che si siano aggiunti nuovi metodi a un tipo esistente, come nel pattern cosiddetto &#8220;Decora la mia libreria&#8221; ampiamente sfruttato nel capitolo 11. Per effettuare una conversione si possono anche usare valori funzione accompagnati dalla parola chiave <code>implicit</code>. Vedremo un esempio di entrambe le soluzioni tra breve.
 
-<p>Una <em>vista</em> è un valore implicito di tipo funzione che converte un tipo <code>A</code> in un tipo <code>B</code>. La funzione è di tipo <code>A =&gt; B</code> oppure <code>(=&gt; A) =&gt; B</code> (dove <code>(=&gt; A)</code> è un <em>parametro con nome</em>). Si può usare come vista un metodo implicito con la stessa firma visibile nell'ambito corrente, cioè un metodo implicito importato da un <code>object</code>. Il termine <em>vista</em> esprime l'idea che da un tipo (<code>A</code>) sia possibile vedere un altro tipo (<code>B</code>).
+<p>Una <em>vista</em> è un valore implicito di tipo funzione che converte un tipo <code>A</code> in un tipo <code>B</code>. La funzione è di tipo <code>A =&gt; B</code> oppure <code>(=&gt; A) =&gt; B</code> (dove <code>(=&gt; A)</code> è un <em>parametro con nome</em>). Si può usare come vista un metodo implicito con la stessa firma visibile nell&#8217;ambito corrente, cioè un metodo implicito importato da un <code>object</code>. Il termine <em>vista</em> esprime l&#8217;idea che da un tipo (<code>A</code>) sia possibile vedere un altro tipo (<code>B</code>).
 
 <p>Una vista viene applicata in due circostanze.
 
 <ol>
-<li>Quando un tipo <code>A</code> viene usato in un contesto dove è richiesto un altro tipo <code>B</code> e l'ambito di visibilità contiene una vista in grado di convertire <code>A</code> in <code>B</code>.
-<li>Quando si fa riferimento a un membro inesistente <code>m</code> di un tipo <code>A</code> ma l'ambito di visibilità contiene una vista in grado di convertire <code>A</code> in un tipo <code>B</code> dotato del membro <code>m</code>.
+<li>Quando un tipo <code>A</code> viene usato in un contesto dove è richiesto un altro tipo <code>B</code> e l&#8217;ambito di visibilità contiene una vista in grado di convertire <code>A</code> in <code>B</code>.
+<li>Quando si fa riferimento a un membro inesistente <code>m</code> di un tipo <code>A</code> ma l&#8217;ambito di visibilità contiene una vista in grado di convertire <code>A</code> in un tipo <code>B</code> dotato del membro <code>m</code>.
 </ol>
 
-<p>Un esempio comune della seconda circostanza è la sintassi di inizializzazione <code>x -&gt; y</code> delle mappe, che innesca l'invocazione di <code>Predef.anyToArrowAssoc(x)</code> come abbiamo detto nella sezione <a href=cap-7.html#PredefObject>L'oggetto <code>Predef</code></a> del capitolo 7.
+<p>Un esempio comune della seconda circostanza è la sintassi di inizializzazione <code>x -&gt; y</code> delle mappe, che innesca l&#8217;invocazione di <code>Predef.anyToArrowAssoc(x)</code> come abbiamo detto nella sezione <a href=cap-7.html#PredefObject>L&#8217;oggetto <code>Predef</code></a> del capitolo 7.
 
-<p>Come esempio della prima circostanza, si possono considerare le viste definite da <code>Predef</code> per convertire i tipi <code>AnyVal</code> tra loro e per convertire un tipo <code>AnyVal</code> nel tipo corrispondente del package <code>java.lang</code>. Per esempio, <code>double2Double</code> converte un numero <code>scala.Double</code> in un'istanza di <code>java.lang.Double</code>.
+<p>Come esempio della prima circostanza, si possono considerare le viste definite da <code>Predef</code> per convertire i tipi <code>AnyVal</code> tra loro e per convertire un tipo <code>AnyVal</code> nel tipo corrispondente del package <code>java.lang</code>. Per esempio, <code>double2Double</code> converte un numero <code>scala.Double</code> in un&#8217;istanza di <code>java.lang.Double</code>.
 
 <p>Un <em>limite di vista</em> in una dichiarazione di tipo viene indicato con la parola chiave <code>&lt;%</code>, per esempio <code>A &lt;% B</code>. Il limite consente di usare come valore di <code>A</code> qualsiasi tipo che possa essere convertito in <code>B</code> usando una vista.
 
 
 <p>Si noti che abbiamo una lista di parametri aggiuntiva anziché un parametro aggiuntivo nella lista di parametri esistente.
 
-<p>Questa trasformazione ha l'effetto voluto perché l'argomento implicito <code>viewAB</code>, posto che l'ambito di visibilità contenga una vista del tipo corretto che lo soddisfi, verrà invocato all'interno di <code>m</code> per convertire tutte le istanze di <code>A</code> in istanze di <code>B</code> ove sia necessario. &Egrave; anche possibile passare esplicitamente una funzione con la firma corretta in una seconda lista di argomenti quando si invoca <code>m</code>, sebbene in alcune situazioni particolari, che descriveremo dopo il nostro prossimo esempio, questo modo di operare non funzioni.
+<p>Questa trasformazione ha l&#8217;effetto voluto perché l&#8217;argomento implicito <code>viewAB</code>, posto che l&#8217;ambito di visibilità contenga una vista del tipo corretto che lo soddisfi, verrà invocato all&#8217;interno di <code>m</code> per convertire tutte le istanze di <code>A</code> in istanze di <code>B</code> ove sia necessario. &Egrave; anche possibile passare esplicitamente una funzione con la firma corretta in una seconda lista di argomenti quando si invoca <code>m</code>, sebbene in alcune situazioni particolari, che descriveremo dopo il nostro prossimo esempio, questo modo di operare non funzioni.
 
 <p>Per i limiti di vista sui tipi, la lista di parametri contenente la vista implicita viene aggiunta al costruttore principale.
 
 <p><span class=u>&#x261E;</span>I tratti non possono avere limiti di vista per i loro parametri di tipo, poiché i loro costruttori non possono accettare argomenti.
 </blockquote>
 
-<p>Per concretizzare quanto è stato detto in un esempio pratico, useremo i limiti di vista per implementare una classe <code>LinkedList</code> dove la lista sia formata da nodi e ogni istanza di <code>Node</code> sia dotata di un campo <code>payload</code> che rappresenta il valore dell'elemento nella lista e di un riferimento all'istanza di <code>Node</code> successiva. Per prima cosa, ecco la gerarchia di nodi.
+<p>Per concretizzare quanto è stato detto in un esempio pratico, useremo i limiti di vista per implementare una classe <code>LinkedList</code> dove la lista sia formata da nodi e ogni istanza di <code>Node</code> sia dotata di un campo <code>payload</code> che rappresenta il valore dell&#8217;elemento nella lista e di un riferimento all&#8217;istanza di <code>Node</code> successiva. Per prima cosa, ecco la gerarchia di nodi.
 
 <pre><code>// <a href=esempi/cap-12/node.scala>esempi/cap-12/node.scala</a>
 
   override def toString = "*"
 }</code></pre>
 
-<p>Questa gerarchia di tipi è modellata sulla falsariga di <code>List</code> e <code>AbbrevList</code>. Il tipo <code>::</code> rappresenta i nodi intermedi e <code>NilNode</code> è l'analogo di <code>Nil</code> per <code>List</code>. Il metodo <code>toString</code> è stato ridefinito per fornire una rappresentazione conveniente dei nodi, che esamineremo tra breve.
+<p>Questa gerarchia di tipi è modellata sulla falsariga di <code>List</code> e <code>AbbrevList</code>. Il tipo <code>::</code> rappresenta i nodi intermedi e <code>NilNode</code> è l&#8217;analogo di <code>Nil</code> per <code>List</code>. Il metodo <code>toString</code> è stato ridefinito per fornire una rappresentazione conveniente dei nodi, che esamineremo tra breve.
 
 <p>Lo script seguente definisce un tipo <code>LinkedList</code> che usa istanze di <code>Node</code>.
 
 
 <p>In questo caso, lo script verrebbe eseguito allo stesso modo, a parte il fatto che alcune liste temporanee userebbero <code>Node[Any]</code> anziché <code>Node[Int]</code>.
 
-<p>La dichiarazione di <code>LinkedList</code> definisce un limite di vista su <code>A</code> e accetta come singolo argomento l'istanza di <code>Node</code> che fa da testa alla lista (che potrebbe essere la testa di una catena di nodi).
+<p>La dichiarazione di <code>LinkedList</code> definisce un limite di vista su <code>A</code> e accetta come singolo argomento l&#8217;istanza di <code>Node</code> che fa da testa alla lista (che potrebbe essere la testa di una catena di nodi).
 
 <pre><code>case class LinkedList[A &lt;% Node[A]](val head: Node[A]) { &hellip; }</code></pre>
 
-<p>Come si vede più avanti nello script, anche se il costruttore richiede un argomento di tipo <code>Node[A]</code>, è possibile passargli un'istanza di <code>A</code> e aspettarsi l'invocazione della vista implicita <code>any2Node</code>. Il vantaggio di questo approccio è che il cliente non deve mai preoccuparsi di costruire opportunamente le istanze di <code>Node</code> perché il meccanismo gestisce questo processo in maniera automatica.
+<p>Come si vede più avanti nello script, anche se il costruttore richiede un argomento di tipo <code>Node[A]</code>, è possibile passargli un&#8217;istanza di <code>A</code> e aspettarsi l&#8217;invocazione della vista implicita <code>any2Node</code>. Il vantaggio di questo approccio è che il cliente non deve mai preoccuparsi di costruire opportunamente le istanze di <code>Node</code> perché il meccanismo gestisce questo processo in maniera automatica.
 
 <p>La classe è anche dotata di un operatore <code>::</code>.
 
 <pre><code>def ::[B &gt;: A &lt;% Node[B]](x: Node[B]) = &hellip;</code></pre>
 
-<p>Il parametro di tipo significa che &#8220;<code>B</code> è limitato inferiormente da (cioè è un supertipo di) <code>A</code> e ha un limite di vista uguale a <code>B &lt;% Node[B]</code>.&#8221; Come abbiamo visto per <code>List</code> e <code>AbbrevList</code>, il limite inferiore consente di aggiungere in testa alla lista elementi di tipi differenti rispetto al tipo <code>A</code> originale. Il compilatore aggiungerà a questo metodo un argomento implicito per la vista, ma il nostro metodo implicito parametrico <code>any2Node</code> verrà usato anche per quell'argomento.
+<p>Il parametro di tipo significa che &#8220;<code>B</code> è limitato inferiormente da (cioè è un supertipo di) <code>A</code> e ha un limite di vista uguale a <code>B &lt;% Node[B]</code>.&#8221; Come abbiamo visto per <code>List</code> e <code>AbbrevList</code>, il limite inferiore consente di aggiungere in testa alla lista elementi di tipi differenti rispetto al tipo <code>A</code> originale. Il compilatore aggiungerà a questo metodo un argomento implicito per la vista, ma il nostro metodo implicito parametrico <code>any2Node</code> verrà usato anche per quell&#8217;argomento.
 
-<p>In precedenza abbiamo affermato che, se l'ambito corrente non contiene una vista adatta, è possibile passare esplicitamente un convertitore &#8220;non implicito&#8221; in una seconda lista di argomenti. Nel nostro esempio, in realtà, questo espediente non funzionerebbe, perché il costruttore e il metodo <code>::</code> di <code>LinkedList</code> accettano argomenti di tipo <code>Node[A]</code>, ma noi li invochiamo con istanze di <code>Int</code> e <code>String</code>. Per poter passare manualmente il convertitore dovremmo invocare entrambi usando argomenti di tipo <code>Node[Int]</code> e <code>Node[String]</code>, e l'invocazione di <code>::</code> risulterebbe anche piuttosto inelegante, come in <code>val list2 = list1.::(2)(convertitore)</code>.
+<p>In precedenza abbiamo affermato che, se l&#8217;ambito corrente non contiene una vista adatta, è possibile passare esplicitamente un convertitore &#8220;non implicito&#8221; in una seconda lista di argomenti. Nel nostro esempio, in realtà, questo espediente non funzionerebbe, perché il costruttore e il metodo <code>::</code> di <code>LinkedList</code> accettano argomenti di tipo <code>Node[A]</code>, ma noi li invochiamo con istanze di <code>Int</code> e <code>String</code>. Per poter passare manualmente il convertitore dovremmo invocare entrambi usando argomenti di tipo <code>Node[Int]</code> e <code>Node[String]</code>, e l&#8217;invocazione di <code>::</code> risulterebbe anche piuttosto inelegante, come in <code>val list2 = list1.::(2)(convertitore)</code>.
 
-<p>Si noti la particolare sintassi usata per il parametro di tipo, che a prima vista potrebbe creare confusione. Leggendo <code>B &gt;: A &lt;% Node[B]</code> si potrebbe essere tentati di assumere che, in questa espressione, l'operatore <code>&lt;%</code> vada applicato ad <code>A</code>, ma in realtà deve essere applicato a <code>B</code>. La grammatica per i parametri di tipo, compresi i limiti di vista, è la seguente <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a>.
+<p>Si noti la particolare sintassi usata per il parametro di tipo, che a prima vista potrebbe creare confusione. Leggendo <code>B &gt;: A &lt;% Node[B]</code> si potrebbe essere tentati di assumere che, in questa espressione, l&#8217;operatore <code>&lt;%</code> vada applicato ad <code>A</code>, ma in realtà deve essere applicato a <code>B</code>. La grammatica per i parametri di tipo, compresi i limiti di vista, è la seguente <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a>.
 
 <pre><code>TypeParam ::= (id | &#8216;_&#8217;) [TypeParamClause] [&#8216;&gt;:&#8217; Type] [&#8216;&lt;:&#8217; Type] [&#8216;&lt;%&#8217; Type]
 TypeParamClause ::= &#8216;[&#8217; VariantTypeParam {&#8216;,&#8217; VariantTypeParam} &#8216;]&#8217;
 
 <p>Come vedete, è possibile costruire espressioni per rappresentare tipi gerarchici molto complessi. Nel metodo <code>::</code> definito per <code>LinkedList</code>, <code>id</code> è <code>B</code>, <code>TypeParamClause</code> è vuota e sulla destra abbiamo le espressioni <code>&gt;: A</code> e <code>&lt;% Node[B]</code>. Ancora una volta, tutte le espressioni dei limiti si applicano al primo <code>id</code> (cioè <code>B</code>) o alla variabile indicata dal trattino basso <code>_</code> usato per i <em>tipi esistenziali</em>, di cui parleremo più avanti in una sezione a loro dedicata.
 
-<p>Infine, in fondo allo script creiamo un'istanza di <code>LinkedList</code> e vi aggiungiamo in testa alcuni valori per creare nuove liste che poi verranno stampate.
+<p>Infine, in fondo allo script creiamo un&#8217;istanza di <code>LinkedList</code> e vi aggiungiamo in testa alcuni valori per creare nuove liste che poi verranno stampate.
 
 <pre><samp>1 :: *
 2 :: 1 :: *
 3 :: 2 :: 1 :: *
 QUATTRO! :: 3 :: 2 :: 1 :: *</samp></pre>
 
-<p>Per ricapitolare, i limiti di vista ci permettono di lavorare con &#8220;valori utili&#8221; di tipo intero e stringa mentre l'implementazione gestisce le conversioni necessarie per ottenere le istanze di <code>Node</code>.
+<p>Per ricapitolare, i limiti di vista ci permettono di lavorare con &#8220;valori utili&#8221; di tipo intero e stringa mentre l&#8217;implementazione gestisce le conversioni necessarie per ottenere le istanze di <code>Node</code>.
 
 <p>I limiti di vista non vengono usati con la stessa frequenza dei limiti inferiore e superiore sui tipi, ma offrono un meccanismo elegante da adoperare nelle situazioni in cui si desidera sfruttare la conversione automatica tra due tipi. Come sempre, gli impliciti devono essere usati con cautela: le conversioni implicite non risultano assolutamente chiare dalla lettura del codice e durante le attività di debug.
 
 
 <p><code>Null</code> è un tratto dichiarato come <code>final</code> (in modo che non possa essere esteso) di cui esiste una sola istanza, <code>null</code>. Dato che <code>Null</code> è un sottotipo di tutti i tipi <code>AnyRef</code>, è sempre possibile usare <code>null</code> come istanza di qualsiasi altro tipo. Java, al contrario, tratta semplicemente <code>null</code> come una parola chiave gestita in modo particolare dal compilatore. Tuttavia, il <code>null</code> di Java in realtà si comporta come se fosse un sottotipo di tutti i tipi riferimento, proprio come il <code>Null</code> di Scala.
 
-<p>D'altra parte, dato che <code>Null</code> non è un sottotipo di <code>AnyVal</code>, non è possibile usare <code>null</code> come istanza di <code>Int</code>, per esempio, coerentemente con la semantica dei tipi primitivi in Java.
+<p>D&#8217;altra parte, dato che <code>Null</code> non è un sottotipo di <code>AnyVal</code>, non è possibile usare <code>null</code> come istanza di <code>Int</code>, per esempio, coerentemente con la semantica dei tipi primitivi in Java.
 
-<p>Anche <code>Nothing</code> è un tratto dichiarato come <code>final</code>, ma dato che non ne esiste alcuna istanza viene utilizzato per definire altri tipi. Il miglior esempio è <code>Nil</code>, che rappresenta la lista vuota come un <code>case object</code> di tipo <code>List[Nothing]</code>. Dato che, come abbiamo visto, le liste in Scala sono covarianti, <code>Nil</code> è a tutti gli effetti un'istanza di <code>List[T]</code> per qualsiasi tipo <code>T</code>. Questa caratteristica è stata anche sfruttata nelle precedenti implementazioni di <code>AbbrevList</code> e <code>LinkedList</code>.
+<p>Anche <code>Nothing</code> è un tratto dichiarato come <code>final</code>, ma dato che non ne esiste alcuna istanza viene utilizzato per definire altri tipi. Il miglior esempio è <code>Nil</code>, che rappresenta la lista vuota come un <code>case object</code> di tipo <code>List[Nothing]</code>. Dato che, come abbiamo visto, le liste in Scala sono covarianti, <code>Nil</code> è a tutti gli effetti un&#8217;istanza di <code>List[T]</code> per qualsiasi tipo <code>T</code>. Questa caratteristica è stata anche sfruttata nelle precedenti implementazioni di <code>AbbrevList</code> e <code>LinkedList</code>.
 
 <h2 id=_understanding_abstract_types>Capire i tipi astratti</h2>
 
 
 <p>Il tipo del campo <code>x</code> rimane indefinito. Non è possibile usare <code>A</code> perché non è visibile dai parametri del costruttore. Si potrebbe usare <code>Any</code>, perdendo però il valore aggiunto di una dichiarazione che usi i tipi nel modo più opportuno.
 
-<p>Se si corre il rischio di dichiarare i parametri di un costruttore usando un tipo &#8220;segnaposto&#8221; che non è ancora stato definito, allora i tipi parametrici sono l'unica soluzione valida (a meno di usare <code>Any</code> o <code>AnyRef</code>).
+<p>Se si corre il rischio di dichiarare i parametri di un costruttore usando un tipo &#8220;segnaposto&#8221; che non è ancora stato definito, allora i tipi parametrici sono l&#8217;unica soluzione valida (a meno di usare <code>Any</code> o <code>AnyRef</code>).
 
-<p>I tipi astratti si possono usare nei parametri di un metodo e come valori di ritorno all'interno di una funzione. Tuttavia, possono sorgere due problemi: primo, nel caso si usino tipi dipendenti dal percorso (esaminati più avanti nella sezione <a href=#PathDependentTypes>Tipi dipendenti dal percorso</a>) il compilatore potrebbe confondersi, ritenendo incompatibile l'uso di un tipo in un particolare contesto quando in effetti il percorso conduce a un tipo compatibile; secondo, è insolito esprimere metodi come <code>List.::</code> usando tipi astratti là dove possono avvenire cambiamenti di tipo (espansioni, in questo caso).
+<p>I tipi astratti si possono usare nei parametri di un metodo e come valori di ritorno all&#8217;interno di una funzione. Tuttavia, possono sorgere due problemi: primo, nel caso si usino tipi dipendenti dal percorso (esaminati più avanti nella sezione <a href=#PathDependentTypes>Tipi dipendenti dal percorso</a>) il compilatore potrebbe confondersi, ritenendo incompatibile l&#8217;uso di un tipo in un particolare contesto quando in effetti il percorso conduce a un tipo compatibile; secondo, è insolito esprimere metodi come <code>List.::</code> usando tipi astratti là dove possono avvenire cambiamenti di tipo (espansioni, in questo caso).
 
 <pre><code>class List[+A] {
   &hellip;
 
 <p>Inoltre, se si desidera esprimere la varianza in caso di ereditarietà che è legata alle astrazioni di tipo, allora i tipi parametrici sono in grado di chiarire ed esplicitare questi comportamenti usando le annotazioni di varianza.
 
-<p>Queste limitazioni sui tipi astratti in realtà riflettono la tensione tra l'ereditarietà orientata agli oggetti e le origini funzionali dei tipi astratti, introdotti nei sistemi di tipi adottati nella programmazione funzionale pura, che non possiede il concetto di ereditarietà. I tipi parametrici sono più popolari nei linguaggi orientati agli oggetti perché gestiscono l'ereditarietà in maniera più naturale nella maggior parte delle situazioni.
+<p>Queste limitazioni sui tipi astratti in realtà riflettono la tensione tra l&#8217;ereditarietà orientata agli oggetti e le origini funzionali dei tipi astratti, introdotti nei sistemi di tipi adottati nella programmazione funzionale pura, che non possiede il concetto di ereditarietà. I tipi parametrici sono più popolari nei linguaggi orientati agli oggetti perché gestiscono l&#8217;ereditarietà in maniera più naturale nella maggior parte delle situazioni.
 
-<p>D'altra parte, talvolta è utile fare riferimento a un'astrazione di tipo come a un membro di un altro tipo anziché come a un parametro usato per costruire nuovi tipi a partire da un tipo parametrico. Una dichiarazione di tipo astratto che viene perfezionata attraverso una serie di raffinamenti del tipo che la racchude può rivelarsi piuttosto elegante.
+<p>D&#8217;altra parte, talvolta è utile fare riferimento a un&#8217;astrazione di tipo come a un membro di un altro tipo anziché come a un parametro usato per costruire nuovi tipi a partire da un tipo parametrico. Una dichiarazione di tipo astratto che viene perfezionata attraverso una serie di raffinamenti del tipo che la racchude può rivelarsi piuttosto elegante.
 
 <pre><code>trait T1 {
   type t
 
 <p>In più, questo esempio mostra che i tipi astratti vengono spesso usati per dichiarare variabili astratte dello stesso tipo. Vengono usati, meno frequentemente, anche per le dichiarazioni di metodo.
 
-<p>Per rendere finalmente concrete le variabili astratte è possibile definirle all'interno del corpo del tipo, in maniera molto simile a come sono state dichiarate in origine, oppure inizializzarle tramite gli argomenti del costruttore. Questa seconda tecnica permette a chi usa il tipo di scegliere l'effettivo valore, mentre la prima lascia questa decisione al progettista del tipo.
+<p>Per rendere finalmente concrete le variabili astratte è possibile definirle all&#8217;interno del corpo del tipo, in maniera molto simile a come sono state dichiarate in origine, oppure inizializzarle tramite gli argomenti del costruttore. Questa seconda tecnica permette a chi usa il tipo di scegliere l&#8217;effettivo valore, mentre la prima lascia questa decisione al progettista del tipo.
 
-<p>Abbiamo effettuato l'inizializzazione sfruttando gli argomenti del costruttore nella classe <code>BulkReader</code>, parte del breve esempio presentato nella sezione <a href=cap-2.html#AbstractTypesAndParameterizedTypes>Tipi astratti e tipi parametrici</a> del capitolo 2.
+<p>Abbiamo effettuato l&#8217;inizializzazione sfruttando gli argomenti del costruttore nella classe <code>BulkReader</code>, parte del breve esempio presentato nella sezione <a href=cap-2.html#AbstractTypesAndParameterizedTypes>Tipi astratti e tipi parametrici</a> del capitolo 2.
 
 <pre><code>// <a href=esempi/cap-2/abstract-types-script.scala>esempi/cap-2/abstract-types-script.scala</a>
 
 println(new StringBulkReader("Ciao Scala!").read)
 println(new FileBulkReader(new File("abstract-types-script.scala")).read)</code></pre>
 
-<p>Chi si è formato sulla programmazione orientata agli oggetti tenderà naturalmente a usare i tipi parametrici più spesso dei tipi astratti. Anche la libreria standard di Scala tende a enfatizzare l'uso dei tipi parametrici. In ogni caso, è consigliabile riconoscere i meriti dei tipi astratti e imparare a usarli quando ha senso farlo.
+<p>Chi si è formato sulla programmazione orientata agli oggetti tenderà naturalmente a usare i tipi parametrici più spesso dei tipi astratti. Anche la libreria standard di Scala tende a enfatizzare l&#8217;uso dei tipi parametrici. In ogni caso, è consigliabile riconoscere i meriti dei tipi astratti e imparare a usarli quando ha senso farlo.
 
 <h2 id=PathDependentTypes>Tipi dipendenti dal percorso</h2>
 
 <p>I linguaggi che consentono di annidare i tipi mettono anche a disposizione alcuni modi di fare riferimento al <em>percorso</em> di quei tipi. Scala è dotato di una ricca sintassi per i tipi dipendenti dal percorso, di cui è utile comprendere i concetti principali anche se viene usata raramente, in quanto i messaggi di errore del compilatore contengono spesso percorsi di tipo.
 
-<p>Si consideri l'esempio seguente.
+<p>Si consideri l&#8217;esempio seguente.
 
 <pre><code>// <a href=esempi/cap-12/type-path-wont-compile.scala>esempi/cap-12/type-path-wont-compile.scala</a>
 // Non verrà compilato!
   def doRun = true  // fai qualcosa di concreto...
 }</code></pre>
 
-<p>Compilando questo file si ottiene l'errore seguente.
+<p>Compilando questo file si ottiene l&#8217;errore seguente.
 
 <pre><samp>&hellip;:27: error: error overriding value logger in trait Service of type MyService2.Logger;
  value logger has incompatible type MyService1.MyService1Logger
 
 <h3 id=_c_this>Il percorso <code>C.this</code></h3>
 
-<p>All'interno del corpo di una qualsiasi classe <code>C</code> potete usare <code>C.this</code> o <code>this</code> per fare riferimento all'istanza corrente.
+<p>All&#8217;interno del corpo di una qualsiasi classe <code>C</code> potete usare <code>C.this</code> o <code>this</code> per fare riferimento all&#8217;istanza corrente.
 
 <pre><code>class C1 {
   var x = "1"
 
 <p>Sia <code>setX1</code> sia <code>setX2</code> hanno lo stesso effetto, perché <code>C1.this</code> è equivalente a <code>this</code>.
 
-<p>All'interno del corpo di un tipo e al di fuori della definizione di un metodo <code>this</code> fa riferimento al tipo stesso.
+<p>All&#8217;interno del corpo di un tipo e al di fuori della definizione di un metodo <code>this</code> fa riferimento al tipo stesso.
 
 <pre><code>trait T1 {
   class C
   val c2 = new this.C
 }</code></pre>
 
-<p>I valori <code>c1</code> e <code>c2</code> sono dello stesso tipo. L'occorrenza di <code>this</code> nell'espressione <code>this.C</code> fa riferimento al tratto <code>T1</code>.
+<p>I valori <code>c1</code> e <code>c2</code> sono dello stesso tipo. L&#8217;occorrenza di <code>this</code> nell&#8217;espressione <code>this.C</code> fa riferimento al tratto <code>T1</code>.
 
 <h3 id=_c_super>Il percorso <code>C.super</code></h3>
 
 
 <p><code>C3.super</code> è equivalente a <code>super</code> in questo esempio. Se volete fare riferimento a uno specifico genitore tra tutti quelli di un tipo, potete qualificare <code>super</code> con il tipo, come mostrato in <code>setX5</code>. Questo è particolarmente utile nel caso in cui un tipo mescoli diversi tratti, ognuno dei quali ridefinisca lo stesso metodo: se avete bisogno di accedere al metodo di un tratto specifico, potete qualificare <code>super</code>. Tuttavia, questa qualifica non può spingersi oltre il livello immediatamente superiore nella gerarchia, cioè non può fare riferimento ai tipi genitore del tipo genitore, e così via.
 
-<p>Se invocate <code>super</code> in una classe dotata di numerosi mixin e che estende un altro tipo, nel caso in cui il riferimento non sia qualificato sono le regole di <em>linearizzazione</em> a determinare l'obiettivo di <code>super</code> (si veda la sezione <a href=cap-7.html#Linearization>Linearizzare la gerarchia di un oggetto</a> nel capitolo 7).
+<p>Se invocate <code>super</code> in una classe dotata di numerosi mixin e che estende un altro tipo, nel caso in cui il riferimento non sia qualificato sono le regole di <em>linearizzazione</em> a determinare l&#8217;obiettivo di <code>super</code> (si veda la sezione <a href=cap-7.html#Linearization>Linearizzare la gerarchia di un oggetto</a> nel capitolo 7).
 
 <p>Proprio come accade per <code>this</code>, potete usare <code>super</code> per fare riferimento al tipo genitore nel corpo di un tipo al di fuori di un metodo.
 
   val name = P1.O1.O2.name
 }</code></pre>
 
-<p><code>C7.name</code> usa un percorso verso il valore <code>name</code> in <code>O2</code>. Gli elementi di un percorso di tipo devono essere <em>stabili</em>, il che a grandi linee comprende package e oggetti singleton, e dichiarazioni di tipo usate come alias di queste due entità. L'ultimo elemento di un percorso può essere una classe o un tratto. Si veda <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a> per i dettagli.
+<p><code>C7.name</code> usa un percorso verso il valore <code>name</code> in <code>O2</code>. Gli elementi di un percorso di tipo devono essere <em>stabili</em>, il che a grandi linee comprende package e oggetti singleton, e dichiarazioni di tipo usate come alias di queste due entità. L&#8217;ultimo elemento di un percorso può essere una classe o un tratto. Si veda <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a> per i dettagli.
 
 <pre><code>object O3 {
   object O4 {
 <p>Dato che Scala è tipato in modo forte e statico, ogni valore è dotato di tipo. Il termine <em>tipi valore</em> si riferisce a tutte le forme differenti che questi tipi possono assumere, quindi comprende molte forme che ora ci sono familiari, più alcune nuove forme che finora non abbiamo incontrato.
 
 <blockquote class=warning>
-<p><span class=u>&#x2762;</span>Qui stiamo usando il termine <em>tipi valore</em> nello stesso modo in cui viene usato in <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a>. Tuttavia, in altri punti del libro abbiamo anche seguito l'uso sovraccaricato del termine adottato dalla specifica per fare riferimento a tutti i sottotipi di <code>AnyVal</code>.
+<p><span class=u>&#x2762;</span>Qui stiamo usando il termine <em>tipi valore</em> nello stesso modo in cui viene usato in <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a>. Tuttavia, in altri punti del libro abbiamo anche seguito l&#8217;uso sovraccaricato del termine adottato dalla specifica per fare riferimento a tutti i sottotipi di <code>AnyVal</code>.
 </blockquote>
 
 <h3 id=_type_designators>Designatori di tipo</h3>
 
 <h3 id=_parameterized_types>Tipi parametrici</h3>
 
-<p>I tipi creati a partire da un tipo parametrico, come <code>List[Int]</code> e <code>List[String]</code>, creati a partire da <code>List[A]</code>, sono tipi valore perché vengono associati alla dichiarazione di valori, come nell'espressione <code>val names = List[String]()</code>.
+<p>I tipi creati a partire da un tipo parametrico, come <code>List[Int]</code> e <code>List[String]</code>, creati a partire da <code>List[A]</code>, sono tipi valore perché vengono associati alla dichiarazione di valori, come nell&#8217;espressione <code>val names = List[String]()</code>.
 
 <h3 id=_annotated_types>Tipi annotati</h3>
 
 }
 x: java.lang.Object with T1 with T2{type z = String; def v: this.z} = $anon$1@9d9347d</samp></pre>
 
-<p>Si noti il tipo dipendente dal percorso <code>this.z</code> nell'ultima riga.
+<p>Si noti il tipo dipendente dal percorso <code>this.z</code> nell&#8217;ultima riga.
 
 <p>Particolarmente interessante è il caso di una dichiarazione della forma <code>val x = new { R }</code>, priva di qualsiasi identificatore di tipo. Questa dichiarazione è equivalente a <code>val x = new AnyRef { R }</code>.
 
 <h3 id=_infix_types>Tipi infissi</h3>
 
-<p>Alcuni tipi parametrici possono accettare due argomenti di tipo, per esempio <code>scala.Either[+A,+B]</code>. Scala vi consente di dichiarare istanze di questi tipi usando una notazione infissa, come in <code>a Either b</code>. Si consideri l'uso che viene fatto di <code>Either</code> nello script seguente.
+<p>Alcuni tipi parametrici possono accettare due argomenti di tipo, per esempio <code>scala.Either[+A,+B]</code>. Scala vi consente di dichiarare istanze di questi tipi usando una notazione infissa, come in <code>a Either b</code>. Si consideri l&#8217;uso che viene fatto di <code>Either</code> nello script seguente.
 
 <pre><code>// <a href=esempi/cap-12/infix-types-script.scala>esempi/cap-12/infix-types-script.scala</a>
 
 println(attempt { true })
 println(attempt { false })</code></pre>
 
-<p>Il metodo <code>attempt</code> valuterà il parametro <code>operation</code> <em>invocato per nome</em> e restituirà il suo risultato di tipo <code>Boolean</code>, racchiuso in un'istanza di <code>Right</code>, <em>oppure</em> una qualsiasi istanza di <code>Throwable</code> che sia stata catturata, racchiusa in un'istanza di <code>Left</code>. Lo script stampa il testo seguente.
+<p>Il metodo <code>attempt</code> valuterà il parametro <code>operation</code> <em>invocato per nome</em> e restituirà il suo risultato di tipo <code>Boolean</code>, racchiuso in un&#8217;istanza di <code>Right</code>, <em>oppure</em> una qualsiasi istanza di <code>Throwable</code> che sia stata catturata, racchiusa in un&#8217;istanza di <code>Left</code>. Lo script stampa il testo seguente.
 
 <pre><samp>Left(java.lang.RuntimeException: Bu!)
 Right(true)
 Right(false)</samp></pre>
 
-<p>Si noti la dichiarazione del valore di ritorno, <code>Throwable Either Boolean</code>, che è identica a <code>Either[Throwable, Boolean]</code>. Ricordatevi che, come abbiamo visto nella sezione <a href=cap-7.html#ScalaTypeHierarchy>La gerarchia di tipi di Scala</a> del capitolo 7, quando si sfrutta questo idioma per gestire le eccezioni con <code>Either</code> la convenzione vuole che <code>Left</code> venga usato per l'eccezione e <code>Right</code> per il valore di ritorno ordinario.
+<p>Si noti la dichiarazione del valore di ritorno, <code>Throwable Either Boolean</code>, che è identica a <code>Either[Throwable, Boolean]</code>. Ricordatevi che, come abbiamo visto nella sezione <a href=cap-7.html#ScalaTypeHierarchy>La gerarchia di tipi di Scala</a> del capitolo 7, quando si sfrutta questo idioma per gestire le eccezioni con <code>Either</code> la convenzione vuole che <code>Left</code> venga usato per l&#8217;eccezione e <code>Right</code> per il valore di ritorno ordinario.
 
 <h3 id=FunctionTypes>Tipi funzione</h3>
 
 <p>Anche le funzioni che abbiamo scritto finora sono tipate. <code>(T<sub>1</sub>, T<sub>2</sub>, &hellip; T<sub>N</sub>) =&gt; R</code> è il tipo di tutte le funzioni che accettano <code>N</code> argomenti e restituiscono un valore di tipo <code>R</code>.
 
-<p>Quando c'è un solo argomento, è possibile tralasciare le parentesi, come in <code>T =&gt; R</code>. Una funzione che accetta un parametro <em>invocato per nome</em> (come discusso nel <a href=cap-8.html>capitolo 8</a>) è di tipo <code>(=&gt;T) =&gt; R</code>. Abbiamo usato un argomento invocato per nome nell'esempio con la funzione <code>attempt</code> della sezione precedente.
+<p>Quando c&#8217;è un solo argomento, è possibile tralasciare le parentesi, come in <code>T =&gt; R</code>. Una funzione che accetta un parametro <em>invocato per nome</em> (come discusso nel <a href=cap-8.html>capitolo 8</a>) è di tipo <code>(=&gt;T) =&gt; R</code>. Abbiamo usato un argomento invocato per nome nell&#8217;esempio con la funzione <code>attempt</code> della sezione precedente.
 
 <p>Ricordatevi che in Scala ogni cosa è un oggetto, persino le funzioni. La libreria Scala definisce i tratti <code>FunctionN</code>, per <code>N</code> che va da <code>0</code> a <code>22</code>, estremi inclusi. Ecco, per esempio, il codice sorgente di <code>scala.Function3</code> incluso nella versione 2.7.5 di Scala, privo della maggior parte dei commenti e di alcuni ulteriori dettagli a cui per ora non siamo interessati.
 
 
 <p>Come abbiamo detto nella sezione <a href=#VarianceUnderInheritance>Varianza in caso di ereditarietà</a>, i tratti <code>FunctionN</code> sono <em>controvarianti</em> nei parametri di tipo per gli argomenti e <em>covarianti</em> nel parametro di tipo per il tipo di ritorno.
 
-<p>Se ricordate, quando si usa il riferimento a un oggetto qualsiasi seguito da una lista di argomenti, Scala invoca il metodo <code>apply</code> su quell'oggetto. In questo modo, anche qualsiasi oggetto dotato di un metodo <code>apply</code> può essere considerato una funzione, offrendo una gradevole visione simmetrica della doppia natura di Scala, funzionale e orientata agli oggetti.
+<p>Se ricordate, quando si usa il riferimento a un oggetto qualsiasi seguito da una lista di argomenti, Scala invoca il metodo <code>apply</code> su quell&#8217;oggetto. In questo modo, anche qualsiasi oggetto dotato di un metodo <code>apply</code> può essere considerato una funzione, offrendo una gradevole visione simmetrica della doppia natura di Scala, funzionale e orientata agli oggetti.
 
-<p>Quando si definisce un valore funzione, il compilatore istanzia l'oggetto <code>FunctionN</code> appropriato e usa la definizione di funzione come corpo di <code>apply</code>.
+<p>Quando si definisce un valore funzione, il compilatore istanzia l&#8217;oggetto <code>FunctionN</code> appropriato e usa la definizione di funzione come corpo di <code>apply</code>.
 
 <pre><code>// <a href=esempi/cap-12/function-types-script.scala>esempi/cap-12/function-types-script.scala</a>
 
 
 <p>Nella prima parte dello script, definiamo un valore <code>f</code> di tipo <code>Function3</code> che esegue operazioni aritmetiche sui numeri <code>Double</code>. Creiamo un nuovo valore funzione <code>fc</code> applicando il currying a <code>f</code>. Poi invochiamo entrambe le funzioni con gli stessi argomenti e stampiamo i risultati che, come previsto, sono uguali. Si noti che, in questo caso, non ci sono problemi per quanto riguarda eventuali errori di arrotondamento nei confronti di uguaglianza: entrambe le funzioni invocano lo stesso metodo <code>apply</code>, quindi devono restituire lo stesso valore.
 
-<p>Nella seconda parte dello script sfruttiamo la possibilità di <em>applicare parzialmente</em> gli argomenti delle funzioni curry, creando nuove funzioni fino a quando non li abbiamo applicati tutti. L'esempio ci aiuta anche a capire la dichiarazione di <code>curry</code> in <code>Function3</code>.
+<p>Nella seconda parte dello script sfruttiamo la possibilità di <em>applicare parzialmente</em> gli argomenti delle funzioni curry, creando nuove funzioni fino a quando non li abbiamo applicati tutti. L&#8217;esempio ci aiuta anche a capire la dichiarazione di <code>curry</code> in <code>Function3</code>.
 
-<p>Le funzioni sono associative a destra, quindi un tipo <code>T1 =&gt; T2 =&gt; T3 =&gt; R</code> è equivalente a <code>T1 =&gt; (T2 =&gt; (T3 =&gt; R))</code>, come possiamo vedere nello script. Infatti l'istruzione <code>val fc1 = fc(2.)</code> invoca <code>fc</code> solo con la prima lista di argomenti (in questo caso, <code>T1</code> corrisponde a <code>Double</code>) e restituisce una <em>nuova</em> funzione di tipo <code>T2 =&gt; (T3 =&gt; R)</code>, nel nostro caso <code>Double =&gt; (Double =&gt; Double)</code>. Successivamente, in <code>val fc2 = fc1(5.)</code>, passiamo il secondo argomento (<code>T2</code>) e otteniamo una nuova funzione di tipo <code>T3 =&gt; R</code>, cioè <code>Double =&gt; Double</code>. Infine, in <code>val answer3 = fc2(4.)</code> passiamo l'ultimo argomento per calcolare il valore del tipo <code>R</code>, cioè <code>Double</code>.
+<p>Le funzioni sono associative a destra, quindi un tipo <code>T1 =&gt; T2 =&gt; T3 =&gt; R</code> è equivalente a <code>T1 =&gt; (T2 =&gt; (T3 =&gt; R))</code>, come possiamo vedere nello script. Infatti l&#8217;istruzione <code>val fc1 = fc(2.)</code> invoca <code>fc</code> solo con la prima lista di argomenti (in questo caso, <code>T1</code> corrisponde a <code>Double</code>) e restituisce una <em>nuova</em> funzione di tipo <code>T2 =&gt; (T3 =&gt; R)</code>, nel nostro caso <code>Double =&gt; (Double =&gt; Double)</code>. Successivamente, in <code>val fc2 = fc1(5.)</code>, passiamo il secondo argomento (<code>T2</code>) e otteniamo una nuova funzione di tipo <code>T3 =&gt; R</code>, cioè <code>Double =&gt; Double</code>. Infine, in <code>val answer3 = fc2(4.)</code> passiamo l&#8217;ultimo argomento per calcolare il valore del tipo <code>R</code>, cioè <code>Double</code>.
 
 <blockquote class=note>
 <p><span class=u>&#x261E;</span>Un tipo <code>T1 =&gt; T2 =&gt; T3 =&gt; R</code> è equivalente a <code>T1 =&gt; (T2 =&gt; (T3 =&gt; R))</code>. Quando si invoca una funzione di questo tipo con un valore per <code>T1</code>, essa restituisce una nuova funzione di tipo <code>T2 =&gt; (T3 =&gt; R)</code>, e così via.
 
 <h3 id=_singleton_types>Tipi singleton</h3>
 
-<p>Dato un valore <code>v</code> di un sottotipo di <code>AnyRef</code>, compreso <code>null</code>, è possibile ottenere il suo <em>tipo singleton</em> tramite l'espressione <code>v.type</code>, utilizzabile anche come tipo nelle dichiarazioni. Questa proprietà si rivela utile in rare occasioni per aggirare i problemi dovuti ai tipi dipendenti dal percorso visti nella sezione <a href=#PathDependentTypes>Tipi dipendenti dal percorso</a>. In questi casi il tipo dipendente dal percorso di un oggetto potrebbe sembrare incompatibile con un altro tipo dipendente dal percorso, mentre in effetti i due tipi sono compatibili. Tramite l'espressione <code>v.type</code> si recupera il tipo singleton, un tipo &#8220;unico&#8221; che elimina la dipendenza dal percorso. I tipi dipendenti dal percorso di due valori <code>v1</code> e <code>v2</code> potrebbero essere diversi, ma il loro tipo singleton può essere lo stesso.
+<p>Dato un valore <code>v</code> di un sottotipo di <code>AnyRef</code>, compreso <code>null</code>, è possibile ottenere il suo <em>tipo singleton</em> tramite l&#8217;espressione <code>v.type</code>, utilizzabile anche come tipo nelle dichiarazioni. Questa proprietà si rivela utile in rare occasioni per aggirare i problemi dovuti ai tipi dipendenti dal percorso visti nella sezione <a href=#PathDependentTypes>Tipi dipendenti dal percorso</a>. In questi casi il tipo dipendente dal percorso di un oggetto potrebbe sembrare incompatibile con un altro tipo dipendente dal percorso, mentre in effetti i due tipi sono compatibili. Tramite l&#8217;espressione <code>v.type</code> si recupera il tipo singleton, un tipo &#8220;unico&#8221; che elimina la dipendenza dal percorso. I tipi dipendenti dal percorso di due valori <code>v1</code> e <code>v2</code> potrebbero essere diversi, ma il loro tipo singleton può essere lo stesso.
 
 <p>Questo esempio usa il tipo singleton di un valore nella dichiarazione di un altro valore.
 
 
 <h2 id=SelfTypeAnnotations>Annotazioni self-type</h2>
 
-<p>All'interno di un metodo è possibile usare <code>this</code> per fare riferimento al tipo che ne contiene la definizione, e attraverso il riferimento al tipo accedere a uno dei suoi membri. In quest'ultimo caso, di solito l'uso di <code>this</code> non è necessario, ma in alcune occasioni può rivelarsi utile per evitare riferimenti ambigui quando in un determinato ambito sono visibili più valori con lo stesso nome. Per default, il tipo di <code>this</code> è uguale al tipo all'interno del quale viene usato, ma questa è una condizione niente affatto necessaria.
+<p>All&#8217;interno di un metodo è possibile usare <code>this</code> per fare riferimento al tipo che ne contiene la definizione, e attraverso il riferimento al tipo accedere a uno dei suoi membri. In quest&#8217;ultimo caso, di solito l&#8217;uso di <code>this</code> non è necessario, ma in alcune occasioni può rivelarsi utile per evitare riferimenti ambigui quando in un determinato ambito sono visibili più valori con lo stesso nome. Per default, il tipo di <code>this</code> è uguale al tipo all&#8217;interno del quale viene usato, ma questa è una condizione niente affatto necessaria.
 
-<p>Le <em>annotazioni self-type</em> permettono di specificare vincoli aggiuntivi sul tipo di <code>this</code> e possono essere usate per creare alias di <code>this</code>. Si consideri per primo quest'ultimo caso.
+<p>Le <em>annotazioni self-type</em> permettono di specificare vincoli aggiuntivi sul tipo di <code>this</code> e possono essere usate per creare alias di <code>this</code>. Si consideri per primo quest&#8217;ultimo caso.
 
 <pre><code>// <a href=esempi/cap-12/this-alias-script.scala>esempi/cap-12/this-alias-script.scala</a>
 
 <pre><samp>C1.talk: Ciao
 C1.talk: C3.talk: Mondo</samp></pre>
 
-<p>Al <code>this</code> dell'ambito più esterno (<code>C1</code>) viene dato l'alias <code>self</code> per potervi fare riferimento facilmente in <code>C3</code>. Sarebbe possibile usare <code>self</code> in qualsiasi metodo all'interno del corpo di <code>C1</code> o nei suoi tipi annidati. Si noti che il nome <code>self</code> è arbitrario, ma piuttosto convenzionale; in effetti si potrebbe scrivere <code>this =&gt;</code>, pur essendo assolutamente ridondante.
+<p>Al <code>this</code> dell&#8217;ambito più esterno (<code>C1</code>) viene dato l&#8217;alias <code>self</code> per potervi fare riferimento facilmente in <code>C3</code>. Sarebbe possibile usare <code>self</code> in qualsiasi metodo all&#8217;interno del corpo di <code>C1</code> o nei suoi tipi annidati. Si noti che il nome <code>self</code> è arbitrario, ma piuttosto convenzionale; in effetti si potrebbe scrivere <code>this =&gt;</code>, pur essendo assolutamente ridondante.
 
-<p>Se l'annotazione self-type contiene un tipo, i benefici che ne derivano sono molto diversi.
+<p>Se l&#8217;annotazione self-type contiene un tipo, i benefici che ne derivano sono molto diversi.
 
 <pre><code>// <a href=esempi/cap-12/selftype-script.scala>esempi/cap-12/selftype-script.scala</a>
 
 
 MyApp.run</code></pre>
 
-<p>Questo script illustra la struttura schematica di un'infrastruttura in grado di supportare diversi livelli applicativi sotto forma di componenti per la memorizzazione persistente, l'elaborazione dei dati e l'interfaccia utente. Esploreremo in maniera approfondita questa metodologia di progettazione dei componenti nel <a href=cap-13.html>capitolo 13</a>. Per ora, ci interessa semplicemente il ruolo delle annotazioni self-type.
+<p>Questo script illustra la struttura schematica di un&#8217;infrastruttura in grado di supportare diversi livelli applicativi sotto forma di componenti per la memorizzazione persistente, l&#8217;elaborazione dei dati e l&#8217;interfaccia utente. Esploreremo in maniera approfondita questa metodologia di progettazione dei componenti nel <a href=cap-13.html>capitolo 13</a>. Per ora, ci interessa semplicemente il ruolo delle annotazioni self-type.
 
-<p>Ogni tratto astratto dichiara un metodo di avvio che effettua l'inizializzazione del componente, ignorando tutte le possibili condizioni di errore. Ogni componente astratto è implementato da un tratto concreto corrispondente anziché da una classe, in modo da poterli usare come mixin. I tratti definiti nello script rappresentano un meccanismo per la persistenza in un database, una sorta di cluster di elaborazione per effettuare le operazioni di logica applicativa e una interfaccia web per l'utente.
+<p>Ogni tratto astratto dichiara un metodo di avvio che effettua l&#8217;inizializzazione del componente, ignorando tutte le possibili condizioni di errore. Ogni componente astratto è implementato da un tratto concreto corrispondente anziché da una classe, in modo da poterli usare come mixin. I tratti definiti nello script rappresentano un meccanismo per la persistenza in un database, una sorta di cluster di elaborazione per effettuare le operazioni di logica applicativa e una interfaccia web per l&#8217;utente.
 
 <p>Il tratto <code>App</code> collega i componenti tra loro, avviandoli uno per uno nel metodo <code>run</code>.
 
 <p>La particolare annotazione self-type <code>self: Persistence with Midtier with UI =&gt;</code> ha due effetti pratici.
 
 <ol>
-<li>Consente al corpo del tratto di considerare se stesso come un'istanza di <code>Persistence</code>, <code>Midtier</code> e <code>UI</code>, e quindi di invocare i metodi definiti in quei tipi, proprio come succede nel metodo <code>run</code>, a prescindere dal fatto che, a questo punto, siano effettivamente legati a una definizione.
+<li>Consente al corpo del tratto di considerare se stesso come un&#8217;istanza di <code>Persistence</code>, <code>Midtier</code> e <code>UI</code>, e quindi di invocare i metodi definiti in quei tipi, proprio come succede nel metodo <code>run</code>, a prescindere dal fatto che, a questo punto, siano effettivamente legati a una definizione.
 <li>Obbliga il tipo concreto che mescola questo tratto a mescolare quegli altri tre tratti o i loro discendenti.
 </ol>
 
 <p>In altre parole, il tipo <code>self</code> di <code>App</code> specifica le dipendenze dagli altri componenti, che vengono successivamente soddisfatte in <code>MyApp</code> mescolando i tratti concreti per i tre livelli applicativi.
 
-<p>Alternativamente, avremmo potuto definire <code>App</code> sfruttando l'ereditarietà.
+<p>Alternativamente, avremmo potuto definire <code>App</code> sfruttando l&#8217;ereditarietà.
 
 <pre><code>trait App with Persistence with Midtier with UI {
   def run = { &hellip; }
 }</code></pre>
 
-<p>In effetti, non ci sarebbero state differenze. Come abbiamo detto, l'annotazione self-type permette ad <code>App</code> di considerarsi come un tipo <code>Persistence</code>, <i class=baa>&amp;</i>c., e questo è proprio ciò che succede anche quando mescolate un tratto.
+<p>In effetti, non ci sarebbero state differenze. Come abbiamo detto, l&#8217;annotazione self-type permette ad <code>App</code> di considerarsi come un tipo <code>Persistence</code>, <i class=baa>&amp;</i>c., e questo è proprio ciò che succede anche quando mescolate un tratto.
 
-<p>Anche se sembrano equivalenti all'ereditarietà, esistono alcuni casi particolari in cui le annotazioni self-type, per ragioni teoriche, offrono vantaggi unici. In pratica sarebbe possibile usare l'ereditarietà in quasi tutti i casi, ma per convenzione la si usa quando si desidera indicare che un tipo <em>si comporta come</em> (eredita da) un altro tipo, e si usano le annotazioni self-type quando si vuole esprimere una dipendenza tra un tipo e altri tipi <a href=apa.html#McIver2009>[McIver2009]</a>.
+<p>Anche se sembrano equivalenti all&#8217;ereditarietà, esistono alcuni casi particolari in cui le annotazioni self-type, per ragioni teoriche, offrono vantaggi unici. In pratica sarebbe possibile usare l&#8217;ereditarietà in quasi tutti i casi, ma per convenzione la si usa quando si desidera indicare che un tipo <em>si comporta come</em> (eredita da) un altro tipo, e si usano le annotazioni self-type quando si vuole esprimere una dipendenza tra un tipo e altri tipi <a href=apa.html#McIver2009>[McIver2009]</a>.
 
-<p>Nel nostro esempio, l'applicazione non viene considerata come se <em>fosse</em> un'interfaccia utente, un database, <i class=baa>&amp;</i>c., bensì come una composizione di questi elementi. Si noti che nella maggior parte dei linguaggi orientati agli oggetti questa dipendenza tra componenti verrebbe espressa attraverso i campi, in particolare se il linguaggio non supporta la composizione dei mixin, come Java. Per esempio, si potrebbe scrivere <code>App</code> in Java nel modo che segue (dove, incidentalmente, le interfacce dei componenti sono annidate per evitare di dover creare file separati per ognuna).
+<p>Nel nostro esempio, l&#8217;applicazione non viene considerata come se <em>fosse</em> un&#8217;interfaccia utente, un database, <i class=baa>&amp;</i>c., bensì come una composizione di questi elementi. Si noti che nella maggior parte dei linguaggi orientati agli oggetti questa dipendenza tra componenti verrebbe espressa attraverso i campi, in particolare se il linguaggio non supporta la composizione dei mixin, come Java. Per esempio, si potrebbe scrivere <code>App</code> in Java nel modo che segue (dove, incidentalmente, le interfacce dei componenti sono annidate per evitare di dover creare file separati per ognuna).
 
 <pre><code>// <a href=esempi/cap-12/selftype/JavaApp.java>esempi/cap-12/selftype/JavaApp.java</a>
 
   }
 }</code></pre>
 
-<p>&Egrave; certamente possibile scrivere applicazioni in questo modo anche in Scala. Tuttavia, l'esplicitazione del tipo per la classe corrente trasforma la risoluzione imperativa delle dipendenze, che avviene a tempo di esecuzione tramite il passaggio di oggetti ai costruttori o ai metodi di scrittura dei valori, in una risoluzione dichiarativa che avviene a tempo di compilazione e cattura prima gli eventuali errori. Il paradigma dichiarativo, da cui deriva la programmazione funzionale, permette di esprimere codice più robusto, conciso e chiaro rispetto al paradigma imperativo.
+<p>&Egrave; certamente possibile scrivere applicazioni in questo modo anche in Scala. Tuttavia, l&#8217;esplicitazione del tipo per la classe corrente trasforma la risoluzione imperativa delle dipendenze, che avviene a tempo di esecuzione tramite il passaggio di oggetti ai costruttori o ai metodi di scrittura dei valori, in una risoluzione dichiarativa che avviene a tempo di compilazione e cattura prima gli eventuali errori. Il paradigma dichiarativo, da cui deriva la programmazione funzionale, permette di esprimere codice più robusto, conciso e chiaro rispetto al paradigma imperativo.
 
-<p>Riprenderemo le annotazioni self-type come modello per la composizione di componenti nel <a href=cap-13.html>capitolo 13</a>, in particolare nelle sezioni <a href=cap-13.html#SelfTypeAnnotationsAndAbstractTypeMembers>Annotazioni self-type e membri tipo astratti</a> e <a href=cap-13.html#DependencyInjectionInScala>L'iniezione di dipendenza in Scala: il pattern Cake</a>.
+<p>Riprenderemo le annotazioni self-type come modello per la composizione di componenti nel <a href=cap-13.html>capitolo 13</a>, in particolare nelle sezioni <a href=cap-13.html#SelfTypeAnnotationsAndAbstractTypeMembers>Annotazioni self-type e membri tipo astratti</a> e <a href=cap-13.html#DependencyInjectionInScala>L&#8217;iniezione di dipendenza in Scala: il pattern Cake</a>.
 
 <h2 id=StructuralTypes>Tipi strutturali</h2>
 
-<p>I <em>tipi strutturali</em> si possono considerare come un meccanismo type-safe di <em>duck typing</em>, termine usato per indicare il modo in cui funziona la risoluzione dei metodi nei linguaggi dinamicamente tipati. L'interprete Ruby, per esempio, esegue l'espressione <code>starFighter.shootWeapons</code> cercando un metodo <code>shootWeapons</code> nell'oggetto a cui <code>starFighter</code> fa riferimento. Questo metodo, se trovato, potrebbe essere stato definito nella classe usata per istanziare <code>starFighter</code> o in una delle classi genitore o in uno dei moduli &#8220;inclusi&#8221;, oppure potrebbe anche essere stato aggiunto all'oggetto usando le funzionalità di metaprogrammazione di Ruby. In alternativa, l'oggetto potrebbe ridefinire il metodo <code>method_missing</code> ed eseguire una particolare operazione quando l'oggetto riceve il &#8220;messaggio&#8221; <code>shootWeapons</code>.
+<p>I <em>tipi strutturali</em> si possono considerare come un meccanismo type-safe di <em>duck typing</em>, termine usato per indicare il modo in cui funziona la risoluzione dei metodi nei linguaggi dinamicamente tipati. L&#8217;interprete Ruby, per esempio, esegue l&#8217;espressione <code>starFighter.shootWeapons</code> cercando un metodo <code>shootWeapons</code> nell&#8217;oggetto a cui <code>starFighter</code> fa riferimento. Questo metodo, se trovato, potrebbe essere stato definito nella classe usata per istanziare <code>starFighter</code> o in una delle classi genitore o in uno dei moduli &#8220;inclusi&#8221;, oppure potrebbe anche essere stato aggiunto all&#8217;oggetto usando le funzionalità di metaprogrammazione di Ruby. In alternativa, l&#8217;oggetto potrebbe ridefinire il metodo <code>method_missing</code> ed eseguire una particolare operazione quando l&#8217;oggetto riceve il &#8220;messaggio&#8221; <code>shootWeapons</code>.
 
-<p>Scala non supporta questo genere di risoluzione dei metodi, ma vi consente di specificare che un oggetto deve aderire a una certa <em>struttura</em>, cioè contenere certi tipi, campi, o metodi, a prescindere dal suo tipo effettivo. Abbiamo incontrato i tipi strutturali per la prima volta all'inizio del <a href=cap-4.html>capitolo 4</a>, analizzando una variazione del pattern Observer come esempio.
+<p>Scala non supporta questo genere di risoluzione dei metodi, ma vi consente di specificare che un oggetto deve aderire a una certa <em>struttura</em>, cioè contenere certi tipi, campi, o metodi, a prescindere dal suo tipo effettivo. Abbiamo incontrato i tipi strutturali per la prima volta all&#8217;inizio del <a href=cap-4.html>capitolo 4</a>, analizzando una variazione del pattern Observer come esempio.
 
 <pre><code>// <a href=esempi/cap-4/observer/observer.scala>esempi/cap-4/observer/observer.scala</a>
 
 
 <p>La dichiarazione <code>type Observer = { def receiveUpdate(subject: Any) }</code> richiede che qualsiasi osservatore valido sia dotato del metodo <code>receiveUpdate</code>. Il vero tipo del particolare osservatore non è importante.
 
-<p>I tipi strutturali hanno il pregio di minimizzare l'interfaccia tra due entità. Nel nostro esempio, l'accoppiamento consiste solo nella firma di un singolo metodo anziché in un tipo come nel caso di un tratto condiviso. Purtroppo i tipi strutturali non riescono a eliminare le dipendenze da <em>nomi</em> particolari. Se un nome è arbitrario, ci interessa solo l'intento che nasconde. Nel nostro esempio, è possibile evitare la dipendenza dal nome di un singolo metodo usando un oggetto funzione al posto del tipo strutturale, proprio come è stato fatto nella sezione <a href=cap-6.html#OverridingAbstractTypes>Ridefinire i tipi astratti</a> del capitolo 6.
+<p>I tipi strutturali hanno il pregio di minimizzare l&#8217;interfaccia tra due entità. Nel nostro esempio, l&#8217;accoppiamento consiste solo nella firma di un singolo metodo anziché in un tipo come nel caso di un tratto condiviso. Purtroppo i tipi strutturali non riescono a eliminare le dipendenze da <em>nomi</em> particolari. Se un nome è arbitrario, ci interessa solo l&#8217;intento che nasconde. Nel nostro esempio, è possibile evitare la dipendenza dal nome di un singolo metodo usando un oggetto funzione al posto del tipo strutturale, proprio come è stato fatto nella sezione <a href=cap-6.html#OverridingAbstractTypes>Ridefinire i tipi astratti</a> del capitolo 6.
 
-<p>D'altra parte, se il nome viene adottato come una specie di convenzione universale, la dipendenza ha maggior valore. Per esempio, <code>foreach</code> è un nome molto comune nella libreria Scala e ha un particolare significato, quindi definire un tipo strutturale sulla base di <code>foreach</code> anziché usare una funzione anonima di qualche genere potrebbe essere vantaggioso per comunicarne l'intento al programmatore.
+<p>D&#8217;altra parte, se il nome viene adottato come una specie di convenzione universale, la dipendenza ha maggior valore. Per esempio, <code>foreach</code> è un nome molto comune nella libreria Scala e ha un particolare significato, quindi definire un tipo strutturale sulla base di <code>foreach</code> anziché usare una funzione anonima di qualche genere potrebbe essere vantaggioso per comunicarne l&#8217;intento al programmatore.
 
 <h2 id=ExistentialTypes>Tipi esistenziali</h2>
 
-<p>I <em>tipi esistenziali</em> sono astrazioni usate per individuare un tipo disinteressandosi della sua reale identità: permettono di &#8220;indicare&#8221; la presenza di un tipo senza specificare estattamente quale sia, di solito perché non lo si conosce e non è necessario conoscerlo nel contesto in cui viene usata l'espressione che lo contiene.
+<p>I <em>tipi esistenziali</em> sono astrazioni usate per individuare un tipo disinteressandosi della sua reale identità: permettono di &#8220;indicare&#8221; la presenza di un tipo senza specificare estattamente quale sia, di solito perché non lo si conosce e non è necessario conoscerlo nel contesto in cui viene usata l&#8217;espressione che lo contiene.
 
 <p>I tipi esistenziali sono particolarmente utili per interfacciarsi al sistema di tipi di Java in tre casi.
 
 <ol>
-<li>Quando si usano i generici, poiché i loro parametri di tipo vengono &#8220;cancellati&#8221; a livello di bytecode (tramite un procedimento chiamato <em>cancellazione di tipo</em>), come nel caso in cui si crea un'istanza di <code>List[Int]</code> e il tipo <code>Int</code> non è disponibile nel bytecode.
+<li>Quando si usano i generici, poiché i loro parametri di tipo vengono &#8220;cancellati&#8221; a livello di bytecode (tramite un procedimento chiamato <em>cancellazione di tipo</em>), come nel caso in cui si crea un&#8217;istanza di <code>List[Int]</code> e il tipo <code>Int</code> non è disponibile nel bytecode.
 <li>Quando si incontra un tipo &#8220;grezzo&#8221; (in inglese, <em>raw type</em>), come nelle librerie precedenti a Java 5 dove le collezioni non avevano parametri di tipo. In questo caso, tutti i parametri di tipo sono effettivamente <code>Object</code>.
-<li>Quando Java usa le wildcard per esprimere il comportamento di varianza nel punto in cui i generici vengono <em>usati</em>, poiché l'effettivo tipo rappresentato dalla wildcard è sconosciuto. (Ne abbiamo già parlato nella sezione <a href=#VarianceUnderInheritance>Varianza in caso di ereditarietà</a> di questo capitolo.)
+<li>Quando Java usa le wildcard per esprimere il comportamento di varianza nel punto in cui i generici vengono <em>usati</em>, poiché l&#8217;effettivo tipo rappresentato dalla wildcard è sconosciuto. (Ne abbiamo già parlato nella sezione <a href=#VarianceUnderInheritance>Varianza in caso di ereditarietà</a> di questo capitolo.)
 </ol>
 
-<p>Si consideri il caso del pattern matching su oggetti di tipo <code>List[A]</code>. L'idea di scrivere codice come quello riportato di seguito potrebbe essere seducente.
+<p>Si consideri il caso del pattern matching su oggetti di tipo <code>List[A]</code>. L&#8217;idea di scrivere codice come quello riportato di seguito potrebbe essere seducente.
 
 <pre><code>// <a href=esempi/cap-12/type-erasure-wont-work.scala>esempi/cap-12/type-erasure-wont-work.scala</a>
 // Attenzione: non funziona come potreste aspettarvi
   }
 }</code></pre>
 
-<p>Se però provate a compilare lo script con l'opzione <code>-unchecked</code> sulla <abbr>JVM</abbr> otterrete alcuni messaggi di avvertimento sul mancato controllo di tipo per parametri come <code>Int</code>, a causa della cancellazione che impedisce al compilatore di distinguere tra loro i tipi di lista elencati. Nemmeno i <em>manifest</em> esaminati in precedenza possono essere d'aiuto in questo caso, perché non sono in grado di recuperare il tipo cancellato di <code>B</code>.
+<p>Se però provate a compilare lo script con l&#8217;opzione <code>-unchecked</code> sulla <abbr>JVM</abbr> otterrete alcuni messaggi di avvertimento sul mancato controllo di tipo per parametri come <code>Int</code>, a causa della cancellazione che impedisce al compilatore di distinguere tra loro i tipi di lista elencati. Nemmeno i <em>manifest</em> esaminati in precedenza possono essere d&#8217;aiuto in questo caso, perché non sono in grado di recuperare il tipo cancellato di <code>B</code>.
 
-<p>Abbiamo già visto che la soluzione migliore da adottare con il pattern matching consiste nel concentrarsi sul fatto di avere una lista ed evitare di provare a determinare il parametro di tipo &#8220;perduto&#8221; per l'istanza di lista. Allo scopo di salvaguardare la sicurezza dei tipi, è necessario specificare che la lista ha un parametro, il quale però, essendo ignoto, verrà indicato con il carattere <code>_</code> usato come wildcard per il parametro di tipo, nel modo illustrato dall'esempio seguente.
+<p>Abbiamo già visto che la soluzione migliore da adottare con il pattern matching consiste nel concentrarsi sul fatto di avere una lista ed evitare di provare a determinare il parametro di tipo &#8220;perduto&#8221; per l&#8217;istanza di lista. Allo scopo di salvaguardare la sicurezza dei tipi, è necessario specificare che la lista ha un parametro, il quale però, essendo ignoto, verrà indicato con il carattere <code>_</code> usato come wildcard per il parametro di tipo, nel modo illustrato dall&#8217;esempio seguente.
 
 <pre><code>case l: List[_] =&gt; // fai qualcosa di "generico" con la lista</code></pre>
 
 </table>
 </div>
 
-<p>Se si considerano le somiglianze tra Scala e Java nella sintassi usata per i generici, è possibile notare che la struttura di un'espressione come <code>java.util.List[_ &lt;: scala.actors.AbstractActor]</code> corrisponde a quella dell'espressione di varianza Java <code>java.util.List&lt;? extends scala.actors.AbstractActor&gt;</code>. In effetti, le due dichiarazioni hanno lo stesso effetto. Anche se abbiamo detto che in Scala il comportamento di varianza viene definito nella dichiarazione, si possono usare le espressioni di tipo esistenziale per definire il comportamento di varianza nella invocazione. Questa pratica, tuttavia, viene sconsigliata per le ragioni discusse in precedenza.
+<p>Se si considerano le somiglianze tra Scala e Java nella sintassi usata per i generici, è possibile notare che la struttura di un&#8217;espressione come <code>java.util.List[_ &lt;: scala.actors.AbstractActor]</code> corrisponde a quella dell&#8217;espressione di varianza Java <code>java.util.List&lt;? extends scala.actors.AbstractActor&gt;</code>. In effetti, le due dichiarazioni hanno lo stesso effetto. Anche se abbiamo detto che in Scala il comportamento di varianza viene definito nella dichiarazione, si possono usare le espressioni di tipo esistenziale per definire il comportamento di varianza nella invocazione. Questa pratica, tuttavia, viene sconsigliata per le ragioni discusse in precedenza.
 
-<p>La sintassi completa con <code>forSome</code> non viene usata molto spesso nel codice Scala, perché i tipi esistenziali esistono principalmente per supportare i generici Java preservando nel contempo la correttezza nel sistema di tipi di Scala. L'inferenza di tipo nasconde i dettagli nella maggior parte dei contesti. Quando si lavora con i tipi di Scala, è preferibile usare gli altri costrutti di tipo visti in questo capitolo anziché ricorrere ai tipi esistenziali.
+<p>La sintassi completa con <code>forSome</code> non viene usata molto spesso nel codice Scala, perché i tipi esistenziali esistono principalmente per supportare i generici Java preservando nel contempo la correttezza nel sistema di tipi di Scala. L&#8217;inferenza di tipo nasconde i dettagli nella maggior parte dei contesti. Quando si lavora con i tipi di Scala, è preferibile usare gli altri costrutti di tipo visti in questo capitolo anziché ricorrere ai tipi esistenziali.
 
 <h2 id=InfiniteDataStructuresAndLaziness>Strutture dati infinite ed esecuzione ritardata</h2>
 
 
 <pre><code>fibonacci_sequence = for (i &lt;- 0 to infinity) yield fib(i)</code></pre>
 
-<p>L'esecuzione di Scala non è ritardata per default (né esiste alcun valore o parola chiave <code>infinity</code>) ma la libreria contiene una classe <code>Stream</code> che supporta la valutazione ritardata e quindi può supportare strutture dati infinite; la sfrutteremo tra un momento per presentarvi una nuova implementazione della sequenza di Fibonacci. Prima, però, ecco un esempio più semplice che usa quella classe per rappresentare tutti gli interi positivi, tutti gli interi dispari positivi e tutti gli interi pari positivi.
+<p>L&#8217;esecuzione di Scala non è ritardata per default (né esiste alcun valore o parola chiave <code>infinity</code>) ma la libreria contiene una classe <code>Stream</code> che supporta la valutazione ritardata e quindi può supportare strutture dati infinite; la sfrutteremo tra un momento per presentarvi una nuova implementazione della sequenza di Fibonacci. Prima, però, ecco un esempio più semplice che usa quella classe per rappresentare tutti gli interi positivi, tutti gli interi dispari positivi e tutti gli interi pari positivi.
 
 <pre><code>// <a href=esempi/cap-12/lazy-ints-script.scala>esempi/cap-12/lazy-ints-script.scala</a>
 
 <pre><samp>1, 3, 5, 7, 9, 11, 13, 15, 17, 19, Stream.empty
 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, Stream.empty</samp></pre>
 
-<p>Si noti che il metodo <code>from</code>, utilizzato per definire <code>ints</code>, è ricorsivo e non termina mai. <code>Stream.cons</code> è un oggetto dotato di un metodo <code>apply</code> che è analogo al metodo <code>::</code> (chiamato &#8220;cons&#8221;) di <code>List</code>: restituisce un nuovo flusso, cioè una nuova istanza di <code>Stream</code>, con il primo argomento come testa e con il secondo argomento, un'altra istanza di <code>Stream</code>, come coda. I valori ritardati <code>odds</code> e <code>evens</code> vengono calcolati filtrando <code>ints</code>.
+<p>Si noti che il metodo <code>from</code>, utilizzato per definire <code>ints</code>, è ricorsivo e non termina mai. <code>Stream.cons</code> è un oggetto dotato di un metodo <code>apply</code> che è analogo al metodo <code>::</code> (chiamato &#8220;cons&#8221;) di <code>List</code>: restituisce un nuovo flusso, cioè una nuova istanza di <code>Stream</code>, con il primo argomento come testa e con il secondo argomento, un&#8217;altra istanza di <code>Stream</code>, come coda. I valori ritardati <code>odds</code> e <code>evens</code> vengono calcolati filtrando <code>ints</code>.
 
 <p>Una volta definiti gli insiemi di numeri, usiamo il metodo <code>take</code> per recuperare una nuova istanza di <code>Stream</code> della dimensione fissa specificata, <code>10</code> in questo caso, e poi la stampiamo con il metodo <code>print</code>, generando i primi dieci elementi seguiti da <code>Stream.empty</code> quando si arriva al termine del flusso.
 
-<p>Tornando alla sequenza di Fibonacci, ne esiste una famosa definizione basata su sequenze infinite ritardate che sfruttano l'operazione <code>zip</code> (si veda per esempio <a href=apa.html#Abelson1996>[Abelson1996]</a>). La nostra analisi di questa definizione in Scala è adattata da <a href=apa.html#Ortiz2007>[Ortiz2007]</a>.
+<p>Tornando alla sequenza di Fibonacci, ne esiste una famosa definizione basata su sequenze infinite ritardate che sfruttano l&#8217;operazione <code>zip</code> (si veda per esempio <a href=apa.html#Abelson1996>[Abelson1996]</a>). La nostra analisi di questa definizione in Scala è adattata da <a href=apa.html#Ortiz2007>[Ortiz2007]</a>.
 
 <pre><code>// <a href=esempi/cap-12/lazy-fibonacci-script.scala>esempi/cap-12/lazy-fibonacci-script.scala</a>
 
 
 <pre><samp>0, 1, 1, 2, 3, 5, 8, 13, 21, 34, Stream.empty</samp></pre>
 
-<p>Come nella nostra definizione iterativa all'inizio di questa sezione, abbiamo esplicitamente specificato i primi due valori, <code>0</code> e <code>1</code>. Il resto dei numeri viene calcolato usando <code>zip</code> e sfruttando il fatto che <code>fib(n) = fib(n-1) + fib(n-2)</code> per <code>n &gt; 1</code>.
+<p>Come nella nostra definizione iterativa all&#8217;inizio di questa sezione, abbiamo esplicitamente specificato i primi due valori, <code>0</code> e <code>1</code>. Il resto dei numeri viene calcolato usando <code>zip</code> e sfruttando il fatto che <code>fib(n) = fib(n-1) + fib(n-2)</code> per <code>n &gt; 1</code>.
 
-<p>L'invocazione <code>fib.zip(fib.tail)</code> crea un nuovo flusso di tuple che contengono gli elementi di <code>fib</code> in prima posizione e gli elementi di <code>fib.tail</code> in seconda posizione. Per ottenere un flusso di singoli numeri interi, mappiamo il flusso di tuple in un flusso di <code>Int</code> sommando tra loro gli elementi di ogni tupla. Ecco le tuple calcolate.
+<p>L&#8217;invocazione <code>fib.zip(fib.tail)</code> crea un nuovo flusso di tuple che contengono gli elementi di <code>fib</code> in prima posizione e gli elementi di <code>fib.tail</code> in seconda posizione. Per ottenere un flusso di singoli numeri interi, mappiamo il flusso di tuple in un flusso di <code>Int</code> sommando tra loro gli elementi di ogni tupla. Ecco le tuple calcolate.
 
 <pre><samp>(0,1), (1,1), (1,2), (2,3), (3,5), (5,8), (8,13), (13,21), (21,34), &hellip;</samp></pre>
 
 -1537171498
 -1537171498</samp></pre>
 
-<p>Si noti che l'invocazione di <code>first</code> sulla sequenza non restituisce sempre lo stesso valore. Il motivo è che l'intervallo all'inizio dell'espressione <code>for</code> obbliga l'intera sequenza a essere ritardata, e quindi ne innesca una nuova valutazione a <em>ogni</em> invocazione di <code>first</code>: così, il primo valore nella sequenza effettivamente cambia, dato che <code>Random</code> restituisce un numero differente ogni volta (almeno lo farà se tra un'invocazione e l'altra trascorre un intervallo di tempo sufficiente).
+<p>Si noti che l&#8217;invocazione di <code>first</code> sulla sequenza non restituisce sempre lo stesso valore. Il motivo è che l&#8217;intervallo all&#8217;inizio dell&#8217;espressione <code>for</code> obbliga l&#8217;intera sequenza a essere ritardata, e quindi ne innesca una nuova valutazione a <em>ogni</em> invocazione di <code>first</code>: così, il primo valore nella sequenza effettivamente cambia, dato che <code>Random</code> restituisce un numero differente ogni volta (almeno lo farà se tra un&#8217;invocazione e l&#8217;altra trascorre un intervallo di tempo sufficiente).
 
-<p>Tuttavia, l'invocazione di <code>toList</code> sulla sequenza innesca la valutazione dell'intero intervallo e crea una lista <em>rigorosa</em>, in cui tutti gli elementi sono calcolati.
+<p>Tuttavia, l&#8217;invocazione di <code>toList</code> sulla sequenza innesca la valutazione dell&#8217;intero intervallo e crea una lista <em>rigorosa</em>, in cui tutti gli elementi sono calcolati.
 
 <blockquote class=warning>
 <p><span class=u>&#x2762;</span>Evitate di usare gli intervalli in costrutti del tipo <code>for (&hellip;) yield x</code>, mentre potete usarli in quelli del tipo <code>for (&hellip;) {&hellip;}</code>.
 
 <p>Va ricordato che non è necessario padroneggiare le complessità del ricco sistema di tipi di Scala per usare efficacemente il linguaggio. Man mano che prenderete confidenza, comincerete a creare librerie potenti e sofisticate che incrementeranno la vostra produttività.
 
-<p>La specifica del linguaggio <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a> descrive i dettagli formali del sistema di tipi. Come qualsiasi specifica, può risultare difficile da leggere, ma vale la pena farlo se desiderate conoscere il sistema di tipi in profondità. Esiste anche una lunga serie di articoli sul sistema di tipi di Scala, che potete rintracciare a partire dal sito ufficiale del linguaggio all'indirizzo <a class=url href=http://scala-lang.org>http://scala-lang.org</a>.
+<p>La specifica del linguaggio <a href=apa.html#ScalaSpec2009>[ScalaSpec2009]</a> descrive i dettagli formali del sistema di tipi. Come qualsiasi specifica, può risultare difficile da leggere, ma vale la pena farlo se desiderate conoscere il sistema di tipi in profondità. Esiste anche una lunga serie di articoli sul sistema di tipi di Scala, che potete rintracciare a partire dal sito ufficiale del linguaggio all&#8217;indirizzo <a class=url href=http://scala-lang.org>http://scala-lang.org</a>.
 
 <p>Nei prossimi due capitoli ci occuperemo di analizzare gli aspetti pratici della progettazione di software e gli strumenti e le librerie per sviluppare applicazioni in Scala.
 
 
 <h1>La progettazione di applicazioni</h1>
 
-<p>In questo capitolo esamineremo gli aspetti pratici dello sviluppo di applicazioni in Scala. Analizzeremo alcune caratteristiche del linguaggio e della <abbr>API</abbr> di cui finora non abbiamo parlato, discuteremo di pattern di progettazione e di idiomi comuni, infine rivisiteremo i <em>tratti</em> nell'ottica della strutturazione efficace del codice.
+<p>In questo capitolo esamineremo gli aspetti pratici dello sviluppo di applicazioni in Scala. Analizzeremo alcune caratteristiche del linguaggio e della <abbr>API</abbr> di cui finora non abbiamo parlato, discuteremo di pattern di progettazione e di idiomi comuni, infine rivisiteremo i <em>tratti</em> nell&#8217;ottica della strutturazione efficace del codice.
 
 <h2 id=Annotations>Annotazioni</h2>
 
 <p>Al pari di Java e .NET, Scala supporta le <em>annotazioni</em> come meccanismo per aggiungere <em>metadati</em> alle dichiarazioni. Le annotazioni vengono largamente impiegate dagli strumenti adottati per realizzare le tipiche applicazioni aziendali e di rete: per esempio, alcuni framework <abbr>ORM</abbr><sup id=fnn-1><a href=#fn-1>1</a></sup> usano le annotazioni sui tipi e sui loro membri per fornire al compilatore informazioni riguardanti la persistenza degli oggetti. Anche se Scala dispone di meccanismi alternativi per gli usi più comuni delle annotazioni in Java e .NET, esse possono rivelarsi essenziali per interagire con le librerie che, su queste piattaforme, ne sfruttano tutte le proprietà. Per fortuna, è possibile usare le annotazioni Java e .NET nel codice Scala.
 
-<p>Il modo in cui le annotazioni Scala vengono interpretate dipende dall'ambiente a tempo di esecuzione. In questa sezione ci concentreremo sull'ambiente offerto dal <abbr>JDK</abbr>.
-
-<p>In Java le annotazioni si dichiarano usando convenzioni particolari, per esempio adoperando la parola chiave <code>@interface</code> al posto di <code>class</code> o <code>interface</code>. Ecco la dichiarazione di un'annotazione estratta dalla libreria Contract4J <a href=apa.html#Contract4J>[Contract4J]</a> che usa le annotazioni per supportare la <em>progettazione per contratto</em> in Java (si veda anche la sezione <a href=#DesignByContractExample>Una progettazione migliore con la progettazione per contratto</a> più avanti). Alcuni commenti sono stati rimossi dal codice e, per chiarezza, i rimanenti sono stati tradotti.
+<p>Il modo in cui le annotazioni Scala vengono interpretate dipende dall&#8217;ambiente a tempo di esecuzione. In questa sezione ci concentreremo sull&#8217;ambiente offerto dal <abbr>JDK</abbr>.
+
+<p>In Java le annotazioni si dichiarano usando convenzioni particolari, per esempio adoperando la parola chiave <code>@interface</code> al posto di <code>class</code> o <code>interface</code>. Ecco la dichiarazione di un&#8217;annotazione estratta dalla libreria Contract4J <a href=apa.html#Contract4J>[Contract4J]</a> che usa le annotazioni per supportare la <em>progettazione per contratto</em> in Java (si veda anche la sezione <a href=#DesignByContractExample>Una progettazione migliore con la progettazione per contratto</a> più avanti). Alcuni commenti sono stati rimossi dal codice e, per chiarezza, i rimanenti sono stati tradotti.
 
 <pre><code>// <a href=esempi/cap-13/Pre.java>esempi/cap-13/Pre.java</a>
 
   String message() default "";
 }</code></pre>
 
-<p>L'annotazione <code>@Pre</code> viene usata per specificare le &#8220;precondizioni&#8221; che devono essere soddisfatte quando si <em>entra</em> in un metodo o in un costruttore, o <em>prima</em> di usare un parametro passato a un metodo o a un costruttore. Le condizioni vengono specificate sotto forma di una stringa che in realtà è una porzione di codice sorgente, scritta in un linguaggio di scripting come Groovy o JRuby, la cui valutazione deve dare come risultato <code>true</code> oppure <code>false</code>. Il nome della variabile che contiene questa stringa, <code>value</code>, è quello adottato come convenzione per indicare il campo più importante di un'annotazione. L'altro campo, <code>message</code>, rappresenta un messaggio opzionale da usare quando viene presentato un fallimento.
-
-<p>Alla dichiarazione vengono applicate altre annotazioni: per esempio, l'annotazione <code>@Retention</code> con il valore <code>RetentionPolicy.RUNTIME</code> significa che le informazioni relative a ogni occorrenza di <code>@Pre</code> saranno conservate nel file di classe per essere usate a tempo di esecuzione.
+<p>L&#8217;annotazione <code>@Pre</code> viene usata per specificare le &#8220;precondizioni&#8221; che devono essere soddisfatte quando si <em>entra</em> in un metodo o in un costruttore, o <em>prima</em> di usare un parametro passato a un metodo o a un costruttore. Le condizioni vengono specificate sotto forma di una stringa che in realtà è una porzione di codice sorgente, scritta in un linguaggio di scripting come Groovy o JRuby, la cui valutazione deve dare come risultato <code>true</code> oppure <code>false</code>. Il nome della variabile che contiene questa stringa, <code>value</code>, è quello adottato come convenzione per indicare il campo più importante di un&#8217;annotazione. L&#8217;altro campo, <code>message</code>, rappresenta un messaggio opzionale da usare quando viene presentato un fallimento.
+
+<p>Alla dichiarazione vengono applicate altre annotazioni: per esempio, l&#8217;annotazione <code>@Retention</code> con il valore <code>RetentionPolicy.RUNTIME</code> significa che le informazioni relative a ogni occorrenza di <code>@Pre</code> saranno conservate nel file di classe per essere usate a tempo di esecuzione.
 
 <p>Ecco un esempio di come usare <code>@Pre</code> in Scala, specificando i parametri <code>value</code> e <code>message</code> in modi diversi.
 
     value.matches("""^\s*\d{3}-\d{2}-\d{4}\s*$""")
 }</code></pre>
 
-<p>Nella classe <code>Person</code>, l'annotazione <code>@Pre</code> accetta come argomento una semplice stringa, contenente la &#8220;precondizione&#8221; che un nome passato da un utente deve soddisfare: questo valore non può essere <code>null</code> e non può essere di lunghezza zero. Come in Java, se all'annotazione viene passato un singolo argomento, questo viene assegnato al campo <code>value</code>.
+<p>Nella classe <code>Person</code>, l&#8217;annotazione <code>@Pre</code> accetta come argomento una semplice stringa, contenente la &#8220;precondizione&#8221; che un nome passato da un utente deve soddisfare: questo valore non può essere <code>null</code> e non può essere di lunghezza zero. Come in Java, se all&#8217;annotazione viene passato un singolo argomento, questo viene assegnato al campo <code>value</code>.
 
 <p>Una simile annotazione <code>@Pre</code> viene usata per il terzo argomento <code>ssn</code>, il numero di previdenza sociale. In entrambi i casi, al campo <code>message</code> viene assegnata una stringa vuota, specificata come valore predefinito nella definizione di <code>Pre</code>.
 
-<p>L'annotazione <code>@Pre</code> usata per l'età mostra come specificare valori per più di un campo usando le parentesi graffe anziché le parentesi tonde. La sintassi dei campi somiglia a quella di una dichiarazione <code>val</code> priva delle informazioni di tipo, in quanto i tipi possono essere sempre inferiti! Di conseguenza, è possibile usare la sintassi abbreviata per <code>value</code> e specificare comunque i valori per gli altri campi.
+<p>L&#8217;annotazione <code>@Pre</code> usata per l&#8217;età mostra come specificare valori per più di un campo usando le parentesi graffe anziché le parentesi tonde. La sintassi dei campi somiglia a quella di una dichiarazione <code>val</code> priva delle informazioni di tipo, in quanto i tipi possono essere sempre inferiti! Di conseguenza, è possibile usare la sintassi abbreviata per <code>value</code> e specificare comunque i valori per gli altri campi.
 
 <blockquote class=note>
-<p><span class=u>&#x261E;</span>Se <code>Person</code> fosse una classe Java, questa annotazione sarebbe identica, eccetto che per l'assenza della parola chiave <code>val</code> e l'uso delle parentesi tonde.
+<p><span class=u>&#x261E;</span>Se <code>Person</code> fosse una classe Java, questa annotazione sarebbe identica, eccetto che per l&#8217;assenza della parola chiave <code>val</code> e l&#8217;uso delle parentesi tonde.
 </blockquote>
 
-<p>L'annotazione <code>@Pre</code> sul parametro del costruttore della classe <code>SSN</code> mostra la sintassi alternativa per assegnare valori a più di un campo. Il campo <code>value</code> viene specificato come prima, tramite una lista di parametri contenente un elemento; il campo <code>message</code> viene inizializzato nel blocco successivo, racchiuso tra parentesi graffe.
+<p>L&#8217;annotazione <code>@Pre</code> sul parametro del costruttore della classe <code>SSN</code> mostra la sintassi alternativa per assegnare valori a più di un campo. Il campo <code>value</code> viene specificato come prima, tramite una lista di parametri contenente un elemento; il campo <code>message</code> viene inizializzato nel blocco successivo, racchiuso tra parentesi graffe.
 
 <p>Per collaudare questo script sarebbe necessario installare e configurare Conctract4J. Fate riferimento a <a href=apa.html#Contract4J>[Contract4J]</a> per scoprire come effettuare queste operazioni.
 
-<p>Anziché usare una sintassi speciale, le annotazioni Scala vengono dichiarate come normali classi. In questo modo si evita un &#8220;caso particolare&#8221; nel linguaggio, ma come vedremo si perdono anche alcune delle caratteristiche offerte dalle annotazioni Java. Ecco un'annotazione di esempio, <code>SerialVersionUID</code>, tratta dalla libreria Scala (ancora una volta con i commenti rimossi, per chiarezza).
+<p>Anziché usare una sintassi speciale, le annotazioni Scala vengono dichiarate come normali classi. In questo modo si evita un &#8220;caso particolare&#8221; nel linguaggio, ma come vedremo si perdono anche alcune delle caratteristiche offerte dalle annotazioni Java. Ecco un&#8217;annotazione di esempio, <code>SerialVersionUID</code>, tratta dalla libreria Scala (ancora una volta con i commenti rimossi, per chiarezza).
 
 <pre><code>package scala
 
 class SerialVersionUID(uid: Long) extends StaticAnnotation</code></pre>
 
-<p>L'annotazione <code>@SerialVersionUID</code> viene applicata a una classe per definire un identificatore unico globale sotto forma di numero <code>Long</code>. Quando si usa questa annotazione, l'identificatore viene specificato come un argomento del costruttore; in una classe Java, quello stesso numero verrebbe assegnato a un campo <code>static</code> chiamato <code>serialVersionUID</code>. Questo è un esempio di un'annotazione Scala che corrisponde a un costrutto Java diverso da un'annotazione.
+<p>L&#8217;annotazione <code>@SerialVersionUID</code> viene applicata a una classe per definire un identificatore unico globale sotto forma di numero <code>Long</code>. Quando si usa questa annotazione, l&#8217;identificatore viene specificato come un argomento del costruttore; in una classe Java, quello stesso numero verrebbe assegnato a un campo <code>static</code> chiamato <code>serialVersionUID</code>. Questo è un esempio di un&#8217;annotazione Scala che corrisponde a un costrutto Java diverso da un&#8217;annotazione.
 
 <p><code>SerialVersionUID</code> estende il tratto <code>scala.StaticAnnotation</code>, usato come genitore per tutte le annotazioni che dovrebbero essere visibili durante i controlli di tipo, anche attraverso i confini delle unità di compilazione. A sua volta, <code>scala.StaticAnnotation</code> estende <code>scala.Annotation</code>, che è il genitore di tutte le annotazioni Scala.
 
-<p>Nella dichiarazione del parametro <code>uid</code> non compare alcuna parola chiave <code>val</code>: <code>uid</code> non viene dichiarato come campo perché il dato dell'annotazione non è destinato a essere usato dal programma, ma solo da strumenti esterni come <kbd>scalac</kbd>. Questo significa anche che non c'è alcun modo di definire valori nelle annotazioni di Scala 2.7.X, in quanto il supporto per gli argomenti impliciti è assente. Tuttavia, si potrebbe ricorrere agli argomenti predefiniti introdotti in Scala 2.8.0 (non sono ancora stati implementati al momento della scrittura, quindi non ci è stato possibile verificare).
-
-<p>Come per le annotazioni Java, la clausola che contiene un'annotazione Scala viene applicata alla definizione che precede. Potete usare più di una clausola per una singola definizione, e l'ordine in cui compaiono le clausole non è significativo. La sintassi da usare per scrivere queste clausole è <code>@Annotazione</code>, se il costruttore dell'annotazione non accetta argomenti, oppure <code>@Annotazione(arg1, &hellip; argN)</code>, se il costruttore accetta un numero N di argomenti. L'annotazione deve essere una sottoclasse di <code>scala.Annotation</code>.
+<p>Nella dichiarazione del parametro <code>uid</code> non compare alcuna parola chiave <code>val</code>: <code>uid</code> non viene dichiarato come campo perché il dato dell&#8217;annotazione non è destinato a essere usato dal programma, ma solo da strumenti esterni come <kbd>scalac</kbd>. Questo significa anche che non c&#8217;è alcun modo di definire valori nelle annotazioni di Scala 2.7.X, in quanto il supporto per gli argomenti impliciti è assente. Tuttavia, si potrebbe ricorrere agli argomenti predefiniti introdotti in Scala 2.8.0 (non sono ancora stati implementati al momento della scrittura, quindi non ci è stato possibile verificare).
+
+<p>Come per le annotazioni Java, la clausola che contiene un&#8217;annotazione Scala viene applicata alla definizione che precede. Potete usare più di una clausola per una singola definizione, e l&#8217;ordine in cui compaiono le clausole non è significativo. La sintassi da usare per scrivere queste clausole è <code>@Annotazione</code>, se il costruttore dell&#8217;annotazione non accetta argomenti, oppure <code>@Annotazione(arg1, &hellip; argN)</code>, se il costruttore accetta un numero N di argomenti. L&#8217;annotazione deve essere una sottoclasse di <code>scala.Annotation</code>.
 
 <p>Tutti i parametri del costruttore devono essere espressioni costanti, comprese stringhe, letterali classe, enumerazioni Java, espressioni numeriche, e array monodimensionali di questi tipi. Tuttavia, il compilatore permette di usare anche clausole di annotazione con altri argomenti, come valori booleani e mappe, in modo simile a quanto presentato in questo esempio.
 
 @Persist("ACCOUNTS", Map(("dbms", "MySql"), ("writeAutomatically", true)))
 class Account(val balance: Double)</code></pre>
 
-<p>Stranamente, se tentate di usare la normale sintassi per i letterali <code>Map</code> mostrata nel commento, il compilatore genera un errore lamentando la mancanza del metodo <code>-&gt;</code> nella classe <code>String</code>. La conversione implicita verso <code>ArrowAssoc</code> che abbiamo esaminato nella sezione <a href=cap-7.html#PredefObject>L'oggetto <code>Predef</code></a> del capitolo 7 non viene invocata, perciò dovete usare una lista di oggetti <code>Tuple</code>, che è il tipo effettivo dell'argomento atteso da <code>Map.apply</code>.
+<p>Stranamente, se tentate di usare la normale sintassi per i letterali <code>Map</code> mostrata nel commento, il compilatore genera un errore lamentando la mancanza del metodo <code>-&gt;</code> nella classe <code>String</code>. La conversione implicita verso <code>ArrowAssoc</code> che abbiamo esaminato nella sezione <a href=cap-7.html#PredefObject>L&#8217;oggetto <code>Predef</code></a> del capitolo 7 non viene invocata, perciò dovete usare una lista di oggetti <code>Tuple</code>, che è il tipo effettivo dell&#8217;argomento atteso da <code>Map.apply</code>.
 
 <p>Il tratto <code>scala.ClassfileAnnotation</code> è un altro figlio di <code>scala.Annotation</code>, progettato per essere esteso da annotazioni che dovrebbero venire conservate nel file di classe in modo da rimanere disponibili a tempo di esecuzione. Tuttavia, se usate questo tratto con la versione di Scala per il <abbr>JDK</abbr>, il compilatore genererà errori simili a quello riportato di seguito.
 
             you want, you must write the annotation class in Java.
 &hellip;</samp></pre>
 
-<p>Perciò se desiderate la visibilità a tempo di esecuzione dovete implementare l'annotazione in Java, potendola poi usare tranquillamente nel codice Scala al pari di qualsiasi altra annotazione Java. Al momento, forse per ovvie ragioni, la libreria Scala non definisce annotazioni derivate da <code>ClassfileAnnotation</code>.
+<p>Perciò se desiderate la visibilità a tempo di esecuzione dovete implementare l&#8217;annotazione in Java, potendola poi usare tranquillamente nel codice Scala al pari di qualsiasi altra annotazione Java. Al momento, forse per ovvie ragioni, la libreria Scala non definisce annotazioni derivate da <code>ClassfileAnnotation</code>.
 
 <blockquote class=warning>
 <p><span class=u>&#x2762;</span>Evitate <code>ClassfileAnnotation</code> e implementate in Java le annotazioni che richiedono di essere conservate a tempo di esecuzione.
 </blockquote>
 
-<p>Per le versioni 2.7.X di Scala è necessario tenere presente un'altra importante limitazione: le annotazioni non possono essere annidate. Questo diventa un problema quando usate annotazioni <abbr>JPA</abbr> nel codice Scala, per esempio, come si vede in <a href=apa.html#JPAScala>[JPAScala]</a>. Tuttavia, la versione 2.8 di Scala rimuove questa limitazione.
+<p>Per le versioni 2.7.X di Scala è necessario tenere presente un&#8217;altra importante limitazione: le annotazioni non possono essere annidate. Questo diventa un problema quando usate annotazioni <abbr>JPA</abbr> nel codice Scala, per esempio, come si vede in <a href=apa.html#JPAScala>[JPAScala]</a>. Tuttavia, la versione 2.8 di Scala rimuove questa limitazione.
 
 <blockquote class=warning>
 <p><span class=u>&#x2762;</span>Le annotazioni si possono annidare solo in Scala 2.8.
 <tr>
 <td align=left valign=top><p><code>ClassfileAnnotation</code>
 <td align=left valign=top><p>Annotazione con <code>@Retention(RetentionPolicy.RUNTIME)</code>
-<td align=left valign=top><p>Il tratto genitore per le annotazioni che dovrebbero essere conservate nel file di classe per l'accesso a tempo di esecuzione&nbsp;&mdash;&nbsp;ma in realtà non funziona con il <abbr>JDK</abbr>!
+<td align=left valign=top><p>Il tratto genitore per le annotazioni che dovrebbero essere conservate nel file di classe per l&#8217;accesso a tempo di esecuzione&nbsp;&mdash;&nbsp;ma in realtà non funziona con il <abbr>JDK</abbr>!
 <tr>
 <td align=left valign=top><p><code>BeanDescription</code>
 <td align=left valign=top><p><code>BeanDescriptor</code> (classe)
-<td align=left valign=top><p>Un'annotazione per i componenti <em>JavaBeans</em> che associa a un tipo o a un membro una breve descrizione (fornita all'annotazione come argomento) che verrà inclusa tra le informazioni generate per il componente.
+<td align=left valign=top><p>Un&#8217;annotazione per i componenti <em>JavaBeans</em> che associa a un tipo o a un membro una breve descrizione (fornita all&#8217;annotazione come argomento) che verrà inclusa tra le informazioni generate per il componente.
 <tr>
 <td align=left valign=top><p><code>BeanDisplayName</code>
 <td align=left valign=top><p><code>BeanDescriptor</code> (classe)
-<td align=left valign=top><p>Un'annotazione per i componenti <em>JavaBeans</em> che associa a un tipo o a un membro un nome (fornito all'annotazione come argomento) che verrà incluso tra le informazioni generate per il componente.
+<td align=left valign=top><p>Un&#8217;annotazione per i componenti <em>JavaBeans</em> che associa a un tipo o a un membro un nome (fornito all&#8217;annotazione come argomento) che verrà incluso tra le informazioni generate per il componente.
 <tr>
 <td align=left valign=top><p><code>BeanInfo</code>
 <td align=left valign=top><p><code>BeanInfo</code> (classe)
 <tr>
 <td align=left valign=top><p><code>TypeConstraint</code>
 <td align=left valign=top><p><em>nessuno</em>
-<td align=left valign=top><p>Un tratto applicabile come annotazione ad altre annotazioni che definiscono vincoli su un tipo, basandosi solo sulle informazioni definite all'interno del tipo stesso anziché su informazioni esterne relative al contesto in cui il tipo viene definito o usato. Il compilatore può sfruttare questa restrizione per riscrivere il vincolo. Attualmente la libreria Scala non contiene annotazioni che usano questo tratto.
+<td align=left valign=top><p>Un tratto applicabile come annotazione ad altre annotazioni che definiscono vincoli su un tipo, basandosi solo sulle informazioni definite all&#8217;interno del tipo stesso anziché su informazioni esterne relative al contesto in cui il tipo viene definito o usato. Il compilatore può sfruttare questa restrizione per riscrivere il vincolo. Attualmente la libreria Scala non contiene annotazioni che usano questo tratto.
 <tr>
 <td align=left valign=top><p><code>unchecked</code>
 <td align=left valign=top><p><em>nessuno</em>
-<td align=left valign=top><p>Un marcatore da applicare al selettore in una istruzione di pattern matching (per esempio, la <code>x</code> in <code>x match {&hellip;}</code>) per omettere un messaggio di avvertimento del compilatore nel caso in cui le clausole <code>case</code> non siano &#8220;esaustive&#8221;. Durante l'esecuzione può ancora avvenire un errore di tipo <code>MatchError</code> se non esiste alcuna corrispondenza per un valore di <code>x</code> nelle clausole <code>case</code>. Si veda l'esempio più avanti.
+<td align=left valign=top><p>Un marcatore da applicare al selettore in una istruzione di pattern matching (per esempio, la <code>x</code> in <code>x match {&hellip;}</code>) per omettere un messaggio di avvertimento del compilatore nel caso in cui le clausole <code>case</code> non siano &#8220;esaustive&#8221;. Durante l&#8217;esecuzione può ancora avvenire un errore di tipo <code>MatchError</code> se non esiste alcuna corrispondenza per un valore di <code>x</code> nelle clausole <code>case</code>. Si veda l&#8217;esempio più avanti.
 <tr>
 <td align=left valign=top><p><code>unsealed</code>
 <td align=left valign=top><p><em>nessuno</em>
 <tr>
 <td align=left valign=top><p><code>deprecated</code>
 <td align=left valign=top><p><code>java.lang.Deprecated</code>
-<td align=left valign=top><p>Un marcatore applicabile a qualsiasi definizione per indicare che l'elemento definito è obsoleto. Il compilatore genererà un messaggio di avvertimento quando l'elemento viene usato.
+<td align=left valign=top><p>Un marcatore applicabile a qualsiasi definizione per indicare che l&#8217;elemento definito è obsoleto. Il compilatore genererà un messaggio di avvertimento quando l&#8217;elemento viene usato.
 <tr>
 <td align=left valign=top><p><code>inline</code>
 <td align=left valign=top><p><em>nessuno</em>
 <tr>
 <td align=left valign=top><p><code>SerialVersionUID</code>
 <td align=left valign=top><p>Un campo <em>statico</em> <code>serialVersionUID</code> in una classe
-<td align=left valign=top><p>Definisce un identificatore unico globale ai fini della serializzazione. Il costruttore dell'annotazione accetta un numero <code>Long</code> come argomento per rappresentare l'identificatore unico.
+<td align=left valign=top><p>Definisce un identificatore unico globale ai fini della serializzazione. Il costruttore dell&#8217;annotazione accetta un numero <code>Long</code> come argomento per rappresentare l&#8217;identificatore unico.
 <tr>
 <td align=left valign=top><p><code>switch</code>
 <td align=left valign=top><p><em>nessuno</em>
-<td align=left valign=top><p>Un'annotazione da applicare a un'espressione di pattern matching, come per esempio <code>(x: @switch) match {&#8230;}</code>. Quando è presente, il compilatore verificherà che il costrutto sia stato compilato sotto forma di una istruzione <code>switch</code> basata su tabella o su ricerca, generando un errore se il costrutto è stato compilato sotto forma di una serie di espressioni condizionali, che sono meno efficienti. Disponibile solo a partire da Scala 2.8.
+<td align=left valign=top><p>Un&#8217;annotazione da applicare a un&#8217;espressione di pattern matching, come per esempio <code>(x: @switch) match {&#8230;}</code>. Quando è presente, il compilatore verificherà che il costrutto sia stato compilato sotto forma di una istruzione <code>switch</code> basata su tabella o su ricerca, generando un errore se il costrutto è stato compilato sotto forma di una serie di espressioni condizionali, che sono meno efficienti. Disponibile solo a partire da Scala 2.8.
 <tr>
 <td align=left valign=top><p><code>specialized</code>
 <td align=left valign=top><p><em>nessuno</em>
-<td align=left valign=top><p>Un'annotazione da applicare ai parametri di tipo nei tipi e nei metodi parametrici. Induce il compilatore a generare versioni ottimizzate del tipo o del metodo per i tipi <code>AnyVal</code> corrispondenti ai tipi primitivi della piattaforma. Opzionalmente, è possibile limitare i tipi <code>AnyVal</code> per i quali verranno generate le implementazioni specializzate (si veda più avanti per una discussione in merito). Disponibile solo a partire da Scala 2.8.
+<td align=left valign=top><p>Un&#8217;annotazione da applicare ai parametri di tipo nei tipi e nei metodi parametrici. Induce il compilatore a generare versioni ottimizzate del tipo o del metodo per i tipi <code>AnyVal</code> corrispondenti ai tipi primitivi della piattaforma. Opzionalmente, è possibile limitare i tipi <code>AnyVal</code> per i quali verranno generate le implementazioni specializzate (si veda più avanti per una discussione in merito). Disponibile solo a partire da Scala 2.8.
 <tr>
 <td align=left valign=top><p><code>tailrec</code>
 <td align=left valign=top><p><em>nessuno</em>
-<td align=left valign=top><p>Un'annotazione applicabile ai metodi per indurre il compilatore a verificare che il metodo sia stato ottimizzato per la ricorsione in coda. Quando è presente, il compilatore genererà un errore se il metodo non può essere ottimizzato in un ciclo. Questo può succedere, per esempio, quando il metodo non è qualificato come <code>private</code> o <code>final</code>, quando può essere ridefinito, e quando l'invocazione ricorsiva non è realmente l'ultima istruzione del metodo. Disponibile solo a partire da Scala 2.8.
+<td align=left valign=top><p>Un&#8217;annotazione applicabile ai metodi per indurre il compilatore a verificare che il metodo sia stato ottimizzato per la ricorsione in coda. Quando è presente, il compilatore genererà un errore se il metodo non può essere ottimizzato in un ciclo. Questo può succedere, per esempio, quando il metodo non è qualificato come <code>private</code> o <code>final</code>, quando può essere ridefinito, e quando l&#8217;invocazione ricorsiva non è realmente l&#8217;ultima istruzione del metodo. Disponibile solo a partire da Scala 2.8.
 <tr>
 <td align=left valign=top><p><code>throws</code>
 <td align=left valign=top><p><code>throws</code> (parola chiave)
 </table>
 </div>
 
-<p>Tra le annotazioni disponibili solo a partire dalla versione 2.8 di Scala considerate <code>@tailrec</code>, usata nell'esempio seguente.
+<p>Tra le annotazioni disponibili solo a partire dalla versione 2.8 di Scala considerate <code>@tailrec</code>, usata nell&#8217;esempio seguente.
 
 <pre><code>import scala.annotation.tailrec
 
 }
 println(fib(5))</code></pre>
 
-<p>Notate che <code>fib</code> effettua il calcolo dei numeri di Fibonacci in maniera ricorsiva, ma la funzione non è ricorsiva in coda perché l'invocazione a se stessa non è l'ultima operazione eseguita nella seconda clausola <code>case</code>. Infatti, dopo essersi richiamata due volte, la funzione esegue una somma, perciò non è possibile effettuare l'ottimizzazione per la ricorsione in coda su questo metodo, e quando il compilatore vede l'annotazione <code>@tailrec</code> genera un errore informandoci del problema, come potete verificare se tentate di eseguire lo script.
+<p>Notate che <code>fib</code> effettua il calcolo dei numeri di Fibonacci in maniera ricorsiva, ma la funzione non è ricorsiva in coda perché l&#8217;invocazione a se stessa non è l&#8217;ultima operazione eseguita nella seconda clausola <code>case</code>. Infatti, dopo essersi richiamata due volte, la funzione esegue una somma, perciò non è possibile effettuare l&#8217;ottimizzazione per la ricorsione in coda su questo metodo, e quando il compilatore vede l&#8217;annotazione <code>@tailrec</code> genera un errore informandoci del problema, come potete verificare se tentate di eseguire lo script.
 
 <pre><samp>&hellip; 4: error: could not optimize @tailrec annotated method
 def fib(i: Int): Int = i match {
 }
 println(fib(5))</code></pre>
 
-<p>Questa volta annotiamo la variabile <code>i</code> nell'istruzione <code>match</code>, inducendo il compilatore a generare un errore nel caso non sia in grado di generare un costrutto <code>switch</code> nel bytecode a partire dai casi dell'istruzione <code>match</code>. In genere, i costrutti <code>switch</code> sono più efficienti rispetto alle espressioni condizionali. L'esecuzione di questo script produce l'uscita seguente.
+<p>Questa volta annotiamo la variabile <code>i</code> nell&#8217;istruzione <code>match</code>, inducendo il compilatore a generare un errore nel caso non sia in grado di generare un costrutto <code>switch</code> nel bytecode a partire dai casi dell&#8217;istruzione <code>match</code>. In genere, i costrutti <code>switch</code> sono più efficienti rispetto alle espressioni condizionali. L&#8217;esecuzione di questo script produce l&#8217;uscita seguente.
 
 <pre><samp>&hellip; 3: error: could not emit switch for @switch annotated match
 def fib(i: Int): Int = (i: @switch) match {
 
 <p>Evidentemente è necessario generare blocchi condizionali anziché un costrutto <code>switch</code>, a causa della guardia <code>if i &lt;= 1</code> che abbiamo inserito nella prima clausola <code>case</code>.
 
-<p>Diamo ora un'occhiata a un esempio di <code>@unchecked</code> in azione, adattato dalla pagina <em>Scaladoc</em> relativa a questa annotazione. Considerate il seguente frammento di codice.
+<p>Diamo ora un&#8217;occhiata a un esempio di <code>@unchecked</code> in azione, adattato dalla pagina <em>Scaladoc</em> relativa a questa annotazione. Considerate il seguente frammento di codice.
 
 <pre><code>&hellip;
 def process(x: Option[int]) = x match {
 }
 &hellip;</code></pre>
 
-<p>Grazie all'annotazione <code>@unchecked</code> applicata a <code>x</code> nel modo illustrato, il messaggio di avvertimento non viene emesso. Tuttavia, se <code>x</code> dovesse mai valere <code>None</code>, allora verrà lanciata una eccezione di tipo <code>MatchError</code>.
-
-<p>L'annotazione <code>@specialized</code> è un'altra delle annotazioni relative all'ottimizzazione aggiunte nella versione 2.8 di Scala e rappresenta una pratica soluzione di compromesso tra l'efficienza in termini di spazio e le prestazioni. In Java e in Scala l'implementazione di un tipo o di un metodo parametrico viene generata nel punto in cui è stato dichiarato (come abbiamo detto nella sezione <a href=cap-12.html#ParameterizedTypes>Capire i tipi parametrici</a> del capitolo 12), a differenza di quanto accade in C++, dove si sfrutta un <em>template</em> per generare l'implementazione dei parametri di tipo reali nei punti in cui il template viene usato. L'approccio del C++ ha il vantaggio di permettere la generazione di implementazioni ottimizzate per i tipi primitivi, ma ha lo svantaggio di produrre codice ipertrofico a causa di tutte le istanziazioni dei template.
-
-<p>La generazione di implementazioni &#8220;a richiesta&#8221; non è adatta ai linguaggi per la <abbr>JVM</abbr>, principalmente a causa della mancanza del passo di &#8220;collegamento&#8221; compiuto dal <em>linker</em> nei linguaggi compilati, durante il quale possono essere determinate le istanziazioni richieste di un template. Di solito, un tipo o un metodo parametrico Scala verrà tradotto in una singola implementazione usando <code>Any</code> per i parametri di tipo (in parte a causa della cancellazione di tipo a livello di bytecode); i generici Java funzionano allo stesso modo. Tuttavia, se il tipo o il metodo vengono usati con uno dei tipi <code>AnyVal</code>, per esempio <code>Int</code>, l'implementazione sarà penalizzata da inefficienti operazioni di conversione tra i tipi primitivi della piattaforma e i corrispondenti tipi oggetto avvolgenti.
-
-<p>Come alternativa, si potrebbe generare un'implementazione separata per ogni <code>AnyVal</code> corrispondente a un tipo primitivo, provocando però la già citata ipertrofia del codice se si considera, in particolare, quanto sarebbe raro per un'applicazione usare tutte quelle implementazioni. I creatori di Scala hanno dovuto affrontare questo dilemma, riuscendo infine a trovare un accomodamento.
-
-<p>L'annotazione <code>@specialized</code> rappresenta un pratico compromesso: l'utente può usarla per segnalare al compilatore che l'efficienza a tempo di esecuzione è più importante dell'efficienza in termini di spazio, inducendolo quindi a generare le implementazioni separate per ogni tipo primitivo corrispondente a <code>AnyVal</code>. Qui di seguito riportiamo un esempio di come usare l'annotazione.
+<p>Grazie all&#8217;annotazione <code>@unchecked</code> applicata a <code>x</code> nel modo illustrato, il messaggio di avvertimento non viene emesso. Tuttavia, se <code>x</code> dovesse mai valere <code>None</code>, allora verrà lanciata una eccezione di tipo <code>MatchError</code>.
+
+<p>L&#8217;annotazione <code>@specialized</code> è un&#8217;altra delle annotazioni relative all&#8217;ottimizzazione aggiunte nella versione 2.8 di Scala e rappresenta una pratica soluzione di compromesso tra l&#8217;efficienza in termini di spazio e le prestazioni. In Java e in Scala l&#8217;implementazione di un tipo o di un metodo parametrico viene generata nel punto in cui è stato dichiarato (come abbiamo detto nella sezione <a href=cap-12.html#ParameterizedTypes>Capire i tipi parametrici</a> del capitolo 12), a differenza di quanto accade in C++, dove si sfrutta un <em>template</em> per generare l&#8217;implementazione dei parametri di tipo reali nei punti in cui il template viene usato. L&#8217;approccio del C++ ha il vantaggio di permettere la generazione di implementazioni ottimizzate per i tipi primitivi, ma ha lo svantaggio di produrre codice ipertrofico a causa di tutte le istanziazioni dei template.
+
+<p>La generazione di implementazioni &#8220;a richiesta&#8221; non è adatta ai linguaggi per la <abbr>JVM</abbr>, principalmente a causa della mancanza del passo di &#8220;collegamento&#8221; compiuto dal <em>linker</em> nei linguaggi compilati, durante il quale possono essere determinate le istanziazioni richieste di un template. Di solito, un tipo o un metodo parametrico Scala verrà tradotto in una singola implementazione usando <code>Any</code> per i parametri di tipo (in parte a causa della cancellazione di tipo a livello di bytecode); i generici Java funzionano allo stesso modo. Tuttavia, se il tipo o il metodo vengono usati con uno dei tipi <code>AnyVal</code>, per esempio <code>Int</code>, l&#8217;implementazione sarà penalizzata da inefficienti operazioni di conversione tra i tipi primitivi della piattaforma e i corrispondenti tipi oggetto avvolgenti.
+
+<p>Come alternativa, si potrebbe generare un&#8217;implementazione separata per ogni <code>AnyVal</code> corrispondente a un tipo primitivo, provocando però la già citata ipertrofia del codice se si considera, in particolare, quanto sarebbe raro per un&#8217;applicazione usare tutte quelle implementazioni. I creatori di Scala hanno dovuto affrontare questo dilemma, riuscendo infine a trovare un accomodamento.
+
+<p>L&#8217;annotazione <code>@specialized</code> rappresenta un pratico compromesso: l&#8217;utente può usarla per segnalare al compilatore che l&#8217;efficienza a tempo di esecuzione è più importante dell&#8217;efficienza in termini di spazio, inducendolo quindi a generare le implementazioni separate per ogni tipo primitivo corrispondente a <code>AnyVal</code>. Qui di seguito riportiamo un esempio di come usare l&#8217;annotazione.
 
 <pre><code>class SpecialCollection[@specialized +T](&hellip;) {
   &hellip;
 }</code></pre>
 
-<p>Al momento della scrittura, l'implementazione degli assemblaggi &#8220;notturni&#8221; di Scala 2.8 supporta solo la generazione di implementazioni specializzate per <code>Int</code> e <code>Double</code>, ma per il rilascio finale della versione 2.8 si prevede di supportare anche gli altri tipi derivati da <code>AnyVal</code>, oltre a offrire all'utente la possibilità di specificare i tipi per i quali richiedere la generazione delle implementazioni ottimizzate, evitandogli così di ritrovarsi con implementazioni inutilizzate per qualche sottoclasse di <code>AnyVal</code>. Si veda la documentazione <em>Scaladoc</em> della versione 2.8 definitiva per i dettagli sull'insieme di caratteristiche effettivamente supportate.
-
-<p>Un'altra annotazione prevista per la versione 2.8 è <code>@cps</code>, il cui nome è l'acronimo dell'inglese <em>continuation passing style</em> (stile a passaggio di continuazioni). Sarà una direttiva interpretata da un plug-in del compilatore che attiverà la generazione di bytecode basato sulle continuazioni per le invocazioni dei metodi al posto del bytecode predefinito basato su un modello a stack. L'annotazione non avrà effetto a meno che non venga usato il corrispondente plug-in di <kbd>scalac</kbd>. Non appena sarà disponibile, consultate la documentazione della versione definitiva di Scala 2.8 per ottenere maggiori informazioni su questa funzione.
-
-<p>Per comprendere l'annotazione <code>@throws</code> è importante ricordare che Scala, a differenza di Java, non dispone di eccezioni controllate, né di una clausola <code>throws</code> per le dichiarazioni di metodo. Questo non costituisce un problema nel caso in cui un metodo Scala invochi un metodo Java che dichiara di lanciare un'eccezione controllata, in quanto Scala tratterà questa eccezione come non controllata. Tuttavia, supponete che il metodo Scala in questione non catturi l'eccezione ma la lasci passare: cosa succede se questo metodo Scala viene invocato da altro codice Java?
-
-<p>Diamo un'occhiata a un esempio in cui si verifica questa situazione, relativa all'eccezione controllata <code>java.io.IOException</code>. La classe Scala riportata di seguito stampa il contenuto di un <code>java.io.File</code>.
+<p>Al momento della scrittura, l&#8217;implementazione degli assemblaggi &#8220;notturni&#8221; di Scala 2.8 supporta solo la generazione di implementazioni specializzate per <code>Int</code> e <code>Double</code>, ma per il rilascio finale della versione 2.8 si prevede di supportare anche gli altri tipi derivati da <code>AnyVal</code>, oltre a offrire all&#8217;utente la possibilità di specificare i tipi per i quali richiedere la generazione delle implementazioni ottimizzate, evitandogli così di ritrovarsi con implementazioni inutilizzate per qualche sottoclasse di <code>AnyVal</code>. Si veda la documentazione <em>Scaladoc</em> della versione 2.8 definitiva per i dettagli sull&#8217;insieme di caratteristiche effettivamente supportate.
+
+<p>Un&#8217;altra annotazione prevista per la versione 2.8 è <code>@cps</code>, il cui nome è l&#8217;acronimo dell&#8217;inglese <em>continuation passing style</em> (stile a passaggio di continuazioni). Sarà una direttiva interpretata da un plug-in del compilatore che attiverà la generazione di bytecode basato sulle continuazioni per le invocazioni dei metodi al posto del bytecode predefinito basato su un modello a stack. L&#8217;annotazione non avrà effetto a meno che non venga usato il corrispondente plug-in di <kbd>scalac</kbd>. Non appena sarà disponibile, consultate la documentazione della versione definitiva di Scala 2.8 per ottenere maggiori informazioni su questa funzione.
+
+<p>Per comprendere l&#8217;annotazione <code>@throws</code> è importante ricordare che Scala, a differenza di Java, non dispone di eccezioni controllate, né di una clausola <code>throws</code> per le dichiarazioni di metodo. Questo non costituisce un problema nel caso in cui un metodo Scala invochi un metodo Java che dichiara di lanciare un&#8217;eccezione controllata, in quanto Scala tratterà questa eccezione come non controllata. Tuttavia, supponete che il metodo Scala in questione non catturi l&#8217;eccezione ma la lasci passare: cosa succede se questo metodo Scala viene invocato da altro codice Java?
+
+<p>Diamo un&#8217;occhiata a un esempio in cui si verifica questa situazione, relativa all&#8217;eccezione controllata <code>java.io.IOException</code>. La classe Scala riportata di seguito stampa il contenuto di un <code>java.io.File</code>.
 
 <pre><code>// <a href=esempi/cap-13/file-printer.scala>esempi/cap-13/file-printer.scala</a>
 
   }
 }</code></pre>
 
-<p>L'annotazione <code>@throws</code> viene applicata al metodo <code>print</code> e l'argomento del suo costruttore è un singolo oggetto <code>java.lang.Class[Any]</code>, in questo caso <code>classOf[IOException]</code> poiché i metodi della <abbr>API</abbr> Java di I/O usati da <code>print</code> e il metodo privato <code>loop</code> potrebbero lanciare questa eccezione.
-
-<p>Notate che <code>loop</code> usa una ricorsione in coda in stile funzionale anziché un ciclo. Nessuna variabile è stata modificata durante la produzione del testo in uscita! (A dire il vero, non sappiamo cosa succeda realmente all'interno delle classi di I/O di Java&hellip;)
+<p>L&#8217;annotazione <code>@throws</code> viene applicata al metodo <code>print</code> e l&#8217;argomento del suo costruttore è un singolo oggetto <code>java.lang.Class[Any]</code>, in questo caso <code>classOf[IOException]</code> poiché i metodi della <abbr>API</abbr> Java di I/O usati da <code>print</code> e il metodo privato <code>loop</code> potrebbero lanciare questa eccezione.
+
+<p>Notate che <code>loop</code> usa una ricorsione in coda in stile funzionale anziché un ciclo. Nessuna variabile è stata modificata durante la produzione del testo in uscita! (A dire il vero, non sappiamo cosa succeda realmente all&#8217;interno delle classi di I/O di Java&hellip;)
 
 <p>Ecco una classe Java che usa <code>FilePrinter</code> in un metodo <code>main</code>.
 
 
 <pre><samp>scala -cp build FilePrinterMain annotations/FilePrinterMain.java</samp></pre>
 
-<p>Dovreste ottenere l'uscita seguente.
+<p>Dovreste ottenere l&#8217;uscita seguente.
 
 <pre><samp> 1: import java.io.*;
  2:
 14:   }
 15: }</samp></pre>
 
-<p>Ora, tornando alla classe <code>FilePrinter</code>, supponete di nascondere l'annotazione <code>@throws</code> in un commento. Il file che contiene quella classe verrà ancora compilato, ma tentando di compilare <span class=file>FilePrinterMain.java</span> otterrete l'errore seguente.
+<p>Ora, tornando alla classe <code>FilePrinter</code>, supponete di nascondere l&#8217;annotazione <code>@throws</code> in un commento. Il file che contiene quella classe verrà ancora compilato, ma tentando di compilare <span class=file>FilePrinterMain.java</span> otterrete l&#8217;errore seguente.
 
 <pre><samp>annotations/FilePrinterMain.java:9: exception java.io.IOException is never
 thrown in body of corresponding try statement
 
 <p>Nonostante sia ancora possibile che <code>FilePrinter</code> lanci una <code>java.io.IOException</code>, il bytecode generato da <kbd>scalac</kbd> non contiene questa informazione, perciò <kbd>javac</kbd> conclude la propria analisi deducendone erroneamente che <code>IOException</code> non viene mai lanciata.
 
-<p>Lo scopo di <code>@throws</code>, quindi, è quello di inserire nel bytecode che verrà letto da <kbd>javac</kbd> l'informazione sulle eccezioni controllate che possono essere lanciate.
+<p>Lo scopo di <code>@throws</code>, quindi, è quello di inserire nel bytecode che verrà letto da <kbd>javac</kbd> l&#8217;informazione sulle eccezioni controllate che possono essere lanciate.
 
 <blockquote class=note>
-<p><span class=u>&#x261E;</span>In un ambiente misto Java/Scala considerate l'ipotesi di aggiungere l'annotazione <code>@throws</code> a tutti i vostri metodi Scala che possono lanciare eccezioni controllate Java. Prima o poi qualche porzione di codice Java finirà probabilmente per invocare uno di quei metodi.
+<p><span class=u>&#x261E;</span>In un ambiente misto Java/Scala considerate l&#8217;ipotesi di aggiungere l&#8217;annotazione <code>@throws</code> a tutti i vostri metodi Scala che possono lanciare eccezioni controllate Java. Prima o poi qualche porzione di codice Java finirà probabilmente per invocare uno di quei metodi.
 </blockquote>
 
 <h2 id=EnumerationsVsPatternMatching>Un confronto tra enumerazioni e pattern matching</h2>
 
-<p>Le enumerazioni consentono di definire un insieme finito di valori costanti e rappresentano un'alternativa leggera alle classi <code>case</code>. Usando un'enumerazione potete fare riferimento direttamente ai valori, attraversarli in un'iterazione, accedervi tramite un indice intero, <span class=baa>&amp;</span>c.
+<p>Le enumerazioni consentono di definire un insieme finito di valori costanti e rappresentano un&#8217;alternativa leggera alle classi <code>case</code>. Usando un&#8217;enumerazione potete fare riferimento direttamente ai valori, attraversarli in un&#8217;iterazione, accedervi tramite un indice intero, <span class=baa>&amp;</span>c.
 
 <p>Proprio come per le annotazioni, la forma delle enumerazioni di Scala è basata sulle classi e su un particolare insieme di idiomi anziché su parole chiave speciali da applicare alla definizione, come invece accade per le enumerazioni in Java e .NET. Tuttavia, in Scala potete anche usare le enumerazioni definite su quelle due piattaforme.
 
-<p>Le enumerazioni di Scala si definiscono estendendo la classe astratta <code>scala.Enumeration</code> e si possono costruire in diversi modi. Vi mostreremo l'idioma che ricalca più da vicino le forme usate in Java e .NET che potreste già conoscere.
-
-<p>A questo scopo riprenderemo gli script per i metodi <abbr>HTTP</abbr> che abbiamo realizzato nella sezione <a href=cap-7.html#SealedClassHierarchies>Gerarchie di classi sigillate</a> del capitolo 7. Se ricordate, avevamo definito l'insieme dei metodi di <abbr>HTTP</abbr> 1.1 usando una gerarchia sigillata di classi <code>case</code>.
+<p>Le enumerazioni di Scala si definiscono estendendo la classe astratta <code>scala.Enumeration</code> e si possono costruire in diversi modi. Vi mostreremo l&#8217;idioma che ricalca più da vicino le forme usate in Java e .NET che potreste già conoscere.
+
+<p>A questo scopo riprenderemo gli script per i metodi <abbr>HTTP</abbr> che abbiamo realizzato nella sezione <a href=cap-7.html#SealedClassHierarchies>Gerarchie di classi sigillate</a> del capitolo 7. Se ricordate, avevamo definito l&#8217;insieme dei metodi di <abbr>HTTP</abbr> 1.1 usando una gerarchia sigillata di classi <code>case</code>.
 
 <pre><code>// <a href=esempi/cap-7/sealed/http-script.scala>esempi/cap-7/sealed/http-script.scala</a>
 
 
 methods.foreach { method =&gt; handle(method) }</code></pre>
 
-<p>In quell'esempio ogni metodo aveva un attributo <code>body</code> per il corpo del messaggio. Qui ipotizzeremo che il corpo venga gestito in altri modi: ci interessa solo identificare il tipo di metodo <abbr>HTTP</abbr>. Quindi, ecco una classe <code>Enumeration</code> per i metodi di <abbr>HTTP</abbr> 1.1.