- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] reifying typeclasses
by oleg＠okmij.org 17 Sep '13

17 Sep '13

Evan Laforge wrote: > I have a typeclass which is instantiated across a closed set of 3 > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that > problem. But in other places I want the type-safety that separate > types provide, and packing everything into a sum type would destroy > that. So, expression problem-like, I guess. > > It seems to me like I should be able to replace a typeclass with > arbitrary methods with just two, to reify the type and back. This > seems to work when the typeclass dispatches on an argument, but not on > a return value. E.g.: If the universe (the set of types of interest to instantiate the type class to) is closed, GADTs spring to mind immediately. See, for example, the enclosed code. It is totally unproblematic (one should remember to always write type signatures when programming with GADTs. Weird error messages otherwise ensue.) One of the most notable differences between GADT and type-class--based programming is that GADTs are closed and type classes are open (that is, new instances can be added at will). In fact, a less popular technique of implementing type classes (which has been used in some Haskell systems -- but not GHC)) is intensional type analysis, or typecase. It is quite similar to the GADT solution. The main drawback of the intensional type analysis as shown in the enclosed code is that it breaks parametricity. The constraint Eq a does not let one find out what the type 'a' is and so what other operations it may support. (Eq a) says that the type a supports (==), and does not say any more than that. OTH, Representable a tells quite a lot about type a, essentially, everything. > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that Why not to introduce several type classes, even a type class for each method if necessary. Grouping methods under one type class is appropriate when such a grouping makes sense. Otherwise, Haskell won't lose in expressiveness if a type class could have only one method. {-# LANGUAGE GADTs #-} module G where data TRep a where TInt :: TRep Int TChar :: TRep Char class Representable a where repr :: TRep a instance Representable Int where repr = TInt instance Representable Char where repr = TChar argument :: Representable a => a -> Int argument x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> a -> Int go TInt x = x go TChar x = fromEnum x -- just the `mirror inverse' result :: Representable a => Int -> a result x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> Int -> a go TInt x = x go TChar x = toEnum x t1 = argument 'a' t2 = show (result 98 :: Char)

3 3

Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring
by Michael Snoyman 17 Sep '13

17 Sep '13

That's really funny timing. I started work on a very similar project just this week: https://github.com/snoyberg/mono-traversable It's not refined yet, which is why I haven't discussed it too publicly, but it's probably at the point where some review would make sense. There's been a bit of a discussion on a separate Github issue[1] about it. A few caveats: - The names are completely up for debate, many of them could be improved. - The laws aren't documented yet, but they mirror the laws for the polymorphic classes these classes are based on. - The Data.MonoTraversable module is the main module to look at. The other two are far more nascent (though I'd definitely appreciate feedback people have on them). I think this and mono-foldable have a lot of overlap, I'd be interested to hear what you think in particular John. Michael [1] https://github.com/snoyberg/classy-prelude/issues/18 On Wed, Sep 11, 2013 at 11:05 PM, John Lato <jwlato(a)gmail.com> wrote: > I agree with everything Edward has said already. I went through a similar > chain of reasoning a few years ago when I started using ListLike, which > provides a FoldableLL class (although it uses fundeps as ListLike predates > type families). ByteString can't be a Foldable instance, nor do I think > most people would want it to be. > > Even though I would also like to see mapM_ in bytestring, it's probably > faster to have a library with a separate monomorphic Foldable class. So I > just wrote one: > > https://github.com/JohnLato/mono-foldable > http://hackage.haskell.org/package/mono-foldable > > Petr Pudlak has done some work in this area. A big problem is that > foldM/mapM_ are typically implemented in terms of Foldable.foldr (or > FoldableLL), but this isn't always optimal for performance. They really > need to be part of the type class so that different container types can > have specialized implementations. I did that in mono-foldable, using > Artyom's map implementation (Artyom, please let me know if you object to > this!) > > pull requests, forks, etc all welcome. > > John L. > > > On Wed, Sep 11, 2013 at 1:29 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > >> mapM_ is actually implemented in terms of Foldable, not Traversable, and >> its implementation in terms of folding a ByteString is actually rather slow >> in my experience doing so inside lens and isn't much faster than the naive >> version that was suggested at the start of this discussion. >> >> But as we're not monomorphizing Foldable/Traversable, this isn't a think >> that is able to happen anyways. >> >> -Edward >> >> >> On Wed, Sep 11, 2013 at 2:25 PM, Henning Thielemann < >> lemming(a)henning-thielemann.de> wrote: >> >>> >>> On Wed, 11 Sep 2013, Duncan Coutts wrote: >>> >>> For mapM etc, personally I think a better solution would be if >>>> ByteString and Text and other specialised containers could be an >>>> instance of Foldable/Traversable. Those classes define mapM etc but >>>> currently they only work for containers that are polymorphic in their >>>> elements, so all specialised containers are excluded. I'm sure there >>>> must be a solution to that (I'd guess with type families) and that would >>>> be much nicer than adding mapM etc to bytestring itself. We would then >>>> just provide efficient instances for Foldable/Traversable. >>>> >>> >>> I'd prefer to keep bytestring simple with respect to the number of type >>> extensions. Since you must implement ByteString.mapM anyway, you can plug >>> this into an instance definition of Traversable ByteString. >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

3 12

Proposal: New syntax for Haskell
by Niklas Hambüchen 16 Sep '13

16 Sep '13

Impressed by the productivity of my Ruby-writing friends, I have recently come across Cucumber: http://cukes.info It is a great tool for specifying tests and programs in natural language, and especially easy to learn for beginners. I propose that we add a Cucumber syntax for Haskell, with the extension ".chs", next to .hs and .lhs. Code written in cucumber syntax is concise and easy to read: You can find some example code in https://gist.github.com/nh2/6505995. Quoting from that: Feature: The Data.List module In order to be able to use lists As a programmer I want a module that defines list functions Scenario: Defining the function foldl Given I want do define foldl Which has the type (in brackets) a to b to a (end of brackets), to a, to list of b, to a And my arguments are called f, acc, and l When l is empty Then the result better be acc Otherwise l is x cons xs Then the result should be foldl f (in brackets) f acc x (end of brackets) xs PS: People even already started a testing framework for Haskell in it: https://github.com/sol/cucumber-haskell#cucumber-for-haskell

21 23

An APL library for Haskell
by Simon Peyton-Jones 16 Sep '13

16 Sep '13

Friends Many of you will know the array language APL<http://en.wikipedia.org/wiki/APL_%28programming_language%29>. It focuses on arrays and in particular has a rich, carefully-thought-out array algebra. An obvious idea is: what would a Haskell library that embodies APL's array algebra look like? In conversation with John Scholes and some of his colleagues in the APL community a group of us developed some ideas for a possible API, which you can find on the Haskell wiki here: http://www.haskell.org/haskellwiki/APL However, we have all gone our separate ways, and I think it's entirely possible that that the idea will go no further. So this message is to ask: * Is anyone interested in an APL-style array library in Haskell? * If so, would you like to lead the process of developing the API? I think there are quite a few people who would be willing to contribute, including some core gurus from the APL community: John Scholes, Arthur Whitney, and Roger Hui. Simon

5 5

Re: [Haskell-cafe] OS X ghci problem
by Jan-Philip Loos 16 Sep '13

16 Sep '13

> What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. > The only wrinkle is figuring out where you want the dylib. > I think homebrew will put one in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. > Another option is to build the dylib yourself from the GLFW source bundled with the GLFW-b package, then tell cabal where to find it. Hi, for me the problem relocates now to the "bindings-glfw" package, since the native bindings moved to this package and are wrapped up with "glfw-b". My way to the same exception already mentioned by Brian Lewis: 1) > cabal install bindings-glfw 2) > ghci 3) ghci> :m Bindings.GLFW 4) ghci> Bindings.GLFW.c'glfwInit 5) ghci terminates with exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x7fc443c01b30' Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no clue how to do this. I built the according glfw version on my own as a dylib and loaded ghci with it explicitly, this didn't help. I guess the compiled bindings-glfw is already statically packed up. How can I get ghci to use the native glfw dylib in combination with bindings-glfw? If I have to compile bindings-glfw with different settings, which settings? I have some oversight over haskell but no really deep knowledge according to bindings and lib-loading of ghci, but I'm willing to learn it ;) My Platform: - OSX 10.8.5 - ghc(i) 7.6.3 - cabal 1.18.0.1 - xcode dev tools 4.6.3 Thanks and Greetings Jan

3 3

ANN: Cabal v1.18.0 released
by Johan Tibell 16 Sep '13

16 Sep '13

Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of "dependency hell" and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-in… (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors.

7 9

Recent problems with -cafe -- Fixed (I hope)
by Gershom Bazerman 15 Sep '13

15 Sep '13

There were problems with the -cafe mailinglist today. Best I can tell, we had an unplanned system reboot last night. In the course of it going down and back up, the configuration for -cafe got corrupted and the auto-fixed configuration had roughly 3/4 of the membership deleted. I've gone in and replaced it with a recent backup config, which should have fixed the problem. If this email goes through, then we're in good shape -- sorry about the mess. --Gershom

1 0

reifying typeclasses (resend)
by Evan Laforge 15 Sep '13

15 Sep '13

[ This is the second time I sent this, the first time it said it was awaiting moderation because I'm not subscribed to haskell-cafe, which is weird because I thought I was. Did a bunch of people get unsubscribed? ] I'm sure this is old-hat to typeclass wizards, but I've managed to get pretty far without understanding them too well, so here's a basic question. I haven't seen it phrased this way before though: I have a typeclass which is instantiated across a closed set of 3 types. It has an ad-hoc set of methods, and I'm not too happy with them because being a typeclass forces them to all be defined in one place, breaking modularity. A sum type, of course, wouldn't have that problem. But in other places I want the type-safety that separate types provide, and packing everything into a sum type would destroy that. So, expression problem-like, I guess. It seems to me like I should be able to replace a typeclass with arbitrary methods with just two, to reify the type and back. This seems to work when the typeclass dispatches on an argument, but not on a return value. E.g.: {-# LANGUAGE ScopedTypeVariables #-} class Taggable a where toTagged :: a -> Tagged toTaggedType :: a -> TaggedType fromTagged :: Tagged -> Maybe a m_argument :: a -> Int m_result :: Int -> a data Tagged = TInt Int | TChar Char deriving (Show) data TaggedType = TypeInt | TypeChar deriving (Show) instance Taggable Int where toTagged = TInt toTaggedType _ = TypeInt fromTagged (TInt x) = Just x fromTagged _ = Nothing m_argument = id m_result = id instance Taggable Char where toTagged = TChar toTaggedType _ = TypeChar fromTagged (TChar x) = Just x fromTagged _ = Nothing m_argument = fromEnum m_result = toEnum argument :: (Taggable a) => a -> Int argument a = case toTagged a of TInt x -> x TChar c -> fromEnum c result :: forall a. (Taggable a) => Int -> a result val = case toTaggedType (undefined :: a) of TypeInt -> val TypeChar -> toEnum val Say m_argument and m_result are the ad-hoc methods I'd like to get out of the typeclass. I can do that well enough for 'argument', but 'result' runs into trouble. One is the ugly undefined trick with toTaggedType, but the bigger one is that ghc says 'Could not deduce (a ~ Int) from the context (Taggable a)'. I wasn't really expecting it to work, because it would entail a case with multiple types. As far as I know, the only way for that to happen is with GADTs. But I don't see how they could help me here. So, perhaps my intuition was wrong. toTagged and fromTagged methods give you the power to go between value and type level, but apparently that's not enough power to express what typeclasses give you. Also it seems like there's a fundamental difference between dispatching on argument vs dispatching on result. Is there a way to more formally understand the extents of what typeclasses provide, and what a toTagged fromTagged scheme gives me, so I can have a better intuition for how to go between value and type levels? Also, the toTaggedType thing is pretty ugly. Not just passing it undefined, but how it has to repeat the types. I don't really see a way to get around that though.

3 2

Re: [Haskell-cafe] reifying typeclasses
by oleg＠okmij.org 15 Sep '13

15 Sep '13

[I too had the problem sending this e-mail to Haskell list. I got a reply saying the message awaits moderator approval] Evan Laforge wrote: > I have a typeclass which is instantiated across a closed set of 3 > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that > problem. But in other places I want the type-safety that separate > types provide, and packing everything into a sum type would destroy > that. So, expression problem-like, I guess. > > It seems to me like I should be able to replace a typeclass with > arbitrary methods with just two, to reify the type and back. This > seems to work when the typeclass dispatches on an argument, but not on > a return value. E.g.: If the universe (the set of types of interest to instantiate the type class to) is closed, GADTs spring to mind immediately. See, for example, the enclosed code. It is totally unproblematic (one should remember to always write type signatures when programming with GADTs. Weird error messages otherwise ensue.) One of the most notable differences between GADT and type-class--based programming is that GADTs are closed and type classes are open (that is, new instances can be added at will). In fact, a less popular technique of implementing type classes (which has been used in some Haskell systems -- but not GHC)) is intensional type analysis, or typecase. It is quite similar to the GADT solution. The main drawback of the intensional type analysis as shown in the enclosed code is that it breaks parametricity. The constraint Eq a does not let one find out what the type 'a' is and so what other operations it may support. (Eq a) says that the type a supports (==), and does not say any more than that. OTH, Representable a tells quite a lot about type a, essentially, everything. > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that Why not to introduce several type classes, even a type class for each method if necessary. Grouping methods under one type class is appropriate when such a grouping makes sense. Otherwise, Haskell won't lose in expressiveness if a type class could have only one method. {-# LANGUAGE GADTs #-} module G where data TRep a where TInt :: TRep Int TChar :: TRep Char class Representable a where repr :: TRep a instance Representable Int where repr = TInt instance Representable Char where repr = TChar argument :: Representable a => a -> Int argument x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> a -> Int go TInt x = x go TChar x = fromEnum x -- just the `mirror inverse' result :: Representable a => Int -> a result x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> Int -> a go TInt x = x go TChar x = toEnum x t1 = argument 'a' t2 = show (result 98 :: Char)

1 0

LATA 2014: 3rd call for papers
by GRLMC 15 Sep '13

15 Sep '13

*To be removed from our mailing list, please respond to this message with UNSUBSCRIBE in the subject line* ************************************************************************* 8th INTERNATIONAL CONFERENCE ON LANGUAGE AND AUTOMATA THEORY AND APPLICATIONS LATA 2014 Madrid, Spain March 10-14, 2014 Organized by: Research Group on Implementation of Language-Driven Software and Applications (ILSA) Complutense University of Madrid Research Group on Mathematical Linguistics (GRLMC) Rovira i Virgili University http://grammars.grlmc.com/lata2014/ ********************************************************************* AIMS: LATA is a yearly conference on theoretical computer science and its applications. Following the tradition of the diverse PhD training events in the field developed at Rovira i Virgili University in Tarragona since 2002, LATA 2014 will reserve significant room for young scholars at the beginning of their career. It will aim at attracting contributions from both classical theory fields and application areas (bioinformatics, language technology, artificial intelligence, etc.). VENUE: LATA 2014 will take place in Madrid, the capital of Spain. The venue will be the School of Informatics of Complutense University. SCOPE: Topics of either theoretical or applied interest include, but are not limited to: algebraic language theory algorithms for semi-structured data mining algorithms on automata and words automata and logic automata for system analysis and programme verification automata, concurrency and Petri nets automatic structures cellular automata codes combinatorics on words compilers computability computational complexity data and image compression decidability issues on words and languages descriptional complexity DNA and other models of bio-inspired computing digital libraries and document engineering foundations of finite state technology foundations of XML fuzzy and rough languages grammars (Chomsky hierarchy, contextual, unification, categorial, etc.) grammatical inference and algorithmic learning graphs and graph transformation language varieties and semigroups language-based cryptography language-theoretic foundations of artificial intelligence and artificial life natural language and speech automatic processing parallel and regulated rewriting parsing patterns power series quantum, chemical and optical computing semantics string and combinatorial issues in computational biology and bioinformatics string processing algorithms symbolic dynamics symbolic neural networks term rewriting transducers trees, tree languages and tree automata weighted automata STRUCTURE: LATA 2014 will consist of: invited talks invited tutorials peer-reviewed contributions INVITED SPEAKERS: Javier Esparza (Munich Tech, DE), On Trees and Fixed Point Equations (tutorial) Leslie A. Goldberg (Oxford, UK), The Complexity of Approximate Counting Oscar H. Ibarra (Santa Barbara, US), tba Sanjeev Khanna (Philadelphia, US), tba Helmut Seidl (Munich Tech, DE), tba PROGRAMME COMMITTEE: Dana Angluin (Yale, US) Eugene Asarin (Paris Diderot, FR) Jos Baeten (Amsterdam, NL) Christel Baier (Dresden, DE) Jan Bergstra (Amsterdam, NL) Jin-Yi Cai (Madison, US) Marek Chrobak (Riverside, US) Andrea Corradini (Pisa, IT) Mariangiola Dezani (Turin, IT) Ding-Zhu Du (Dallas, US) Michael R. Fellows (Darwin, AU) Jörg Flum (Freiburg, DE) Nissim Francez (Technion, IL) Jürgen Giesl (Aachen, DE) Annegret Habel (Oldenburg, DE) Kazuo Iwama (Kyoto, JP) Sampath Kannan (Philadelphia, US) Ming-Yang Kao (Northwestern, US) Deepak Kapur (Albuquerque, US) Joost-Pieter Katoen (Aachen, DE) S. Rao Kosaraju (Johns Hopkins, US) Evangelos Kranakis (Carleton, CA) Gad M. Landau (Haifa, IL) Andrzej Lingas (Lund, SE) Jack Lutz (Iowa State, US) Ian Mackie (École Polytechnique, FR) Carlos Martín-Vide (Tarragona, ES, chair) Giancarlo Mauri (Milan, IT) Faron G. Moller (Swansea, UK) Paliath Narendran (Albany, US) Enno Ohlebusch (Ulm, DE) Helmut Prodinger (Stellenbosch, ZA) Jean-François Raskin (Brussels, BE) Wolfgang Reisig (Humboldt Berlin, DE) Marco Roveri (Bruno Kessler, Trento, IT) Michaël Rusinowitch (LORIA, Nancy, FR) Yasubumi Sakakibara (Keio, JP) Davide Sangiorgi (Bologna, IT) Colin Stirling (Edinburgh, UK) Jianwen Su (Santa Barbara, US) Jean-Pierre Talpin (IRISA, Rennes, FR) Andrzej Tarlecki (Warsaw, PL) Rick Thomas (Leicester, UK) Sophie Tison (Lille, FR) Rob van Glabbeek (NICTA, Sydney, AU) Helmut Veith (Vienna Tech, AT) ORGANIZING COMMITTEE: Adrian Horia Dediu (Tarragona) Ana Fernández-Pampillón (Madrid) Carlos Martín-Vide (Tarragona, co-chair) Antonio Sarasa (Madrid) José-Luis Sierra (Madrid, co-chair) Bianca Truthe (Magdeburg) Florentina Lilica Voicu (Tarragona) SUBMISSIONS: Authors are invited to submit non-anonymized papers in English presenting original and unpublished research. Papers should not exceed 12 single-spaced pages (including eventual appendices) and should be formatted according to the standard format for Springer Verlag's LNCS series (see http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0) Submissions have to be uploaded to: https://www.easychair.org/conferences/?conf=lata2014 PUBLICATIONS: A volume of proceedings published by Springer in the LNCS series will be available by the time of the conference. A special issue of a major journal will be later published containing peer-reviewed extended versions of some of the papers contributed to the conference. Submissions to it will be by invitation. REGISTRATION: The period for registration is open from July 15, 2013 to March 10, 2014. The registration form can be found at: http://grammars.grlmc.com/lata2014/Registration.php DEADLINES: Paper submission: October 14, 2013 (23:59 CET) Notification of paper acceptance or rejection: November 25, 2013 Final version of the paper for the LNCS proceedings: December 2, 2013 Early registration: December 9, 2013 Late registration: February 24, 2014 Starting of the conference: March 10, 2014 End of the conference: March 14, 2014 Submission to the post-conference journal special issue: June 14, 2014 QUESTIONS AND FURTHER INFORMATION: florentinalilica.voicu(a)urv.cat POSTAL ADDRESS: LATA 2014 Research Group on Mathematical Linguistics (GRLMC) Rovira i Virgili University Av. Catalunya, 35 43002 Tarragona, Spain Phone: +34-977-559543 Fax: +34-977-558386 ACKNOWLEDGEMENTS: Departament dEconomia i Coneixement, Generalitat de Catalunya Universidad Complutense de Madrid Universitat Rovira i Virgili

1 0