Zėŋōfōbìå

1 dicembre 2009

Perl is a four letter word. Or six.

Filed under: architettura, Linguaggi, Perl — Tag:, — Zeno @ 19:27

Sto chiaccherando su facebook con Francesco Oha sul Perl 6, versione che rivoluziona il linguaggio e, visto l’interesse che ho per l’argomento ho pensato di spostare sul Blog la conversazione, per coinvolgere chiunque sia interessato. (Rodi, parlo con te. ;-)

Io sono praticamente fermo al Perl 4, che è stato il mio primo linguaggio dinamico. Ne ho abusato, come ogni pessimo programmatore. Mi sono accorto che nel frattempo il Perl si è evoluto enormemente, anche grazie alla splendida comunità che si è consolidata. Ho letto il libro introduttivo di Stefano Rodighiero, e ho riassaporato il gusto del dinamismo portato alle estreme conseguenze.

Da diversi anni la comunità Perl, una delle più affascinanti in tutto il panorama hacker mondiale, sta lavorando alla versione 6, che si distingue dalla versione 5 per un numero impressionante di differenze. Non credo di dire un eresia nel sostenere che la versione 6 sia un linguaggio nuovo ispirato alle versioni precedenti.

Francesco, solleticando la mia attenzione con la frase “[…]il sorgente puo’ modificare in linea la grammatica del compilatore, rendendo dinamico non solo l’eseguito ma anche il compilante.“,  mi propone di leggere un testo introduttivo: http://perlgeek.de/en/article/5-to-6 .

La mia considerazione conseguente alla lettura è stata:

Sto guardando, stavo leggendo, tutto bene, le stringhe, gli array i tipi, sì… I TIPI? AH! finalmente!

Bello che la trasformazione di Schwartz viene fatta dal compilatore, è un’idea geniale, ma l’implementazione non spetta al programmatore. Non riesco a capire però perché non poteva essere fatta dal compilatore già dal perl 5. Qualcuno me lo spiega?

Però, decisamente più bello del 5! Le prestazioni poi saranno eccezionali, paragonabili al C, immagino…

La sintassi è ancora troppo criptica, però. Ti faccio un esempio: i Context e i twigils, il cross meta operator (come fai a vederlo? non si poteva usare lo zip di haskell?)

Uè, le liste lazy, bene! Le adoro.
L’overload degli operatori…
Che spettacolo le regexpes, si fanno i parser al volo!!!
Il reduction meta operator non l’avevo ancora visto, modo strano per fare folding.

Molto paradigma funzionale, ma rielaborato. Le funzioni diventano operatori. questo fa perdere un po’ di espressività, temo.

Francesco Oha mi fa notare che:

[…] trovo piu’ spiacevoli ancora i puntatori C e gli unari affini.

per come la vedo io, per ora, il perl6 e’ ancora un calderone… ci vorra’ ancora molto prima che esca quello che serve, ma gia’ solo per le RegExp e’ sensazionale (e il compilatore e’ fatto con quelle regexp, quindi puoi overloadare il compilatore, ed essendo dinamico puoi capire l’esoterismo che si puo’ ottenere)

Che ne dite? Proseguiamo con il discorso?

30 novembre 2009

F# e C# nello stesso progetto DDD

Filed under: architettura, C#, F#, informatica, Pattern — Tag:, — Zeno @ 11:37

Ho postato una domanda su StackOverflow su come pensare una soluzione che incorpori parti in C# e parti in F#.

Mi chiedo, in sostanza, se abbia senso pensare all’utilizzo di F# in una architettura DDD.

(more…)

20 gennaio 2009

Contract Checking

Filed under: C#, DbC, informatica — Tag:, — Zeno @ 18:03

Guardando il webcast di PDC2008 relativo al Contract Checking and Automated Test Generatione with Pex mi sono chiariti una serie di aspetti relativi al DbC. Intanto pare proprio che la libreria Code Contract Library di cui parlavo nell’articolo Design By Contract verrà inclusa nella versione 4 di .NET 4.0 come core component. Poi viene spiegato che una ragione per usare questa tecnica è che fornendo maggiori informazioni sulla “semantica” del programma (vedi gli axioms del C++0x) si può aiutare il compilatore a fare scelte performanti, ma anche  generare in automatico dei test case. In particolare viene proposto Pex.

L’uso dei Contract serve quindi per:

  • run time checking
  • static checking
  • documentation generation

Il webcast specifica bene il significato di alcuni “contract”:

Requires

  • Ciò che deve essere vero all’entrata di un metodo

Ensures:

  • Ciò che deve essere vero all’uscita del metodo
  • Può specificare un comportamento quando viene lanciata un’eccezione

Invariants:

  • Ciò che deve essere vero per tutti i metodi della classe (inclusi i tipi derivati)

Interessante il fatto che impostando un contratto su un metodo virtuale della classe, anche gli override lo ereditano.

Come per gli Assert del C, la release non viene appesantita dai contracts.

17 gennaio 2009

Design by Contract

Filed under: C#, DbC, informatica — Tag:, — Zeno @ 19:41

Chiacchierando con JP sul suo blog, cercando di parlare male dei linguaggi che ci danno da vivere, siamo incappati nella questione del DbC.

Design By Contract (DbC) è una tecnica di programmazione adottata per la prima volta dal linguaggio Eiffel, che permette di definire delle condizioni a contorno del codice che debbano essere garantite durante tutta la sua esecuzione. I linguaggi e le estensioni che ammettono il DbC in genere permettono di definire:

– precondizioni : condizioni in entrata di funzione, possono essere dei limiti sulle variabili in ingresso.

– postcondizioni : garanzie fornite in uscita di funzione, che definiscono, per esempio, l’insieme dei valori d’uscita ed eventuali side effect.

– invarianti : certezze che devono essere mantenute durante l’esecuzione (per esempio il limite sui side effects)

Interessante il fatto che, in presenza di ereditarietà, le precondizioni degli ancestor possono essere strette, le postcondizioni allargate.

Questa tecnica sembra essere pronta per una rinascita, dal momento che sia il C++ che C# si stanno evidentemente preparando ad estendersi in questa direzione.

C++0x, infatti, incorpora i “concept”, che sono una estensione dei templates, certamente utili per fornire, tramite tecniche di metaprogrammazione, robusti metodi formali per garantire la correttezza del codice.

C#, a sua volta, pare che nella versione 4 incorpori una libreria, chiamata Code Contract Library, che è già disponibile al download. (Allego il contractsmanual  )

Ovviamente, simulare il DbC usando l’equivalente delle ASSERT del C, è possibile, in parte limitante, certamente inefficace: se la garanzia formale di correttezza venisse garantita staticamente i vantaggi sarebbero enormi. Un buon DbC effettuerà una parte di controlli staticamente, il resto runtime.

Come funziona il controllo statico? Questa è la domanda che più mi incuriosisce e mi immagino che la risposta sia sufficientemente interessante da farmi provare questa tecnica appena possibile.

Installando la CCL (Microsoft Research), oltre all’installazione della libreria e della documentazione pdf, viene integrato in VS2008 uno strumento atto alla gestione del DbC. In particolare, nelle propietà del progetto, viene aggiunta una nuova sezione, che permette di abilitare:

– dynamic check (con la possibilità di definire delle asserzioni implicite)

– static check.

Se si costruisce un metodo che ha tra le precondizioni un valore maggiore di 0 e gli si passa un valore negativo il DbC statico identifica il problema. (Spesso basterebbe aver modo di definire i range dei tipi, come in Ada , io credo, e avere un controllo statico sui boundaries. ).

Se per esempio una funzione con una postcondizione che limita l’ouput ad un intero minore di 10 viene passata come argomento ad una funzione che tra le precondizioni vuole un intero maggiore di 10, possiamo immaginare che esiste un possibile controllo statico che blocchi la compilazione di fronte a questa incongruenza.

Ho provato ad installare la libreria e a scrivere questo snippet:

internal double logarithm(double c)
{
  CodeContract.Requires(c  > 0);
  return Math.Log(c);
}

internal double negative(double a)
{
  CodeContract.Ensures(CodeContract.Result<double>() <= 0 );
  if (a > 0)
    return (-a);
  else
    return a;
}

Mi aspetterei un errore alla riga dove scrivo :

double c=logarithm(negative(123.0));

E in effetti ho un warning: requires unproven

Cioè viene detto che non è certo che i requisiti in ingresso del logaritmo siano provati.

Ovviamente ottengo l’errore runtime, ma, francamente mi aspettavo un errore un po’ più visibile.

Probabilmente la tecnologia è ancora troppo sperimentale, o forse non ho usato la keyword giusta, ma d’altra parte, mi pare che non sia ancora possibile scrivere un programma che sappia esprimersi sulla correttezza di un altro programma. ;-)

L’implementazione della libreria, per la parte runtime, è molto semplice, non aggiunge più overhead di quello di un’assert e l’impatto nella versione di release è praticamente nullo.

Credo quindi che abbia senso utilizzarla fin da adesso, se non altro per favorire la documentazione.

Blog su WordPress.com.