- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
by John A. De Goes 09 Jan '09

09 Jan '09

Hi Austin, How do you know it's not your experience with FFI code that isn't biased? As far as I know, there has been no systematic attempt to document whether pure Haskell or FFI-based libraries are better designed and better maintained. Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between. In my experience, FFI code is often based on bulk translation of C header files into the IO monad. It requires an exact version of a library to work (usually much older than the current), it does not compile out of the box, there's scant documentation, and very little high-level design has been imposed on the low-level C interface (may as well use C!). Exceptions to this rule, there are, but as I said before, my experience leads me to believe they *are* exceptions to a *general* rule. Regards, John On Jan 8, 2009, at 3:47 PM, Austin Seipp wrote: > Excerpts from John A. De Goes's message of Thu Jan 08 12:14:18 -0600 > 2009: >> But really, what's the point? FFI code is fragile, often uncompilable >> and unsupported, and doesn't observe the idioms of Haskell nor take >> advantage of its powerful language features. > > This is a completely unfair generalization. The FFI is an excellent > way to interoperate with an extraordinary amount of external > libraries, and if you ask me, it's *worth* taking those pieces of C > code and wrapping them up in a nice, safe haskell interface. I will > also > mention that Haskell has *the* simplest FFI I have ever used, which to > me only means it's easier to get it right (the fact that there are > customized *languages* like e.g. cython to make writing python > extensions easier makes me wonder.) > > I suggest you take a look at the haskell llvm bindings - they are > extraordinarily well documented, and the high level interface uses > *many* haskell idioms that make the library safe and easy to use: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ > llvm-0.4.2.0 > > This code most certainly takes advantage of powerful features and > idioms that only Haskell can provide. Please do not take your bad > experiences with a few crappy binding (or not even crappy bindings, > perhaps bindings that just aren't very abstract) and extend them to > the bindings that are excellent with a sweeping statement like that. > > Austin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

ANNOUNCE: haskell-src-exts 0.4.8
by Niklas Broberg 09 Jan '09

09 Jan '09

Fellow Haskelleers, it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.8: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts… darcs get http://code.haskell.org/HSP/haskell-src-exts This is a bug-fix release in the wake of the flurry of bug reports I received due to Neil Mitchell's release of hlint. Not all bugs have been squashed, but all the ones that I could handle with fairly small changes to the library should be. Those include deriving for MPTCs, importing constructor symbols, inline pragmas in instance declarations, scoped type variables, and a few more. There are some minor non-backwards compatible changes to the abstract syntax, but nothing too serious. The most pervasive is that the Match and PatBind constructors have an extra argument of type Maybe Type, representing an optional type signature. Derivings also are no longer just a list of class names, since those classes can now have extra parameters. Four things remain on the bug list: - Support for explicitly kinded arguments to type families. Shouldn't be too hard, but will require changes to the AST that I will leave for the next release. - Support for (un-parenthesised) higher-ranked types as arguments. haskell-src-exts supports e.g. foo :: b -> (forall a . [a]) -> b but not foo :: b -> forall a . [a] -> b. Supporting the latter is simply a parser issue, but a rather tricky one. - Correct handling of hyphened vars (an artifact of HSX/HSP) vs minus operators. This one is nasty. - Support for Unicode symbols for e.g. ->. Fixing that would require me to have a Unicode-compliant editor, which it appears I don't. And I couldn't have someone else submit a patch either, since then I couldn't open the file anymore in my editor. So unless someone can point out a good Unicode-aware editor for Windows, I'm afraid this is a feature that won't be implemented. If you find anything else that haskell-src-exts fails on, please report it. Cheers and Happy Haskelling, /Niklas

6 6

ANNOUNCE: X Haskell Bindings
by Antoine Latter 09 Jan '09

09 Jan '09

Folks, I'd like to announce a preview-release of the X Haskell Bindings. The goal of the library is to provide low-level access to the X11 protocol, in the spirit of the X C Bindings This is a "preview" because I expect that the interface will still need to change - but I do plan on bump the minor-version number when that happens. On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb What works: All X protocol requests have corresponding functions. I haven't tested all of them. Requests are sent asynchronously - the caller is not blocked until they need to examine the result of the request Errors and Events are unpacked into Haskell data types It should be safe to use the same connection in multiple threads What needs improvement: * There's no documentation - you pretty much need to be sitting down with the X Protocol reference while using this library. Once we can get documentation into the XML that this library is generated from, we should be able to generate Haddock documentation at the same time * A lot of parameters are specified using integer types, even though a proper Haskell enum-like data type exists. * Many functions take a ValueParam argument, which is not fun to work with in a language like Haskell. I have plans for how to make these more type-safe, but this is something else that requires more information in the XML protocol descriptions. * There's no way to share a connection between XHB and libraries built against the Xlib bindings. * I haven't done any benchmarking, so it's possible that all of this is pretty slow. Keep in mind that this is a library for the X Protocol - it alone is not a replacement for XLib - XLib does a lot more than pushing and pulling on a file-handle. Related releases: Spencer Janssen has released FFI bindings to Xauth: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Xauth-0.1 I've released a small library for determining the byte-ordering of the system: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/byteorder-1.0.0 Related projects: X C Bindings: http://xcb.freedesktop.org/ -Antoine

1 0

ANNOUNCE: Data.TCache 0.5.5
by Alberto G. Corona 09 Jan '09

09 Jan '09

The main addition of this versión is the capablity to safely handle transact, and serialize to permanent storage many datatypes simultaneously in the same piece of code and incrementally. Just register each new datatype (with registerType :: <Type>). So it is not necessary to glue all types in advance in a single algebraic datatype. I suppose taht "enhanced composablility" applies to this feature. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TCache In this release: Added a Data.TCache.Dynamic. (SEE dynamicsample.hs) - Can handle, transact, and serialize to disk many datatypes simultaneously and incrementally - Dynamic uses the same interface than TCache and add *DResource(s) calls for handling many datatypes simultaneously - Safe dynamic data handling trough a lighter, indexable and serializable version of Data.Dynamic - Added KEY object for retrieving any object of any type. Data.Tcache is a transactional cache with configurable persistence. It tries to simulate Hibernate for Java or Rails for Ruby. The main difference is that transactions are done in memory trough STM. There are transactional cache implementations for some J2EE servers like JBOSS. TCache uses STM. It can atomically apply a function to a list of cached objects. The resulting objects go back to the cache (withResources). It also can retrieve these objects (getResources). Persistence can be syncronous (syncCache) or asyncronous, wtih configurable time between cache writes and configurable cache clearance strategy. the size of the cache can be configured too . All of this can be done trough clearSyncCacheProc. Even the TVar variables can be accessed directly (getTVar) to acceess all the semantic of atomic blocks while maintaining the persistence of the TVar updates. Persistence can be defined for each object: Each object must have a defined key, a default filename path (if applicable). Persistence is pre-defined in files, but the readResource writeResource and delResource methods can be redefined to persist in databases or whatever. There are Samples in the package that explain the main features.

1 0

advanced class constraints in Haskell 98?
by Henning Thielemann 09 Jan '09

09 Jan '09

GHC accepts a class declaration like class Monad (m Maybe) => C m where ... without having any language extension switched on. But it isn't Haskell 98, is it? Hugs 2005 also accepts this.

4 10

Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
by John A. De Goes 09 Jan '09

09 Jan '09

> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >> >> The number of applications requiring the implementation of a custom >> web >> server is an insignificant fraction of the number of applications >> requiring a messaging system. I don't think anyone would dispute >> Haskell's ability to do low-level, raw networking, of the type that >> few >> people actually need to do. It's the higher level stuff where >> there's a >> huge amount of room for improvement. > > I disagree on both points. > > Haskell has had somewhat of a deficit in the low-level networking > stuff, not even supporting IPv6 in the standard stack until just > recently. (That is, things like AF_INET6 were not present.) > > I think it has pretty much caught up by now though. If you think Haskell has caught up by now, then you DO NOT disagree with my statement that "[no one] would dispute Haskell's ability to do low-level, raw networking." Which makes me wonder what you mean by, "I disagree on both points." > On the other hand, I see nothing in Haskell that would prevent its use > for any of your purposes. There are numerous high-level web > infrastructures already. Perhaps they are more or less suited to your > needs, but that's a library issue, not a language issue. In other words, to quote myself, "it's the higher level stuff where there's a huge amount of room for [library] improvement." Nothing in the Haskell language prevents its use for high-level networking. But the sad fact of the matter is that there is no library support for it. So applications that need such networking today are better off written in Erlang. Regards, John

1 0

issues with posix-realtime package
by Manlio Perillo 09 Jan '09

09 Jan '09

Hi. I'm testing the posix-realtime package, but I have found a problem. Configuration, build and install works well, but if I execute some code from ghci I get: GHCi runtime linker: fatal error: I found a duplicate definition for symbol __hsunix_wifexited whilst processing object file /usr/local/lib/posix-realtime-0.0.0.1/ghc-6.8.2/HSposix-realtime-0.0.0.1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. If I comment the definition for __hsunix_wifexited, I get a duplicate definition for symbol pPrPr_disableITimers, and so on, for all the definitions in HsUnix.h and execvpe.h Thanks Manlio Perillo

1 0

Staged evaluation, names?
by wren ng thornton 09 Jan '09

09 Jan '09

Dear Cafe, Every now and then I find myself in the position where I'd like to define some hairy value as a CAF instead of a literal, but I'd like for it to be fully evaluated at compile-time rather than postponed until runtime. It'd be possible to bludgeon the CPP into doing this, but it seems easier to use an autocannon like Template Haskell to swat this fly. This seems like a common thing for folks to want but the TH documentation targets much higher-hanging fruit, which actually made it harder to figure out how to do something this basic (which would have been transparent with MetaML/MetaOCaml-like syntax). I've figured it out and circumvented the gotchas, and I was thinking of releasing the code as a counterpoint to all the very-high level TH tutorials. The question for y'all is what should I call it? I've been calling the template-function qaf (for Compiled Applicative Form ;) and the type class with that function would be the only thing in the package, but I'm not sure where QAF.hs should be in the module hierarchy. Thoughts? -- Live well, ~wren

3 5

Marshalling recursive data structures with the FFI
by Ron de Bruijn 09 Jan '09

09 Jan '09

Hi, A few days ago we published an article (http://gamr7.com/blog/?p=66) on using the FFI to marshal recursive data structures between Haskell and C (or Python if you use ctypes). Best regards, Ron de Bruijn

1 0

GHC libraries documentation and links to source files
by Manlio Perillo 09 Jan '09

09 Jan '09

Hi. I have noted that recent versions of the GHC libraries documentation, no longer have links to the source code. What is the reason? I find it very useful. Thanks Manlio Perillo

3 2