February 2012 - Haskell-Cafe

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

Commutative monads vs Applicative functors
by Ronald Guida 09 Jul '16

09 Jul '16

I have a few questions about commutative monads and applicative functors. >From what I have read about applicative functors, they are weaker than monads because with a monad, I can use the results of a computation to select between alternative future computations and their side effects, whereas with an applicative functor, I can only select between the results of computations, while the structure of those computations and their side effects are fixed in advance. But then there are commutative monads. I'm not exactly sure what a commutative monad is, but my understanding is that in a commutative monad the order of side effects does not matter. This leads me to wonder, are commutative monads still stronger than applicative functors, or are they equivalent? And by the way, what exactly is a commutative monad?

6 6

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

Proposal: TypeDirectedNameResolution
by Johannes Waldmann 03 Mar '13

03 Mar '13

While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti… This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. Is there 'ghc -XTypeDirectedNameResolution' yet? - J.W.

23 35

XCode Dependency for HP on Mac
by Tom Murphy 21 Jan '13

21 Jan '13

This may sound ignorant because, well, it is ignorant: I know very little about the underlying mechanics here. Installing the Haskell Platform currently requires XCode developer tools. To get XCode on my 10.6 machine, I... [*** begin ranty details (skippable) ... was told I could get a free version by registering as an Apple Developer. So I lie on the forms (phone number and address, for example, are _required_ fields!), and lie on the _required_ 2-3 page survey. I put in a code that they sent to my email (couldn't lie on that!), and log in. The page tells me, in the exact box that told me if I registered I could get XCode for free, that I... *** end ranty details] ...have to either pay to upgrade to their newer OS (10.7: Lion), or pay $99/year for a Mac OS Developer Membership. Is there a way to install HP without XCode? Could there be in the future? I'm tired of dealing with Apple's constant upgrade requirements, registration requirements, etc., and it seems like a small function that XCode actually performs in the Haskell development "toolchain." Again, I'm ignorant of the details and I'm sorry if this is ranty, but I'd love to hear your reactions. Thanks! Tom

16 26

arr considered harmful
by Ryan Ingram 21 Dec '12

21 Dec '12

I know it's a bit of an 'intentionally provocative' title, but with the recent discussions on Arrows I thought it timely to bring this up. Most of the conversion from arrow syntax into arrows uses 'arr' to move components around. However, arr is totally opaque to the arrow itself, and prevents describing some very useful objects as arrows. For example, I would love to be able to use the arrow syntax to define objects of this type: data Circuit a b where Const :: Bool -> Circuit () Bool Wire :: Circuit a a Delay :: Circuit a a And :: Circuit (Bool,Bool) Bool Or :: Circuit (Bool,Bool) Bool Not :: Circuit Bool Bool Then :: Circuit a b -> Circuit b c -> Circuit a c Pair :: Circuit a c -> Circuit b d -> Circuit (a,b) (c,d) First :: Circuit a b -> Circuit (a,c) (b,c) Swap :: Circuit (a,b) (b,a) AssocL :: Circuit ((a,b),c) (a,(b,c)) AssocR :: Circuit (a,(b,c)) ((a,b),c) Loop :: Circuit (a,b) (a,c) -> Circuit b c etc. Then we can have code that examines this concrete data representation, converts it to VHDL, optimizes it, etc. However, due to the presence of the opaque 'arr', there's no way to make this type an arrow without adding an 'escape hatch' Arr :: (a -> b) -> Circuit a b which breaks the abstraction: circuit is supposed to represent an actual boolean circuit; (Arr not) is not a valid circuit because we've lost the information about the existence of a 'Not' gate. The arrow syntax translation uses arr to do plumbing of variables. I think a promising project would be to figure out exactly what plumbing is needed, and add those functions to a sort of 'PrimitiveArrow' class. All of these plumbing functions are trivially implemented in terms of 'arr', when it exists, but if it doesn't, it should be possible to use the arrow syntax regardless. -- ryan

9 13

Partial statical linking
by Jason Dusek 26 Sep '12

26 Sep '12

Some time ago, I wrote to this list about making shared libraries with GHC, in such a way that the RTS was linked and ready to go. Recently, I've been looking a similar but, in a sense, opposite problem: linking Haskell executables with some of their non-Haskell dependencies, for distribution. I tried passing a few different sets of options to the linker through GHC, with -optl: -optl'-Wl,-r' -optl'-Wl,-r,-dy' -optl'-Wl,-static,-lffi,-lgmp,-dy' None of these had the desired effect. In the end, running GHC with -v and carefully editing the linker line produced the desired change (I have linked to and provided the diff below). The effect -optl seems to be to introduce options in the linker line just before -lHSrtsmain, which would seem to prevent one from linking libffi and libgmp differently. Is editing and storing away the linker script the best option at present for partially static linking? -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments https://github.com/solidsnack/arx/commit/90ec5efdb0e991344aa9a4ad29456d466e… #@@ -122,10 +122,8 @@ # -lHSarray-0.3.0.2 \ # -lHSbase-4.3.1.0 \ # -lHSinteger-gmp-0.2.0.3 \ #- -lgmp \ # -lHSghc-prim-0.2.0.0 \ # -lHSrts \ #- -lffi \ # -lm \ # -lrt \ # -ldl \ #@@ -136,4 +134,7 @@ # -lgcc_s --no-as-needed \ # /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o \ # /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o \ #+ -static \ #+ -lgmp \ #+ -lffi \

5 10

Could not find module `Text.Regex'
by zaxis 16 Sep '12

16 Sep '12

import Text.Regex date_by_ntday dateStr ntday = do let [y,m,d] = map (\x -> read x::Int) $ splitRegex (mkRegex "-") dateStr .... %ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 Which package(s) do i need to use Text.Regex ? Sincerely! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Could-not-find-module-%60Text.Regex%27-tp27366745p273… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 5

Hackage 2 maintainership
by Ben Gamari 26 Jun '12

26 Jun '12

Hey all, Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator. It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary. I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier). That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation. It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances This will surely be a non-trivial process but I would be willing to move things forward. Cheers, - Ben [1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html

12 17

Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
by Jason Dagit 20 Jun '12

20 Jun '12

In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: > Well, cabal-dev could not resolve the conflict of "the diamond". > Because the conflict is "depending different version at the SAME > time". > > On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit <dagitj(a)gmail.com> wrote: >> On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds >> <magicloud.magiclouds(a)gmail.com> wrote: >>> Hello, >>> As I recalled, ghc works in staticly link mode. So after one library >>> is compiled, all its build dependencies are useless. Lost, changed, >>> wheresoever, it does not matter. >>> Then why the problem of version conflicting exists? >> >> I'm not sure, but for me this problem has gone away by using cabal-dev >> to build everything. >> >> Jason > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com.

4 9