March 2013 - Haskell-Cafe

question about PutM patterns
by Alexander V Vershilov 23 Mar '13

23 Mar '13

Hello, cafe. I have a big problem using builders, so currently I'm using own builder based on Nettle one [1]. It uses Strict bytestring to build into and unchecked writes, thus it's very unsafe, plus other builders/PutM, developed rapidly so I like to switch to another one. However I use some patterns that seems not implemented in other builders, so I'd like to hear advices how to implement it there or how I can write code without using them. All of the patterns is done in order to have more performance and gives a way to build complex data without additional allocations. 1). Delayed input: This unsafe pattern can be implemented in any PutM monad for any constant sized value, the idea is that we write a plaseholder and returns a funtion that will write correct value to the address when applied. This pattern is needed when we need to update length or CRC sum after content is written: > test1 put = delayedWord16be >>= \ph -> someOtherStuff >> undelay ph calculateCRC 2). LookAhead: Sometimes I need to know the length of the content to be written, possibly I can write content to ByteString, and calculate length and write it, however if resulting type is not LBS it leads to additional allocations and memory move. For PutM a special wrapper can be written withLength :: a {- length type -} -> PutM () -> PutM (). Or special data structure and delayed input can be used, special data structure is Marker, it marks a place in datastructure allowing to calculate distances, it works very efficiently with ByteString, but I have no idea how to implement it with LBS: > test1 put = delayedWord32be >>= \ph -> marker -> \m -> put >> distance m >>= undelay . fromIntegral 3). LookBehind Returning back to crc calculation I had to use additional pattern, it's a lookback: I need to inspect unfinished data, that I've already have written, I have not done correct wrappers so I've used markers and fromForeignPtr from ByteString.Internal: > test3 = do > m <- marker > somestuff > d <- distance marker > let crc = (unsafePerformIO $ BS.unsafePackAddressLen hlen' (toAddr m)) -- Alexander

1 0

Tutorials at Commercial Users of Functional Programming 2013
by Simon Thompson 22 Mar '13

22 Mar '13

There's still time to submit a tutorial proposal for Commercial Users of Functional Programming in Boston … http://cufp.org/cufp2013-call-tutorials Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

To seq or not to seq, that is the question
by Edward Z. Yang 22 Mar '13

22 Mar '13

Are these equivalent? If not, under what circumstances are they not equivalent? When should you use each? evaluate a >> return b a `seq` return b return (a `seq` b) Furthermore, consider: - Does the answer change when a = b? In such a case, is 'return $! b' permissible? - What about when b = () (e.g. unit)? - What about when 'return b' is some arbitrary monadic value? - Does the underlying monad (e.g. if it is IO) make a difference? - What if you use pseq instead of seq? In http://hackage.haskell.org/trac/ghc/ticket/5129 we a bug in 'evaluate' deriving precisely from this confusion. Unfortunately, the insights from this conversation were never distilled into a widely publicized set of guidelines... largely because we never really figured out was going on! The purpose of this thread is to figure out what is really going on here, and develop a concrete set of guidelines which we can disseminate widely. Here is one strawman answer (which is too complicated to use in practice): - Use 'evaluate' when you mean to say, "Evaluate this thunk to HNF before doing any other IO actions, please." Use it as much as possible in IO. - Use 'return (a `seq` b)' for strictness concerns that have no relation to the monad. It avoids unnecessary strictness when the value ends up never being used and is good hygiene if the space leak only occurs when 'b' is evaluated but not 'a'. - Use 'return $! a' when you mean to say, "Eventually evaluate this thunk to HNF, but if you have other thunks which you need to evaluate to HNF, it's OK to do those first." In particular, (return $! a) >> (return $! b) === a `seq` (return $! b) === a `seq` b `seq` return b === b `seq` a `seq` return b [1] This situation is similar for 'a `seq` return ()' and 'a `seq` m'. Avoid using this form in IO; empirically, you're far more likely to run into stupid interactions with the optimizer, and when later monadic values maybe bottoms, the optimizer will be justified in its choice. Prefer using this form when you don't care about ordering, or if you don't mind thunks not getting evaluated when bottoms show up. For non-IO monads, since everything is imprecise anyway, it doesn't matter. - Use 'pseq' only when 'par' is involved. Edward

3 4

Fwd: A Thought: Backus, FP, and Brute Force Learning
by Eli Frey 22 Mar '13

22 Mar '13

---------- Forwarded message ---------- From: Eli Frey <eli.lee.frey(a)gmail.com> Date: Wed, Mar 20, 2013 at 4:56 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP <owpmailact(a)gmail.com> I have not read Bacchus' paper, so i might be off the mark here. Functional code is just as simple (if not more so) to puzzle apart and understand as imperative code. You might find that instead of "stepping through the process" of code, you end up "walking the call graph" more often. FPers tend to break their problem into ever smaller parts before re-assembling them back together, often building their own vocabulary as they go. Not to say this is not done in imperative languages, but it is not so heavily encouraged and embraced. One result of this is that you can easily understand a piece of code in isolation, without considering it's place in some "process". It sounds as though you are not yet comfortable with this yet. So yes, you might have to learn more vocabulary to understand a piece of functional code. This is not because the inner workings are obfuscated, but because there are so many more nodes in the call graph that are given names. You can still go and scrutinize each of those new pieces of vocabulary by themselves and understand them without asking for the author to come down from on high with his explanation. Let's take iteration for example. In some imperative languages, people spend an awful lot of time writing iteration in terms of language primitives. You see a for loop. "What is this for loop doing?" you say to yourself. So you step through the loop imagining how it behaves as it goes and you say "Oh, this guy is walking through the array until he finds an element that matches this predicate." In a functional style, you would reuse some iterating function and give it functions to use as it is iterating. The method of iteration is still there, it has just nested into the call graph and if you've never seen that function name before you've got to go look at it. Again I don't mean to suggest that this isn't happening in an imperative language, just not to the same degree. As well there is a bit of a learning curve in seeing what a function "does" when there is no state or "doing" to observe in it. Once you get used to it, I believe you will find it quite nice though. You have probably heard FPers extolling the virtues of "declarative" code. When there is no state or "process" to describe, you end up describing what a thing is. I for one think this greatly increases readability. Good Luck! Eli On Wed, Mar 20, 2013 at 3:59 PM, OWP <owpmailact(a)gmail.com> wrote: > I made an error. I meant FP to stand for Functional Programming, the > concept not the language. > > On Wed, Mar 20, 2013 at 6:54 PM, OWP <owpmailact(a)gmail.com> wrote: > >> This thought isn't really related to Haskell specifically but it's more >> towards FP ideal in general. >> >> I'm new to the FP world and to get me started, I began reading a few >> papers. One paper is by John Backus called "Can Programming Be Liberated >> from the von Neumann Style? A Functional Style and It's Algebra of >> Programs". >> >> While I like the premise which notes the limitation of the von Neumann >> Architecture, his solution to this problem makes me feel queasy when I read >> it. >> >> For me personally, one thing I enjoy about a typical procedural program >> is that it allows me to "Brute Force Learn". This means I stare at a >> particular section of the code for a while until I figure out what it >> does. I may not know the reasoning behind it but I can have a pretty >> decent idea of what it does. If I'm lucky, later on someone may tell me >> "oh, that just did a gradient of such and such matrix". In a way, I feel >> happy I learned something highly complex without knowing I learned >> something highly complex. >> >> Backus seems to throw that out the window. He introduces major new terms >> which require me to break out the math book which then requires me to break >> out a few other books to figure out which bases things using archaic >> symbols which then requires me to break out the pen and paper to mentally >> expand what in the world that does. It makes me feel CISCish except >> without a definition book nearby. It's nice if I already knew what a >> "gradient of such and such matrix" is but what happens if I don't? >> >> For the most part, I like the idea that I have the option of Brute Force >> Learning my way towards something. I also like the declarative aspect of >> languages such as SQL which let's me asks the computer of things once I >> know the meaning of what I'm asking. I like the ability to play and learn >> but I also like the ability to declare this or that once I do learn. From >> Backus paper, if his world comes to a reality, it seems like I should know >> what I'm doing before I even start. The ability to learn while coding >> seems to have disappeared. In a way, if the von Neumann bottleneck wasn't >> there, I'm not sure programming would be as popular as it is today. >> >> Unfortunately, I'm still very new and quite ignorant about Haskell so I >> do not know how much of Backus is incorporated in Haskell but so far, in >> the start of my FP learning adventure, this is how things seem to be seen. >> >> If I may generously ask, where am I wrong and where am I right with this >> thought? >> >> Thank you for any explanation >> >> P.S. If anyone knows of a better place I can ask this question, please >> feel free to show me the way. >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Fwd: A Thought: Backus, FP, and Brute Force Learning
by Eli Frey 22 Mar '13

22 Mar '13

I always forget to reply-all :( ---------- Forwarded message ---------- From: Eli Frey <eli.lee.frey(a)gmail.com> Date: Thu, Mar 21, 2013 at 5:04 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP <owpmailact(a)gmail.com> Ah, ye old "point free programming" [1]. Yes when you first see this stile it's a bit alarming. I think it's valid to say you shouldn't take this too far, but IMHO it is a good thing. If it is any more enlightening, it is good to think of this style like building shell pipelines. Depending on your disposition, that might make you more dismayed though :). Personally I like this style because it allows me to very rapidly prototype my ideas. When I am fleshing some solution out I will write it nearly entirely in this style. As I am throwing code around and refactoring, I will reevaluate things and name my pipes and their inputs and outputs where it makes sense to increase legibility. I am sure that Bacchus is serious about this, but have no fear. Just because you can do this does not mean you have to. You are still free to name your inputs and outputs as much as you please. However, no-one is forcing you to. There is a parallel in languages that have syntactic support for OOP. obj.dothis.dothat.andthis.andthat.andanotherthing There is just as much debate about how far to go with method chaining, and when to name intermediate values. [1] https://en.wikipedia.org/wiki/Tacit_programming On Thu, Mar 21, 2013 at 4:21 PM, OWP <owpmailact(a)gmail.com> wrote: > Thank you for this reply. This thought is more about Backus (he is cited > quite a lot) and how much of his theory made it into Haskell and other > commonly used functional programming. > > In Backhu's paper ( > http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf) > is his comparison between FP and Impertive as seen in 5.1 & 5.2 of > "Programs for Inner Product". > > When I start seeing that program described as: > > "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" > > I start getting queasy. When he later describes functional programming > main purpose is to expand on that, I get worried. When he later explains > how I don't need to use variables and just need to use "elementary > substitution rule" for everything, I'm wondering if he's really serious > about this. > > From what you say, it doesn't sound as bad and I hope it isn't as I learn > more. > > Thanks for the reply. > > On Wed, Mar 20, 2013 at 7:56 PM, Eli Frey <eli.lee.frey(a)gmail.com> wrote: > >> I have not read Bacchus' paper, so i might be off the mark here. >> >> Functional code is just as simple (if not more so) to puzzle apart and >> understand as imperative code. You might find that instead of "stepping >> through the process" of code, you end up "walking the call graph" more >> often. FPers tend to break their problem into ever smaller parts before >> re-assembling them back together, often building their own vocabulary as >> they go. Not to say this is not done in imperative languages, but it is >> not so heavily encouraged and embraced. One result of this is that you can >> easily understand a piece of code in isolation, without considering it's >> place in some "process". It sounds as though you are not yet comfortable >> with this yet. >> >> So yes, you might have to learn more vocabulary to understand a piece of >> functional code. This is not because the inner workings are obfuscated, >> but because there are so many more nodes in the call graph that are given >> names. You can still go and scrutinize each of those new pieces of >> vocabulary by themselves and understand them without asking for the author >> to come down from on high with his explanation. >> >> Let's take iteration for example. In some imperative languages, people >> spend an awful lot of time writing iteration in terms of language >> primitives. You see a for loop. "What is this for loop doing?" you say to >> yourself. So you step through the loop imagining how it behaves as it goes >> and you say "Oh, this guy is walking through the array until he finds an >> element that matches this predicate." In a functional style, you would >> reuse some iterating function and give it functions to use as it is >> iterating. The method of iteration is still there, it has just nested into >> the call graph and if you've never seen that function name before you've >> got to go look at it. Again I don't mean to suggest that this isn't >> happening in an imperative language, just not to the same degree. >> >> As well there is a bit of a learning curve in seeing what a function >> "does" when there is no state or "doing" to observe in it. Once you get >> used to it, I believe you will find it quite nice though. You have >> probably heard FPers extolling the virtues of "declarative" code. When >> there is no state or "process" to describe, you end up describing what a >> thing is. I for one think this greatly increases readability. >> >> Good Luck! >> Eli >> >> >> On Wed, Mar 20, 2013 at 3:59 PM, OWP <owpmailact(a)gmail.com> wrote: >> >>> I made an error. I meant FP to stand for Functional Programming, the >>> concept not the language. >>> >>> On Wed, Mar 20, 2013 at 6:54 PM, OWP <owpmailact(a)gmail.com> wrote: >>> >>>> This thought isn't really related to Haskell specifically but it's more >>>> towards FP ideal in general. >>>> >>>> I'm new to the FP world and to get me started, I began reading a few >>>> papers. One paper is by John Backus called "Can Programming Be Liberated >>>> from the von Neumann Style? A Functional Style and It's Algebra of >>>> Programs". >>>> >>>> While I like the premise which notes the limitation of the von Neumann >>>> Architecture, his solution to this problem makes me feel queasy when I read >>>> it. >>>> >>>> For me personally, one thing I enjoy about a typical procedural program >>>> is that it allows me to "Brute Force Learn". This means I stare at a >>>> particular section of the code for a while until I figure out what it >>>> does. I may not know the reasoning behind it but I can have a pretty >>>> decent idea of what it does. If I'm lucky, later on someone may tell me >>>> "oh, that just did a gradient of such and such matrix". In a way, I feel >>>> happy I learned something highly complex without knowing I learned >>>> something highly complex. >>>> >>>> Backus seems to throw that out the window. He introduces major new >>>> terms which require me to break out the math book which then requires me to >>>> break out a few other books to figure out which bases things using archaic >>>> symbols which then requires me to break out the pen and paper to mentally >>>> expand what in the world that does. It makes me feel CISCish except >>>> without a definition book nearby. It's nice if I already knew what a >>>> "gradient of such and such matrix" is but what happens if I don't? >>>> >>>> For the most part, I like the idea that I have the option of Brute >>>> Force Learning my way towards something. I also like the declarative >>>> aspect of languages such as SQL which let's me asks the computer of things >>>> once I know the meaning of what I'm asking. I like the ability to play and >>>> learn but I also like the ability to declare this or that once I do learn. >>>> From Backus paper, if his world comes to a reality, it seems like I should >>>> know what I'm doing before I even start. The ability to learn while coding >>>> seems to have disappeared. In a way, if the von Neumann bottleneck wasn't >>>> there, I'm not sure programming would be as popular as it is today. >>>> >>>> Unfortunately, I'm still very new and quite ignorant about Haskell so I >>>> do not know how much of Backus is incorporated in Haskell but so far, in >>>> the start of my FP learning adventure, this is how things seem to be seen. >>>> >>>> If I may generously ask, where am I wrong and where am I right with >>>> this thought? >>>> >>>> Thank you for any explanation >>>> >>>> P.S. If anyone knows of a better place I can ask this question, please >>>> feel free to show me the way. >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >

1 0

ANN: text-printer - abstract interface for text builders/printers
by Mikhail Vorozhtsov 22 Mar '13

22 Mar '13

Hello, I was writing a library for working with IP addresses when I found myself puzzled with the number of contexts in which the textual representation of an address could be used: plain strings, bytestring builders (ASCII/UTF8), text builders, pretty printers, etc. I could've just written an `addressToString :: Address -> String` function, but that would be suboptimal: (a) namespace pollution (that's a lot of *ToString's if you count IPv4/6, network addresses, socket addresses, etc) and (b) some contexts can take advantage of the fact that textual representations are ASCII (e.g. UTF8 bytestring builder). And so the text-printer[1] was born. It is mainly two type classes. One for injecting text into a monoid, with special methods for ASCII and UTF-8 characters/strings. The other provides the default injection for values of a type (think of the `Pretty` type class in pretty printing libraries), the textual representation is supposed to be simple (single-line). Plus some convenient combinators and number formatters. [1] http://hackage.haskell.org/package/text-printer

1 0

ANN: bytestring-lexing 0.4.3
by wren ng thornton 21 Mar '13

21 Mar '13

-------------------------------------------- -- bytestring-lexing 0.4.3 -------------------------------------------- The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -------------------------------------------- -- Changes (since 0.4.2) -------------------------------------------- * Fixed a segfault bug in packDecimal. Due to the optimizations introduced in 0.4.2, packDecimal could segfault when passed a value larger than (maxBound::Word64). This patch corrects the oversight, and is a recommended upgrade for all users. Unfortunately, the safety test results in a 1.19x slowdown over version 0.4.2; reducing the 1.28x speedup for 0.4.0-->0.4.2 to a mere 1.08x for 0.4.0-->0.4.3. Future versions will probably introduce a type class to remove the safety check for types where it must vacuously succeed. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

2nd CFP: SBLP 2013 (17th Brazilian Symposium on Programming Languages)
by Andre Rauber Du Bois 21 Mar '13

21 Mar '13

[Apologies if you receive multiple copies of this CFP] ======================================================= 2nd CALL FOR PAPERS 17th BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES Brasília, Distrito Federal, Brazil September 29th to October 4th, 2013 http://cbsoft2013.cic.unb.br/sblp ======================================================== IMPORTANT DATES Paper abstract submission (15 lines): April 19th Full paper submission: April 26th, 2013 Notification of acceptance: May 31st, 2013 Final papers due: June 28th, 2013 INVITED SPEAKERS * Tim Harris, Oracle Labs * More TBA INTRODUCTION The 17th Brazilian Symposium on Programming Languages, SBLP 2013, will be held in Brasília, Brazil, on September 29th to October 4th, 2013. SBLP provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. The symposium will be part of the 4th Brazilian Conference on Software: Theory and Practice, CBSoft 2013, http://cbsoft2013.cic.unb.br/, which will host four traditional, well-established symposia: * XXVII Brazilian Symposium on Software Engineering (SBES) * XVII Brazilian Symposium on Programming Languages (SBLP) * XVI Brazilian Symposium on Formal Methods (SBMF) * VII Brazilian Symposium on Components, Software Architecture and Software Reuse (SBCARS) SBLP 2013 invites authors to contribute with technical papers related (but not limited) to: * Program generation and transformation, including domain-specific languages and model-driven development in the context of programming languages. * Programming paradigms and styles, including functional, object-oriented, aspect-oriented, scripting languages, real-time, service-oriented, multithreaded, parallel, and distributed programming. * Formal semantics and theoretical foundations, including denotational, operational, algebraic and categorical. * Program analysis and verification, including type systems, static analysis and abstract interpretation. * Programming language design and implementation, including new programming models, programming language environments, compilation and interpretation techniques. SUBMISSIONS Contributions should be written in Portuguese or English. We solicit papers that should fall into one of two different categories: full papers, with at most 15 pages, or short papers, with at most 5 pages. Full papers submitted in English will be published in a volume of Lecture Notes in Computer Science (LNCS), by Springer (pending approval). For this reason, all papers must be prepared using the LNCS template, available at http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0. We encourage the submission of short papers reporting on partial results of on-going master dissertations or doctoral theses. All accepted papers will be published in the conference proceedings distributed in a digital media by the CBSOFT organizers. Submissions should be done using SBLP 2013 installation of the EasyChair conference mangement system at http://www.easychair.org/conferences/?conf=sblp2013. As in previous editions, a journal special issue, with selected papers from accepted contributions, is anticipated. Selected papers from 2003 to 2008 editions of SBLP were published in special issues of the Journal of Universal Computer Science, by Springer. The post-proceedings of SBLP from 2009 to 2012, also with selected papers from the conference proceedings, are being edited as special issues of Science of Computer Programming, published by Elsevier. CBSOFT CHAIRS Genaina Nunes Rodrigues, UnB Rodrigo Bonifácio, UnB Diego Aranha, UnB PROGRAMME CHAIRS André Rauber Du Bois, UFPel Phil Trinder, Glasgow University PROGRAMME COMMITTEE Alberto Pardo, Univ. de La Republica Alex Garcia, IME Alvaro Freitas Moreira, UFRGS André Rauber Du Bois, UFPel (co-chair) Andre Santos, UFPE Carlos Camarao, UFMG Christiano Braga, UFF Edwin Brady, University of St. Andrews Fernando Castor Filho, UFPE Fernando Quintão Pereira, UFMG Francisco Heron de Carvalho Junior, UFC Hans-Wofgang Loidl, Heriot-Watt University Jeremy Singer, Glasgow University Joao Saraiva, Universidade do Minho João F. Ferreira, Teesside University Lucilia Figueiredo, UFOP Luis Soares Barbosa, Univ. do Minho Manuel António Martins, Univ. de Aveiro Marcelo A. Maia, UFU Marcello Bonsangue, Leiden Univ/CWI Marcelo d'Amorim, UFPE Marco Tulio Valente, UFMG Mariza A. S. Bigonha, UFMG Martin A. Musicante, UFRN Noemi Rodriguez, PUC-Rio Peter Mosses, Swansea University Phil Trinder, Glasgow University (co-chair) Qiu Zongyang, Beijing University Rafael Dueire Lins, UFPE Renato Cerqueira, PUC-Rio Ricardo Massa, UFPE Roberto S. Bigonha, UFMG Roberto Ierusalimschy, PUC-Rio Sandro Rigo, UNICAMP Sergio Soares, UFPE Simon Thompson, Univ. of Kent Varmo Vene, Univ. de Tartu

1 0

Excercise on tagless final interpreters
by matteo vezzola 21 Mar '13

21 Mar '13

I'm playing with tagless final interpreters reading [1], using a very simple language: >>> class Ints repr where >>> int :: Integer -> repr Integer >>> (.+.) :: repr Integer -> repr Integer -> repr Integer >>> (.*.) :: repr Integer -> repr Integer -> repr Integer >>> (.-.) :: repr Integer -> repr Integer >>> (.<=.) :: repr Integer -> repr Integer -> repr Bool >>> newtype P repr t = P { unP :: Bool -> repr t } >>> instance Ints repr => Ints (P repr) where >>> int n = P $ \ s -> if s then int n else (.-.) (int n) >>> (.-.) n = P $ unP n . not >>> n .+. m = P $ \ s -> unP n s .+. unP m s >>> n .*. m = P $ \ s -> unP n s .*. unP m s >>> n .<=. m = P $ \ s -> unP n s .<=. unP m s After pushing down negations I'd like to distribute (.*.) over (.+.). [1] leaves it as an exercise, so it can't be that hard, but I don't get it... Anyone knows how I could do it? [1]: <http://okmij.org/ftp/tagless-final/course/lecture.pdf> thanks, -- matteo

3 2

Extracting exposed modules from an installed library
by Corentin Dupont 21 Mar '13

21 Mar '13

Hi Cafe! I'm looking for how to extract the exposed modules (as a list of strings) from an installed library, giving the library name. I can see some structures in Cabal (InstalledPackageInfo) and some functions in ghc-pkg.hs in GHC, but nothing readily useable... Thanks, Corenti

3 3