Il LISP è ancora attuale come linguaggio?

[Massimo Soricetti]

Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente. Poi ho pensato
anche all'Haskell e allo Scheme, e poi ho pensato che sicuramente ce ne
sono anche altri che non conosco. E ho pensato che probabilmente i
"nuovi" linguaggi funzionali sono migliori. Va bene che non lo imparo
per lavoro, ma non vorrei ritrovarmi con un linguaggio-mausoleo in cui
si programma male e con fatica...

Ora come ora conosco Pascal, C, C++, asm x86, un pò di VBA, Delphi, PHP,
Javascript e Prolog, ma attualmente uso soprattutto il C++ e il VBA,
mentre gli altri sono un pò sbiaditi dal tempo.

Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

[Lawrence Oluyede]

Post by Massimo Soricetti
Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente. Poi ho pensato
anche all'Haskell e allo Scheme, e poi ho pensato che sicuramente ce ne
sono anche altri che non conosco. E ho pensato che probabilmente i
"nuovi" linguaggi funzionali sono migliori. Va bene che non lo imparo
per lavoro, ma non vorrei ritrovarmi con un linguaggio-mausoleo in cui
si programma male e con fatica...

Il LISP è una famiglia di linguaggi che comprende tra i più famosi
Common Lisp e Scheme e i più recenti Clojure e Lisp.NET o che.

Post by Massimo Soricetti
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

Beh dipende da cosa ti serve. Haskell è sicuramente interessante e
mind-challenging, Scheme lo vedo un po più didattico e fine a sé stesso,
Common Lisp ha sicuramente più librerie, Clojure sta andando ora di moda
perché è basato sulla JVM. In più c'è Erlang di cui hai sicuramente
sentito parlare. Hai saltato in toto i linguaggi funzionali della
famiglia ML, ma non li conosco quindi mi astengo.

[Massimo Soricetti]

Post by Lawrence Oluyede
Il LISP è una famiglia di linguaggi che comprende tra i più famosi
Common Lisp e Scheme e i più recenti Clojure e Lisp.NET o che.

Lisp.NET? Questa non la sapevo... informarmi devo.

Post by Lawrence Oluyede
Beh dipende da cosa ti serve. Haskell è sicuramente interessante e
mind-challenging, Scheme lo vedo un po più didattico e fine a sé stesso,
Common Lisp ha sicuramente più librerie, Clojure sta andando ora di moda
perché è basato sulla JVM. In più c'è Erlang di cui hai sicuramente
sentito parlare. Hai saltato in toto i linguaggi funzionali della
famiglia ML, ma non li conosco quindi mi astengo.

Sono contento di sapere che in famiglia stanno tutti bene (dei linguaggi
funzionali intendo). A me interessava apprendere il paradigma di
programmazione funzionale, e il modo migliore è prendere un linguaggio
funzionale e programmarci. Quindi mi va bene un linguaggio didattico
come Scheme. Il Lisp.NET di cui hai parlato mi permetterebbe di usare le
classi del framework .NET (giusto?) quindi sarebbe più direttamente
"spendibile"... cosa in fin dei conti non disprezzabile.

Ma quello che mi premeva era, come dicevo, la sicurezza di non mettermi
a studiare, per ignoranza della materia, un linguaggio fossile. Non so
se esiste un analogo funzionale del PL/1 ma non mi andrebbe di scoprirlo
a mie spese.

[Lawrence Oluyede]

Post by Massimo Soricetti
Lisp.NET? Questa non la sapevo... informarmi devo.

Credo che quel progetto <http://www.lsharp.org/> sia un po' defunto
però, F# è sicuramente più noto e diffuso:
http://msdn.microsoft.com/en-us/fsharp/default.aspx

Post by Massimo Soricetti
Sono contento di sapere che in famiglia stanno tutti bene (dei linguaggi
funzionali intendo). A me interessava apprendere il paradigma di
programmazione funzionale, e il modo migliore è prendere un linguaggio
funzionale e programmarci. Quindi mi va bene un linguaggio didattico
come Scheme.

Sicuramente Scheme è più didattico. Su stacktrace.it trovi una intera
serie di articoli a proposito: <http://stacktrace.it/tag/scheme/>

Post by Massimo Soricetti
Il Lisp.NET di cui hai parlato mi permetterebbe di usare le
classi del framework .NET (giusto?) quindi sarebbe più direttamente
"spendibile"... cosa in fin dei conti non disprezzabile.

Vedi F#

Post by Massimo Soricetti
Ma quello che mi premeva era, come dicevo, la sicurezza di non mettermi
a studiare, per ignoranza della materia, un linguaggio fossile. Non so
se esiste un analogo funzionale del PL/1 ma non mi andrebbe di scoprirlo
a mie spese.

Non credo che ci siano fossili tra quelli elencati. Solo più o meno
utili. Se pensi la famiglia dei LISP ha 50 anni...

[Giovanni Zezza]

Massimo Soricetti, nel messaggio

Post by Massimo Soricetti
Sono contento di sapere che in famiglia stanno tutti bene (dei linguaggi
funzionali intendo). A me interessava apprendere il paradigma di
programmazione funzionale, e il modo migliore è prendere un linguaggio
funzionale e programmarci.

Allora forse Lisp (che NON è rigorosamente un linguaggio funzionale,
non foss'altro per il fatto che ha variabili) non è la scelta giusta.
Se l'interesse è principalmente didattico (capire di che si tratta),
forse è meglio cominciare con un linguaggio funzionale puro,
trascurando la questione sulla maggiore o minore "attualità" o utilità
pratica.

Non me ne intendo molto, e lascio quindi ad altri il dibattito su
quale sia il linguaggio più funzionale (Haskell, comunque, mi sembra
un candidato migliore di Scheme), ma mi pare che, posta la cosa in
questi termini, il punto principale sia questo.

Post by Massimo Soricetti
http://www.b-list.org/weblog/2006/oct/11/functional-language-s-right-under-your-nose/

Elementi di programmazione funzionale possono essere rintracciati in
più o meno qualunque linguaggio.

Ciao.

[Manlio Perillo]

Post by Massimo Soricetti
Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente. Poi ho pensato
anche all'Haskell e allo Scheme, e poi ho pensato che sicuramente ce ne
sono anche altri che non conosco. E ho pensato che probabilmente i
"nuovi" linguaggi funzionali sono migliori. Va bene che non lo imparo
per lavoro, ma non vorrei ritrovarmi con un linguaggio-mausoleo in cui
si programma male e con fatica...
[...]
re gli altri sono un pò sbiaditi dal tempo.
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

Come ti ha detto Lawrence, il LISP è ancora attuale.
Io personalmente sto studiando Haskell, e lo trovo molto interessante;
inoltre la comunità è molto attiva ed si fa molta ricerca (inclusa la
Microsoft).

Sto valutanto anche Erlang.


Per quanto riguarda Haskell, comunque, non sono ancora riuscito ad usarlo
per un progetto serio; avevo in mente di usarlo in un paio di progetti
(personali) ma sto optando per Python, che conosco molto meglio.




Ciao Manlio

[Massimo Soricetti]

Post by Manlio Perillo
Io personalmente sto studiando Haskell, e lo trovo molto interessante;
inoltre la comunità è molto attiva ed si fa molta ricerca (inclusa la
Microsoft).

Sì, ma tu lo consiglieresti Haskell a uno che non sa nulla di
programmazione funzionale, tanto per cominciare?

Post by Manlio Perillo
Sto valutanto anche Erlang.

Nome sentito, ma niente di più.

[Manlio Perillo]

Post by Massimo Soricetti

Post by Manlio Perillo
Io personalmente sto studiando Haskell, e lo trovo molto interessante;
inoltre la comunità è molto attiva ed si fa molta ricerca (inclusa la
Microsoft).

Sì, ma tu lo consiglieresti Haskell a uno che non sa nulla di
programmazione funzionale, tanto per cominciare?

Direi di si.
Nel mio caso è stato così, almeno; non avevo esperienza diretta con
linguaggi funzionali.

Un pò di numeri (si, io quando imparo un nuovo linguaggio parto dalla sua
definizione).

La definizione di Haskell 98:
http://haskell.org/haskellwiki/Language_and_library_specification

è relativamente piccola (circa 148 pagine, esclusa la libreria standard).

Di contro, la definizione di Standard ML (1990) è di circa 86 pagine;
la definizione di Scheme (Revised Report 5) è circa 90 pagine.


Tra questi linguaggi, probabilmente Haskell è quello con la comunità più
attiva; ha anche una libreria sviluppata da terzi molto ampia e ben
organizzata:
http://hackage.haskell.org/

Francamente, ho trovato la comunità di haskell, e l'ambiente offerto da
GHC veramente ottimi, superiori a quanto ho visto altrove.

Di recente hanno publicato un libro:
http://www.realworldhaskell.org/

L'ho letto online è l'ho trovato ben scritto, anche se un paio di
capitoli mi hanno un pò deluso.


Haskell è comunque abbastanza difficile da padroneggiare.


Un altro linguaggio funzionale (ma non solo) che ha un grosso (beh, si
parla relativamente) è Ocaml.


Un aspetto interessante di Haskell (in particolare di GHC, il suo
compilatore principale) è il suo supporto alla programmazione parallela.

Di recente hanno implementato un garbage collector parallelo, ed è allo
studio il supporto per il "nested data parallelism":
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

GHC supporta da diverso tempo la parallelizazione del codice e software
transactional memory.
C'è un bel capitolo in Real World Haskell:
http://book.realworldhaskell.org/read/concurrent-and-multicore-
programming.html#id675076

in particolare una semplice implementazione di map reduce.


GHC supporta anche la programmazione concorrente, usando micro threads.
E uno dei pochi linguaggi ad offrire una implementazione dei micro thread
efficiente (l'altro esempio notevole è Erlang):
http://shootout.alioth.debian.org/u64q/benchmark.php?
test=threadring&lang=all





Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Un altro linguaggio funzionale (ma non solo) che ha un grosso (beh, si
parla relativamente) è Ocaml.

Se non sei francese non vale la pena di usarlo. <g>

Scherzi a parte, e' il C++ dei linguaggi funzionali: pieno di feature,
complesso da capire quando usare una o l'altra. Piuttosto pragmatico, ma
non abbastanza. Mono-implementazione sostanzialmente... boh.

[Manlio Perillo]

Post by Enrico Franchi

Post by Manlio Perillo
Un altro linguaggio funzionale (ma non solo) che ha un grosso (beh, si
parla relativamente) è Ocaml.

Se non sei francese non vale la pena di usarlo. <g>
Scherzi a parte, e' il C++ dei linguaggi funzionali: pieno di feature,
complesso da capire quando usare una o l'altra. Piuttosto pragmatico, ma
non abbastanza. Mono-implementazione sostanzialmente... boh.

Un utilizzatore di Ocaml, con cui ho discusso durante la PyFiorentina,
non era molto d'accordo su questo punto di vista.



Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Un utilizzatore di Ocaml, con cui ho discusso durante la PyFiorentina,
non era molto d'accordo su questo punto di vista.

Ero io o no? :P

Poi capisco che se a uno piace piace. Ma a OCaml preferisco SML (molto
piu' pulito e facile da apprendere). Certo, le implementazioni di OCaml
sono piu' efficienti (anche di quelle di Haskell, che io ricordi) e sono
maggiormente supportate.

[Manlio Perillo]

Post by Enrico Franchi

Post by Manlio Perillo
Un utilizzatore di Ocaml, con cui ho discusso durante la PyFiorentina,
non era molto d'accordo su questo punto di vista.

Ero io o no? :P

No.

Post by Enrico Franchi
[...]

Ciao Manlio

[Enrico Franchi]

Post by Massimo Soricetti
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

Beh, in tanti ne abbiamo usati. Fra i linguaggi funzionali
sostanzialmente puri io suggerirei Haskell o Erlang.

Sono entrambi molto divertenti, IMHO. Erlang e' un linguaggio con
un'utilita' pratica piuttosto spiccata, facile da imparare (abbastanza,
per lo meno) facile da trovare subito cose "utili" da fare.

Per contro confesso che da un punto di vista preferisco Haskell. Haskell
ha un'ottima comunita'. GHC e' sufficientemente efficiente (se dai un
occhio allo shootout, scopri che al peggio e' 5 volte piu' lento di C,
il che vuole dire che nel mondo reale puoi usarlo *anche* per managgiare
grosse quantita' di dati).

Il fatto che sia lazy non ha prezzo(tm). IMHO, eh. Il mio giudizio era
piuttosto offuscato dal fatto che non avessi ben capito come usare la
gestione dell'errore, ma credo fosse colpa del testo su cui avevo
studiato. Un testo molto divertente e interessante, ma relativamente
vecchio e poco orientato agli aspetti pratici (ovvero the haskell school
of expression). Ora con real world haskell (e qualche anno di
esperienza) ho le cose molto piu' chiare e devo dire che il modo in cui
gira il suo typesystem mi fa proprio impazzire.

Detto questo e' molto probabilmente piu' rapido sviluppare in Erlang. Io
direi che puoi quasi quasi studiarli entrambi. Al di la delle librerie
diverse, lo studio affiancato ha un pregio: vedi il mondo lazy e quello
strict insieme. Non e' cosa da poco.

Non solo: Erlang e' un linguaggio fondamentalmente IO oriented (nel
senso che buona parte dei programmi erlang hanno a che fare con rete,
parallelismo, scambio di messaggi). Viceversa il cuore di Haskell e' la
separazione fra I/O e computazione. Credo possano essere buoni compagni
di studi.

Come penultima cosa potrei suggerirti Oz. Il linguaggio non lo usa quasi
nessuno, ma Concepts, Techniques and Models of Computer Programming e'
un testo favoloso (per la programmazione funzionale, imperativa, tutto).
E usano Oz per tutti gli esempi.

Valuta anche di riskillarti in Prolog. Non e' un linguaggio funzionale,
ma e' qualcosa che uso e che e' davvero interessante. Eventualmente
estenditi a CLP (e' pazzesco quello che riesci a fare con qualche
vincolo fatto bene), CHR, etc etc etc.

In ultimo... il sistema di templates di C++ e' un linguaggio funzionale
puro. Una volta appreso il paradigma funzionale, il tuo C++ potrebbe
cambiare per sempre (di solito i colleghi dicono in peggio, nel senso
che potrebbero non essere piu' in grado di capire quello che scrivi...
<g>).

[Manlio Perillo]

Post by Enrico Franchi

Post by Massimo Soricetti
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

Beh, in tanti ne abbiamo usati. Fra i linguaggi funzionali
sostanzialmente puri io suggerirei Haskell o Erlang.
Sono entrambi molto divertenti, IMHO. Erlang e' un linguaggio con
un'utilita' pratica piuttosto spiccata, facile da imparare (abbastanza,
per lo meno) facile da trovare subito cose "utili" da fare.

Personalmente vedo Erlang abbastanza specific purpose.
Un pò come il Fortran è praticamente specializzato alla computazione
scientifica, Erlang è specializzato in applicazioni di rete.

Post by Enrico Franchi
[...]
Il fatto che sia lazy non ha prezzo(tm).
IMHO, eh. Il mio giudizio era
piuttosto offuscato dal fatto che non avessi ben capito come usare la
gestione dell'errore, ma credo fosse colpa del testo su cui avevo
studiato.
[...]
Detto questo e' molto probabilmente piu' rapido sviluppare in Erlang. Io
direi che puoi quasi quasi studiarli entrambi. Al di la delle librerie
diverse, lo studio affiancato ha un pregio: vedi il mondo lazy e quello
strict insieme. Non e' cosa da poco.

Un altra differenza importante è che Haskell è tipizzato fortemente (ma
il type sistem piace molto anche a me), mentre Erlang è tipizzato
dinamicamente (come Python).

Post by Enrico Franchi
[...]

Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Personalmente vedo Erlang abbastanza specific purpose.
Un pò come il Fortran è praticamente specializzato alla computazione
scientifica, Erlang è specializzato in applicazioni di rete.

Si. Ma di applicazioni di rete ce ne sono proprio tante! Praticamente
tutto il mondo server. Oltretutto anche le cose che offre per la
programmazione web sono eccellenti. Come dire... non e' poi cosi'
ristretto.

Oltretutto ci si lavora piuttosto bene *e* credo sia importante il modo
in cui introduce il parallelismo nel mondo reale. Piu' volte lo ho usato
per cose "normali" e mi sono contestualmente chiesto come e se potevo
parallelizzare il tutto.

Ovviamente potrei parallelizzare anche in C. Ma di fatto a uno non salta
in testa di farlo gratis se non c'e' un buon motivo.

Post by Manlio Perillo
Un altra differenza importante è che Haskell è tipizzato fortemente (ma
il type sistem piace molto anche a me), mentre Erlang è tipizzato
dinamicamente (come Python).

Si. Ma complessivamente e' meno rilevante, IMHO. Dopotutto quando usi
gli elementi (e il primo in particolare) della tupla per dare
un'informazione semantica sul tipo *e* usi il pattern matching, stai di
fatto usando una forma di tipizzazione statica (sebbene gli errori
eventuali li hai a runtime). Non credo di essere stato molto chiaro.

[Manlio Perillo]

Post by Enrico Franchi

Personalmente vedo Erlang abbastanza specific purpose. Un pò come il
Fortran è praticamente specializzato alla computazione scientifica,
Erlang è specializzato in applicazioni di rete.

Si. Ma di applicazioni di rete ce ne sono proprio tante! Praticamente
tutto il mondo server. Oltretutto anche le cose che offre per la
programmazione web sono eccellenti. Come dire... non e' poi cosi'
ristretto.
Oltretutto ci si lavora piuttosto bene

Dici davvero?
Leggendo qui:
http://damienkatz.net/2008/03/what_sucks_abou.html

c'è da mettersi le mani nei capelli.

Io cercherei di tenermi alla larga da un linguaggio che permette:

1> [100,111,103] == "dog".
true


Di contro Haskell da errore a compilation time:

Prelude> [100,111,103] == "dog"

<interactive>:1:9:
No instance for (Num Char)
arising from the literal `103' at <interactive>:1:9-11
Possible fix: add an instance declaration for (Num Char)
In the expression: 103
In the first argument of `(==)', namely `[100, 111, 103]'
In the expression: [100, 111, 103] == "dog"


Anche lo stesso Python:

In [1]: [100, 111, 103] == "dog"
Out[1]: False

Post by Enrico Franchi
[...]

Un altra differenza importante è che Haskell è tipizzato fortemente (ma
il type sistem piace molto anche a me), mentre Erlang è tipizzato
dinamicamente (come Python).

Si. Ma complessivamente e' meno rilevante, IMHO. Dopotutto quando usi
gli elementi (e il primo in particolare) della tupla per dare
un'informazione semantica sul tipo *e* usi il pattern matching, stai di
fatto usando una forma di tipizzazione statica (sebbene gli errori
eventuali li hai a runtime).

Effettivamentem credo tu abbia ragione.

Post by Enrico Franchi
Non credo di essere stato molto chiaro.

Non capisco perchè hai messo in mezzo le tuple.



Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Dici davvero?
http://damienkatz.net/2008/03/what_sucks_abou.html
c'è da mettersi le mani nei capelli.
1> [100,111,103] == "dog".
true

Questo e' l'unico comportamente sensato per Erlang. In Erlang
internamente non esiste il concetto di "carattere". Un carattere e' un
intero. Una stringa e' una lista di caratteri. Ergo quello che tu hai
scritto sono due sintassi alternative per la stessa medesima cosa.

9> $d == 100.
true
10> [$d, $o, $g] == "dog".
true

BTW, questo viene da Prolog. Meta' delle critiche fatte in quella pagina
sono relative alla sintassi di Prolog o a cose che vengono da Prolog. Io
posso dire che ho una discreta quantita' di esperienza in Prolog, pur
senza essere un guru, e la trovo piuttosto adatta e naturale al compito.

Oggettivamente in Erlang e' abbastanza fuori luogo. Mi piacciono di piu'
le sintassi ML-eggianti (in questo ci metto anche Haskell, alla fine).

Post by Manlio Perillo
Prelude> [100,111,103] == "dog"

Per un motivo banale: Haskell non considera "numeri" i caratteri.

import Data.ByteString.Char8 as C8 (pack)
import Data.ByteString as BS (pack)

check =
let dog1 = C8.pack "dog"
dog2 = BS.pack [100, 111, 103]
in dog1 == dog2

main :: IO ()
main = do
putStrLn $ show check

Post by Manlio Perillo
In [1]: [100, 111, 103] == "dog"
Out[1]: False

E anche questo e' ovvio. Dal momento che in Python non esistono neppure
i caratteri e le stringhe non sono liste...

Nota che non e' un esempio di tipizzazione debole di Erlang: e' solo che
i caratteri non esistono e pertanto i numeri li rappresentano. Sono un
solo tipo, e' ovvio che 'valgano' la stessa cosa.

Post by Manlio Perillo
Non capisco perchè hai messo in mezzo le tuple.

Perche' e' praticamente il tipo di dato piu' frequente in Erlang per
"costruire" tipi. Anche i record sono tuple mascherate. Nelle tabelle si
usano le tuple. Etc etc etc.

Si, e i record non piacciono neppure a me.

[Manlio Perillo]

Post by Enrico Franchi

Post by Manlio Perillo
Dici davvero?
http://damienkatz.net/2008/03/what_sucks_abou.html
c'è da mettersi le mani nei capelli.
1> [100,111,103] == "dog".
true

Questo e' l'unico comportamente sensato per Erlang. In Erlang
internamente non esiste il concetto di "carattere".

Si, è appunto questo che non mi va giù.

Già in Haskell non mi piace lo scarso supporto ad Unicode.
Erlang addirittura non ha un tipo specifico per gestire un carattere!

Python mi ha viziato troppo...

Post by Enrico Franchi
[...]

Post by Manlio Perillo
Prelude> [100,111,103] == "dog"

Per un motivo banale: Haskell non considera "numeri" i caratteri.
import Data.ByteString.Char8 as C8 (pack) import Data.ByteString as BS
(pack)
check =
let dog1 = C8.pack "dog"
dog2 = BS.pack [100, 111, 103]
in dog1 == dog2
main :: IO ()
main = do
putStrLn $ show check

Senza scomodare ByteString, basta un semplice:

import Data.Char

instance Num Char where
fromInteger = chr . fromInteger


main = print ([100, 111, 103] == "dog")

Post by Enrico Franchi
[...]

Post by Manlio Perillo
Non capisco perchè hai messo in mezzo le tuple.

Perche' e' praticamente il tipo di dato piu' frequente in Erlang per
"costruire" tipi. Anche i record sono tuple mascherate. Nelle tabelle si
usano le tuple. Etc etc etc.

Ah, ok.
Io stavo pensando ad Haskell ;-).



Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Si, è appunto questo che non mi va giù.

Si beh, e' una cosa su cui c'e' poco da discutere. O la si digerisce o
no. Oggettivamente *oggi* neanche a me piace l'idea che si confonda
encoding con essenza intrinseca. Ma d'altra parte Prolog quando e'
nato...

Post by Manlio Perillo
Già in Haskell non mi piace lo scarso supporto ad Unicode.

Diciamo che tutto il sistema dei caratteri e' piuttosto involuto, IMHO.
In generale la dicotomia fra Bytestrings, Strings, Char, Word8 etc...
non mi fa impazzire.

Post by Manlio Perillo
Erlang addirittura non ha un tipo specifico per gestire un carattere!

Yep.

Post by Manlio Perillo
Python mi ha viziato troppo...

Quoto.

Post by Manlio Perillo
import Data.Char
instance Num Char where
fromInteger = chr . fromInteger
main = print ([100, 111, 103] == "dog")

Giusto. -10 per me. La tua soluzione e' piu' lineare e mostra meglio il
fatto che volevo sottolineare.

[Manlio Perillo]

Post by Enrico Franchi

Post by Manlio Perillo
Si, è appunto questo che non mi va giù.

Si beh, e' una cosa su cui c'e' poco da discutere. O la si digerisce o
no. Oggettivamente *oggi* neanche a me piace l'idea che si confonda
encoding con essenza intrinseca. Ma d'altra parte Prolog quando e'
nato...

Post by Manlio Perillo
Già in Haskell non mi piace lo scarso supporto ad Unicode.

Diciamo che tutto il sistema dei caratteri e' piuttosto involuto, IMHO.
In generale la dicotomia fra Bytestrings, Strings, Char, Word8 etc...
non mi fa impazzire.

String è un semplice alias a [Char], e Char è un tipo primitivo che
rappresenta un carattere, ed in teoria può basarsi su Unicode.

I problemi con Char sono che GHC non ha nessun supporto builtin per i
codecs.

Ad esempio, se uso ghci su un terminale con encoding latin-15, ghci non
ne tiene conto e si aspetta un encoding utf-8.

Se poi faccio, ad esempio:
putStrLn "\x20AC"

ciascun carattere viene troncato ad 8 bit.


L'altro problema è con la proliferazione di metodi per leggere uno stream
di dati da una data sorgente.

In principio vi era [Char] (aka String), ma era inefficiente per gestire
grosse mole di dati (dato che implementato come una lista concatenata).

In seguito è stato sviluppato ByteString, che risolve il problema
dell'efficenza; ma resta ancora il problema di leggere in modo flessibile
un flusso di dati.

Haskell 98 e ByteString hanno la funzione getContent, che legge una
stringa in modo lazy.

Se a prima vista questo appare come soluzione ideale, ha tanti di quei
problemi che ti chiedi se gli autori avessero mai pensato ad applicazioni
reali (come leggere da un socket...).

Recentemente qualcuno ha proposto l'IO basato su iteratee:
http://www.haskell.org/haskellwiki/Enumerator_and_iteratee


Insomma, un casino su cui c'è ancora molto da studiare.
Speriamo in Haskell Prime.

Post by Enrico Franchi
[...]

Ciao Manlio

[Manlio Perillo]

Post by Manlio Perillo
[...]
I problemi con Char sono che GHC non ha nessun supporto builtin per i
codecs.
Ad esempio, se uso ghci su un terminale con encoding latin-15, ghci non
ne tiene conto e si aspetta un encoding utf-8.
putStrLn "\x20AC"
ciascun carattere viene troncato ad 8 bit.

Hugs invece non ha di questi problemi.

Post by Manlio Perillo
[...]

Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
Hugs invece non ha di questi problemi.

Hugs e' ancora sviluppato "attivamente"?

[Manlio Perillo]

Post by Enrico Franchi

Post by Manlio Perillo
Hugs invece non ha di questi problemi.

Hugs e' ancora sviluppato "attivamente"?

Non lo so.

Comunque l'ultima versione ufficiale risale a settembre 2006, e l'ultimo
commit su CVS risale a ottobre 2008.



Ciao Manlio

[Enrico Franchi]

Post by Manlio Perillo
String è un semplice alias a [Char], e Char è un tipo primitivo che
rappresenta un carattere, ed in teoria può basarsi su Unicode.

Si. Effettivamente su GHC Char e'

Prelude> :info Char
data Char = GHC.Types.C# GHC.Prim.Char#

Che vuole dire che e' a 31 bit.

Post by Manlio Perillo
I problemi con Char sono che GHC non ha nessun supporto builtin per i
codecs.

Si. E d'altra parte non credo sarebbe facilissimo inserirli a posteriori
mantenendosi piu' o meno compatibili con Haskell 98.

Post by Manlio Perillo
Ad esempio, se uso ghci su un terminale con encoding latin-15, ghci non
ne tiene conto e si aspetta un encoding utf-8.

Interessante... Ma solo ghci o anche un compilato?

Post by Manlio Perillo
putStrLn "\x20AC"
ciascun carattere viene troncato ad 8 bit.

Questo mi secca ancora di piu'.

Post by Manlio Perillo
L'altro problema è con la proliferazione di metodi per leggere uno stream
di dati da una data sorgente.

Vero.

Post by Manlio Perillo
Se a prima vista questo appare come soluzione ideale, ha tanti di quei
problemi che ti chiedi se gli autori avessero mai pensato ad applicazioni
reali (come leggere da un socket...).

Io dubito che chi ha scritto Haskell pensasse al tempo ad applicazioni
reali come le intendiamo io e te.

Post by Manlio Perillo
http://www.haskell.org/haskellwiki/Enumerator_and_iteratee
Insomma, un casino su cui c'è ancora molto da studiare.
Speriamo in Haskell Prime.

Vediamo. Purche' sia semplice.

[Manlio Perillo]

Post by Enrico Franchi
[...]

Post by Manlio Perillo
Ad esempio, se uso ghci su un terminale con encoding latin-15, ghci non
ne tiene conto e si aspetta un encoding utf-8.

Interessante... Ma solo ghci o anche un compilato?

Anche compilato.

Post by Enrico Franchi
[...]

Ciao

[Marco Mariani]

Post by Massimo Soricetti
Ora come ora conosco Pascal, C, C++, asm x86, un pò di VBA, Delphi, PHP,
Javascript e Prolog, ma attualmente uso soprattutto il C++ e il VBA,
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

Python!






..oh, come non detto, avevo capito "funzionante"

[Giulio Petrucci]

Post by Massimo Soricetti
Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente.

Anche a me: mi sono messo a studiare il Common Lisp! :-)
Ciao,
Giulio

[Manlio Perillo]

Post by Massimo Soricetti
Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente. Poi ho pensato
anche all'Haskell e allo Scheme, e poi ho pensato che sicuramente ce ne
sono anche altri che non conosco. E ho pensato che probabilmente i
"nuovi" linguaggi funzionali sono migliori. Va bene che non lo imparo
per lavoro, ma non vorrei ritrovarmi con un linguaggio-mausoleo in cui
si programma male e con fatica...

Ritorno su questo vecchio thread per segnalare questo articolo
interessante:
http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/

Post by Massimo Soricetti
[...]

Ciao Manlio Perillo