[Haskell-cafe] FRP, arrows and loops
Hello. I'm trying to understand the FRP (by implementing FRP system on my own) and I think I'm slowly getting it. 1. How to interpret ArrowLoop? I have two possible implementations: type RunSF a = a Dynamic () data SF a b c = SF (a (Dynamic, b, RunSF, Set Unique) (c, Set Unique, SF a b c)) (...) instance ArrowLoop (SF a) where loop (SF f) = loop' f undefined where loop' g d = proc (dyn, b, r, s) - do ((c, d'), s, g') - g - (dyn, (b, d), r, s) returnA - (c, s, loop' g' d') instance ArrowLoop a = ArrowLoop (SF a) where loop (SF f) = SF $! proc (d, b, r, s) - do rec ((c, d), s, f') - f - (d, (b, d), r, s) returnA - (c, s, loop f') Since the first is not unlike ArrayCircuit from arrays I guess second one but I'm not quite sure. 2. Why there is no ArrowIO in arrows? I.e. class Arrow a = ArrowIO a where liftAIO :: Kleisli IO b c - a b c (possibly class Arrow a = ArrowST a where liftAST :: Kleisli ST b c - a b c ) 3. Why switch is needed? How to interpret switch with current continuation? I think switch is equivalent to ArrowChoice but do I miss something? Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Ivan Lazar Miljenovic wrote: I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at checking time would require using something like the GHC API, which immediately reduces the niceness and portability of such a tool/library. As a simple approximation, you could consider functions without type signatures to have changed if their implementation or any function they depend on has changed. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
On 2 April 2010 07:22, Twan van Laarhoven twa...@gmail.com wrote: As a simple approximation, you could consider functions without type signatures to have changed if their implementation or any function they depend on has changed. Ah, too much work. Having libraries where the exported functions have signature seems more desirable than no signatures (documentation benefit, at least). So a tool could just print a warning No type signature for _export-name_. This would be an effective social obligation to encourage people to add signatures to exported functions. Also other developers could see the library wasn't using export signatures and be cautious about depending on it themselves. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP, arrows and loops
1) Haven't look closely, but your second ArrowLoop instance seems righter. The question really is the same as with MonadFix instances; you can always define an instance like this data M = ... -- whatever instance Monad M where ... instance MonadFix M where mfix f = mfix f = f ...but this generally won't do any good. Maciej Piechotka wrote: Hello. I'm trying to understand the FRP (by implementing FRP system on my own) and I think I'm slowly getting it. 1. How to interpret ArrowLoop? I have two possible implementations: type RunSF a = a Dynamic () data SF a b c = SF (a (Dynamic, b, RunSF, Set Unique) (c, Set Unique, SF a b c)) (...) instance ArrowLoop (SF a) where loop (SF f) = loop' f undefined where loop' g d = proc (dyn, b, r, s) - do ((c, d'), s, g') - g - (dyn, (b, d), r, s) returnA - (c, s, loop' g' d') instance ArrowLoop a = ArrowLoop (SF a) where loop (SF f) = SF $! proc (d, b, r, s) - do rec ((c, d), s, f') - f - (d, (b, d), r, s) returnA - (c, s, loop f') Since the first is not unlike ArrayCircuit from arrays I guess second one but I'm not quite sure. 2. Why there is no ArrowIO in arrows? I.e. class Arrow a = ArrowIO a where liftAIO :: Kleisli IO b c - a b c (possibly class Arrow a = ArrowST a where liftAST :: Kleisli ST b c - a b c ) 3. Why switch is needed? How to interpret switch with current continuation? I think switch is equivalent to ArrowChoice but do I miss something? Regards ___ 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] Re: Integers v ints
Jens Blanck jens.bla...@gmail.com writes: On 1 April 2010 10:53, Ivan Lazar Miljenovic ivan.miljeno...@gmail.comwrote: Jens Blanck jens.bla...@gmail.com writes: I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell. Seems to have been in 1998. I don't have a complete archive of the discussion, though, and I don't know where to find the Haskell 98 committee minutes on-line. My guess is precision: some numeric calculations (even doing a round on some Double values) will be too large for Int values (at least on 32bit). Note that unlike Python, etc. Haskell doesn't allow functions like round to choose between Int and Integer (which is equivalent to the long type in Python, etc.). Ints have perfect precision as long as you remember that it implements modulo arithmetic for some power of 2. I was hoping that the reason would be that Integers give more users what they expect, namely integers, instead of something where you can add two positive numbers and wind up with a negative number. As I interpret the part of the discussion I have on file, there are two reasons: (1) as you hoped, because Integers are what people expect: reasoning on Integers is more reliable -- you can't do induction on Int, for example, and people don't generally try to prove that they've implemented f x = the_f_they_originally_wanted x `mod` 2^32 (2) good language design. One of the things I've repeated over the years is that Int doesn't have to be part of the language (it's just another peculiar type that should be defined in a library) but Integer does, because without it there's no way to specify the meaning of an Integral constant¹. Jón [1] This isn't quite true; using subtyping one could make Integral constants into [Digit] and leave the conversion to the point where overloading is resolved, but that's a much longer story. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
On Thu, Apr 1, 2010 at 9:13 PM, Rogan Creswick cresw...@gmail.com wrote: On Thu, Apr 1, 2010 at 3:52 PM, Thomas Tuegel ttue...@gmail.com wrote: There are a few frameworks that provide limited degrees of this functionality. I've recently added to test-framework so that the results can be gathered into an xml format that complies with at least some (maybe all?) junit xml parsers. I specifically targeted junit xml so it would be easy to use existing continuous integration systems as-is, but the format is not for haskell tests. It would be nice, for example, to see how many successful quickcheck inputs were run; and the concept of packages and classes had to be munged to work with Haskell modules and test groupings. I need to clean up the code and get it over to Max for review before it'll be widely available, but that's just a matter of finding the time (possibly next week). Thanks for pointing this out! I also noticed that the testrunner package [1] provides almost the same functionality I described here. (In fact, it's almost exactly the same on the type level.) I wouldn't want to reinvent the wheel, and leveraging one of these existing solutions would allow me to get a lot more done over the course of the summer. I have been somewhat hesitant about using an xml format. If we want Cabal to be able to process the test results itself, which is not strictly necessary but potentially useful, using xml would have a substantial impact on Cabal's build dependencies. The test suite would be included in the package description file with a stanza such as: Test main-is: Test.hs build-depends: foo, QuickCheck, Cabal I've been thinking about this as well, and I like this general idea, but I'm not (yet) convinced it's the best. That's probably just because I'm cautious though :) Well, let me try to convince you! :) My intention is to have Cabal handle the 'Test' stanza exactly as if it were an 'Executable test' stanza. I think this gives package authors the most flexibility and greatest ease of use. It's easy to use because, if you can write an 'Executable' stanza, you can write a 'Test' stanza. At the same time, you get all of Cabal's flexibility in handling executables. Furthermore, since Cabal will build this executable as if it were any other, you can write any test suite you want! Don't buy in to the idea of a common output format for test results? Want to use a different framework? No problem! To Cabal, this is just another executable that it builds, and invokes when you ask for tests (and one that it knows not to install). I think ease of use and flexibility are the most important aspects of this plan. Part of the goal here is to entice more package authors to write test suites, which will only happen if the barrier to entry is low. At the same time, it would be nice to convert some authors with existing high-quality test suites, which requires flexibility to work with their existing tests. At this point, the package author need only run: $ ./Setup configure $ ./Setup build $ ./Setup test My general feeling has been that Setup is being discouraged in favor of using 'cabal foo', but I don't have any solid evidence for that (and I could very well be wrong!). They do do slightly different things, so I think it's wise to figure out which idiom is most likely to be used and work with that. The Cabal documentation wasn't entirely clear to me, regarding which is preferred. In any case, the changes I'm talking about making to Cabal would happen in 'Distribution.Simple,' and cabal-install seems to use that, so the improvements should be available to authors and users regardless of which they use. -- Thomas Tuegel [1] http://hackage.haskell.org/package/testrunner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org re-design
How about something more colourful? http://i.imgur.com/7jCPq.png The Get Haskell box should of course be a shiny button. A shadow separating the content box from the background would probably also be a good idea. But the main point is: less dull colours, and the important links should go at the top. On 2 April 2010 04:37, Ben Millwood hask...@benmachine.co.uk wrote: On Fri, Apr 2, 2010 at 4:36 AM, Ben Millwood hask...@benmachine.co.uk wrote: The easiest thing to do on visiting the website is read about why Haskell is so great, and where to find out how to use it. Uhm, I meant the easiest thing *should be* reading about... Sorry about that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskellers hate GUIs!!
I am in the damned position to have tried to develop a GUI app in Haskell. I'm building on top of gtk2hs, now we have a new compiler version a new Platform release and no gtk2hs release, so I cite from a mail from a potential user/contributor for my GUI app. What shall I say, how should he install gtk2hs? Is their a way to get a stable version from a changing darcs repo? If not all Haskellers were such GUI haters, we would have GUI libs with the platform. Jürgen ... Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) Building gtk2hs from source is broken. Not sure why - I did it OK with ghc-6.10.3. I can run ./configure no problem with ./configure --with-hcflags=-O0 --disable-split-objs --with-ghc=/usr/local/lib/ghc-6.12.1 and it claims that it will build: * The following packages will be built: * * glib : yes * gtk: yes * gio: yes * glade : yes * cairo : yes * svgcairo : yes * gtkglext : no * gconf : yes * sourceview : no * gtksourceview2 : yes * mozembed : no * soegtk : yes * gnomevfs : no * gstreamer : yes * documentation : no But make fails horribly...can't find any packages like base that configure had no problems finding, so I have no idea what the problem is there. Which is why I'd rather figure out a way to make ghc-6.12.1 recognize the gtk2hs packages that I have in that non-standard location. It works but it's awkward. :-) Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) I think I'll pack it in for the evening. The procedure I described works well in theory, but apparently if the depends field in the package conf files says something like foo-2.0.1.0, it's not OK to use an existing registered foo that has a higher version number...I registered everything in gtk2hs manually but when building ltk it complains with Bad interface file: /usr/lib/haskell-packages/ghc6/lib/gtk-0.10.1/imports/Graphics/UI/Gtk.hi mismatched interface file versions (wanted 6121, got ) Unfortunately when using these package configuration files one has to use the ABI ID - ghc-pkg register won't work otherwise - so it's very finicky. I'll have to un-register all my gtk2hs packages, and start again from scratch. Anyway, back to Ubuntu, Haskell and Leksah. :-) I am removing
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
On Thu, Apr 1, 2010 at 9:36 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
I propose to build a test suite as its own executable, but to avoid
the problem of granularity by producing an output file detailing the
success or failure of individual tests and any relevant error
messages. The format of the file would be standardized through
library routines I propose to write; these routines would run tests
with HUnit or QuickCheck and process them into a common format.
Cabal, or any other utility, could read this file to determine the
state of the test suite. Perhaps Cabal could even warn the user about
installing packages with failing tests.
All well and good, but your sample code (which I've ommitted for the
sake of brevity) doesn't seem to lead to much room for customisation:
for graphviz's test suite, I include various comments about the purpose
of the test, etc. as well as changing some of QuickCheck's paramaters;
does your proposal allow the inclusion of such customisations?
I've been looking at graphviz's test suite. You used a type
data Test = Test { name :: String
, desc :: String
, test :: IO Result -- ^ QuickCheck test.
}
to represent tests (sorry for mangling the indentation), but this is
practically the same as the type I suggested:
type Test = (String, IO (Bool, String))
The String output in the IO monad can just as easily be used to output
a test description for a successful test as it can be used for an
error message for a failing test. Other than that, the only
difference is that you keep the entire QuickCheck Result, and I
proposed just to keep a Bool (for compatibility between QuickCheck and
HUnit). The use of Bool is purely illustrative; if I use one of the
frameworks I've been discussing with Rogan, it will be whatever that
framework uses, instead of a Bool.
As an aside, I question the necessity of this kind of proposal: how many
people actually run tests for packages they download from Hackage?
graphviz's test suite runs for 110 minutes, and I mainly use it to test
that my changes/inclusions in what it prints and parses is consistent: I
don't expect a user to bother running it (and would question why anyone
would).
It's true that this proposal does much more for package authors than
for users. I'm not proposing to require users to run tests for every
package. At the same time, I'm sure that on the Linux side,
distribution packagers would appreciate wider and more uniform
availability of package tests; this proposal would help on both
fronts.
How does the inclusion of a test option to Cabal allow any
substantial benefits to developers over building the package with a
build-time flag to enable building a test suite?
Admittedly, you stand to benefit less than a package author without
such a complete test suite. At the very least, the proposed 'Test'
stanza for the package description file would make it unnecessary for
you to worry about recognizing a build-time flag and messing about
with UserHooks. (As I said to Rogan, using the 'Test' stanza wouldn't
lock you in to a particular framework: you could use it to compile
your test suite as-is.) That lowers the barrier to entry for creating
test suites so more authors will use them, and that's a substantial
benefit.
I also envision automated testing being offered as a service for
package authors: I would like, e.g., to ensure that my package works
correctly on different architectures and platforms, but I don't have
the means to acquire all those different machines. Collectively,
however, the community does. If we used a standard format for
handling test results, we could offer a service where uploaded
packages would be compiled and tested on an array of machines. Since
we're using a common format, we can write one tool to parse and
summarize the results across all those platforms, and authors can
immediately see where their packages are failing. Certainly, any
single package author could write a tool to do this for any single
package's tests, but now we have a common tool everyone can use simply
by writing tests.
To summarize: everyone's life is easier if we do this bit of plumbing for them.
--
Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
On Thu, Apr 1, 2010 at 11:27 AM, Jens Blanck jens.bla...@gmail.com wrote: I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell. Also, if you are aware of similar discussions in other languages. There is one for Erlang I am aware of. Unfortunately I can't remember where I have read it, so it will have to come off of my head rather than by correct citation. I think it was Joe Armstrong who mused over the idea of having integers of arbitrary size. The argument is that a bug in software due to overflow can be very costly to fix in big installations. As such, it is better to avoid problems by using, essentially, Integer as the default integer type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskellers hate GUIs!!
Hi Jürgen, For GHC-6.12, just darcs version support. So please download darcs version. Axel has working on that make gtk2hs build on cabal. And i'm working on update All gtk2hs API to Gtk+ 2.18.3 (have finish 99%), i can finish all APIs in later days. Axel have finish some sub-modules on http://www2.in.tum.de/~simona/ (Note, above cabal packages not include patches i push recently) After we finsh work, we can merge gtk2hs into Haskell Platform. Because gtk2hs just interface code for low-level C library, so it's stable enough. As recently so much new code push in gtk2hs, perhaps have bug. So please report any problem on gtk2hs mail-list, we can fix it as soon as we can. -- Haskller GUI lover Jürgen Nicklisch-Franken j...@arcor.de writes: I am in the damned position to have tried to develop a GUI app in Haskell. I'm building on top of gtk2hs, now we have a new compiler version a new Platform release and no gtk2hs release, so I cite from a mail from a potential user/contributor for my GUI app. What shall I say, how should he install gtk2hs? Is their a way to get a stable version from a changing darcs repo? If not all Haskellers were such GUI haters, we would have GUI libs with the platform. Jürgen ... Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) Building gtk2hs from source is broken. Not sure why - I did it OK with ghc-6.10.3. I can run ./configure no problem with ./configure --with-hcflags=-O0 --disable-split-objs --with-ghc=/usr/local/lib/ghc-6.12.1 and it claims that it will build: * The following packages will be built: * * glib : yes * gtk: yes * gio: yes * glade : yes * cairo : yes * svgcairo : yes * gtkglext : no * gconf : yes * sourceview : no * gtksourceview2 : yes * mozembed : no * soegtk : yes * gnomevfs : no * gstreamer : yes * documentation : no But make fails horribly...can't find any packages like base that configure had no problems finding, so I have no idea what the problem is there. Which is why I'd rather figure out a way to make ghc-6.12.1 recognize the gtk2hs packages that I have in that non-standard location. It works but it's awkward. :-) Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) I think I'll pack it in for the evening. The procedure I described works well in theory, but apparently if the depends field in the
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
Never been a fan of GTK myself, but that's because I was a KDE developer I guess :-). Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? Dave On Fri, Apr 2, 2010 at 6:34 AM, Andy Stewart lazycat.mana...@gmail.comwrote: Hi Jürgen, For GHC-6.12, just darcs version support. So please download darcs version. Axel has working on that make gtk2hs build on cabal. And i'm working on update All gtk2hs API to Gtk+ 2.18.3 (have finish 99%), i can finish all APIs in later days. Axel have finish some sub-modules on http://www2.in.tum.de/~simona/ (Note, above cabal packages not include patches i push recently) After we finsh work, we can merge gtk2hs into Haskell Platform. Because gtk2hs just interface code for low-level C library, so it's stable enough. As recently so much new code push in gtk2hs, perhaps have bug. So please report any problem on gtk2hs mail-list, we can fix it as soon as we can. -- Haskller GUI lover Jürgen Nicklisch-Franken j...@arcor.de writes: I am in the damned position to have tried to develop a GUI app in Haskell. I'm building on top of gtk2hs, now we have a new compiler version a new Platform release and no gtk2hs release, so I cite from a mail from a potential user/contributor for my GUI app. What shall I say, how should he install gtk2hs? Is their a way to get a stable version from a changing darcs repo? If not all Haskellers were such GUI haters, we would have GUI libs with the platform. Jürgen ... Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) Building gtk2hs from source is broken. Not sure why - I did it OK with ghc-6.10.3. I can run ./configure no problem with ./configure --with-hcflags=-O0 --disable-split-objs --with-ghc=/usr/local/lib/ghc-6.12.1 and it claims that it will build: * The following packages will be built: * * glib : yes * gtk: yes * gio: yes * glade : yes * cairo : yes * svgcairo : yes * gtkglext : no * gconf : yes * sourceview : no * gtksourceview2 : yes * mozembed : no * soegtk : yes * gnomevfs : no * gstreamer : yes * documentation : no But make fails horribly...can't find any packages like base that configure had no problems finding, so I have no idea what the problem is there. Which is why I'd rather figure out a way to make ghc-6.12.1 recognize the gtk2hs packages that I have in that non-standard location. It works but it's awkward. :-) Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) I think I'll pack it in for the evening. The procedure I described works well in theory, but apparently if the depends field in the package conf files says something like foo-2.0.1.0, it's not OK to use
[Haskell-cafe] Re: The 8 Most Important GSoC Projects
Ivan Lazar Miljenovic schrieb: Stephen Tetley stephen.tet...@gmail.com writes: I had a little experiment along the lines of A Package Versioning Policy Checker a few months ago. I got as far as using Haskell-src-exts to extract module export list, but didn't work out out a hashing scheme for the actual type signatures. I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at checking time would require using something like the GHC API, which immediately reduces the niceness and portability of such a tool/library. I've done a brief experiment diffing APIs using the hoogle backend of haddock. While the hoogle files where not a perfect match, what are the drawbacks of using a haddock backend if you want to use a GHC API based approach? However, the major problem with a GHC API based approach is that the result relies on the installed dependencies of the package. For example, it is hard to compute the API changes for older versions which do not build anymore. I also believe that inferring the type of an exported function is not a good idea for the PVPC, as this way the result is somewhat indeterministic, depending on installed dependencies. Therefore it seems that a solution based on eg haskell-src-exts, which does not rely on correctly installed dependencies, is preferrable. benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Fri, Apr 02, 2010 at 07:41:38AM -0700, David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? I think this is an important issue in developing run-of-the-mill GUI apps in Haskell. I recently wrote a small application using gtk2hs, but found it nearly impossible to deploy. I developed it on Linux (where installing all the infrastructure is not too hard, or at least people are used to doing so), but the work required to get it to run on MacOS X seemed extreme. I ended up rewriting it in another language (due to time pressure) and I'm a little wary of attempting to use Haskell again for developing such an application. I didn't even try getting it to work on Windows; maybe that's easier. On the plus side, I found developing with gtk2hs to be straightforward. Is there a general strategy for deploying Haskell apps, graphical or no, to MacOS X and/or Windows? I'm especially interested in cases where the application uses some heavyweight libraries like OpenGL. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] libraries [was GUI haters]
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice. Basically the you start a Haskell service on port some-large-number and make AJAX calls to it from your web browser using a CGI script as a go-between. In my case all data flows back and forth as JSON objects. You could just as easily use XML. For the front-end I used Qooxdoo [1] , an absolutely gorgeous well-documented Javascript GUI framework but there are plenty to choose from. This has a couple of advantages, it encourages MVC by letting the front-end take care of UI and the back-end does the logic and holds state. It's easy to deploy- Javascript runs everywhere and so does Haskell (the non-GUI parts anyway!). And it looks uniform across platforms. The disadvantages include security (but you can always restrict users to localhost), and performance (you probably don't want to visualize gigabyte size datasets in your browser). Additionally you now need to add and configure an extra piece of software, namely the web-server. Also you now have to learn Javascript and add that to the list of things the maintenance programmer has to worry about. But if you can learn Haskell, Javascript shouldn't be an issue. I've found that none of these disadvantages are really show-stoppers. hth, deech [1] http://qooxdoo.org/ On 4/2/10, gladst...@gladstein.com gladst...@gladstein.com wrote: As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper. One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because Java gives you everything you want, for free. That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had thousands of commands. I'll stop whining now. ___ 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] Re: Haskellers hate GUIs!!
On 2 April 2010 17:53, Dominic Espinosa dces...@fastmail.fm wrote: [SNIP] I ended up rewriting it in another language (due to time pressure) and I'm a little wary of attempting to use Haskell again for developing such an application. Hi Dominic Out of curiosity what language did you choose instead? Each time a thread comes up on the Cafe documenting GUI woes, I always wonder if Python or other languages[*] have such problems and if not why not. [*] Obviously Java and C# have benefited from a large industrial investment so have solved their GUI problems by dollars. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] libraries [was GUI haters]
Hi gladst...@gladstein.com wrote: As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper. One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because Java gives you everything you want, for free. That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had thousands of commands. Looking at Wikipedia I can see that COBOL 2002[1] got user defined functions, but prior it was impossible to define your own functions. You could define sub-rutines (semantically similar to jsr/gosub in assembler/basic), but not functions that could be used like the build-in (intrinsic in COBOL speak) functions. Most COBOL programmers properly still do not use user-defined functions. So from their perspective, it is perfectly reasonable to see functions as part of the language. My point is, that it is properly true that most COBOL programmers sees functions as part of the language. But you cannot generalize from COBOL programmers to programmers in say Java, in this particular case. I'll stop whining now. Greetings, Mads Lindstrøm [1] http://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Fri, Apr 2, 2010 at 12:53 PM, Dominic Espinosa dces...@fastmail.fm wrote: Is there a general strategy for deploying Haskell apps, graphical or no, to MacOS X and/or Windows? I'm especially interested in cases where the application uses some heavyweight libraries like OpenGL. I have a GUI app that I deploy on Mac and Linux that uses OpenGL and wxHaskell. It has been a pretty good experience, but getting wx set up on every development machine is hairier than cabal install. The good news is that it was easy to set up a pure GLUT front end as well as a wx one that both use the same OpenGL code for rendering graphically intensive bits. I just have two build targets to switch between the two. For general cross-platform GUI apps that I need in a pinch, I turn to PLT Scheme. They have a really excellent system in this regard. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
On Thu, Apr 1, 2010 at 5:27 AM, Jens Blanck jens.bla...@gmail.com wrote: I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell. Also, if you are aware of similar discussions in other languages. I'd like to use this information to make an analogous case for defaulting real numerical literals (well, the literals are likely to be in scientific notation, i.e., floating point) to some data type of computable reals rather than to floating point Double. Integer (and Rational) have decidable equality testing. I don't think the same can be said for computable reals. (Does pi == pi? How about 2 * asin 1?) -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
Stephen Tetley stephen.tet...@gmail.com disse: On 2 April 2010 17:53, Dominic Espinosa dces...@fastmail.fm wrote: [SNIP] I ended up rewriting it in another language (due to time pressure) and I'm a little wary of attempting to use Haskell again for developing such an application. Hi Dominic Out of curiosity what language did you choose instead? Each time a thread comes up on the Cafe documenting GUI woes, I always wonder if Python or other languages[*] have such problems and if not why not. For better or worse python interpreter comes with Tk. So, if you develop your application to use Tk, as ugly as it may look, it will work in every platform supported by the python interpreter. However, if you want to use pygtk, you still have to install gtk runtime. When using haskell, can't you just make a static binary on MacOS and Windows, though? Why wouldn't that work? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Seeking advice about monadic traversal functions
Darryn Reid wrote: Heinrich, Thanks for your excellent response! Indeed, it was the rebuilding of the tree that had me stumped. I also see the benefits of using the lift functions, thanks again for this insight. My pleasure. :) By the way, there's also another, very flexible way to rebuild the tree: give each node a unique identifier. The traversal returns a list of labeled nodes with their children replaced by labels, like this: [(1,Nil),(2,Single 'a' 3),(3,Nil),(4,Fork 1 2),...] To rebuild the tree, simply put the list into a finite map and replace identifiers by proper trees again. However, this solution is essentially the same as using a mutable tree, the unique identifiers represent memory addresses. That's why I sought to reconstruct the tree from the structure of the traversal (using the same intermediate queue data structure, etc.). Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Seeking advice about monadic traversal functions
On 3/31/10 12:44, Heinrich Apfelmus wrote: go Next (Single x t1) = liftM (Single x) (rewrite f t1) go Next (Fork t1 t2 ) = liftM2 Fork (rewrite f t1) (rewrite f t2) In particular, liftM and liftM2 make it apparent that we're just wrapping the result in a constructor. A small remark: I prefer using applicative notation for this: go Next (Single x t1) = Single x $ rewrite f t1 go Next (Fork t1 t2 ) = Fork $ rewrite f t1 * rewrite f t2 Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP, arrows and loops
On Fri, 2 Apr 2010, Maciej Piechotka wrote: 1. How to interpret ArrowLoop? I have two possible implementations: type RunSF a = a Dynamic () data SF a b c = SF (a (Dynamic, b, RunSF, Set Unique) (c, Set Unique, SF a b c)) (...) instance ArrowLoop (SF a) where loop (SF f) = loop' f undefined where loop' g d = proc (dyn, b, r, s) - do ((c, d'), s, g') - g - (dyn, (b, d), r, s) returnA - (c, s, loop' g' d') instance ArrowLoop a = ArrowLoop (SF a) where loop (SF f) = SF $! proc (d, b, r, s) - do rec ((c, d), s, f') - f - (d, (b, d), r, s) returnA - (c, s, loop f') Neither of these compile through my eyeball, but I don't think it should be possible for SF to be an Arrow-anything unless 'a' is also. 2. Why there is no ArrowIO in arrows? I.e. class Arrow a = ArrowIO a where liftAIO :: Kleisli IO b c - a b c (possibly class Arrow a = ArrowST a where liftAST :: Kleisli ST b c - a b c ) It would only be a convenience typeclass, and in that case why not just have a generic ArrowKleisli with: (i - m o) - a i o 3. Why switch is needed? How to interpret switch with current continuation? I think switch is equivalent to ArrowChoice but do I miss something? They are not equivalent. A switch, roughly, provides a way to persistently replace a running segment of a program with a different program. ArrowChoice is just a way of implementing if-then-else flow control in an Arrow, which might be useful, but is not the point of FRP. Imagine a light switch that remains on or off after you toggle it, compared to a pressure switch that requires constant supervision. Friendly, --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
Jens Blanck schrieb: I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell. Also, if you are aware of similar discussions in other languages. I think type defaulting is only an issue for GHCi because in compiled code you should not let the compiler and reader of your code guess the type. GHC -Wall warns about uses of default types. I'd like to use this information to make an analogous case for defaulting real numerical literals (well, the literals are likely to be in scientific notation, i.e., floating point) to some data type of computable reals rather than to floating point Double. You might be interested in http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics#Real_and_rational_numbers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Immix GC as a Soc proposal
On 01/04/10 22:19, Thomas Schilling wrote: In my opinion the project would be worthwhile even if it's not in the Top 8. Mentors vote on the accepted projects based both on the priority of the project and the applying student, so it's probably not a bad idea to apply for other projects as well so you don't put all your stakes on just a single horse. Looking at your current proposal, however, I think that your timeline is, well, impossible. You seem to suggest to build a new allocator and garbage collector from scratch. GHC's allocator is already quite similar to Immix, so you don't really have to re-implement much. The main differences (OTTOH) are the different region sizes, the marking accuracy (Immix marks 128 byte blocks, GHC is word-accurate), and eager compaction. Immix actually marks twice: once for the object, and once for the line. I propose that in GHC we just mark once in our bitmap. Then the sweep phase looks for empty lines (we can experiment with different sizes), and constructs a free list from them. We have to choose a representation for the free list, and the allocator in the GC will have to be taught how to allocate from the free list. This is all pretty straighforward. The tricky bit is how to deal with objects that are larger than a line: we'll have to use a different allocator for them, and we'll need to identify them quickly, perhaps with a different object type. The other part is opportunistic defragmentation, which is a doddle in GHC. We just identify blocks (in GHC's terminology) that are too fragmented, and flag them with the BF_COPY bit before GC, and any live objects in that block will be copied rather than marked. The existing mark/sweep collector in GHC already does this. We could experiment with different policies for deciding which blocks to defrag - one idea is just to defrag the oldest 10% of blocks during each GC, so you get to them all eventually. So I think this is all quite doable for a keen SoC student. Marco: I suggest reworking your timeline based on the above. The mutator's allocator doesn't need to change, but the GC's allocator will. In case it isn't clear, I propose we keep the existing generational framework and use Immix only for the old generation. Therefore I'd suggest to move in small steps: Change some parameters (e.g., region size), fix the resulting bugs and benchmark each change. Then, maybe, implement eager compaction on top of the existing system. I believe this will keep you busy enough. If in the end GC is 5% faster that would be a very good outcome! I also don't know how much complexity the parallel GC and other synchronisation stuff will introduce. Maybe Simon (CC'd) can comment on that. To do this in parallel you'd need to change the bitmap to be a byte map, and then it's pretty straightforward I think. Objects are at least 2 words, so the byte-map overhead is 12.5% on a 32-bit machine or 6.25% on a 64-bit machine. There might be contention for the free list, so we might have to divise a scheme to avoid that. Cheers, Simon / Thomas On 1 April 2010 22:00, Marco Túlio Gontijo e Silvamar...@debian.org wrote: Hi. I've written a Google Summer of Code proposal for implementing the Immix Garbage Collector in GHC[0]. It's not on dons list of the 8 most important projects[1], but I only saw that list after the proposal is done. I'd like to hear comments about it, specially about its relevance, since it's not on the list of 8. 0: http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?do=showid=marco_soc 1: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ I'm planning to write another proposal, maybe about LLVM Performance Study, LLVM Cross Compiler, A Package Versioning Policy Checker or “cabal test”, if mentors think they're more relevant than my current proposal. Please let me know if this is the case. Greetings. -- marcot http://wiki.debian.org/MarcoSilva ___ 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] Re: Haskellers hate GUIs!!
On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On 2 April 2010 20:15, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. But that's the variant using X11, no? There now is a Gtk+ framework, which worked well but was missing some common extensions last time I checked (e.g., sourceview). Unfortunately, the website hosting it has been down for a while now (http://www.gtk-osx.org) and I don't know whether it's available somewhere else. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Apr 2, 2010, at 15:21 , Thomas Schilling wrote: On 2 April 2010 20:15, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. But that's the variant using X11, no? There now is a Gtk+ framework, port variants gtk2hs reports a +no_x11 option, which for Gtk+ stuff in MacPorts means it uses one of the native Gtk+ frameworks (there were two last I checked, one not being developed any more). Both of them are missing various things, sadly. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Fri, Apr 2, 2010 at 10:31 AM, Anthony Cowley acow...@seas.upenn.eduwrote: On Fri, Apr 2, 2010 at 12:53 PM, Dominic Espinosa dces...@fastmail.fm wrote: Is there a general strategy for deploying Haskell apps, graphical or no, to MacOS X and/or Windows? I'm especially interested in cases where the application uses some heavyweight libraries like OpenGL. I have a GUI app that I deploy on Mac and Linux that uses OpenGL and wxHaskell. It has been a pretty good experience, but getting wx set up on every development machine is hairier than cabal install. The good news is that it was easy to set up a pure GLUT front end as well as a wx one that both use the same OpenGL code for rendering graphically intensive bits. I just have two build targets to switch between the two. For general cross-platform GUI apps that I need in a pinch, I turn to PLT Scheme. They have a really excellent system in this regard. Yeah PLT is pretty awesome... But I think they're calling it Racket now. :-) http://www.plt-racket.org/new-name.html Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Apr 2, 2010, at 15:21 , Thomas Schilling wrote: On 2 April 2010 20:15, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. But that's the variant using X11, no? There now is a Gtk+ framework, BTW, native Cocoa support is now part of the standard Gtk+ distribution. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On 2 Apr 2010, at 21:01, Brandon S. Allbery KF8NH wrote: On Apr 2, 2010, at 15:21 , Thomas Schilling wrote: On 2 April 2010 20:15, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. But that's the variant using X11, no? There now is a Gtk+ framework, BTW, native Cocoa support is now part of the standard Gtk+ distribution. Unfortunately, it still doesn't behave anything like a Cocoa application.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: tbox-0.1.0: Transactional variables and data structures with IO hooks
This package [1] provides STM data structures with IO hooks. The basic building blocks are instances of class TBox. Such an instance is an STM variable that might contain a value of some type a. In contrast to a plain 'TVar (Maybe a)', a TBox has IO hooks that are executed transparently on writes and reads. The IO hooks of the AdvSTM monad extend the atomicity of STM transactions to the on-commit IO actions, which makes it particularly suitable for implementing a persistent and thread-safe storage. Currently the only instance of class TBox is type TFile. A TFile serializes its content to a file using Data.Binary. New in this release is the implementation of a skip list in module Control.Concurrent.TBox.TSkipList that provides thread-safe persistency. A skip list is a probabilistic data structure that provides expected run time of O(log n) for dictionary operations (insert, lookup, filter, leq, min, delete, update) similar to a balanced tree. The main advantage of a skip list is that it does not need rebalancing, which could lead to high contention among transactions. The TFile-skip list instance tries to reconstruct the content of its elements from the TFile-directory. See module Control.Concurrent.TFile.TSkipList for a usage example. Feedback is highly appreciated! [1] http://hackage.haskell.org/package/tbox ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Fri, Apr 02, 2010 at 06:11:52PM +0100, Stephen Tetley wrote: On 2 April 2010 17:53, Dominic Espinosa dces...@fastmail.fm wrote: [SNIP] I ended up rewriting it in another language (due to time pressure) and I'm a little wary of attempting to use Haskell again for developing such an application. Out of curiosity what language did you choose instead? Some algol-like language purporting to have cross-platform GUI support, widely used by others in our department. I think the name started with J. I did not enjoy the rewrite. The Haskell code was a lot nicer (and shorter). However, the application had to be deployed to arbitrary MacBook users, and the process of installing the Haskell infrastructure plus MacPorts plus the MacPort of gtk2hs (which had a lot of dependencies, if I remember correctly) seemed too arduous to expect all Mac-based users of my application to go through, especially when battling the what is this 'Haskell' business? why didn't you use blub, like a normal person? sentiment. Is there an easier way? The process of using cabal-install on Linux is similar, but the 'distribution culture' there is a lot different. I fully expect to install packages and their dependencies with a package manager, or at least download and compile a tarball, and tend to be suspicious of binary-only releases. But they are the norm on those two other platforms. It would be nice if there were a quick way of generating such packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Software correctness in the auto industry and FPLs
Sorry for no Subject on the first post. In any case, I meant this Wall Street Journal as a challenge to the Haskell community to perhaps step up to the plate in the auto arena vis-a-vis software correctness. I realize that with hard real-time problems and a garbage collector that that could be a problem. In any case , enjoy. Vasili On Fri, Apr 2, 2010 at 5:55 AM, Vasili I. Galchin vigalc...@gmail.com wrote: * * * * * * * More o BigCharts o Virtual Stock Exchange o FiLife.com o WSJ Asia o WSJ Europe o WSJ Portuguese o WSJ Spanish o WSJ Chinese o WSJ Japanese o WSJ Radio o Financial News SEARCH * Wednesday, March 31, 2010 Autos o Welcome, William Halchin Logout o + My Account + My Journal + Help + Message Center ( new) * U.S. Edition WSJ.com is available in the following editions and languages: o U.S. o Asia + India + China + Japan o Europe o Americas + en Español + em Português o Login/Register to set your edition o Set my edition o Today's Paper o Video o Columns o Blogs o Topics o Journal Community Register for FREE Register for FREE Thank you for registering. We sent an email to: Please click on the link inside the email to complete your registration Please register to gain free access to WSJ tools. An account already exists for the email address entered. Forgot your username or password? This service is temporary unavailable due to system maintenance. Please try again later. The username entered is already associated with another account. Please enter a different username The email address you have entered is already in use. Please re-enter the email address. o First Name o Last Name o Email (your email address will be your login) o Confirm Email o Create a Password o Confirm Password o Company Size (Optional) From time to time, we will send you e-mail announcements on new features and special offers from The Wall Street Journal Online. Create a profile for me in the Journal Community Why Register? Privacy Policy | Terms Conditions As a registered user of The Wall Street Journal Online, you will be able to: o Setup and manage your portfolio o Personalize your own news page o Receive and manage newsletters Log In Log In Login Password Log in Your login is either a username or an email address. Keep me logged in. Forgot your password? close window Close * Home * World * U.S. * Business * Markets * Tech * Personal Finance * Life Style * Opinion * Careers * Real Estate * Small Business * Asia * Europe * Earnings * Economy * Health * Law * Autos * Management * Media Marketing * expand More Industries up down o Accounting o Advertising o Airlines o Banking o Chemicals o Computer Hardware o Computer Software o Consumer Products o Defense Aerospace o Energy o Broadcasting Entertainment o Financial Services Insurance o Food Tobacco o Hospitality o Industrial Goods Services o Marketing Strategy o Media Agencies o Metals Mining o Paper Forest Products o Pharmaceutical Biotech o Real Estate o Retail o Semiconductors o Transportation o Utilities * Columns Blogs * * Dow Jones Reprints: This copy is for your personal, non-commercial use only. To order presentation-ready copies for distribution to your colleagues, clients or customers, use the Order Reprints tool at the bottom of any article or visit www.djreprints.com See a sample reprint in PDF format. Order a reprint of this article now * The Wall Street Journal * MARCH 31, 2010 Now, Even NASA Is Involved in Toyota Crisis * Article * Comments (2) more in Auto Industry News » * Email * Print * Save This ↓ More * o facebook facebook o Twitter Twitter o Digg Digg o StumbleUpon
Re: [Haskell-cafe] libraries [was GUI haters]
This is a great idea! IMO this is also one of the main ways that GUI-based apps are likely to evolve into in the future. Cross-platform GUIs are a pain in the butt in _any_ language (possibly excluding full language platforms like Java/.NET, and I'll bet even those were a nightmare for the original implementors). Mike aditya siram wrote: Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice. Basically the you start a Haskell service on port some-large-number and make AJAX calls to it from your web browser using a CGI script as a go-between. In my case all data flows back and forth as JSON objects. You could just as easily use XML. For the front-end I used Qooxdoo [1] , an absolutely gorgeous well-documented Javascript GUI framework but there are plenty to choose from. This has a couple of advantages, it encourages MVC by letting the front-end take care of UI and the back-end does the logic and holds state. It's easy to deploy- Javascript runs everywhere and so does Haskell (the non-GUI parts anyway!). And it looks uniform across platforms. The disadvantages include security (but you can always restrict users to localhost), and performance (you probably don't want to visualize gigabyte size datasets in your browser). Additionally you now need to add and configure an extra piece of software, namely the web-server. Also you now have to learn Javascript and add that to the list of things the maintenance programmer has to worry about. But if you can learn Haskell, Javascript shouldn't be an issue. I've found that none of these disadvantages are really show-stoppers. hth, deech [1] http://qooxdoo.org/ On 4/2/10, gladst...@gladstein.com gladst...@gladstein.com wrote: As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper. One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because Java gives you everything you want, for free. That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had thousands of commands. I'll stop whining now. ___ 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] libraries [was GUI haters]
On Fri, Apr 2, 2010 at 10:22 AM, Mads Lindstrøm mads_lindstr...@yahoo.dk wrote: Looking at Wikipedia I can see that COBOL 2002[1] got user defined functions, but prior it was impossible to define your own functions. You could define sub-rutines (semantically similar to jsr/gosub in assembler/basic), but not functions that could be used like the build-in (intrinsic in COBOL speak) functions. Most COBOL programmers properly still do not use user-defined functions. So from their perspective, it is perfectly reasonable to see functions as part of the language. Talking to old COBOL programmers who think their language is relevant because current revisions have some modern features is very depressing. The desperate look in their eyes cuts like a knife. The best you can do is condescendingly tell them what they want to hear the way you would to a small child. Warren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
This may not be helpful for you, but when I did GUI stuff with haskell I wrote the GUI part in c++ with fltk, exposed a medium-level api specific to that gui, and then call that api through the FFI. This is sort of like the web browser + backend thing, except switch c++ and fltk for javascript and the browser, and you are making synchronous FFI function calls instead of sending asynchronous JSON messages. It has worked well for me so far, but my GUIs are all simple with well defined interaction with the backend (i.e. backend says add these 15 items and GUI says user selected this item). If you have complicated interaction between backend and GUI you may get tired implementing a large API and lots of marshal/unmarshal. Of course you could still pass data via JSON or protobufs or something, and there are various tools to automate wrapping large numbers of C calls. In terms of distribution, you get a single binary and fltk is designed for static linking. You can run on X, mac, and windows, though it doesn't look like a native app on any. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Software correctness in the auto industry and FPLs
On Fri, Apr 2, 2010 at 2:28 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Sorry for no Subject on the first post. In any case, I meant this Wall Street Journal as a challenge to the Haskell community to perhaps step up to the plate in the auto arena vis-a-vis software correctness. I realize that with hard real-time problems and a garbage collector that that could be a problem. In any case , enjoy. Our group at Eaton uses Haskell to program vehicle computers that control hybrid powertrains for heavy duty trucks -- garbage to be specific. Our systems interface with engines, transmissions, brake controllers, and yes, accelerator pedals. (It's a good thing garbage trucks don't have floor mats.) Haskell and Atom help us maintain correctness in several ways. For one, Haskell GADTs ensure type correctness of the generated C code. I find it interesting that a type system in one language can prevent type problems in another. Another benefit is the type system distinguishes between stateful and stateless operations. This helps manage how state is modified in an embedded control program, which by its nature tend to be a complex state machine. For example: doSomething :: E Bool - E Bool - E Bool -- Guaranteed not to change state. versus in C: bool doSomething(bool, bool); // No guarantees what this thing does under the hood. One thing specific to Atom is it makes it very easy to create multi-rate programs without having to partition a lot of code and hook it up to an RTOS task scheduler, or worse, having to schedule it by hand. Often I find myself deep in the design of a feature and realized I need to perform a task at a faster or slower rate than the surrounding code. If it were C, I would have to plumb out all the communicating variables, create a handful of mutex locks, and bind it to a task scheduler. In Atom, I simply specify a different execution period: period 20 $ atom someTask $ do ... But I think the biggest gain is Atom's guarded atomic actions. There is something about writing a block of code and knowing it will execute atomically without anything else getting in the way. I find it difficult to explain the benefits of this type of embedded programming paradigm -- it usually only comes with practice. In fact, I didn't fully appreciate Atom until I started using it on a large production design -- and I'm the one who wrote the library. Of course, nothing is perfect. It is still possible to write buggy programs with Haskell+Atom. But as Simon PJ stated in a presentation, the bugs you can write are far more interesting. Of course, our definition of interesting is when hardware grinds together and metal chunks fly through the air. -Tom By BEN WORTHEN U.S. regulators on Tuesday announced a broad investigation into automotive computer systems and software, which have come under scrutiny because of sudden acceleration and other reports involving some Toyota Motor Corp. cars. An examination of Toyota's problems will be conducted by experts from the National Aeronautics and Space Administration, while the National Academy of Sciences, which advises the government, will undertake a separate, 15-month study into the use of computer technology in cars, U.S. Transportation Secretary Ray LaHood said. Toyota has said there is no evidence that software or electronic systems are responsible for sudden acceleration in its cars. The company repeatedly and rigorously tests its software and has subjected it to outside review, a spokesman said. Electronics have led to some of the biggest safety breakthroughs in vehicles, such as antilock brakes and stability control. Software controls an ever-growing variety of functions in cars, including braking and accelerating. Increasingly, cars include software that links these systems to do things like parallel park the vehicle or remember the seat positions, temperatures and radio stations preferred by different drivers. Ninety percent of all innovation in cars today is driven by software, said Ingolf Krueger, an associate professor of computer science and engineering at the University of California in San Diego. No surprise then that software is sometimes to blame when things go wrong. While Toyota has received most of the attention, other car makers have had software-related incidents. Ford Motor Co.'s 2010 Fusion Hybrid has a high-tech braking system that also recharges its battery through a process called regenerative braking. Software monitors sensors in the car and determines when to engage the conventional braking system instead. Several drivers filed complaints with the National Highway Traffic Safety Administration, the agency responsible for vehicle safety, stating that they depressed the brake pedal as far as possible but the brakes didn't engage. A Ford spokesman said a sensor on the car was set too sensitively and that software interpreted the signal to mean it should skip the
[Haskell-cafe] Metaprogramming in Haskell vs. Ocaml
Hi all, I would like to learn a little bit more about metaprogramming in Haskell. And I'm also wondering why metaprogramming is used much more in Ocaml than in Haskell. Camlp4 (Ocaml's metaprogramming facility) doesn't seem to much more powerful that Template Haskell. The former is celebrated in its community as a killer feature of the language and its use is encouraged by numerous accessible tutorials. The latter however is down-played and not as well documented. Seeing that the languages are parallel in many ways is there some reason for this? Is metaprogramming less useful in Haskell? Is it worth learning? thanks ... -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Metaprogramming in Haskell vs. Ocaml
aditya.siram: Hi all, I would like to learn a little bit more about metaprogramming in Haskell. And I'm also wondering why metaprogramming is used much more in Ocaml than in Haskell. Camlp4 (Ocaml's metaprogramming facility) doesn't seem to much more powerful that Template Haskell. The former is celebrated in its community as a killer feature of the language and its use is encouraged by numerous accessible tutorials. The latter however is down-played and not as well documented. Seeing that the languages are parallel in many ways is there some reason for this? Is metaprogramming less useful in Haskell? Is it worth learning? Template Haskell is actually a fairly popular extension (around 5% of Hackage packages use some TH). And the addition of quasiquotation -- which allows custom syntax -- might make it more popular. I think we don't see as much metaprogramming because of other language features -- laziness, operator syntax, and type classes -- make a bunch of common designs work without needing metaprogramming. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Seeking advice about monadic traversal functions
Martijn, Thanks for your comment and advice. Could you explain a little further your thinking? Specifically, what advantage do you find in the applicative notation, and when would you advise using it and when would you advise not using it? Thanks again, I appreciate your help. Darryn. On Fri, 2010-04-02 at 20:26 +0200, Martijn van Steenbergen wrote: On 3/31/10 12:44, Heinrich Apfelmus wrote: go Next (Single x t1) = liftM (Single x) (rewrite f t1) go Next (Fork t1 t2 ) = liftM2 Fork (rewrite f t1) (rewrite f t2) In particular, liftM and liftM2 make it apparent that we're just wrapping the result in a constructor. A small remark: I prefer using applicative notation for this: go Next (Single x t1) = Single x $ rewrite f t1 go Next (Fork t1 t2 ) = Fork $ rewrite f t1 * rewrite f t2 Martijn. ___ 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
