Haskell versus F#, OCaml, et. al. ...

newer
Distributing Haskell binaries as...

Galchin, Vasili

30 Sep 2008 30 Sep '08

2:32 a.m.

Hello, Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality? Regards, Vasili

Attachments:

attachment.html (text/html — 300 bytes)

Show replies by date

Don Stewart

30 Sep 30 Sep

2:46 a.m.

vigalchin:

...

Hello,

Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

Without more information, all we can really do is an overview. There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate. If I visit Arch Linux, I find, 602 Haskell libraries and tools, http://tinyurl.com/3jxlpl 21 OCaml libraries and tools, http://tinyurl.com/4fl485 7 Erlang libraries and tools, http://tinyurl.com/54oj7u 0 F# libraries and tools, http://tinyurl.com/4v53pl Of course, this is on Linux, and your distro may vary (and on Windows, F# gets to use all the .NET libraries), but you get the idea. One of the main themes that came out of the commercial users of FP meeting last week, http://cufp.galois.com was the need for languages to start building standard, blessed platforms of libraries, and to encourage reuse. Haskell was in the nice position of already having such a process underway, http://haskell.org/haskellwiki/Haskell_Platform Enjoy! -- Don

Galchin, Vasili

2:53 a.m.

thanks .. ... just trying to get an objective viewpoint and see where the "holes" are ... Vasili On Tue, Sep 30, 2008 at 1:46 AM, Don Stewart wrote:

...

vigalchin:

...
Hello,

Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

Without more information, all we can really do is an overview.

There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

If I visit Arch Linux, I find,

602 Haskell libraries and tools, http://tinyurl.com/3jxlpl

21 OCaml libraries and tools, http://tinyurl.com/4fl485

7 Erlang libraries and tools, http://tinyurl.com/54oj7u

0 F# libraries and tools, http://tinyurl.com/4v53pl

Of course, this is on Linux, and your distro may vary (and on Windows, F# gets to use all the .NET libraries), but you get the idea.

One of the main themes that came out of the commercial users of FP meeting last week,

http://cufp.galois.com

was the need for languages to start building standard, blessed platforms of libraries, and to encourage reuse. Haskell was in the nice position of already having such a process underway,

http://haskell.org/haskellwiki/Haskell_Platform

Enjoy!

-- Don

minh thu

3:29 a.m.

2008/9/30 Galchin, Vasili :

...

thanks .. ... just trying to get an objective viewpoint and see where the "holes" are ...

[...]

...

On Tue, Sep 30, 2008 at 1:46 AM, Don Stewart wrote:

...
[...]

...
Without more information, all we can really do is an overview.

There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

If I visit Arch Linux, I find, [...]

Haskell is growing really fast (in community, libraries and tools). But, Vasili, Dons pushes a lot into Arch, so although he gives a correct statement, you shouldn't build your point of view relying only on that part of his answer.... Just rember the number about the Haskell libraries (and the fact it is growing), not the particular state in Arch (which seems a very nice place to use haskell, I'm new to Arch for a few days now...). Cheers, Thu

Don Stewart

3:41 a.m.

noteed:

...

Haskell is growing really fast (in community, libraries and tools). But, Vasili, Dons pushes a lot into Arch, so although he gives a correct statement, you shouldn't build your point of view relying only on that part of his answer....

Just rember the number about the Haskell libraries (and the fact it is growing), not the particular state in Arch (which seems a very nice place to use haskell, I'm new to Arch for a few days now...).

Yeah, I only want to say, "there's a lot of libraries, probably more than most people are aware of". I'm not really pushing Arch, only using it as a vehicle to get the Debian guys into action :-) They'll be able to move once the platform is released in the next couple of weeks, http://haskell.org/haskellwiki/Haskell_Platform -- Don

Galchin, Vasili

4:14 a.m.

ok .. is there a "roadmap" for Haskell?? Vasili On Tue, Sep 30, 2008 at 2:41 AM, Don Stewart wrote:

...

noteed:

...
Haskell is growing really fast (in community, libraries and tools). But, Vasili, Dons pushes a lot into Arch, so although he gives a correct statement, you shouldn't build your point of view relying only on that part of his answer....

Just rember the number about the Haskell libraries (and the fact it is growing), not the particular state in Arch (which seems a very nice place to use haskell, I'm new to Arch for a few days now...).

Yeah, I only want to say, "there's a lot of libraries, probably more than most people are aware of".

I'm not really pushing Arch, only using it as a vehicle to get the Debian guys into action :-) They'll be able to move once the platform is released in the next couple of weeks,

http://haskell.org/haskellwiki/Haskell_Platform

-- Don

Don Stewart

4:18 a.m.

vigalchin:

...

ok .. is there a "roadmap" for Haskell??

for the language? * http://video.google.com/videoplay?docid=5177116830079185902 for the compiler? * http://hackage.haskell.org/trac/ghc/wiki/Status/Releases for the libraries? * http://haskell.org/haskellwiki/Haskell_Platform Cheers, Don

Claus Reinke

4:58 a.m.

...

for the libraries?

* http://haskell.org/haskellwiki/Haskell_Platform

You might have mentioned that there is finally a tracker (*) and an approximate .cabal meta-package (for dependencies only). - is the programs are not registered by Cabal issue going to be fixed before platform release? - haddock currently seems bundled with ghc, for interdependency reasons - shouldn't there be some compilers in the platform release as well (and possibly a language/library report)? - I'd like to see ghc-paths somewhere, too. Registering programs with cabal or having ghc installation info via ghc-paths may look minor, as the packages would be tiny, with meta-information only, but that is surprisingly useful. Claus (*) please could the email notifications be switched on for haskell.org-hosted trackers by default (haven't tried this one yet, but notifications are off for haddock's tracker)? Trackers that don't inform anyone of ticket activity are of limited use;-)

Don Stewart

5:09 a.m.

claus.reinke:

...

...
for the libraries?

* http://haskell.org/haskellwiki/Haskell_Platform

You might have mentioned that there is finally a tracker (*) and an approximate .cabal meta-package (for dependencies only).

- is the programs are not registered by Cabal issue going to be fixed before platform release?

No. Not the right thing for cabal the package system to do.

...

- haddock currently seems bundled with ghc, for interdependency reasons

They're both in the platform.

...

- shouldn't there be some compilers in the platform release as well (and possibly a language/library report)?

The platform depends on GHC, and a specific release of the core libraries No, the platform doesn't specify the language. The library report is the haddock documentation however.

...

- I'd like to see ghc-paths somewhere, too. Registering programs with cabal or having ghc installation info via ghc-paths may look minor, as the packages would be tiny, with meta-information only, but that is surprisingly useful.

The initial is just extralibs + cabal-install We need to work out the ticket creation process first before adding new pieces.

...

(*) please could the email notifications be switched on for haskell.org-hosted trackers by default (haven't tried this one yet, but notifications are off for haddock's tracker)? Trackers that don't inform anyone of ticket activity are of limited use;-)

Good idea. Personal subscriptions, or to the libraries@ list? -- Don

Claus Reinke

6:23 a.m.

...

...
- is the programs are not registered by Cabal issue going to be fixed before platform release?

No. Not the right thing for cabal the package system to do.

Huh? Having tool availability out in the open, as updateable packages, would be more flexible than the current built-in stuff in cabal the build system, and it would give the build-tools field something to point to (#227,#132), and it would make meta-packages with tools possible (like the haskell platform). So, what isn't right about it? Claus

Krasimir Angelov

4:45 a.m.

On Tue, Sep 30, 2008 at 8:46 AM, Don Stewart wrote:

...

There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

This is missleading and depends on how you count the libraries. For instance "base" is now split into "arrays", "containers", "process", "parallel" .... etc. In the same time on platforms like Java and .NET this might be only one package. Krasimir

Don Stewart

4:51 a.m.

kr.angelov:

...

On Tue, Sep 30, 2008 at 8:46 AM, Don Stewart wrote:

...
There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

This is missleading and depends on how you count the libraries. For instance "base" is now split into "arrays", "containers", "process", "parallel" .... etc. In the same time on platforms like Java and .NET this might be only one package.

Indeed, it corresponds to only discrete units of maintainance, in separate repositories. There are no meta-packages yet. haskell-platform will be the first, http://trac.haskell.org/haskell-platform/ If we count via 'categories', say, an alternative grouping, there are 62 disinct categories on hackage, which would give an idea of what is provided logically, AI (3) Algorithms (12) Bioinformatics (8) Code Generation (3) Codec (23) Codecs (3) Combinators (2) Comonads (1) Compilers/Interpreters (16) Composition (1) Concurrency (1) Console (2) Control (34) Cryptography (4) Data (72) Data Mining (2) Data Structures (16) Database (32) Debug (1) Desktop (1) Development (41) Distributed Computing (5) Distribution (14) Editor (4) Foreign (5) FRP (4) Game (24) Generics (5) Graphics (41) GUI (8) Hardware (3) Interfaces (4) Language (31) List (2) Math (30) Monadic Regions (1) Monads (8) Music (3) Natural Language Processing (9) Network (46) Numerical (2) Other (1) ParserCombinators (1) Parsing (17) Physics (3) Pugs (9) Reactivity (5) Screensaver (1) Scripting (1) Search (3) Sound (28) Source-tools (4) System (72) Testing (12) Text (76) Theorem Provers (2) User Interfaces (23) User-interface (1) Utils (1) Web (36) XML (11) Unclassified (21). There are duplicates here, but if you can find missing categories, that might give an indication of weak points. No "Real Time" package, for example. -- Don

Don Stewart

4:55 a.m.

dons:

...

kr.angelov:

...
On Tue, Sep 30, 2008 at 8:46 AM, Don Stewart wrote:

...
There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

This is missleading and depends on how you count the libraries. For instance "base" is now split into "arrays", "containers", "process", "parallel" .... etc. In the same time on platforms like Java and .NET this might be only one package.

Basically, pick a way to divide this graph of the libraries, and what they depend on, sensibly into units, and you'll know how many "libraries" there are, with distinct capabilities, http://galois.com/~dons/tmp/hackage.png -- Don

Hans van Thiel

8:07 a.m.

On Tue, 2008-09-30 at 01:55 -0700, Don Stewart wrote:

...

dons:

...
kr.angelov:

...
On Tue, Sep 30, 2008 at 8:46 AM, Don Stewart wrote:

...
There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

This is missleading and depends on how you count the libraries. For instance "base" is now split into "arrays", "containers", "process", "parallel" .... etc. In the same time on platforms like Java and .NET this might be only one package.

Basically, pick a way to divide this graph of the libraries, and what they depend on, sensibly into units, and you'll know how many "libraries" there are, with distinct capabilities,

http://galois.com/~dons/tmp/hackage.png

-- Don

But not all 'libraries' are libraries, some are applications. The difference, IMO, is that a library is meant to be used in other programs, possibly very different ones. An application is for a specific purpose. Another way to put it, to use a library you need a (documented) API, to use an application you need a user guide (or not, in the rare case it's self documenting). I feel it's a mistake not to distinguish between those two, in particular when the number of packages gets very large, as is now happening. Secondly, some major libraries are not on Hackage (yet), e.g. Gtk2Hs. Regards, Hans van Thiel

Gour

11:17 a.m.

...

...
...
...
...
"Don" == Don Stewart writes:

Don> There are duplicates here, but if you can find missing categories, Don> that might give an indication of weak points. No "Real Time" Don> package, for example. I'd say, despite the danger to repeat oneself, that, imho, Haskell needs something better in the realm of 'i18n' over the present i18n package labelled with the 'experimental stability tag. In http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44054 thread I provided a list of 'serious' languages with proper gettext support and some reasons (from gtk2hs dev) what is missing in Haskell version with only Duncan's reply :-( Quick googling gives the following for: a) Ocaml - http://sylvain.le-gall.net/ocaml-gettext.html b) Erlang - http://www.trapexit.org/Gettext_-_An_internationalization_package. Dunno about Clean, while there is no point in discussing i18n capabilities in F# ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

Galchin, Vasili

4:46 p.m.

side tangent ... I wrote a posix real-time package and it sits now in System 1) I'm sure it can be improved .... I purposely tried to keep the API close to the Posix real-time API; however, I am open to suggestions about the implementation itself and also the API 2) I am looking at changing the async i/o api some based on a suggestion to use the State monad. Regards. Vasili On Tue, Sep 30, 2008 at 3:51 AM, Don Stewart wrote:

...

kr.angelov:

...
On Tue, Sep 30, 2008 at 8:46 AM, Don Stewart wrote:

...
There's almost 800 Haskell libraries on hackage.haskell.org (millions of lines of code). On average, 2 new libraries are released each day (though 12 new libs were released in the last 24 hours). That's 700 new libraries a year at the current rate.

This is missleading and depends on how you count the libraries. For instance "base" is now split into "arrays", "containers", "process", "parallel" .... etc. In the same time on platforms like Java and .NET this might be only one package.

Indeed, it corresponds to only discrete units of maintainance, in separate repositories. There are no meta-packages yet. haskell-platform will be the first,

http://trac.haskell.org/haskell-platform/

If we count via 'categories', say, an alternative grouping, there are 62 disinct categories on hackage, which would give an idea of what is provided logically,

AI (3) Algorithms (12) Bioinformatics (8) Code Generation (3) Codec (23) Codecs (3) Combinators (2) Comonads (1) Compilers/Interpreters (16) Composition (1) Concurrency (1) Console (2) Control (34) Cryptography (4) Data (72) Data Mining (2) Data Structures (16) Database (32) Debug (1) Desktop (1) Development (41) Distributed Computing (5) Distribution (14) Editor (4) Foreign (5) FRP (4) Game (24) Generics (5) Graphics (41) GUI (8) Hardware (3) Interfaces (4) Language (31) List (2) Math (30) Monadic Regions (1) Monads (8) Music (3) Natural Language Processing (9) Network (46) Numerical (2) Other (1) ParserCombinators (1) Parsing (17) Physics (3) Pugs (9) Reactivity (5) Screensaver (1) Scripting (1) Search (3) Sound (28) Source-tools (4) System (72) Testing (12) Text (76) Theorem Provers (2) User Interfaces (23) User-interface (1) Utils (1) Web (36) XML (11) Unclassified (21).

There are duplicates here, but if you can find missing categories, that might give an indication of weak points. No "Real Time" package, for example.

-- Don

Jim Burton

7:08 a.m.

Don Stewart-2 wrote:

...

[...] Haskell was in the nice position of already having such a process underway,

http://haskell.org/haskellwiki/Haskell_Platform

Hi Don, I'm curious -- what do the images on that page represent? Can you link to readable versions? Thanks, Jim

...

Enjoy!

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Haskell-versus-F-%2C-OCaml%2C-et.-al.-...-tp19736848p1... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Chris Eidhof

7:47 a.m.

Here's the original file: http://blog.well-typed.com/wp-content/uploads/2008/09/package-sizes-all-crop... The area of each package is determined by the number of packages that depend on it. -chris On 30 sep 2008, at 13:08, Jim Burton wrote:

...

Don Stewart-2 wrote:

...
[...] Haskell was in the nice position of already having such a process underway,

http://haskell.org/haskellwiki/Haskell_Platform

Hi Don, I'm curious -- what do the images on that page represent? Can you link to readable versions? Thanks,

Jim

...
Enjoy!

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Haskell-versus-F-%2C-OCaml%2C-et.-al.-...-tp19736848p1... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Mitchell, Neil

3:40 a.m.

Hi, For libraries F# is probably superior to all, as it has libraries for virtually everything, and can interoperate seamlessly with COM and .NET. I doubt there will be any library functionality that can't be found or bought. Thanks Neil ---------------------- Hello, Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality? Regards, Vasili ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

Don Stewart

3:51 a.m.

neil.mitchell.2:

...

Hi,

For libraries F# is probably superior to all, as it has libraries for virtually everything, and can interoperate seamlessly with COM and .NET. I doubt there will be any library functionality that can't be found or bought.

Libraries for monad transformers or comonadic streams? ;) -- Don

Mitchell, Neil

3:59 a.m.

...

...
For libraries F# is probably superior to all, as it has libraries for virtually everything, and can interoperate seamlessly with COM and .NET. I doubt there will be any library functionality that can't be found or bought.

Libraries for monad transformers

I found lots of stuff for Monads: http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.a spx http://blogs.msdn.com/lukeh/archive/2007/08/19/monadic-parser-combinator s-using-c-3-0.aspx No Monad transformers yet, but I have seen GADT's in C# (which means they probably work in F# too).

...

or comonadic streams? ;)

Google doesn't even know what this is! http://www.google.co.uk/search?hl=en&q=%22comonadic%20streams%22&meta= (of course, it will in a day or so, when it sees this message) Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

Jon Harrop

10:27 a.m.

On Tuesday 30 September 2008 08:40:51 Mitchell, Neil wrote:

...

Hi,

For libraries F# is probably superior to all, as it has libraries for virtually everything, and can interoperate seamlessly with COM and .NET. I doubt there will be any library functionality that can't be found or bought.

Although the .NET platform is general purpose by design it is actually only used in quite specific domains (primarily web and database). Technical computing is one domain where .NET is rarely used (it is about as popular as OCaml in this context) and, unsurprisingly, the libraries available for .NET are not great for this. In contrast, OCaml has mature bindings to BLAS, LAPACK and FFTW as well as bindings to GSL and many other libraries have been written natively in OCaml. This is why we started two products that are designed to provide to F# customers similar capabilities to those already available for free to OCaml users. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

Manlio Perillo

6:53 a.m.

Galchin, Vasili ha scritto:

...

Hello,

Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

The "advantage" of F# is that you get all the .NET framework (but this leaves me some doubts, it is not possible to write an optimal framework that needs to be accessed by different languages). The advantage of Erlang is its robust and tested support for writing scalable concurrent applications. Many programmers don't like Erlang syntax, but, like for SQL, Erlang just works and you just use it. Haskell in this area is not as mature as Erlang, and it does not have support for master/slave architecture.

...

Regards, Vasili

Manlio Perillo

Jon Harrop

10:33 a.m.

On Tuesday 30 September 2008 11:53:02 Manlio Perillo wrote:

...

Galchin, Vasili ha scritto:

...
Hello,

Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

The "advantage" of F# is that you get all the .NET framework (but this leaves me some doubts, it is not possible to write an optimal framework that needs to be accessed by different languages).

Most of the problems I encounter are not due to cross-language impedance mismatches but, rather, to poor design. For example, the Task Parallel Library correctly uses higher-order functions to represent data parallel aggregate operations despite being language agnostic (C# is a functional language now, after all) but Windows Presentation Foundations makes pens (an encapsulation of the color and width of a line) thread unsafe for no reason whatsoever which goes a long way to undermining the reliability of GUI code. At least in the case of OCaml, my impression is that the libraries are far better designed and, consequently, much more productive to use. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

John Goerzen

10:25 a.m.

Galchin, Vasili wrote:

...

Hello,

Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

I used OCaml for a little while before I moved to Haskell. In some ways, such as the type system, is is somewhat similar. I had a number of gripes about OCaml, though. * Terrible I/O system. Different type for read handles than for write handles. No capability to open a file Read/Write in standard library. Could do so with the unix module, but it had yet another incompatible type and didn't work with standard functions. * Two list-like types. Standard list was strict, the other list ("streams") was lazy. Two sets of library functions for this. (But have we cloned this with ByteStreams? Hmm.) * The whole build system. Huge PITA. There were about half a dozen different attempts at making this work. Some based on make, some on autoconf, some on other things. OCaml can be compiled to bytecode or native code, the latter not supported on all platforms. Executables can only be built using libraries built the same way (bytecode vs. native code). Nothing similar to Cabal over there. I don't know if any of the above have strengthened in the last couple of years. -- John

Brandon S. Allbery KF8NH

10:55 a.m.

On 2008 Sep 30, at 10:25, John Goerzen wrote:

...

Galchin, Vasili wrote:

...
Frank mode on ... ;^) In terms of functionality, where is Haskell superior vs inferior to ML, Caml, OCaml, F#, Erlang, etc.? E.g. in terms of library functionality?

* Two list-like types. Standard list was strict, the other list ("streams") was lazy. Two sets of library functions for this. (But have we cloned this with ByteStreams? Hmm.)

It would take a fair amount of Prelude and Data.List hackery, but I think the IsString typeclass could be used to make ByteStrings fit into the mold. Although we also need to think about Data.Stream (which duplicates Data.List) in this context -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

6078

Age (days ago)

6078

Last active (days ago)

List overview

Download

25 comments

14 participants

participants (14)

Brandon S. Allbery KF8NH
Chris Eidhof
Claus Reinke
Don Stewart
Galchin, Vasili
Gour
Hans van Thiel
Jim Burton
John Goerzen
Jon Harrop
Krasimir Angelov
Manlio Perillo
minh thu
Mitchell, Neil