Re: [Haskell-cafe] Data.IArray rant
On 03/09/2011, at 03:04, Ivan Lazar Miljenovic wrote: On 3 September 2011 11:38, Evan Laforge qdun...@gmail.com wrote: The result is that my first contact with haskell arrays left me with the impression that they were complicated, hard to use, and designed for someone with different priorities than me. Of course, Data.Vector didn't exist back then, but if someone were new to haskell now I would recommend they skip Data.IArray and head straight for vector. To an extent, I wonder how much of this has been that arrays were considered to be bad in Haskell, so no-one used them and no-one bothered to try and improve the API much (and instead went and created Vector, etc.). It's rather that some considered the IArray API to be inadequate most of the time. Really, H98 arrays aren't very good at anything they do. For collective operations, you are supposed to convert the array to a list, work on the list and then convert it back to an array which just seems wrong. Multidimensional arrays can't be sliced and diced in the style of Repa or NumPy. In general, H98 arrays seem to have been designed with the goal of providing a container with O(1) indexing. They do that, I suppose, although they aren't very well integrated with the rest of the language and they have conceptual problems (such as requiring two bounds checks for one array access). But requirements have shifted quite a bit since then. Now, people want to write real array programs and they want those to be fast. Personally, I don't know how to improve the H98 array API to provide this. You basically need to create a completely new API based on different principles. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Configuration Problem and Plugins
Greetings,
I'm a Python programmer who is relatively new to Haskell, so go easy on me :)
I have a program that uses (or will use) plugins to render output to
the user in a generic way. I'm basing the design of the plugin
infrastructure on the Plugins library, and have the following
interface:
data Renderer = Renderer {
initialize :: IO (),
destroy :: IO (),
render :: SystemOutput - IO ()
}
The program loads plugins at the start and runs the initialize
function, and then enters the main loop where it repeatedly calls the
render function with output to display. When the program exits the
main loop, it calls the destroy function to clean up any resources
used by the plugin. You can probably already see my problem: how do I
pass initialization information created in the initialize function to
the render function?
I'm vaguely aware of some solutions to the typical configuration
problem, such as implicit arguments or explicitly passing the
configuration data through the function call hierarchy. As far as I
can tell, neither of these approaches would work because the program
can't know at compile time what, if any, configuration data is used by
the plugin.
I suppose I could pass a Dynamic up the call chain and let the plugin
decode it in the render function, but that seems a little kludgy to
me.
Any thoughts would be greatly appreciated.
--
M. George Hansen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Configuration Problem and Plugins
data Renderer = Renderer {destroy :: IO (); render :: SystemOutput - IO ()}
newtype Initializer = Initializer {initialize :: IO Renderer}
Отправлено с iPad
03.09.2011, в 14:15, M. George Hansen technopolit...@gmail.com написал(а):
Greetings,
I'm a Python programmer who is relatively new to Haskell, so go easy on me :)
I have a program that uses (or will use) plugins to render output to
the user in a generic way. I'm basing the design of the plugin
infrastructure on the Plugins library, and have the following
interface:
data Renderer = Renderer {
initialize :: IO (),
destroy :: IO (),
render :: SystemOutput - IO ()
}
The program loads plugins at the start and runs the initialize
function, and then enters the main loop where it repeatedly calls the
render function with output to display. When the program exits the
main loop, it calls the destroy function to clean up any resources
used by the plugin. You can probably already see my problem: how do I
pass initialization information created in the initialize function to
the render function?
I'm vaguely aware of some solutions to the typical configuration
problem, such as implicit arguments or explicitly passing the
configuration data through the function call hierarchy. As far as I
can tell, neither of these approaches would work because the program
can't know at compile time what, if any, configuration data is used by
the plugin.
I suppose I could pass a Dynamic up the call chain and let the plugin
decode it in the render function, but that seems a little kludgy to
me.
Any thoughts would be greatly appreciated.
--
M. George Hansen
___
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] ANN: EclipseFP 2.1.0 released
Hi there, I wanted to give the 2.1.0 version a try, so I followed the install instructions on the website and downloaded one of the available Eclipse packages (I chose Eclipse IDE for JavaScript Web Developers). Installing EclipseFP then gave me the following error: Cannot complete the install because one or more required items could not be found. Software currently installed: FP: Haskell support for Eclipse 2.1.0 (net.sf.eclipsefp.haskell.feature.group 2.1.0) Missing requirement: Haskell Plug-in Debug Core 2.1.0 (net.sf.eclipsefp.haskell.debug.core 2.1.0) requires 'bundle org.eclipse.jdt.junit 3.3.0' but it could not be found Cannot satisfy dependency: From: Haskell Plug-in Debug UI 2.1.0 (net.sf.eclipsefp.haskell.debug.ui 2.1.0) To: bundle net.sf.eclipsefp.haskell.debug.core 0.0.0 Cannot satisfy dependency: From: FP: Haskell support for Eclipse 2.1.0 (net.sf.eclipsefp.haskell.feature.group 2.1.0) To: net.sf.eclipsefp.haskell.debug.ui 2.0.3 As I couldn't find a hint where to report bugs, I thought I might simply reply to your announcement. Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: EclipseFP 2.1.0 released
Sorry, there was an error in the installation instructions. You need to download a version of Eclipse with Java support (Eclipse for Java developers, Eclipse for Java EE developers or Eclipse Classic). If you find any other error, you can report it in the mailing list at http://sourceforge.net/mailarchive/forum.php?forum_name=eclipsefp-develop 2011/9/3 Andreas Baldeau andr...@baldeau.net Hi there, I wanted to give the 2.1.0 version a try, so I followed the install instructions on the website and downloaded one of the available Eclipse packages (I chose Eclipse IDE for JavaScript Web Developers). Installing EclipseFP then gave me the following error: Cannot complete the install because one or more required items could not be found. Software currently installed: FP: Haskell support for Eclipse 2.1.0 (net.sf.eclipsefp.haskell.feature.group 2.1.0) Missing requirement: Haskell Plug-in Debug Core 2.1.0 (net.sf.eclipsefp.haskell.debug.core 2.1.0) requires 'bundle org.eclipse.jdt.junit 3.3.0' but it could not be found Cannot satisfy dependency: From: Haskell Plug-in Debug UI 2.1.0 (net.sf.eclipsefp.haskell.debug.ui 2.1.0) To: bundle net.sf.eclipsefp.haskell.debug.core 0.0.0 Cannot satisfy dependency: From: FP: Haskell support for Eclipse 2.1.0 (net.sf.eclipsefp.haskell.feature.group 2.1.0) To: net.sf.eclipsefp.haskell.debug.ui 2.0.3 As I couldn't find a hint where to report bugs, I thought I might simply reply to your announcement. Andreas ___ 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] ANN: EclipseFP 2.1.0 released
Is it possible to install it with GHC7.2 ? I tried and it can't compile scion. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: EclipseFP 2.1.0 released
On Sat, Sep 03, 2011 at 06:01:49PM +0200, David Virebayre wrote: Is it possible to install it with GHC7.2 ? I tried and it can't compile scion. David. I ran into this as well. The culprit appears to be MissingH, which does not compile under ghc 7.2 because of conflicts between the base and haskell98 packages. This is a known issue: https://github.com/jgoerzen/missingh/issues/9 Apparently the HEAD version of MissingH has fixed this issue, but a new version has not yet been released. So manually installing it from source ought to work, although I have not tried. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Smarter do notation
Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tasty. On 04/09/11 12:34, Daniel Peebles wrote: Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - -- Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOYuR6AAoJEPxHMY3rBz0PRE8IAMK8sQTzxtgRYeWcyP6JmWso Yl3eDUjny2uMSzIkifJix/t7tYuYG092H6SvA5VhgVBPQUd8LnZH/91X3PDGANBu ufjmCJLuN5+bgeNxvyzBHwz5iYM3GOkPhGvpJ3hJzYFIBlDVnVmMNoCDkki46/nq xJ/gsAIwfgpe4+Ll1LWu9DjVaQHb9nWmdBpTvpbXb7W+WEX7MHIsVsP/KysVFZkc XwPESJntb7oTHCcS3q1GEVTYdMFNKHlWOFcrdkGGQlegvwfjdt221oVDNToZi4z1 wJ268MdvXLSVIcU+JHLYxElQj6zrf2D51oQbHWLS/wlHRnpZHU5gtmrMTKvPvf8= =d1uz -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote: Hi all, For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). What advantage is there in using Applicative rather than Monad for this? Does it _really_ lead to an efficiency increase? -- 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] Smarter do notation
With parsers, for example, it amounts to you have a context-free vs. a context-sensitive language. The functions hidden behind a monadic bind are effectively opaque to any sort of analysis, whereas the static structure of an applicative can be analyzed as much as you want. Ed Kmett does this in his trifecta parsing library (I think there's a couple of other libraries that also do this), but you have to use the applicative interface explicitly where possible to take advantage of the additional optimizations. This would also have benefits for other sorts of EDSLs, for the same reason. An applicative computation might for example be sparked and processed in parallel, whereas it's a lot harder (impossible) to do that if your structure isn't determined beforehand. On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote: Hi all, For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). What advantage is there in using Applicative rather than Monad for this? Does it _really_ lead to an efficiency increase? -- 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] Configuration Problem and Plugins
On Sat, Sep 3, 2011 at 12:33 AM, Max Rabkin max.rab...@gmail.com wrote:
On Sat, Sep 3, 2011 at 03:15, M. George Hansen technopolit...@gmail.com
wrote:
Greetings,
I'm a Python programmer who is relatively new to Haskell, so go easy on me :)
I have a program that uses (or will use) plugins to render output to
the user in a generic way. I'm basing the design of the plugin
infrastructure on the Plugins library, and have the following
interface:
data Renderer = Renderer {
initialize :: IO (),
destroy :: IO (),
render :: SystemOutput - IO ()
}
How about having initialize return the render (and destroy, if
necessary) functions:
initialize :: IO (SystemOutput - IO ())
or
initialize :: IO (SystemOutput - IO (), IO())
Thanks for your reply. That does seem like the best solution, I'll
give it a try.
--
M. George Hansen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Real CMS Application in Haskell
Hello guys, I googled for a real open source CMS application in Haskell but have no luck. So I'm wondering if Haskell is used very little in Web development area. Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Any good topics for Master Thesis
Dear Haskellers, I'm a master student major of computer science and trying to find any topics for my master thesis. My mentor suggest me to find any topic I'm interested in. Therefore I'm thinking whether there are some topics related to FP and Haskell. Especially use such technology to solve problems rather than theory research. Appreciate any suggestions / ideas! -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
