Il progetto consiste nel creare una libreria che costruisca una struttura rappresentate un URI (Uniform resource identifier), attraverso un processo di analisi sintattica (Parsing) a partire da una grammatica definita nel testo del progetto e/o dagli standard RFC. In caso che l'URI rispetti la grammatica data identifica i seguenti elementi:
- Scheme
- Userinfo
- Host
- Port
- Path
- Query
- Fragment
la funzione principale "uri-parse" riceve in input una stringa e richiama la funzione "helper-scheme" che a sua volta chiamerà la funzione che identifica scheme e, in base al valore di ritorno di quest'ultimo richiamerà le funzioni per il parsing del tipo URI1, di uno schema speciale o se null darà errore; per esempio nel casp di un URI di tipo URI1 verrà chiamata una funzione che chiamera il parsing dei singoli elementi da cui è formato e li restituirà in una lista con gli elementi in ordine come descritti nella sezione introduzione (in caso di valore mancate al suo posto ritornerà nil) Nonostante uri-parse sia la funzione principale un'importante menzione da fare riguarda la funzione identificatore, che fa comprendere l'approcio al progetto, nel caso di lisp è carattere per carattere, definendo in particolare caratteri non ammessi e caratteri delimitatori, i primi con il solo obiettivo di rispettare la grammatica data, mentre i secondi sono serviti per suddividere la stringa nei suoi elementi singoli.
- le funzioni con helper nel nome sono considerate funzioni ausiliarie
- viene inteso come "subdomain" l'unione di path query e fragment (nonostante non sia proprio il termine corretto)
- path query e fragment vengono "riuniti" poiché mi sembrava più coerente con la grammatica specificata nel progetto (ma vengono poi controllati e parsati singolarmente)
- le stringe sono considerate nel programma come liste di caratteri in modo tale che sia possibile riutilizzare il rimanente della stringa totale dopo aver parsato un singolo elemento senza ricorrere all'utilizzo di sottostringhe
- per una migliora leggibilità del codice (dato che Lisp "costringe" a scrivere le funzioni di alto livello dopo le funzioni di basso livello) ho cercato, anche solo tramite i commenti, di dividere il codice in sezioni
l'implementazione del progetto avviene attraverso le Prolog definite clause grammar (DCG) poichè risultate ad hoc per raggiungere il fine del progetto
La funzione principale è uri_parse/2 che prende in input una stringa e la ritorna scomposta nelle parti precedentemente citate (se un componente non è nella stringa allora restituisce "[]". Un esempio potrebbe essere:
uri_parse("http://google.it", X).
X = uri(http, [], 'google.com', '80', [], [], []).
- le DCG con helper nel nome sono considerate funzioni ausiliarie
- viene inteso come "subdomain" l'unione di path query e fragment (nonostante non sia proprio il termine corretto)
- path query e fragment vengono "riuniti" poiché mi sembrava più coerente con la grammatica specificata nel progetto (ma vengono poi controllati e parsati singolarmente)
- le stringe sono considerate nel programma come liste di caratteri in modo tale che sia possibile riutilizzare il rimanente della stringa totale dopo aver parsato un singolo elemento senza ricorrere all'utilizzo di sottostringhe