Re: [Haskell-cafe] coding style vs. foreign interfaces
On 7 Feb 2011, at 03:10, Donn Cave wrote: I just noticed a handful of spelling errors, in a package that isn't all that obscure. Enums from a C interface - data AlarmingNews = -- ALARM_STUFF_WENT_WRONG AlarmStufWentWrong | ... FWIW, if you generate these bindings with a tool (e.g. hsc2hs, c2hs), then there are standard machine-generated translations, which follow simple rules (so are easy to guess) and being mechanical, are always spelled as expected. For example aLARM_STUFF_WENT_WRONG for a constant Haskell Int value corresponding to the C enum or CPP constant. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
Johan Tibell johan.tib...@gmail.com writes: The GHC documentation says the information is in the interface files, but they are binary now, and I can't find it there. ghc --show-iface HI_FILE The strictness signatures are a bit hard to parse though. Having a cheat sheet would be nice. Am I the only one who keep thinking it'd be great to have this incorporated in my Emacs haskell-mode? Along with a nice interface to core, please. And a pony. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 05/02/2011 15:35, Andrew Coppin wrote: At the very least we need to teach people how to tell which arguments a pure function is strict in by looking at its definition. That's not necessarily tractible. It depends on what other functions you call. Many functions have obvious strictness properties, but very few have *documented* strictness properties. It's often struck me that, this information is clearly part of the interface to a function, given that correct operation of calls to that function may depend on it, yet we (implicitly) pretend that it's not (by rarely documenting it). Would it not be both incredibly useful and possible to automatically document information of this sort using tools like haddock? Obviously, entirely accurate indicators of lazyness are not going to be computable, but it seems like we could at least get information of the type argument never forced, argument always forced, argument may be forced. It seems like this would be a huge step forward - data structures like map which are pure containers for their elements would be clearly indicated as such in their documentation. Jimbo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
From: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com On 7 February 2011 12:30, wren ng thornton w...@freegeek.org wrote: On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote: On 7 February 2011 08:12, Alexey Khudyakovalexey.sklad...@gmail.com ?wrote: Also there is a container-classes package which provide set of type class for containers. [1] http://hackage.haskell.org/package/container-classes Don't use that package: it's broken. ?I did start on a re-write that works (and there are similar libraries around that I believe do work), but gave up because it was a) too fiddly, and b) I decided that the use case I had for them wasn't worth it (as it would just make that library more complicated and difficult to use, possibly also less efficient). ?If anyone wants it I can certainly send them what I've got though. Any chance you could push a 0.0.0.1 version which tells people this, so that they know to avoid it? Didn't think about that; I'll try to do so tonight. Perhaps a better approach would be to ask the hackage maintainer (Ross Patterson, if I'm not mistaken) to deprecate container-classes. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 7 February 2011 10:16, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote: It's often struck me that, this information is clearly part of the interface to a function, given that correct operation of calls to that function may depend on it, yet we (implicitly) pretend that it's not (by rarely documenting it). Would it not be both incredibly useful and possible to automatically document information of this sort using tools like haddock? Interesting point, but excepting that its adding more complexity Haskell type system, the Clean way of putting strictness information into the type system seems preferable don't you think? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending GHCi
$ ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :m +Data.IORef Control.Concurrent Control.Monad Prelude Data.IORef Control.Concurrent Control.Monad msg - newIORef Hello Prelude Data.IORef Control.Concurrent Control.Monad let echo = forever $ readIORef msg = putStrLn threadDelay 300 Prelude Data.IORef Control.Concurrent Control.Monad t - forkIO echo Hello Prelude Data.IORef Control.Concurrent Control.Monad Hello Hello writeIORefHello msg World Prelude Data.IORef Control.Concurrent Control.Monad World World On my mac, this works..but on Linux, the moment I do t - forkIO ... , it starts off a thread in the foreground and does not return to the prompt. Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On Mon, Feb 07, 2011 at 11:05:53AM +, John Lato wrote: From: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com On 7 February 2011 12:30, wren ng thornton w...@freegeek.org wrote: On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote: On 7 February 2011 08:12, Alexey Khudyakovalexey.sklad...@gmail.com ?wrote: Also there is a container-classes package which provide set of type class for containers. [1] http://hackage.haskell.org/package/container-classes Don't use that package: it's broken. ?I did start on a re-write that works (and there are similar libraries around that I believe do work), but gave up because it was a) too fiddly, and b) I decided that the use case I had for them wasn't worth it (as it would just make that library more complicated and difficult to use, possibly also less efficient). ?If anyone wants it I can certainly send them what I've got though. Any chance you could push a 0.0.0.1 version which tells people this, so that they know to avoid it? Didn't think about that; I'll try to do so tonight. Perhaps a better approach would be to ask the hackage maintainer (Ross Patterson, if I'm not mistaken) to deprecate container-classes. Done. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 07/02/2011 11:40, Stephen Tetley wrote: Interesting point, but excepting that its adding more complexity Haskell type system, the Clean way of putting strictness information into the type system seems preferable don't you think? If we were starting from a clean sheet (no pun intended) then yes, I would say this is unquestionably preferable. Given the amount of Haskell code out in the world, I'd expect people to argue against it, on the basis that fiddling with the types is quite a major change. (Though I would not necessarily be one of those people) Regards, Jimbo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal license combinations
Dear All, There was recently a discussion on haskell-cafe ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg86472.html) about licenses of libraries such as hmatrix and the combination of various different licences. One question was about per-package versus by-file licenses: In Haskell the compilation unit is the module, and the per-file cabal header allows for a license field. It seems then that a package should be the least restrictive combination of all the licenses in all the contained modules. If this has to become a hand-coded fancy function of various GPLx, BSDy, OpenSource, and other licenses then so be it. That is the legal reality. And use of a BSD3 module in hmatrix that does not depend upon GPL'd GSL modules would be acceptable. In short, I argue for a per-file(module) license regime. Vivian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending GHCi
On 02/07/2011 12:45 PM, C K Kashyap wrote: $ ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :m +Data.IORef Control.Concurrent Control.Monad Prelude Data.IORef Control.Concurrent Control.Monad msg - newIORef Hello Prelude Data.IORef Control.Concurrent Control.Monad let echo = forever $ readIORef msg = putStrLn threadDelay 300 Prelude Data.IORef Control.Concurrent Control.Monad t - forkIO echo Hello Prelude Data.IORef Control.Concurrent Control.Monad Hello Hello writeIORefHello msg World Prelude Data.IORef Control.Concurrent Control.Monad World World On my mac, this works..but on Linux, the moment I do t - forkIO ... , it starts off a thread in the foreground and does not return to the prompt. Strange. Works for me (ghc 6.12.1 on Debian squeeze). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: case-insensitive-0.1
Hi Bas This could be a useful package but can you add a note that this does not do correct Unicode-aware comparison on String (though AFAICT it is correct for Text)? --Max On Mon, Feb 7, 2011 at 02:06, Bas van Dijk v.dijk@gmail.com wrote: Dear all, I had this old module laying around that I wrote some time ago. I dusted it off and uploaded it to Hackage: http://hackage.haskell.org/package/case-insensitive-0.1 The package provides the module Data.CaseInsensitive which exports the CI type constructor which can be parameterised by a string-like type like: String, ByteString, Text, etc.. Comparisons of values of the resulting type are then insensitive to cases. It is my hope that one day packages like snap-core[1], http-types[2] or wai[3] all use this common way of making strings case insensitive. Regards, Bas [1] http://hackage.haskell.org/packages/archive/snap-core/latest/doc/html/Data-CIByteString.html [2] http://hackage.haskell.org/packages/archive/http-types/0.3.0/doc/html/Network-HTTP-Types.html#t:CIByteString [3] http://hackage.haskell.org/packages/archive/wai/latest/doc/html/Network-Wai.html#v:CIByteString ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal license combinations
It seems then that a package should be the least restrictive combination of all the licenses in all the contained modules. Omit the words least restrictive and I think you are correct. To combine licences, just aggregate them. There is no lattice of subsumption; no more or less restrictive ordering. It's simple: you must obey all of them. Some aggregations introduce a contradiction of terms, so you cannot legally aggregate those modules without breaking some term. But if the terms of the aggregated licences are compatible rather than contradictory, then all is good. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending GHCi
I tried a fresh install of Haskell platform on my Vista box and I find that starting the thread does not return to the prompt. Is there some setting I need to do? Sent from my Windows Phone -- From: Steffen Schuldenzucker Sent: Monday, 7 February 2011 6:46 PM To: C K Kashyap Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Extending GHCi On 02/07/2011 12:45 PM, C K Kashyap wrote: $ ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :m +Data.IORef Control.Concurrent Control.Monad Prelude Data.IORef Control.Concurrent Control.Monad msg - newIORef Hello Prelude Data.IORef Control.Concurrent Control.Monad let echo = forever $ readIORef msg = putStrLn threadDelay 300 Prelude Data.IORef Control.Concurrent Control.Monad t - forkIO echo Hello Prelude Data.IORef Control.Concurrent Control.Monad Hello Hello writeIORefHello msg World Prelude Data.IORef Control.Concurrent Control.Monad World World On my mac, this works..but on Linux, the moment I do t - forkIO ... , it starts off a thread in the foreground and does not return to the prompt. Strange. Works for me (ghc 6.12.1 on Debian squeeze). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On Mon, Feb 7, 2011 at 1:36 PM, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote: On 07/02/2011 11:40, Stephen Tetley wrote: Interesting point, but excepting that its adding more complexity Haskell type system, the Clean way of putting strictness information into the type system seems preferable don't you think? If we were starting from a clean sheet (no pun intended) then yes, I would say this is unquestionably preferable. Given the amount of Haskell code out in the world, I'd expect people to argue against it, on the basis that fiddling with the types is quite a major change. (Though I would not necessarily be one of those people) I dunno. As a language extension, would - let's call it BangTypes - be backwards-incompatible in any way? As far as I understand it, 'banged' types would accept only evaluated values, whereas 'unbanged' types would accept either evaluated or unevaluated ones -- exactly as it is now. So, given that none of the types in currently-existing Haskell code are banged, the effect on them of enabling the extension should be pretty more or less nil. And I think code with banged types would still be completely interoperable with code without (at least if evaluation happened implicitly wherever required) -- passing a value of a banged type to a function expecting an unbanged one would have no special effect, while passing a value of an unbanged type to a function expecting a banged one would merely result in it being evaluated. The potentially disruptive effect I can think of is that currently authors of data structures have full control over their strictness (for good or ill), whereas with this extension their users would be able to instantiate them to various varieties of strictness themselves. I'm not sure if the implementations of the data structures (or other external uses thereof) tend to depend on their assumed strictness, and would break were it different? If that were the case it might indeed be problematic, forcing people to distinguish between 'bang-safe' and 'bang-unsafe' code. But I don't know if this is the case (or, for that matter, whether it's even possible for it to be the case...). One thing I'm unclear on is what precisely the meaning of banging a type would be (or what the meaning is in Clean). Would !a indicate that values of type !a must be evaluated to WHNF, that constructors of !a which occur in a's definition recursively would be strict (as if they had been declared with a bang pattern), or both? (Or something else entirely?) You would need the second property to be able to specify a spine-strict but element-lazy list (as opposed to merely a non-bottom list) as ![a]; you would need the first for it to have any effect on non-recursive types. Or would it have the first meaning for type variables, and both meanings for concrete types? Regards, Jimbo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fetching BLOBs
Hello, cafe, Is there a way to get BLOB fields from OracleDB using Takusen? What about other possibilities (through HDBC - ODBC)? Dima ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending GHCi
On Sun, Feb 6, 2011 at 11:59 PM, C K Kashyap ckkash...@gmail.com wrote: $ ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :m +Data.IORef Control.Concurrent Control.Monad Prelude Data.IORef Control.Concurrent Control.Monad msg - newIORef Hello Prelude Data.IORef Control.Concurrent Control.Monad let echo = forever $ readIORef msg = putStrLn threadDelay 300 Prelude Data.IORef Control.Concurrent Control.Monad t - forkIO echo Hello Prelude Data.IORef Control.Concurrent Control.Monad Hello Hello writeIORefHello msg World Prelude Data.IORef Control.Concurrent Control.Monad World World Thanks ... this is the possibility I was looking for. Btw, I am thinking I'd need to use STM to synchronize right? Regards, Kashyap You need STM when you need groups of references to change simultaneously as perceived by concurrent processes. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding style vs. foreign interfaces
On Sun, Feb 6, 2011 at 10:10 PM, Donn Cave d...@avvanta.com wrote: Of the people who are apt to be interested, a sizeable percentage already will be familiar with ALARM_STUFF_WENT_WRONG, and as the nice Haskell spelling offers no practical advantage at all, it's purely a waste of their time to translate from one to the other. Is screenflicker_frequency() going to be screenFlickerFrequency, or screenflickerFrequency? gah! I don't think it's this simple. It is disheartening to innocently download a library from Hackage to find that it only supports a very non-Haskelly API. Why am I being punished by the history of a library? To support both kinds of users, we have designs like that used in the OpenGL library: a Foo-Raw library, with a friendlier API layered on top, perhaps in a separate package. If the friendly API turns out to be no friend of yours, you are free to turn to the raw wrappers. Perhaps we should aim for a more systematic application of this design pattern? I know that I appreciate a more idiomatic Haskell API when it is available, and certainly do not want library authors discouraged from providing such a service solely due to the provenance of the functionality. On the other hand, when I am porting, say, C coded against a particular API to Haskell, being able to use a more symmetric API is beneficial. One can keep both APIs in the same package until a legitimate desire to split them arises (e.g. to provide alternate high-level APIs). Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding style vs. foreign interfaces
Quoth Anthony Cowley acow...@seas.upenn.edu, ... To support both kinds of users, we have designs like that used in the OpenGL library: a Foo-Raw library, with a friendlier API layered on top, perhaps in a separate package. If the friendly API turns out to be no friend of yours, you are free to turn to the raw wrappers. Perhaps we should aim for a more systematic application of this design pattern? I know that I appreciate a more idiomatic Haskell API when it is available, and certainly do not want library authors discouraged from providing such a service solely due to the provenance of the functionality. On the other hand, when I am porting, say, C coded against a particular API to Haskell, being able to use a more symmetric API is beneficial. I don't know the OpenGL example, but I gather you're talking about an API that's different in a practical way, not just a thin layer with the names spelled differently. In that case, assuming that it really is more Haskell-functional-etc, vive la difference! No one would argue with this, I think. I just think that's how far you should have gotten, before you need to think about new Haskell-style names. For examples where someone apparently felt that new names for everything was the first order of business, you could look just about anywhere in System.Posix. System.Posix.Terminal - at least the documentation helpfully reveals the actual POSIX 1003.1 function names, but try for example to figure out what has become of the the fairly commonly used ICANON flag, without looking at the source. If you're hoping that in the course of time a significantly functionally designed API will come along for any of these things, note that names it might have used are already taken. Donn Cave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hsc2hs not using foreign.c types?
I'm just now trying to figure out how to use the FFI, along with hsc2hs. When I use the #type ... directive in my .hsc files to pull in a c typedef that is aliased to an integer, it puts in Word32 instead of CInt. I was hoping to use this in my foreign imports: Two questions: - Can I declare a foreign import of a c function that takes a c 'int' to have a 'word32' input type in Haskell and will that function correctly? - Why doesn't hsc2hs use 'CInt' instead? -- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
On Wed, 2011-02-02 at 01:33 +, Duncan Coutts wrote: As you will be aware, some of the *.haskell.org websites have been down recently, specifically: code.haskell.org trac.haskell.org projects.haskell.org planet.haskell.org community.haskell.org [...] We have not yet re-enabled user login accounts, nor re-enabled access to code repositories. The support ticket system is not yet enabled. We will send a further update when these are re-enabled, or procedures for people to re-enable them are finalised. We have restored read-only access to the majority of projects on: code.haskell.org(code repositories) projects.haskell.org(project webspace) A small number have been held back because they contain .js, .html or .tar.gz snapshots that are not recorded in any repository. We will ask project owners to check these before they are restored. Duncan (On behalf of the Haskell infrastructure team) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: case-insensitive-0.1
On 7 February 2011 15:26, Max Rabkin max.rab...@gmail.com wrote: This could be a useful package but can you add a note that this does not do correct Unicode-aware comparison on String (though AFAICT it is correct for Text)? Good point! I just released version 0.2: http://hackage.haskell.org/package/case-insensitive-0.2 Changelog: * Added note about the not fully correct case folding of types other than Text Requested by Max Rabkin. * Removed FoldCase instance for [s] and added one for String I think this makes more sense. Bumped version from 0.1 to 0.2 because of the removed instance. * Export foldedCase :: CI s - s. * Other little documentation fixes. Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
Haskell en Clean are very much alike. From what I could determine from a basic Clean introduction, Clean is very *unlike* Haskell, having a far more verbose and low-level syntax. (E.g., the compiler can't even determine whether a binding is recursive or not for itself. You have to say that manually.) I have no idea what you are talking about here. Clean is _very_ Haskell-like, including typeclasses. Here's the first few lines of code from a Clean file I wrote in 1998. I clearly have my languages mixed up. The language I'm thinking of required all variables (even top-level ones) to be declared with let - unless the definition is recursive, in which case you have to say letrec (i.e., the compiler it too stupid to deduce this automatically). Apparently that isn't Clean... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
I think haskell2010's type system is just not expressive enough to create interface generic enough. It's not possible to create type class which will work for both ByteStrings (or IntSet) and lists. It seems that most people agree: The reason why we don't have container classes is that it's difficult to define them in a completely type-safe mannar. (The OOP people, of course, just don't bother trying. They use typecasts everywhere...) Do associated types solve this? Or are there still problems? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 8/02/2011, at 3:47 AM, Gábor Lehel wrote: I dunno. As a language extension, would - let's call it BangTypes - be backwards-incompatible in any way? Let's look at an intermediate step first, BangFunctions. What this does is to say that there are two versions of -: t1 - t2 What we have right now, which might be evaluated or not. !t1 - t2 The function wants its argument evaluated. Suppose f is a value of this type. Then a use of f is rather like a use of (\x - x `seq` f x) and we can already write that. Now if you write f :: !t1 - t2 f p1 = e1 ... f pn = en you're making the function strict whether it would have been strict or lazy. But again, with BangPatterns we can already do that: f !(p1) = e1 ... f !(pn) = en The advantage of BangPatterns is that they can be precisely and selectively located. The advantages of BangFunctions include - the forced strictness is part of the function's (published) *interface*, not its implementation - the question of what happens if some patterns for an argument are banged and some are not does not arise (I *think* that this can avoid some mistakes) - it's compatible with BangTypes but simpler. So in some sense there is (now) nothing new here *except* putting the information where people can easily see it. BangTypes could be rather more complicated. Clean 2 offers lazy, head strict spine lazy, head lazy spine strict, head and spine strict, head unboxed spine lazy, head unboxed spine strict for lists, which are all different types; it also offers strictness-polymorphic lists. I never actually made use of this because having so many kinds of list made my head spin. Roughly speading, Clean 1 had BangFunctions, Clean 2 BangTypes. One of the things that makes me wary of BangPatterns is that it seems as though it's headed in a BangTypes kind of direction. Oh, by the way, I got the Clean syntax wrong. ![a] means lazy list evaluated to WHNF; [a!] means value is spine strict. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On Mon, Feb 7, 2011 at 10:01 PM, Andrew Coppin andrewcop...@btinternet.com wrote: I think haskell2010's type system is just not expressive enough to create interface generic enough. It's not possible to create type class which will work for both ByteStrings (or IntSet) and lists. It seems that most people agree: The reason why we don't have container classes is that it's difficult to define them in a completely type-safe mannar. (The OOP people, of course, just don't bother trying. They use typecasts everywhere...) Do associated types solve this? Or are there still problems? Duncan showed me a definition using associated types, which I have unfortunately forgotten. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 7 February 2011 22:00, Andrew Coppin andrewcop...@btinternet.com wrote: I clearly have my languages mixed up. The language I'm thinking of required all variables (even top-level ones) to be declared with let - unless the definition is recursive, in which case you have to say letrec (i.e., the compiler it too stupid to deduce this automatically). Apparently that isn't Clean... You are not necessarily wrong. Clean, like Haskell, is a moving target. To quote the paper Exchanging Sources Between Clean and Haskell [1]: The year of 1987 was a founding one for two pure, lazy, and strongly typed functional programming languages. Clean (Brus et al., 1987) was presented to the public for the first time and the first steps towards a common functional language, later named Haskell, were taken (Hudak et al., 2007). Clean was conceived at the Radboud University Nijmegen as a core language that is directly based on the computational model of functional term graph rewriting to generate efficient code. It also serves as an intermediate language for the compilation of other functional languages (Koopman and Nöcker, 1988; Plasmeijer and van Eekelen, 1993). For these reasons, it deliberately used a sparse syntax (van Eekelen et al., 1990): “... at some points one can clearly recognize that [..] Clean is a compromise between a functional programming language and an intermediate language used to produce efficient code. For instance, a minimal amount of syntactic sugar is added in [..] Clean.”. Later, the core language was sugared. The Clean of 1987—1994 sounds a lot like the language you are talking about. 1 - http://www.cs.ru.nl/~thomas/publications/groj10-exchanging-sources-between.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 8/02/2011, at 10:00 AM, Andrew Coppin wrote: I clearly have my languages mixed up. The language I'm thinking of required all variables (even top-level ones) to be declared with let - unless the definition is recursive, in which case you have to say letrec (i.e., the compiler it too stupid to deduce this automatically). Apparently that isn't Clean... That sounds like an ML-family language, possibly OCAML. However, this is *not* a question of stupidity. It's a question of scope rules. Example 1: let f x = 1;; let f x = if x = 0 then 0 else f x;; f 3;; This answers 1. Example 2: let f x = 1;; let rec f x = if x = 0 then 0 else f x;; f 3;; This goes into an infinite loop. If you don't like redeclaration, which is rather useful in an interactive top level, try nested: let f x = 1;; let g y = let f x = if x = 0 then 0 else f x in f (f y);; vs let f x = 1;; let g y = let rec f x = if x = 0 then 0 else f x in f (f y);; The distinction between let and letrec predates OCAML. Scheme does it too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
The distinction between let and letrec predates OCAML. Scheme does it too. Haskell's choice of recursive everywhere is nice for the syntax, but occasionally error prone. I don't actually use explicit recursion too often because there are functions for that, but I still occasionally typo a variable name and make a circular reference, say naming a function's output the same as one of its inputs. If they're the same type then you get that least-friendly of crashes: an error-less hang with no indications about where it is. It means you sometimes can't reuse variable names when it would be better to shadow the old one and sometimes wind up with tricks like 'x - return $ f x'. So there's a case to be made for letrec too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 8/02/2011, at 10:43 AM, Roel van Dijk wrote: On 7 February 2011 22:00, Andrew Coppin andrewcop...@btinternet.com wrote: I clearly have my languages mixed up. The language I'm thinking of required all variables (even top-level ones) to be declared with let - unless the definition is recursive, in which case you have to say letrec (i.e., the compiler it too stupid to deduce this automatically). Apparently that isn't Clean... You are not necessarily wrong. The Clean of 1987—1994 sounds a lot like the language you are talking about. 1 - http://www.cs.ru.nl/~thomas/publications/groj10-exchanging-sources-between.pdf No, it doesn't. Here's an example from Clean - A Language for Functional Graph Rewriting, T.H. Brus, M.C.J.D. van Eekelen, M.O. van Leer, M.J. Plasmeijer, a 1987 paper which I _think_ is the first one about Clean: Start stdin - Double (Add (Succ Zero) Zero); Double a- Add a a; Add Zero n -n | Add (Succ m) n -Succ (Add m n); You will notice - an entire absence of 'let' - an entire absence of any 'letrec' You'll also discover that Clean was originally - thought of as an intermediate language - a subset of something called LEAN Clean 1 adopted Haskell-like syntax, but it was lazy from the beginning. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] http-enumerator: redirects, streaming and keep-alive
On Wed, Feb 2, 2011 at 1:01 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: And what about connection limits? We shouldn't create a thousand connections to the same host =). For what it's worth, I wrote a connection pool manager for the riak package that has to solve some of the same problems. https://github.com/mailrank/riak-haskell-client/blob/master/src/Network/Riak/Connection/Pool.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
From: Johan Tibell johan.tib...@gmail.com (The OOP people, of course, just don't bother trying. They use typecasts everywhere...) Do associated types solve this? Or are there still problems? Duncan showed me a definition using associated types, which I have unfortunately forgotten. Yes, associated types (or fundeps) solve this problem. This problem of container types is one of the motivating examples behind both extensions. I think the real problem we have with container classes has a lot more to do with what we would use them for. That is, Haskell already has Monoid, Foldable and Traversable. These three (especially Foldable) cover nearly everything OOP programmers would expect out of generic container operations. What's missing are classes for specific data types. That is, a Map/Dict interface, a Queue interface, and a Heap interface (probably others too, but these are the first that come to mind). But the standard Data.Map and List (for a queue) seem good enough for most people, so there seems to be a lot of inertia to overcome for these to be popular. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building doc for yesod-json
On 07/02/11 04:19, Michael Snoyman wrote: On Mon, Feb 7, 2011 at 2:36 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 7 February 2011 11:11, Magnus Therning mag...@therning.org wrote: Michael, I've now gotten part of the way through the *long* list of dependencies for yesod 0.7.0, and I'm stuck on yesod-json. It's the documentation that fails actually, but I'm not sure why it would: dist/build/tmp20668/Yesod/Json.hs:4:6: parse error on input `-- ^ Convert from a JSON value' It's the very first bit in that file: module Yesod.Json ( -- ^ Convert from a JSON value defaultLayoutJson You want -- * for section headers: -- ^ is only used to annotate constructors. Of all things to mess up... ok, I've uploaded yesod-json-0.0.0.1. Hopefully that should work. That worked beautifully. Thanks! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 8 February 2011 09:57, John Lato jwl...@gmail.com wrote: I think the real problem we have with container classes has a lot more to do with what we would use them for. That is, Haskell already has Monoid, Foldable and Traversable. These three (especially Foldable) cover nearly everything OOP programmers would expect out of generic container operations. That was what my rewrite was going to be using. The problem, however, is two-fold: * Dealing with types of kind * vs kind * - * * Dealing with types of kind * - * that have a restriction on the type parameter (e.g. Set). I was basing my approach on Ganesh's rmonad [1] library whilst taking into account the Functor = Applicative = Monad hierarchy when re-defining the classes, but the approach was very quickly becoming unwieldy. [1]: http://hackage.haskell.org/package/rmonad -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding style vs. foreign interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/7/11 12:36 , Donn Cave wrote: I don't know the OpenGL example, but I gather you're talking about an API that's different in a practical way, not just a thin layer with the names spelled differently. In that case, assuming that it really is more Haskell-functional-etc, vive la difference! No one would argue with this, I think. Usually the low level one is merely a thin layer, whereas the high level one is more than just Haskell conventions but a proper Haskell-style API, using e.g. monads instead of opaque state blobs. helpfully reveals the actual POSIX 1003.1 function names, but try for example to figure out what has become of the the fairly commonly used ICANON flag, without looking at the source. If you're hoping that in the course of time a significantly functionally designed API will come along for any of these things, note that names it might have used are already taken. +1. The stuff that's a thin wrapper, such as System.Posix.*, should keep names as close to the API it's mirroring as possible; if you want to rename them, do it in the context of an actual Haskell API. - -- brandon s. allbery [linux,solaris,freebsd,perl]allber...@gmail.com system administrator [openafs,heimdal,too many hats]kf8nh -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1QiYsACgkQIn7hlCsL25UZ4gCgrS2vGDNqk0QPyPB9+ZVCCYHi oBsAnA5XJyHSozeEny+xlnNcL+K5ZfAy =AfVP -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] forkIO on GHCI does not seem to spawn the thread in the background on some OSs
Hi, I found that on windows and my ubuntu box, when I did this ghci t - forkIO someAction someAction started executing in the foreground - as in, the ghci prompt did not come back (until I pressed Ctrl-C) On my mac however, when I ran the same thing, the action started executing in the background and ghci prompt returned instantaneously. How can I get the thread backgrounded explicitly? Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AES on 32-bit system
Hi all, I released the intel-aes package which has support for AESNI (and as a fallback uses the same C code as AES, both with Thomas's Crypto.Classes.BlockCipher interface). But it has a long way to go to be portable. I'm afraid of exactly these sorts of compiler problems. For arguments sake, what do you think of prebuilding .so files for all of the common platforms? (Especially in the AESNI case which involves a separate makefile, assembly files, and yasm.) I've used this strategy in intel-aes-0.1.2. A stripped linux .so for this purpose is 26K which doesn't seem so bad. Of course these compile/portability problems still need to be solved at least once to build the libraries ;-). Anyway this is not really my area so I'm not trying to bump anyones package out of the way, I just wanted to get something out there with AESNI support (before I heard Vincent was interested). Cheers, -Ryan On Sun, Feb 6, 2011 at 12:37 AM, Michael Snoyman mich...@snoyman.comwrote: OK, now I'm sure I tried it before: I tried switching Haskellers over to AES with that code change you mention, and it results in runtime crashes (I assume segfaults, I didn't really look into it too much). So Svein, please disregard my requested code change, it's a bad idea. Michael On Fri, Feb 4, 2011 at 8:16 AM, Michael Snoyman mich...@snoyman.com wrote: Wow, I thought I'd tried that before, I guess not. Yes, that compiles, and an initial test seems that it does not break at runtime either. I'll email the author and see if he can make that change. Michael On Fri, Feb 4, 2011 at 8:11 AM, Daniel Peebles pumpkin...@gmail.com wrote: Knowing nothing about the package or its code, it looks like a typo to me. The stdint.h naming of types would have it be uint64_t, not uint_64t. Could that be it? On Fri, Feb 4, 2011 at 6:00 AM, Michael Snoyman mich...@snoyman.com wrote: Hi everyone, Does anyone else have trouble installing the AES package on a 32-bit system? My system at home installs it just fine, but my VPS chokes with the following error messages (plus a bunch of warnings): cbits/ctr_inc.c:11:0: error: 'uint_64t' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: (Each undeclared identifier is reported only once cbits/ctr_inc.c:11:0: error: for each function it appears in.) cbits/ctr_inc.c:11:0: error: 'ctr' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: expected expression before ')' token It's actually for this very reason that I'm still maintaining the OpenSSL backend for http-enumerator: I think the tls package is stable enough now to be used in production environments (kudos to Vincent by the way). However, I can't use it in production if I can't build one of its dependencies. This bug is also preventing me from adding some nice features to http-enumerator, such as checking validity of SSL certificates. Anyone have any thoughts? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On Mon, Feb 7, 2011 at 11:57 PM, John Lato jwl...@gmail.com wrote: I think the real problem we have with container classes has a lot more to do with what we would use them for. That is, Haskell already has Monoid, Foldable and Traversable. These three (especially Foldable) cover nearly everything OOP programmers would expect out of generic container operations. Unfortunately using e.g. Foldable hurts performance a lot. We need to look into inlining and specialization and move some functions (e.g. foldl') into the type class if we want acceptable performance. What's missing are classes for specific data types. That is, a Map/Dict interface, a Queue interface, and a Heap interface (probably others too, but these are the first that come to mind). But the standard Data.Map and List (for a queue) seem good enough for most people, so there seems to be a lot of inertia to overcome for these to be popular. I think the missing piece to make this abstraction worthwhile is a second Map/Dict type worth using. Then there's a point in abstracting over which type is actually used. In most OOP languages the two map types are sorted and hashed maps. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unrecognized function symbols in .prof
Hi, I am profiling a Haskell program using GHC, and after executing the program with +RTS -p, I get a .prof file that lists the cost centers of the program. Some of the cost centers listed are for function symbols that do not exist in the given module. For example, I have in my .prof file: COST CENTRE MODULE %time %alloc ==_a2MTFoo 19.80.0 ==_a2R8 Foo 17.80.0 ==_a2Bg Bar 13.70.0 It appears these are generated symbols; how do I find out what those function symbols correspond to? (In this case, my assumption is that these symbols refer to instances of the Eq class, but I'm not sure.) [I couldn't find anything about this in the GHC online documentation or via Googling, but sorry if I missed it.] Thanks, Lee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unrecognized function symbols in .prof
Hi Lee, I would also guess that these are probably the implementations of equality in the given modules. One way to test this would be to name the equality function explicitly. For example, something like this: myEquality x y = ... instance Eq MyType where (==) = myEquality Another option would be to look at the generated core by using -ddump-simpl when compiling. This will generate a whole bunch of output, which you can redirect to a file and the search for the mysterious symbols inside. Hope this helps, -Iavor On Mon, Feb 7, 2011 at 11:12 PM, Lee Pike leep...@gmail.com wrote: Hi, I am profiling a Haskell program using GHC, and after executing the program with +RTS -p, I get a .prof file that lists the cost centers of the program. Some of the cost centers listed are for function symbols that do not exist in the given module. For example, I have in my .prof file: COST CENTRE MODULE %time %alloc ==_a2MTFoo 19.80.0 ==_a2R8 Foo 17.80.0 ==_a2Bg Bar 13.70.0 It appears these are generated symbols; how do I find out what those function symbols correspond to? (In this case, my assumption is that these symbols refer to instances of the Eq class, but I'm not sure.) [I couldn't find anything about this in the GHC online documentation or via Googling, but sorry if I missed it.] Thanks, Lee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
