- Haskell-Cafe - Haskell.org

Some thoughts on Type-Directed Name Resolution
by Steve Horne 03 Feb '12

03 Feb '12

There's a proposal at the moment to add support for TDNR to Haskell - to leverage "the power of the dot" (e.g. for intellisense). http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti… I approve of the goal, but I'd like to suggest a different approach. My basic idea is stolen from Bertrand Meyer (Object-Oriented Software Construction, second edition). Basically, a class *is* both a module and a type. Quote... Classes as modules Object orientation is primarily an architectural technique: its major effect is on the modular structure of software systems. The key role here is again played by classes. A class describes not just a type of objects but also a modular unit. In a pure object-oriented approach: Classes should be the only modules. By the logic of equivalence relations, we can conclude that a type *is* a module. Only I'd adapt that a little. In C++, the following operators can all be used to access the "module" for some type or value... * :: Scope resolution * . Member dereference * -> Member dereference via a pointer * .* Member-pointer dereference * ->* Member-pointer dereference via a pointer In C++, a type and an instance each have their own modules. A (smart) pointer has its own module, separate from the module for the type it points to. And member-pointers exist because sometimes there's a need to reference a member without knowing or (yet) caring which instance. We already have member pointers - the functions that map an instance to the field value. It would make some sense if these could be placed in a module associated with the type (not the instance). When an instance is created of a type, that can effectively (without run-time overhead) create a new module associated with the new instance. This will contain the same field-access functions, but with the instance parameter already curried in. So there's no real need for any new meaning of the . operator - it's just access to names within a module. And there's no need for a new mechanism for accessing fields - only for a way to place them in that module scope, and a little sugar that gives us the same field-access function but with the instance parameter already curried in. Once we have these modules containing compiler-generated field-access functions, though, it makes some sense to allow additional functions (and perhaps types) to be added within that types module explicitly by the programmer. It may also make sense to allow functions to be explicitly defined which will be added to the instance-modules and support the prefix-instance-parameter sugar. Finally, as with C++, when dealing with IORef and similar, it make make sense to have a separate -> operator (spelled differently, of course). Or it could use the standard dot. C++ and D disagree in this (in C++, the smart pointer has its own module separate from the pointed-at instance - in D, there is no -> or equivalent). As an aside, Ada has already gone through a related transition. The original Ada 83 had variant records, but no "true classes". In Ada 95, "tagged types" were added which were like variant records, but which supported inheritance and run-time dispatch. The discriminant is replaced by a "tag" which is presumably implemented as a virtual table pointer. However, functions and procedures weren't members. The typical call of a "method" would be... packagename.procedure_name ( instance_arg, other_args ); Ada 2005 added some workarounds to allow conventional OOP call notation. See section 1.3 of the Ada 2005 rationale for details. However, it all feels a bit kludgy. In particular, the procedures and functions still aren't members - there are just some special rules for when they can be used as if they were. I've not actually used Ada 2005, but I'd bet some confusion can result from that. Personally, I think Meyer was at least partly right - if types (and instances) are modules, the kludge-factor is much lower. C++ actually doesn't get this quite right IMO (you can access static class members through the instance objects, for example, not just through the classes), but C++ classes *do* act mostly like modules and that is a very useful trait - particularly within the declarative sublanguage (templates etc).

6 13

Cabal-1.10.1.0 and bytestring-0.9.2.1 hackage problem.
by Alan Pogrebinschi 03 Feb '12

03 Feb '12

That Cabal-1.10.1.0 bug seems to be back, now with bytestring-0.9.2.1 just uploaded to hackage. Same workaround as last time works (or maybe its time to upgrade...). For more info see: http://www.haskell.org/pipermail/haskell-cafe/2011-August/094883.html Thanks, Alan

3 2

Adding Html formatting to formlets
by Alberto G. Corona 03 Feb '12

03 Feb '12

I came across the idea that is easy to define additional operators to Text.FormLets for adding custom HTML formatting. Had anyone tried that? For example to enclose the Prod formulary in a Table using Text.XHtml tags. I defined additional operators <<< and <++ for enclosing and prepending Html to a formLet, respectively: >data Prod= Prod{pname :: String, pprice :: Int} >getProd= table <<< ( > Prod <$> tr <<< (td << "enter the name" <++ td <<< getString (pname <$> mp)) > <*> tr <<< (td << "enter the price" <++ td <<< getInt ( pprice <$> mp))) even: >p << "paragraph" <++ getProd ++> (more Html stuff) is possible or even it is possible an operator <+> > getProd <+> someOtherStuff to return Either Prod OtherStuff I did it in my own version of FormLets. So It is too heavy to put here a running example. It is part of a package that I will upload soon to hackage. This also may work for embedding formLets in other haskell HTML formats besides Text.XHtml.

2 2

Fwd: Contributing to http-conduit
by Chris Wong 03 Feb '12

03 Feb '12

Sorry, accidentally clicked "Reply" rather than "Reply to all". Here's the message I sent: ---------- Forwarded message ---------- From: Chris Wong <chrisyco%2Bhaskell-cafe(a)gmail.com> Date: Fri, Feb 3, 2012 at 7:44 PM Subject: Re: [Haskell-cafe] Contributing to http-conduit To: "Myles C. Maxfield" <myles.maxfield(a)gmail.com> On Fri, Feb 3, 2012 at 5:32 PM, Myles C. Maxfield <myles.maxfield(a)gmail.com> wrote: > I propose making an entirely unrelated package, public-suffix-list, with a > module Network.PublicSuffixList, which will expose this function, as well as > functions about parsing the list itself. Thoughts? I'll volunteer to write this module, but I'm not sure whether to read it in at run time, or generate the module containing the data in advance. The latter seems less error-prone -- no messing around with file paths or IO. Chris

1 0

ANN: combinatorics
by wren ng thornton 03 Feb '12

03 Feb '12

-------------------------------------------- -- combinatorics 0.1.0 -------------------------------------------- The combinatorics package offers efficient *exact* computation of common combinatorial functions like the binomial coefficients and factorial. (For fast *approximations*, see the math-functions package instead.) -------------------------------------------- -- Long Description -------------------------------------------- * Math.Combinatorics.Primes: provides the prime numbers via Runciman's lazy wheel sieve algorithm. Provided here since efficient algorithms for combinatorial functions often require prime numbers. The current version memoizes the primes as an infinite list CAF, which could lead to memory leaks in long-running programs with irregular access to large primes. I'm looking into a GHC patch to allow resetting individual CAFs from within compiled programs so that you can explicitly decide when to un-memoize the primes. (In GHCi when you reload a module all the CAFs are reset. However, there's no way to access this feature from within compiled programs as yet.) * Math.Combinatorics.Binomial: offers a fast computation of the binomial coefficients based on the prime factorization of the result. As it turns out, it's easier to compute the prime factorization of the answer than it is to compute the answer directly! And you don't even need the factorial function to do so. Albeit, with a fast factorial function, the naive definition of binomial coefficients gives this algorithm a run for its money. * Math.Combinatorics.Factorial: offers a fast computation of factorial numbers. As Peter Luschny comments[1], the factorial function is often shown as a classic example of recursive functions, like addition of Peano numbers, however that naive way of computing factorials is extremely inefficient and does a disservice to those learning about recursion. The current implementation uses the split-recursive algorithm which is more than sufficient for casual use. I'm working on implementing the parallel prime-swing algorithm, which should be a bit faster still. [1] http://www.luschny.de/math/factorial/FastFactorialFunctions.htm -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/combinatorics Darcs: http://community.haskell.org/~wren/combinatorics Haddock (Darcs version): http://community.haskell.org/~wren/combinatorics/dist/doc/html/combinatorics -- Live well, ~wren

3 7

cabal-install package precedence with --extra-lib-dirs
by Scott Lawrence 03 Feb '12

03 Feb '12

When running cabal install with --extra-lib-dirs=./lib, if a package is found both in ~/.cabal/lib and ./lib, cabal seems to favor the ~/.cabal/lib one. Is there some way to specify the correct precedence to use? -- Scott Lawrence

2 1

Re: [Haskell-cafe] strict version of Haskell - does it exist?
by Marc Weber 03 Feb '12

03 Feb '12

> jsonLines :: C.Resource m => C.Conduit B.ByteString m Value > jsonLines = C.sequenceSink () $ do > val <- CA.sinkParser json' > CB.dropWhile isSpace_w8 > return $ C.Emit () [val] Adding a \state -> (the way Felipe Lessa told me) make is work and it runs in about 20sec and that although some conduit overhead is likely to take place. omitting my custom data type using bytestrings operating on Value of Aeson reduces running time to 16secs. PHP/C++ still wins: less than 12secs. Now I can imagine again that even a desktop multi core system is faster than a single threaded C application. Thanks for your help. Maybe I can setup profiling again to understand why its still taking little bit more time. Marc Weber

7 8

ANN: test-framework-doctest 0.2 (now works also with test-framework 0.5)
by Sakari Jokinen 03 Feb '12

03 Feb '12

test-framework-doctest provides integration between doctest-haskell and test-framework.. See http://hackage.haskell.org/package/test-framework-doctest for details. Big thanks to Simon Hengel who did all the real work in making the library work with test-framework 0.5 cheers Sakari

1 0

zlib 0.5.3.2 broken?
by Michael Snoyman 02 Feb '12

02 Feb '12

Hi all, I've received a number of reports of a broken zlib 0.5.3.2 (and experienced it myself). Is this a generally known issue? As a temporary workaround, I've released a new version of zlib-bindings that has an upper bound on zlib to avoid 0.5.3.2 (and later). Once a new patched version is released, I'll release an updated version of zlib-bindings to remove that overly restrictive upper bound. Michael

5 4

PhD studentship in Nottingham (closing date 10th February)
by Graham Hutton 02 Feb '12

02 Feb '12

Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 The closing date is *** Friday 10th February 2012 ***. If you would like to apply, please follow the instructions in the advert, rather than clicking on "apply online". Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0