Re: [Haskell-cafe] The Haskell re-branding exercise
On Sat, Feb 7, 2009 at 11:18 AM, Paul Johnson p...@cogito.org.uk wrote: Paul Johnson wrote: A call has gone out http://www.haskell.org/pipermail/haskell-cafe/2008-December/051836.html for a new logo for Haskell. Candidates (including a couple http://www.haskell.org/haskellwiki/Image:Haskell-logo-revolution.png of mine http://www.haskell.org/sitewiki/images/f/fd/Ouroborous-oval.png) are accumulating here http://www.haskell.org/haskellwiki/Haskell_logos/New_logo_ideas. There has also been a long thread on the Haskell Cafe mailing list. So what's happening about this? I know I'm late to the party, but here's an observation anyway. It might be better to settle on an emblem first, and then a logo. Lambda is popular for functional languages, but it's not a distinctive feature of Haskell. What is distinctive of Haskell is category theory in general and the monad in particular. Both of which are strongly reminiscent of Alchemy. Believe it or not, it's possible to see the operations of the monad as the exact analog of certain aspects of Alchemy (I'm working on a detailed exposition.) Monad as Philosopher's Stone? Galleries of Alchemical emblems and symbols are easily found on the web; see for example the symbol for composition at http://www.iridius.info/current/info/ -gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
Am Mittwoch, 11. Februar 2009 23:02 schrieb Corey O'Connor: The way I read changes in version numbers for a scheme using the format X.Y.Z is: * A change in Z indicates bug fixes only * A change in Y indicates the interface has changed but not in an incompatible way. For instance, maybe a new method was added. * A change in X indicates the interface has changed in a way that could be incompatible with software that depended on a previous version of the library. Note that Haskell’s package versioning policy [1] assigns your meaning of Z to the 4th component of the version, your meaning of Y to the 3rd and your meaning of X to the pair of the 1st and the 2nd component. Best wishes, Wolfgang [1] http://haskell.org/haskellwiki/Package_versioning_policy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing a generic event handler
John Ky newho...@gmail.com wrote:
My question is: Is it possible to write a generic doLoop that works
over arbitrary functions?
Yes and no, that is, you can overcome the no.
The following code typechecks, and would run nicely if there was a
fixed version of reactive, by now[1]. Event handlers can take one
arbitrary argument and return anything (as long as it's the same as
other handlers), and may be curried before registration, of course. As
you can stuff anything you please into one argument, I doubt you'll hit
a wall there. Note the usage of Maybe to dispatch, you should be able
to do something similar with a plain Maybe monad, without all that
Event stuff. Either might also be a good idea.
[1] It would also feature splices that can be spliced further and other
things quite similar to pattern-matching. TBH, I got tired of not
running the code and intimidated by fixpoints of Event streams.
module Main where
-- current darcs XHB
-- hack it to export Graphics.XHB.Connection.Types
-- get rid of the Show constraint in Reactive's filterE (or was it
justE?)
import Graphics.XHB as X
import FRP.Reactive as R
import FRP.Reactive.LegacyAdapters
import Control.Concurrent
import Control.Monad
import Control.Applicative
import Data.Maybe
import Data.Monoid
createSimpleWindow :: Connection - Int - Int - Int - Int - IO
WINDOW createSimpleWindow c x y w h =
let s = getScreen c
black = black_pixel_SCREEN s
root = root_SCREEN s
depth = root_depth_SCREEN s
visual = root_visual_SCREEN s
in do
id - newResource c
createWindow c (MkCreateWindow
depth id root
(fromIntegral x) (fromIntegral y)
(fromIntegral w) (fromIntegral h)
0 0 visual
(toValueParam
[(CWBackPixel,black)
,(CWEventMask,toMask
[ EventMaskExposure
, EventMaskKeyPress
--, EventMaskFocusChange
])]))
return id
createSimpleGC :: Connection - IO GCONTEXT
createSimpleGC c =
let s = getScreen c
root = root_SCREEN s
white = white_pixel_SCREEN s
in do
g - newResource c
createGC c (MkCreateGC
g
(castXid root)
(toValueParam
[(GCForeground,white)
,(GCGraphicsExposures,0)
]))
return g
printErrors c = (forkIO . forever) $ waitForError c = print
getScreen = head . roots_Setup . conf_setup . conn_conf
castXid = fromXid . toXid
main = do
(Just c) - connect
printErrors c
print $ displayInfo c
gc - createSimpleGC c
w - createSimpleWindow c 0 0 640 480
lock - newEmptyMVar
let quit = putMVar lock ()
mapWindow c w
sync - makeSync
evs - eventsX sync c
forkIO $ adaptE $ braidE
(const $ putStrLn Unhandled Event)
[ xEventSplice expose
, xEventSplice (keyPress quit)
] evs
readMVar lock
type Splice a b = (R.Event a, R.Event b) - (R.Event a, R.Event b)
xEventSplice :: X.Event c = (c - b) - Splice SomeEvent b
xEventSplice = mkSplice fromEvent
mkSplice :: (a - Maybe c) - (c - b) - Splice a b
mkSplice f g (a,b) = ( filterE (isNothing . f) a
, (fmap g . justE . fmap f) a `mappend` b )
braidE :: (a - b) - [Splice a b] - R.Event a - R.Event b
braidE f ss i = b `mappend` fmap f a
where (a, b) = (foldr (.) id ss) (i, mzero)
expose :: Expose - Action
expose = const $ putStrLn expose
keyPress :: Action - KeyPress - Action
keyPress quit = const $ putStrLn keyPress quit
type Sync = Clock TimeT
makeSync = makeClock
eventsX cl c = do
(sink, res) - makeEvent cl
(forkIO . forever) $
{-putStrLn tick -} waitForEvent c = sink
return res
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/ . Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don't want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
g9ks157k: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to encorporate ... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell.org GSoC
Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? The fact that you can mark a revision to be the official one and, in case you e.g. have a wiki yourself, disable the hackage wiki? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for pointfree version
On Thu, Feb 12, 2009 at 6:46 PM, Kim-Ee Yeoh a.biurvo...@asuhan.com wrote: On the same note, does anyone have ideas for the following snippet? Tried the pointfree package but the output was useless. pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) $ pointfree '(\op (a, b) (c, d) - (a `op` c, b `op` d))' (`ap` snd) . (. fst) . flip flip snd . ((flip . (ap .)) .) . flip flip fst . ((flip . ((.) .)) .) . (flip = (((.) . flip . (((.) . (,)) .)) .)) 'Useless' is a bit understated , IMO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2HS 0.10.0 Released
Duncan Coutts wrote: On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: Does this version work from ghci? -- Lennart Specifically I believe Lennart is asking about Windows. It's worked in ghci in Linux for ages and it worked in ghci in Windows prior to the 0.9.13 release. In the 0.9.13 release on Windows there was something funky with linking (possibly due to using a newer mingw) and ghci's linker could not understand was was going on and could not load the packages. I'm having trouble http://hackage.haskell.org/trac/ghc/ticket/2615 (cairo depends on pthread, which has a linker script) Is there an easy workaround? Maybe that ticket can be considered in Plans for GHC 6.10.2 Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
2009/2/12 Matthew Elder m...@mattelder.org: would love to see this. basic features first i suppose. here are some of my ideas: meld-like diff view would be great too. http://meld.sourceforge.net/ -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: space leak with 'concat' ?
Peter Verswyvelen wrote: Yes, I was really surprised that this was the case. I while ago I did a little FRP experiment. I made a top level binding to a list of timer event occurrences. The list was generated on another thread. To my surprise, I did not have space leak, which is amazingly cool, but it felt odd :) Is it documented when GHC will garbage collect CAFs? CAFs are garbage collected when they are unreachable by traversing the code that is reachable from the currently running program. In practice we don't actually traverse the code, instead we have these static reference tables that list the top-level closures referenced by each code block, and traverse those instead. Unfortunately we didn't get around to documenting the details of how this works... Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Take a break: write an essay for Onward! Essays
Friends Writing papers is fun, we mostly only get to write one *kind* of paper. Here is an opportunity to write something in a totally different style: Submit an essay to Onward! Essays Deadline: 20 April 2009 http://onward-conference.org/calls/foressays An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma. A successful essay is a clear and compelling piece of writing that explores a topic important to the software community. The subject area should be interpreted broadly, including the relationship of software to human endeavours, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of its topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic. I'm the program chair, and I'd love to get submissions from the POPL/ICFP/types community. Reflections on programming languages, types, testing, verification, software engineering, compilers, society, ... you name it. Anything to do with software. NB: Onward! is co-located with OOPSLA, but they are otherwise unrelated. OO is fine, but not required. Don't forget: 20th April. Simon PS: To get your imagination going, here are a couple of (strongly-contrasting) past essays: * Dan Grossman The transactional memory / garbage collection analogy http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf * Dick Gabriel Designed as designer http://dreamsongs.org/DesignedAsDesigner.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell.org GSoC
Wolfgang Jeltsch wrote: Don Stewart wrote: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? Well, it's excellent if you haven't written said documentation yet. ;) But yes, the package author should have the last word about what goes in and what does not. The goal is simply to drastically lower the bar of participation. Regards, 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: space leak with 'concat' ?
On Thu, Feb 12, 2009 at 10:36 AM, Simon Marlow marlo...@gmail.com wrote: Peter Verswyvelen wrote: Yes, I was really surprised that this was the case. I while ago I did a little FRP experiment. I made a top level binding to a list of timer event occurrences. The list was generated on another thread. To my surprise, I did not have space leak, which is amazingly cool, but it felt odd :) Is it documented when GHC will garbage collect CAFs? CAFs are garbage collected when they are unreachable by traversing the code that is reachable from the currently running program. In practice we don't actually traverse the code, instead we have these static reference tables that list the top-level closures referenced by each code block, and traverse those instead. Unfortunately we didn't get around to documenting the details of how this works... Using this as a guide, I tested these two programs: str = concat $ repeat foo main1 = print foo main2 = print foo print foo = As I'm sure you realize, the first ran in constant memory; the second, not so much. Very interesting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org GSoC
On Thu, Feb 12, 2009 at 2:42 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Wolfgang Jeltsch wrote: Don Stewart wrote: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? Well, it's excellent if you haven't written said documentation yet. ;) But yes, the package author should have the last word about what goes in and what does not. The goal is simply to drastically lower the bar of participation. Something like AnnoCPAN would be a good middle-ground here; i.e. differentiate between official package documentation and user annotations, but make them both visible. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell.org GSoC
From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Don Stewart You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to incorporate ... Yes. PostgreSQL online docs have a similar feature, although their implementation isn't perhaps as nice as RWH's (I like RWH's inline comments feature). See e.g. http://www.postgresql.org/docs/8.3/interactive/tutorial-createdb.html http://www.postgresql.org/docs/8.3/interactive/functions-string.html http://www.postgresql.org/docs/8.3/interactive/indexes-multicolumn.html http://www.postgresql.org/docs/8.3/interactive/textsearch-tables.html Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell.org GSoC
Don Stewart wrote: No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to encorporate ... By the way, the PHP documentation has such a comment feature, see for example http://www.php.net/manual/en/function.preg-match.php But I'm not sure whether this form of commenting is the best way to write/improve documentation. (The many proposed regular expressions for validating e-mail addresses sure have a certain hilarity to them...) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for pointfree version
Benja Fallenstein wrote: Kim-Ee Yeoh wrote: On the same note, does anyone have ideas for the following snippet? Tried the pointfree package but the output was useless. pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) import Control.Monad.Reader -- for the (Monad (a -)) instance import Control.Bifunctor -- package category-extras dup = join (,) mapPair = uncurry bimap pointfree = (mapPair .) . mapPair . dup Or if you're not afraid of *some* points, and want to avoid the imports: dup x = (x,x) mapPair (f,g) (x,y) = (f x, g y) pointfree op = mapPair . mapPair (dup op) That what you're looking for? :-) The pairs are of course an applicative functor (*) = uncurry (***) -- from Control.Arrow pure x = (x,x) pointwise op x y = pure op * x * y Regards, 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: space leak with 'concat' ?
On Thu, Feb 12, 2009 at 10:48 AM, Svein Ove Aas svein@aas.no wrote: Using this as a guide, I tested these two programs: str = concat $ repeat foo main1 = print foo main2 = print foo print foo = As I'm sure you realize, the first ran in constant memory; the second, not so much. Very interesting. That seems logical to me. The first one prints the str once, and str is never needed anymore. The second one prints str, and after it is printed, it prints it again, so the full str is needed again. So the life data analyzer is not clever enough to realize that the second print will never occur. Solving the latter might require solving the halting problem? I don't know It is funny that recently I had a strange problem in C# (I tried to write parts of Reactive in C#) where the garbage collector freed data that was actually needed by my program! I had to fix that by putting a local variable on the stack, passing the constructed data to a function did not work. I think .NET and Java the garbage collector traverses from data (the stack, globals, etc). If I understood Simon correctly, GHC traverse the code blocks instead, which feels correct as it would have fixed the bug I had in C#. So yet again an extreme difference between Haskell and .NET/Java even when it comes to garbage collection, Haskell wins :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 09:20 schrieb Achim Schneider: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? The fact that you can mark a revision to be the official one and, in case you e.g. have a wiki yourself, disable the hackage wiki? What do you mean by “disabling the Hackage wiki”? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can this be done?
On Wed, Feb 11, 2009 at 6:41 PM, Achim Schneider bars...@web.de wrote: ... I got curious and made two pages point to each other, resulting in as many stale continuations as your left mouse button would permit. While the model certainly is cool, I'm not aware of any implementation that even comes close to having production-safe (that is, non-abusable) semantics. Stale continuations are an issue (think of anonymous accesses), even if my personal feeling is that it may be mitigated using continuations wisely (i.e. only when they're actually relevant). Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: space leak with 'concat' ?
2009/2/12 Peter Verswyvelen bugf...@gmail.com: It is funny that recently I had a strange problem in C# (I tried to write parts of Reactive in C#) where the garbage collector freed data that was actually needed by my program! I had to fix that by putting a local variable on the stack, passing the constructed data to a function did not work. I think .NET and Java the garbage collector traverses from data (the stack, globals, etc). If I understood Simon correctly, GHC traverse the code blocks instead, which feels correct as it would have fixed the bug I had in C#. So yet again an extreme difference between Haskell and .NET/Java even when it comes to garbage collection, Haskell wins :) I'm curious, a GC that removes live data is a buggy GC. What was holding the pointer to the data, if it was not the stack? Were you with MS .NET or with Mono? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell.org GSoC
Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Donnerstag, 12. Februar 2009 09:20 schrieb Achim Schneider: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? The fact that you can mark a revision to be the official one and, in case you e.g. have a wiki yourself, disable the hackage wiki? What do you mean by ___disabling the Hackage wiki___? Well, disabling the wiki function of the documentation on hackage and redirect to somewhere else, instead. The point is that it's certainly possible to have some maintainer-guaranteed integrity and the possibility of low-barrier contributions at the same time. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Looking for pointfree version
On Thu, 2009-02-12 at 11:08 +0100, Heinrich Apfelmus wrote: Benja Fallenstein wrote: Kim-Ee Yeoh wrote: On the same note, does anyone have ideas for the following snippet? Tried the pointfree package but the output was useless. pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) import Control.Monad.Reader -- for the (Monad (a -)) instance import Control.Bifunctor -- package category-extras dup = join (,) mapPair = uncurry bimap pointfree = (mapPair .) . mapPair . dup Or if you're not afraid of *some* points, and want to avoid the imports: dup x = (x,x) mapPair (f,g) (x,y) = (f x, g y) pointfree op = mapPair . mapPair (dup op) That what you're looking for? :-) The pairs are of course an applicative functor (*) = uncurry (***) -- from Control.Arrow pure x = (x,x) pointwise op x y = pure op * x * y Regards, apfelmus Concretely (this might do with a few laziness notations): import Control.Applicative data Pair a = a :*: a instance Functor Pair where f `fmap` (x :*: y) = f x :*: f y instance Applicative Pair where (f :*: g) * (x :*: y) = f x :*: f y pure x = x :*: x pointfree :: (a - b - c) - Pair a - Pair b - Pair c --pointfree o x y = pure o * x * y pointfree = ((*) .) . (*) . pure -- in the applicative paper notation: --pointfree o x y = [| o x y |] 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] Gtk2HS 0.10.0 Released
0.10.0 works on Windows for me even when using GHCi. Great work, I love it. On Thu, Feb 12, 2009 at 1:11 AM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: Does this version work from ghci? -- Lennart Specifically I believe Lennart is asking about Windows. It's worked in ghci in Linux for ages and it worked in ghci in Windows prior to the 0.9.13 release. In the 0.9.13 release on Windows there was something funky with linking (possibly due to using a newer mingw) and ghci's linker could not understand was was going on and could not load the packages. Duncan On Wed, Feb 11, 2009 at 5:40 AM, Peter Gavin pga...@gmail.com wrote: Hi everyone, Oh, dear... it seems I've forgotten how to spell cafe, and sent this message to haskell-c...@haskell.org the first time around. I resent it to all the lists again (just to make sure everyone interested receives it), so I apologize for any duplicated messages you might have received. In any case... I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff has gone into this release, including: - Support for GHC 6.10 - Bindings to GIO and GtkSourceView-2.0 - Full switch to the new model-view implementation using a Haskell model - Support for many more model-based widgets such as IconView and an updated binding for ComboBox - Full Drag-and-Drop support - Better support for Attributes in Pango - Replaced Event for EventM monad, thereby improving efficiency and convenience - Functions for interaction between Cairo and Pixbuf drawing - Lots of bug fixes, code cleanups, and portability improvements With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been deprecated. The TreeList modules have been deprecated from the Gtk+ bindings. Source and Win32 binaries are available at: https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440release_id=659598 Thanks to everyone who submitted bug fixes and features this time around! Thanks, Peter Gavin Gtk2HS Release Manager ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2HS 0.10.0 Released
On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote: Duncan Coutts wrote: On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: Does this version work from ghci? -- Lennart Specifically I believe Lennart is asking about Windows. It's worked in ghci in Linux for ages and it worked in ghci in Windows prior to the 0.9.13 release. In the 0.9.13 release on Windows there was something funky with linking (possibly due to using a newer mingw) and ghci's linker could not understand was was going on and could not load the packages. I'm having trouble http://hackage.haskell.org/trac/ghc/ticket/2615 (cairo depends on pthread, which has a linker script) Is there an easy workaround? The way it used to work was that the Gtk2Hs ./configure script just filtered out pthread on linux systems. Of course that's just a hack. Maybe that ticket can be considered in Plans for GHC 6.10.2 Maybe. Dealing with linker scripts properly is probably rather tricky and we get it for free when we switch to shared libraries. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. By the way: I think it may be worthwile to contact Google to point out the recent growth of Haskell community. I don't know on what basis they assign the slots, but it may be beneficial to do so. All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
On Wed, 2009-02-11 at 14:02 -0800, Corey O'Connor wrote: On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Tue, 2009-02-10 at 10:21 -0800, Corey O'Connor wrote: I released a new version of data-spacepart that resolved some of the issues with the previous release. One issue I had was the previous release used the version numbering scheme I use at work: [date].[release] Which does not appear to work as well as the traditional X.Y.Z release numbering scheme with Cabal. I'm not sure I understand. Is there something in Cabal or Hackage that makes date-based numbering schemes not work well? I think version number schemes of the X.Y.Z form are easier to work with when defining cabal depends constraints. A user of the library can use the constrain data-spacepart == 0.1.* to specifying a dependency on any 0.1 release. For date-based version numbers what would the constraint be? data-spacepart == 20090211.* maybe? Or constrain to a range of dates? Both seem awkward to me. Part of the reason they seem awkward to me is that I expect the difference between version numbers to indicate something about what has changed between the two versions. This only ends up being a heuristic but a useful one. Date based version numbers don't communicate much beyond, well, the date the release was built on unless annotations are added in addition to the date. Still, they don't read as nicely as X.Y.Z scheme version numbers. The way I read changes in version numbers for a scheme using the format X.Y.Z is: * A change in Z indicates bug fixes only * A change in Y indicates the interface has changed but not in an incompatible way. For instance, maybe a new method was added. * A change in X indicates the interface has changed in a way that could be incompatible with software that depended on a previous version of the library. I don't know of a mapping that can be applied to date based version numbers that is as rigorous. Right yes. Using a versioning scheme that relates to the API is a good idea for libraries. As Wolfgang mentioned, you may choose to follow the common package versioning policy. http://haskell.org/haskellwiki/Package_versioning_policy We are planning to develop tool support for this. To let packages explicitly opt-in and then we can hold such packages to their promise. We can also advise authors about what form of version constraints they should use for dependencies on packages that follow the PVP. That said, there are still areas where date-based is fine. For example the platform meta-package will be date based but also follow the PVP. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haddock Markup
On Tue, 2009-02-10 at 12:39 +0100, Henning Thielemann wrote:
Heinrich Apfelmus schrieb:
Henning Thielemann wrote:
I want for long to write math formulas in a paper in Haskell. Actually,
lhs2TeX can do such transformations but it is quite limited in handling
of parentheses and does not support more complicated transformations
(transforming prefix notation in infix notation or vice versa with
minimal parentheses).
I would like to write
sumFor [0..n] (\i - i^2)
(with sumFor xs f = sum $ map f xs)
which is rendered as
\sum_{i=0}^{n} i^2
or
integrate 1000 (a,b) (\t - f t)
to be rendered as
\int_a^b f(t) \dif t
Neat idea! Can't you do implement this as a DSL?
sumFor x xs f =
\sum_{ ++ x ++ = ++ head xs ++ }^{ ++ last xs ++ }
++ f x
My original idea was to use the formulas in papers both for typesetting
and for unit testing. Thus, when you state that a function fulfills a
law, that it can be automatically tested by QuickCheck, that this at
least true for some instances.
The same would be useful for Haddock documentation. I remember that
someone proposed to permit Haddock to expose the implementation of some
functions as examples or as unit-tests/laws. Now we could extend this
idea to allow Haddock not only to expose the implementation of
functions, but also to tell Haddock how to render its implementation.
If we want to tell haddock how to render an implementation, surely we
use a derivative of lhs2tex. It requires minimal markup in the standard
case (just spacing for alignment) and has a nice set of standard
presentation rules and allows extending that with formatting directives.
It would not let you write complex display mode maths like
\sum_{i=0}^{n} i^2
but for code, and laws and proofs that look mostly like code it's really
nice.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, 12 Feb 2009, Conrad Parker wrote: 2009/2/12 Don Stewart d...@galois.com: Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. I agree that it's beyond the scope of a SoC project. Rather than H.263 or H.264 I was going to suggest implementation of Theora or OMS, both of which avoid the patent issues and have publicly available specs: http://theora.org/doc/Theora.pdf http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf Scanning those documents should give anyone a fair idea of the amount of work involved. My understanding is that OMS is of a similar complexity to H.263, and H.264 is more complex than any of these. For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora codec is being used in Ekiga (popular SIP/H.323 video softphone but that thing keeps crashing on me :( ) Jamie Conrad. gtener: On Wed, Feb 11, 2009 at 21:00, Jamie hask...@datakids.org wrote: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [te...@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46217 2032 h263.h 91282 2361 h263_parser.c 29165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [te...@laptener libavcodec]$ grep include h263* | grep -v h263.c:#include dsputil.h h263.c:#include avcodec.h h263.c:#include mpegvideo.h h263.c:#include h263data.h h263.c:#include mpeg4data.h h263.c:#include mathops.h h263data.h:#include mpegvideo.h h263dec.c:#include avcodec.h h263dec.c:#include dsputil.h h263dec.c:#include mpegvideo.h h263dec.c:#include h263_parser.h h263dec.c:#include mpeg4video_parser.h h263dec.c:#include msmpeg4.h h263.h:#include config.h h263.h:#include msmpeg4.h h263_parser.c:#include parser.h h263_parser.h:#include parser.h Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrzętnicki ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code
Check out what GHC is doing these days, and come back with an analysis of what still needs to be improved. We can't wait to hear! can you point me to any haskell code that is as fast as it's C equivalent? You should do your own benchmarking! Please, folks! This is hardly helpful. It isn't difficult to find examples of fast Haskell code by Don, nor is it difficult to find benchmarking and analyses of slow GHC-generated code by Bulat. But expecting your readers to search for such fragments instead of providing direct references weakens your cases. In fact, I'm not aware of any documents that would make a coherent argument either way: - most of Don's examples focus on small bits of code where (a) it is still possible to associate core output with parts of the input (making the dire state of tool support less of an issue) and (b) few real-life awkwardnesses interfere with the optimization of pure algorithms (by which I mean code artifacts such as error handling etc confusing GHC's optimization phases). - most of Bulat's analyses refer to the via-C path, which used to be the fastest path, but appears to have an uncertain future (not that I'm aware of any claims, let alone documentation showing that the now standard compilation path in GHC is at least as good as via-C used to be). That summary is of course only based on the fragments I have chosen to find - if you want a fairer summary, you need to provide concrete and uptodate references!-) And if you don't want to be asked to repeat your argument every time this thread comes up, you need to present it in easily referenced form outside this mailing list. In particular, I would suggest that 1. performance issues are recorded as GHC trac tickets, with test cases, (there is an explicit ticket type for this) so that we could check easily whether any general GHC improvements have had any effect on which known bad cases. Note that performance isn't a high-priority issue per se at GHC HQ (due to manpower), unless it is a show-stopper or many users report it as important to them. Nevertheless, the issues should be recorded, so that we know where we stand. 2. performance wisdom is recorded on the Haskell/GHC wikis, or in tutorials/papers. There is a lot of information on small tricks already, but very little on what to do when those small tricks no longer suffice (eg, after one has found out that profiling lies, that core isn't easy to link back to source, when the code in question is not just pure and simple algorithm but riddled with error handling imported from libraries). Personally, I find the situation wrt performance of GHC-generated code very unsatisfactory, not because it isn't good (more often than not, it is), but because there is very little help when it isn't. And the first step towards improving that situation (eg, with tools helping to analyse core, or better understood profiling tools, or support for by-hand application of optimization transformation/undo/modify/retarget/replay..) is to acknowledge that there is a problem. Pointing out that some experienced hackers have been through this, and are now able to make do for themselves, is a non-solution (unless you want to secure consulting fees;-). Just as declarative languages allow us to ignore operational details until/unless they really are needed, offering a clear path on how to specify declarative aspects of our code, so there should be a clear path on how to specify operational details if that becomes necessary. A path that any mildly experienced Haskeller should be able to follow through good documentation, examples, and tools. Claus PS. Talking about high-performance computing seems slightly misleading in this context, if the only goal is to have code as fast as typical C. From what I've heard from HPC folks, generic compilers or generic C code are not tough benchmarks from their point of view, platform vendor compilers and platform-tuned Fortran code are. Of course, that info is second-hand, and somewhat dated, but I think it would help to state our goals explicitly, to avoid confusion or unreasonable expectations. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] attempt creating alternative logging lib which is actually much slower (?)
without removing all all setLevel calls to subloggers?
Is this desirable?
I don't understand the problem. If you told hslogger that you didn't
want to hear about stuff about A, why do you not like that it is
following your instructions?
Because taht don't want to hear abuot A could have been set
without my knowledge. When trouble shooting a problem it could be handy
to just get all messages. But when such a use case arrives I can still
patch hslogger.
mlog (attempt to create a minimal alternative)
I've tried writing another minimal logging system.
The idea was driven by adding the possibility to add a handler logging
everything not matter what levels are set to different loggers or
handlers.
The design is simple: keep a list of log handlers and a list of filters.
you can add a filter telling that a log message of A.B should not be
logged. The actual handler function then looks like this
log shouldbeLogged logmessage loggername prio =
So you can still ignore shouldbeLogged easily.
However I couldn't even come close to the speed of hslogger even when
caching the list of handlers which are supposed to log the message.
[some code snippets see end of mail]
without any attached handlers:
hslogger*[1] : 4ms
mlog[2]: 12ms
with one default stderr logger (./test 2 /dev/null)
hslogger*[1] : 109ms
mlog[2]: 150ms
[1]: my modified version of hslogger (git://mawercer.de/hslogger)
[2]: (git://mawercer.de/mlog)
I've tried doing some investigation figuring out why my lib is that much
slower but I failed. I noticed that -O2 had an impact on how often the
list of generated test cases is run. But that has been all. I don't even
use existential types!
So I'll shut up and keep using hslogger. Thanks to you John Goerzen
for your support.
I've learned that I'm very bad at troubleshooting performance.
I really thought I could make mlog faster than hslogger*.
Using profiling (-P) didn't reveal the source wasting CPU cycles to me.
Sincerly
Marc Weber
[ some code snippets of mlog]
the global logger data looks like this:
data GlobalLoggerData = GlobalLoggerData {
handlers :: M.Map Int LogHandler
-- assign a key so that this logger can be removed easily again
,filters :: M.Map Int GlobalFilter -- allow to add global filters
-- cache information about which logger accepts what logging data
-- String = Priority : loggername
, cached :: M.Map String (Bool, [ LogMessageAction ])
}
{-# NOINLINE globalLoggerData #-}
globalLoggerData :: MVar GlobalLoggerData
globalLoggerData = unsafePerformIO $ newMVar $ GlobalLoggerData M.empty
M.empty M.empty
-- add default handler:
addHandler $ LogHandler {
accept = \ln p - True -- which logging events does this log handler
accept?
,logAction = \ln p msg doLog - hPutStrLn stderr msg
,close = return ()
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HXT + Segmentation Fault
Hi all, I'm trying to parse some XML files using HXT. However, even the examples available on the twiki fail. I guess that the problem is related to some library version, but I'm not sure. The error reported is: Segmentation fault. Thanks in advance. Compiling with GHC-6.8.3 running on MAC/OS Tiger Packages: Cabal-1.2.4.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.2.0, bitset-0.6, bytestring-0.9.0.1.1, cgi-3001.1.6.0, containers-0.1.0.2, curl-1.3.3, directory-1.0.0.1, fgl-5.4.2.0, filepath-1.1.0.0, funsat-0.5.1, ghc-6.8.3, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.1, html-1.0.1.1, hxt-8.1.0, (mtl-1.1.0.1), mtl-1.1.0.2, (network-2.2.0.0), network-2.2.0.1, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.1, parse-dimacs-1.2, parsec-2.1.0.1, parsec-3.0.0, pcre-light-0.3.1, pretty-1.0.0.0, process-1.0.0.1, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, tagsoup-0.6, template-haskell-2.2.0.0, time-1.1.2.1, unix-2.3.0.1, xhtml-3000.2.0.0 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Graph library, was: Haskell.org GSoC
Don Stewart wrote: - Graphs. True graphs (the data structure) are still a weak point! There's no canonical graph library for Haskell. That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? If so, this would be a nice thing to do :) I could look at existing ones (like Boost's graphs) to get a feeling for how an interface might look like and what functionality to implement. BTW, is there some sort of project hosting specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? Thanks, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] TASE 2009 - CALL FOR PAPERS
TASE 2009 - Final CALL FOR PAPERS ** * 3rd IEEE International Symposium on * Theoretical Aspects of Software Engineering * (TASE 2009) * 29-31 July 2009, Tianjin, China * http://www.dur.ac.uk/ieee.tase2009 * * For more information email: ieee.tase2...@durham.ac.uk ** Large scale software systems and the Internet are of growing concern to academia and industry. This poses new challenges to the various aspects of software engineering, for instance, the reliability of software development, web-oriented software architecture and aspect and object-orientation techniques. As a result, new concepts and methodologies are required to enhance the development of software engineering from theoretical aspects. TASE 2009 is a forum for researchers from academia, industry and government to present ideas, results, and ongoing research on theoretical advances in software engineering. TASE 2009 is the third in a series of conference, sponsored by IEEE CS and IFIP. The first TASE conference was held in Shanghai, China, in June 2007. The second TASE conference was held in Nanjing, China, in June 2008. Topics of Interest: Authors are invited to submit high quality technical papers describing original and unpublished work in all theoretical aspects of software engineering. Topics of interest include, but are not limited to: * Requirements Engineering * Specification and Verification * Program Analysis * Software Testing * Model-Driven Engineering * Software Architectures and Design * Aspect and Object Orientation * Embedded and Real-Time Systems * Software Processes and Workflows * Component-Based Software Engineering * Software Safety, Security and Reliability * Reverse Engineering and Software Maintenance * Service-Oriented Computing * Semantic Web and Web Services * Type System and Theory * Program Logics and Calculus * Dependable Concurrency * Software Model Checking Program Co-Chairs - Wei-Ngan Chin (National Univ. of Singapore, Singapore) Shengchao Qin (Durham University, UK) Program Committee - Bernhard Aichernig (Graz University of Technology, Austria) Stefan Andrei (Lamar University, USA) Keijiro Araki (Kyushu University, Japan) Farhad Arbab(CWI and Leiden University, Netherlands) Jonathan Bowen (King's College London, UK) Michael Butler (University of Southampton, UK) Juan Chen (Microsoft Research, USA) Tyng-Ruey Chuang(Academica Sinica, Taiwan) Jim Davies (University of Oxford, UK) Zhenhua Duan(Xidian University, China) Xinyu Feng (Toyota Technological Inst. at Chicago, USA) Dieter Gollmann (Hamburg University of Technology, Germany) Tetsuo Ida (University of Tsukuba, Japan) Radu Iosif (Verimag, CNRS, France) Xuandong Li (Nanjing University, China) Kung-Kiu Lau(University of Manchester, UK) Shaoying Liu(Hosei University, Japan) Dorel Lucanu(University of Iasi, Romania) Tom Maibaum (McMaster University, Canada) Darko Marinov (Univ. of Illinois at Urbana-Champaign, USA) Hong Mei(Peking University, China) Huaikou Miao(Shanghai University, China) Peter Mueller (ETH Zurich, Switzerland) Viet Ha Nguyen (Vietnam National University, Vietnam) Sungwoo Park(Pohang Univ. of Science and Technology, Korea) Corneliu Popeea (MPI-SWS, Germany) Geguang Pu (East China Normal University, China) Zongyan Qiu (Peking University, China) Volker Stolz(UNU/IIST, Macau) Jing Sun(University of Auckland, New Zealand) Jun Sun (National Univ. of Singapore, Singapore) Kenji Taguchi (National Institute of Informatics, Japan) Yih-Kuen Tsay (National Taiwan University, Taiwan) Elizabeth Vidal (San Agustin National University, Peru) Ji Wang (National University of Defense Technology, China) Linzhang Wang (Nanjing University, China) Xianbing Wang (Wuhan University, China) Wang Yi (Uppsala University, Sweden) Jim Woodcock(University of York, UK) Hongyu Zhang(Tsinghua University, China) Jian Zhang (Chinese Academy of Sciences, China) Jianjun Zhao(Shanghai Jiao Tong University, China) Hong Zhu(Oxford Brookes University, UK) Huibiao Zhu (East China Normal University, China) Important Dates: February 20, 2009: Title and abstract submission deadline February 27, 2009: Paper submission deadline April 20, 2009: Acceptance/rejection notification May 11, 2009: Camera-ready version due July 29 -
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Jamie hask...@datakids.org wrote: On Thu, 12 Feb 2009, Conrad Parker wrote: 2009/2/12 Don Stewart d...@galois.com: Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. I agree that it's beyond the scope of a SoC project. Rather than H.263 or H.264 I was going to suggest implementation of Theora or OMS, both of which avoid the patent issues and have publicly available specs: http://theora.org/doc/Theora.pdf http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf Scanning those documents should give anyone a fair idea of the amount of work involved. My understanding is that OMS is of a similar complexity to H.263, and H.264 is more complex than any of these. For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora isn't meant to be a H.264 competitor, but a replacement for flash, wmv and the ilk. I dare to guess that it works decent for low bitrates, especially if you're more interested in detecting shapes than skin pores. I guess you just have to do field tests: encoding video on the fly just isn't what general-purpose CPUs are made for, it's the playing field of processors that take SIMD seriously, i.e. GPUs. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph library, was: Haskell.org GSoC
Daniel Kraft asked: That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? My impression is that there is now standard one, but then again I've only used Haskell + a graph library once. BTW, is there some sort of project hosting specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? Get a community.haskell.org account once you are ready to start a repo, it can not only host your repo (ex: http://community.haskell.org/~tommd/pureMD5) but also allows you to upload packages to hackage.haskell.org. Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Daniel Kraft d...@domob.eu wrote: Don Stewart wrote: - Graphs. True graphs (the data structure) are still a weak point! There's no canonical graph library for Haskell. That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl ? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Daniel Kraft schrieb: Don Stewart wrote: - Graphs. True graphs (the data structure) are still a weak point! There's no canonical graph library for Haskell. That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? I would also like to see a project working on a new graph library. Currently, there is at least Data.Graph (just one Module, package containers), based on Array - adjacency lists, and the functional graph library (package fgl). I think a good general purpose graph library is tricky though: - There are lot of variants of graphs (trees, bipartite, acyclic, undirected, simple, edge labeled etc.), hard to find adequate and easy to use abstraction. - There is no single 'best' implementation (mutable vs. unmutable etc.). - Its hard to find good traversal and zipper abstractions, though fgl has some nice ones. - The complexity of algorithms varies greatly depending on the particular kind of graph. Anyway, that's why it is challenging and interesting. If so, this would be a nice thing to do :) I could look at existing ones (like Boost's graphs) to get a feeling for how an interface might look like and what functionality to implement. BTW, is there some sort of project hosting specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? code.haskell.org / community.haskell.org provides webspace, trac, mailing-list, darcs. benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CFP: 5th Haskell Hackathon, April 17-19, Utrecht
Call for participation: ~~ The 5th Haskell Hackathon April 17 - 19, 2009 Utrecht, The Netherlands ~~ The Haskell Hackathon is a collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure. Of course, we have fun doing it, too! All hackers are welcome to visit and work on various Haskell-related projects. You decide what you want to work on! Lists of projects and concerted efforts are collected on the Hac5 website. == General Information == Information about the projects as well as practicalities such as traveling, accommodation, etc. is available from the Hac5 website: http://haskell.org/haskellwiki/Hac5 == Registration == Please register by following the instructions on the registration page: http://haskell.org/haskellwiki/Hac5/Register Once you've registered, please add your info to the attendees self-organizing page: http://haskell.org/haskellwiki/Hac5/Attendees If you are looking to share costs or want to meet up prior to the Hackathon with other attendees, feel free to organize via the Attendees wiki page or join the Hackathon IRC channel on freenode: #haskell-hac5 == Organizers == Andres Löh, Utrecht University (UU) José Pedro Magalhães, UU Sean Leather, UU Eelco Lempsink, UU + Tupil Chris Eidhof, UU + Tupil ... and more ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Benedikt Huber benj...@gmx.net writes: I would also like to see a project working on a new graph library. [...] I think a good general purpose graph library is tricky though: And please, let us have a library that is scalable! This means there should be one (or several) benchmark application(s) that do non-trivial work on graphs of non-trivial sizes. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 09:15 schrieben Sie: g9ks157k: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to encorporate ... “Wiki” sounds like you could edit the documentation of the package. This wouldn’t necessarily mean that these modifications are written back to the repository. However, it would men that Hackage is not longer showing the real documentation of the repository but what others made of it by wiki editing. I would dislike this. However, a commenting system like that of RWH is a very different thing. People would not edit the actual documentation (so the documentation is not a wiki). People would just add comments. This might be a good idea. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 10:49 schrieb Luke Palmer: Something like AnnoCPAN would be a good middle-ground here; i.e. differentiate between official package documentation and user annotations, but make them both visible. And give visitors of the Hackage website the choice to not see the comments at all. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph library, was: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 15:34 schrieb Thomas DuBuisson: Daniel Kraft asked: That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? My impression is that there is now standard one, but then again I've only used Haskell + a graph library once. BTW, is there some sort of project hosting specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? Get a community.haskell.org account once you are ready to start a repo, it can not only host your repo (ex: http://community.haskell.org/~tommd/pureMD5) but also allows you to upload packages to hackage.haskell.org. I already have a Hackage account. Can this be readily used as a community.haskell.org account? If not, what if I get a community account. Do I have two accounts for Hackage access then? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Benedikt writes: I think a good general purpose graph library is tricky though: - There are lot of variants of graphs (trees, bipartite, acyclic, undirected, simple, edge labeled etc.), hard to find adequate and easy to use abstraction. - There is no single 'best' implementation (mutable vs. unmutable etc.). - Its hard to find good traversal and zipper abstractions, though fgl has some nice ones. - The complexity of algorithms varies greatly depending on the particular kind of graph. Anyway, that's why it is challenging and interesting. Hear, hear! From what I can tell, fgl is the closest thing I've seen to a usable remotely-general-purpose graph library in any language. With all apologies to Siek, et al., the boost graph library is exceedingly complex, to the point of being unusable (one man's opinion) to all but the most ardent lovers of C++ template metaprogramming. That's no knock on its designers, it's just that the graph problem provides an exceptionally challenging tension between managing complexity and providing acceptable performance--on top of trying to achieve respectable generality. It seems to me that anyone who aspires to author a Haskell graph library that can be regarded as canonical really ought to first know fgl inside and out, and probably ought to consider extending that library, vs. starting from scratch. In fact, it was my current work with non-trivial graph problems that ultimately led me to justify switching to using Haskell for my day job a couple of months ago (after having investigated and abandoned other possible solutions in other languages that would have been a much easier sell to my higher-ups). So I have a pressing professional interest on hearing others weigh in on this topic, and particularly on the benefits/shortcomings of fgl. I'd especially like to hear from Martin Erwig on this topic. Martin? You listening? --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Benedikt Huber wrote: I would also like to see a project working on a new graph library. Currently, there is at least Data.Graph (just one Module, package containers), based on Array - adjacency lists, and the functional graph library (package fgl). I don't know those, but functional graph library suggests it is meant to be something like what we're discussing here (and this is also what Google returns for Haskell + graph library). What's the problem with it or in which way is it different? I think a good general purpose graph library is tricky though: - There are lot of variants of graphs (trees, bipartite, acyclic, undirected, simple, edge labeled etc.), hard to find adequate and easy to use abstraction. Well, while an undirected tree / acyclic graph can obviously be represented as a tree structure, all the others would resolve around having nodes and for each node a list of edges to neighbouring nodes; at least concept-wise, wouldn't they? Then one could build an abstraction on top of this with a node class able to name neighbouring nodes or something like that to get rid of a fixed representation (and allow working on graphs constructed on the fly as opposed to being stored in memory), but I think this would be the basic way to go. Everything else (whatever could benefit from a substantial different representation) could go in a seperate library or specialisation. Or do I miss something here? (No expert with regards to graphs and their use-cases yet.) code.haskell.org / community.haskell.org provides webspace, trac, mailing-list, darcs. Thanks for the pointer! Yours, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Malcolm.Wallace: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. I agree: the big projects can stand on their own. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
gtener: On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Gwern Branwen gwe...@gmail.com wrote: * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. By the way: I think it may be worthwile to contact Google to point out the recent growth of Haskell community. I don't know on what basis they assign the slots, but it may be beneficial to do so. In the past it has been based on scale of mentors, proposals and students. If we're under-allocated, that can sometimes be addressed, however. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Daniel Kraft schrieb:
Benedikt Huber wrote:
I would also like to see a project working on a new graph library.
Currently, there is at least Data.Graph (just one Module, package
containers), based on Array - adjacency lists, and the functional
graph library (package fgl).
I don't know those, but functional graph library suggests it is meant
to be something like what we're discussing here (and this is also what
Google returns for Haskell + graph library). What's the problem with it
or in which way is it different?
(I hope the following explanation is correct, apologies otherwise)
The fgl is build upon the concept of Inductive Graphs, described in
Martin Erwig's Inductive Graphs and Functional Graph Algorithms
(http://web.engr.oregonstate.edu/~erwig/papers/InductiveGraphs_JFP01.pdf).
The basic idea is that for traversals, you don't mark visited notes,
but decompose the graph like that:
(nodeContext,restGraph) = matchAny graph
{- or -}
(nodeContext,restGraph) = match nodeId graph
This is in some sense 'more functional' than relying on tables for
marking visited nodes.
DFS e.g. is implemented as (comments for clarification)
xdfsWith :: Graph gr = (Context a b - [Node]) - -- neighbours
(Context a b - c) - -- compute result
[Node] - -- start
gr a b - -- the graph
[c]-- result list
xdfsWith _ _ [] _ = [] -- no more nodes to visit
xdfsWith _ _ _ g | isEmpty g = [] -- empty graph
xdfsWith d f (v:vs) g =
case match v g of-- decompose graph
-- compute result, add neighbours to todo list, recursive dfs
(Just c,g') - f c:xdfsWith d f (d c++vs) g'
-- Couldn't find node, continue
(Nothing,g') - xdfsWith d f vs g'
There's certainly more to say about the fgl, just read the paper.
Now for many applications this is fine, and the fgl is indeed a fine
library. But obviously there is some overhead in matching, and the API
is sometimes a little difficult to understand. And it's not the only way
to do graph algorithms in haskell.
I think a good general purpose graph library is tricky though:
- There are lot of variants of graphs (trees, bipartite, acyclic,
undirected, simple, edge labeled etc.), hard to find adequate and easy
to use abstraction.
Well, while an undirected tree / acyclic graph can obviously be
represented as a tree structure
Acyclic graphs are not tree-like.
The point about trees is that sometimes it is useful to view them as
general purpose graphs, so they should also be represented in a graph
library. However, in my opionion the library should also have a
specialized representation of trees, as most algorithms are much simpler
(Like containers' Data.Tree).
all the others would resolve around
having nodes and for each node a list of edges to neighbouring nodes; at
least concept-wise, wouldn't they?
From an implementation point of view, yes, adjacency lists, as arrays
or trees, and matrices.
But there is a wide range of possibilities for algorithms, from monadic
implementations (using ST/UArray) to inductive graphs.
For efficient algorithms, somethink like Array's freeze/thaw seems to be
a good idea, too.
benedikt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Google Summer of Code 2009
Johan Tibell wrote: On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa felipe.le...@gmail.com wrote: Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. I still haven't figured out what the correct definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of two level monad. I think that's the reason for the frequent occurrences of == and liftI in the code. There seems to be some things we yet have to discover about Iteratees. I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The two level monad part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient. I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
On Thu, Feb 12, 2009 at 4:12 AM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: As Wolfgang mentioned, you may choose to follow the common package versioning policy. http://haskell.org/haskellwiki/Package_versioning_policy We are planning to develop tool support for this. To let packages explicitly opt-in and then we can hold such packages to their promise. We can also advise authors about what form of version constraints they should use for dependencies on packages that follow the PVP. Thanks for the documentation! That's helpful. I'll change the libraries I maintain to follow this policy. None of them would work well for a date-based scheme. Thanks again, Corey O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Delimited continuations: please comment
Hi,
I'm experimenting with delimited continuations in the effort to
understand how they work and when it's convenient to use them.
Consider this piece of code (install the CC-delcont before running it):
{-# LANGUAGE NoMonomorphismRestriction #-}
import Control.Monad.CC
import Control.Monad.Trans -- why do I have to import this?
data Monad m = Susp m a b = Stop | Susp (a - m (Susp m a b))
job = reset $ \p - let askMsg = shift p $ \k - return $ Susp $ k . return
in do x - askMsg
liftIO $ putStrLn $ x was ++ show x
y - askMsg
liftIO $ putStrLn $ y was ++ show y
return Stop
scheduler j = do Susp nj - j
Susp nj - nj Hello!
nj World!
return undefined
main = runCCT $ scheduler job
which produces the output:
[pa...@bagend haskell]$ runhaskell dc.hs
x was Hello!
y was World!
[pa...@bagend haskell]$
The goal of this is to have a test-case implementation of the system
call mechanism found in operating systems, like the one described by
Oleg in (see page 3):
http://okmij.org/ftp/papers/context-OS.pdf
In effect, this is a bit different from the syscall service routine
described by Oleg, as the scheduler function reacts in different ways
for subsequent calls (the first time feeds Hello!, the second one
World!, in a nice monad style). Yet, I liked the separation between
the scheduler and the job, which are two completely different values
and which I tried to keep.
As this is (almost) my first time using delconts, could you provide
feedback, comments, opinions about my piece of code and the topic in
general (convenience, performances, alternatives and so on)?
Thank you,
Cristiano
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Google Summer of Code 2009
On Thu, Feb 12, 2009 at 11:49 AM, John Lato jwl...@gmail.com wrote: Johan Tibell wrote: On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa felipe.le...@gmail.com wrote: Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. I still haven't figured out what the correct definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of two level monad. I think that's the reason for the frequent occurrences of == and liftI in the code. There seems to be some things we yet have to discover about Iteratees. I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The two level monad part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient. I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope. John Lato I agree. Just packaging and cabalizing something is likely not a SoC-worthy project. (This is why the 'cabalize Wash' suggestion will never make it, for example.) In general, cabalizing seems to be either pretty easy (most everything I've cabalized) or next to impossible (gtk2hs, ghc). The former are too trivial for SoC, and the latter likely are impossible without more development of Cabal - at which point it'd be more correct to call it a Cabal SoC and not a cabalizing SoC. -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Google Summer of Code 2009
gwern0: On Thu, Feb 12, 2009 at 11:49 AM, John Lato jwl...@gmail.com wrote: Johan Tibell wrote: On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa felipe.le...@gmail.com wrote: Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. I still haven't figured out what the correct definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of two level monad. I think that's the reason for the frequent occurrences of == and liftI in the code. There seems to be some things we yet have to discover about Iteratees. I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The two level monad part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient. I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope. John Lato I agree. Just packaging and cabalizing something is likely not a SoC-worthy project. (This is why the 'cabalize Wash' suggestion will never make it, for example.) In general, cabalizing seems to be either pretty easy (most everything I've cabalized) or next to impossible (gtk2hs, ghc). The former are too trivial for SoC, and the latter likely are impossible without more development of Cabal - at which point it'd be more correct to call it a Cabal SoC and not a cabalizing SoC. Yes, cabalising was more of a priority when we only had 10 libraries :) So in general, think hard about missing capabilities in Haskell: * tools * libraries * infrastructure that benefit the broadest number of Haskell users or developers. Another route is to identify a clear niche where Haskell could leap ahead of the competition, with a small investment. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is using Data.Dynamic considered a no-go?
Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these hacks. Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Cheers, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is using Data.Dynamic considered a no-go?
bugfact: Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these hacks. Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Inefficiencies and runtime errors? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Is using Data.Dynamic considered a no-go?
Peter Verswyvelen bugf...@gmail.com wrote: Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these hacks. Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Uncertainty. Noone on #haskell seems to know how Typeable-dispatches compare to pattern matching wrt. performance, and I was either too lazy or too uninterested to measure it myself. Combined with a custom type class and existentials, they safe you from writing catch-all ADTs and thus give code flexibility (and conciseness), while retaining static typing, modulo unexhaustive pattern warnings. This is how XHB uses Typeable, and, IMHO, it's a Good Thing. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is using Data.Dynamic considered a no-go?
They are not unsafe in the way unsafePerformIO is, but I regard them as a last resort in certain situations. Still, in those situations they are very useful. -- Lennart 2009/2/12 Peter Verswyvelen bugf...@gmail.com: Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these hacks. Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Cheers, Peter ___ 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: Graph library, was: Haskell.org GSoC
fgl uses pretty much the most beautiful way of abstracting graphs I've seen; a brief review: type Context a b -- a collected representation of a vertex's number, label, and all information on edges going into and out of that vertex match :: Graph gr = Node - gr a b - (Maybe (Context a b), gr a b) -- if a vertex is in the graph, extracts its adjacency information in a Context and returns the graph without that vertex () :: DynGraph gr = Context a b - gr a b - gr a b -- melds a vertex and its adjacency information into the graph I've been doing a huge amount of messing around with graph algorithms recently, and this inductive style of graph querying and modification make several algorithms far more intuitive than most imperative implementations I've seen. In addition, both of these lend themselves well to use in a State monad. Take the following code to extract the connected component of a vertex in an undirected graph: extractComponentM :: DynGraph gr = gr a b - Node - State (gr a b) (gr a b) extractComponentM partialComponent v = State (match v) = maybe (return partialComponent) expandContext where expandContext cxt = liftM (cxt ) (foldM extractComponentM partialComponent (neighbors' cxt)) extractComponent :: DynGraph gr = gr a b -- the initial graph - Node -- the node whose component to find - (gr a b, gr a b) -- the original graph without the component, and the component extractComponent g v = runState (extractComponentM empty v) g That's far more compact -- and intuitive to someone familiar with both fgl and the State monad -- than a standard connected-component finder in an imperative language, speaking as someone who wrote code along these lines imperatively for several years. (Fun fact: I've been working on a nice encapsulation of priority queues as monad transformers to make other common graph algorithms both efficient and make them this pretty to read, too. Any thoughts on that would be appreciated.) I strongly feel that fgl, though it could be improved in some areas, makes a better truly general graph abstraction than anything else I've seen. Areas that could specifically be improved include the stuff that uses LRTrees, and other stuff that isn't especially intuitive, elegant, or even efficient in fgl's implementation. Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Thu, 12 Feb 2009, Achim Schneider wrote: Jamie hask...@datakids.org wrote: For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora isn't meant to be a H.264 competitor, but a replacement for flash, wmv and the ilk. I dare to guess that it works decent for low bitrates, especially if you're more interested in detecting shapes than skin pores. I guess you just have to do field tests: encoding video on the fly just isn't what general-purpose CPUs are made for, it's the playing field of processors that take SIMD seriously, i.e. GPUs. Signers (deaf people or hearing people who know sign language) naturally put strong emphasize on smooth video quality (i.e. at least 25 fps with no blurries/fuzzy). I use Mirial Softphone (to me, a best H.323/SIP video softphone so far, run on Windows) and it runs very nicely and perfectly on my Dell 1 GHz Centrind Duo laptop in both H.263 and H.264 (I even tried H.264 at 704x576 at 30 FPS and it works real nice). However Mirial sure did display CPU overload message time to time on my Samsung NC10 netbook especially using H.264 and result in pixelization of video frames. So no problem at all with my Dell laptop but kind of borderline on Atom 1.6Ghz netbook. I agree it would surely help offload the CPU work when there is hardware encoder/decoder present in GPU. I see more and more GPU now support H.264 decoder which is nice. Jamie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is using Data.Dynamic considered a no-go?
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive* Typeable.
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is using Data.Dynamic considered a no-go?
You're quite right. You should only be allowed to derive Typeable.
(Which could be arranged by hiding the methods of typeable.)
On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive* Typeable.
jcc
___
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: [Haskell] Google Summer of Code 2009
Matthew Elder wrote: would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) Extending this idea, I'd like to see some 3D visualization of the file hierarchy and the partial hierarchy for the patch/diff being considered. That is: not just per-file diff views, but also per-project views. It'd also be nice to see this with more than one layer of diff at a time so you can get an idea about potential conflicts and what parts of the project are getting heavily changed. Felipe Lessa wrote: 2009/2/12 Matthew Elder m...@mattelder.org: would love to see this. basic features first i suppose. here are some of my ideas: meld-like diff view would be great too. http://meld.sourceforge.net/ I especially like the highlighting of what has changed within the line, rather than diff's usual answer of durr, it's different. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is using Data.Dynamic considered a no-go?
It would be interesting to see when you HAVE to use dynamics, e.g. when no
other solution is possible in Haskell...
Right now if I use it, it feels that I'm doing so because I'm too new to
Haskell.
On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson
lenn...@augustsson.netwrote:
You're quite right. You should only be allowed to derive Typeable.
(Which could be arranged by hiding the methods of typeable.)
On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive* Typeable.
jcc
___
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] Is using Data.Dynamic considered a no-go?
Notably, extensible exceptions use dynamics, in conjunction with type
classes and existentials.
A number of solutions to the 'expression problem' involve dynamics.
bugfact:
It would be interesting to see when you HAVE to use dynamics, e.g. when no
other solution is possible in Haskell...
Right now if I use it, it feels that I'm doing so because I'm too new to
Haskell.
On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson lenn...@augustsson.net
wrote:
You're quite right. You should only be allowed to derive Typeable.
(Which could be arranged by hiding the methods of typeable.)
On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive* Typeable.
jcc
___
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can't figure out a type
Hi Job, thanks for replying. Thanks for explaining this. I never really thought about the implications of kinds on type classes, and it's all much more clear now. The first version, with only one parameter, almost works, except that some instances (e.g. uvector, storablevector) have further class restrictions on the element types. I believe these are impossible to express without the element parameter included in the Chunkable class. This was a big disappointment, because otherwise it would be possible in Haskell98. This is also a problem with the map implementation. Since the typeclass restriction exists for both el and el', I don't see how it's possible to type cMap without including el' in the class. I don't want to do that, so I guess the map function will just need to be provided outside the class instance. It does turn out that I don't need either fundeps or type families at least. Thanks to everyone who replied; it really helped me clarify my thoughts on this implementation. Cheers, John Lato On Wed, Feb 11, 2009 at 8:28 PM, Job Vranish jvran...@gmail.com wrote: I think what you probably want is something like this: class Chunckable c where cLength :: c el - Int cHead :: c el - Maybe el cMap :: (a - b) - c a - c b instance Chunckable [] where cLength [] = 0 cLength (x:xs) = 1 + cLength xs cHead [] = Nothing cHead (x:xs) = Just x cMap = map a = [4, 7, 3, 8] test1 = cLength a test2 = cHead a test3 = cMap (Just) a The class does not actually need the second type parameter. You can actually use all sorts of extra type variables in the type signatures in class declarations as long as all your instances are polymorphic across those types (not sure if that's the precise terminology). Basically, as long as cLength, cHead and cMap do the same thing regardless of what el is, then you don't need to have el as a type parameter to the class. Now if you _do_ want to have cLength, etc do something else depending el, then things get more complicated. Maybe something like this: class Chunckable2 c el where cLength2 :: c el - Int cHead2 :: c el - Maybe el cMap2 :: (Chunckable2 c el') = (el - el') - c el - c el' instance Chunckable2 [] Int where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 = map instance Chunckable2 [] Float where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 f xs = [] test4 = cMap2 (fromIntegral) (a::[Int]) :: [Float] test5 = cMap2 (id) ([3.0, 4.0, 1.0]::[Float]) :: [Float] Note that if you want things to work like this, functional dependencies wont help you out (as they don't make sense in this case) On Wed, Feb 11, 2009 at 12:34 PM, John Lato jwl...@gmail.com wrote: Hi Job, Thanks for answering. What I'm trying to do is probably very simple, and I think the biggest problem is that I don't fully understand kinds yet. Here's an example instance: instance Chunkable [a] a where cmap = map --etc. In the class I wrote, c has kind * (e.g. [a]), but then I don't see how to write a suitable map function. For that, I would want c to have kind * - *. Unfortunately then I don't know to write the others. Would I have to do something with c having kind (* - *) ? class Chunkable2 c el where cLength :: c el - Int cHead :: c el - Maybe el cMap :: (el - el') - c el - c el' Sincerely, John On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish jvran...@gmail.com wrote: What do you mean by parameterized over a different type? will c have a kind of * - * ? I don't think it has to be for what you want to work, but the idea of same instance will go out the window. Do you have a small usage example? On Wed, Feb 11, 2009 at 11:52 AM, John Lato jwl...@gmail.com wrote: Hello, I'm working on some code like the following: class Chunkable c el | c - el where cLength :: c - Int cHead :: c - Maybe el I want to be able to map over this type, like this: cMap :: Chunkable c' el' = (el - el') - c - c' but this isn't quite right. c' shouldn't be any instance of Chunkable, it should be the same instance except parameterized over a different type. Another approach would be something like: class (Functor c) = Chunkable c el ... except that's not right either. I think c has the wrong kind to be a Functor instance. I expect there's something very basic I'm missing. Could anyone point in the proper direction of how to do this? Can this be expressed with associated types, perhaps? Thanks, John Lato ___ 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] Race condition possible?
Consider the following code stamp v x = do t - getCurrentTime putMVar v (x,t) Is it possible - with GHC - that a thread switch happens after the t - getCurrentTime and the putMVar v (x,t)? If so, how would it be possible to make sure that the operation of reading the current time and writing the pair to the MVar is an atomic operation, in the sense that no thread switch can happen between the two? Would this require STM? Thanks again for sharing your wisdom with me :) Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can't figure out a type
One clarification. That is, I could write map with the cNull/cCons implementation already suggested, but I couldn't do: instance Chunkable Data.StorableVector.Vector el where ... cMap = Data.StorableVector.map which is what I really want. However, I just realized that I should be able to use the cNull cCons implementation with a rewrite rule for this case, so I think I'm happy now. John On Thu, Feb 12, 2009 at 11:08 PM, John Lato jwl...@gmail.com wrote: Hi Job, thanks for replying. Thanks for explaining this. I never really thought about the implications of kinds on type classes, and it's all much more clear now. The first version, with only one parameter, almost works, except that some instances (e.g. uvector, storablevector) have further class restrictions on the element types. I believe these are impossible to express without the element parameter included in the Chunkable class. This was a big disappointment, because otherwise it would be possible in Haskell98. This is also a problem with the map implementation. Since the typeclass restriction exists for both el and el', I don't see how it's possible to type cMap without including el' in the class. I don't want to do that, so I guess the map function will just need to be provided outside the class instance. It does turn out that I don't need either fundeps or type families at least. Thanks to everyone who replied; it really helped me clarify my thoughts on this implementation. Cheers, John Lato On Wed, Feb 11, 2009 at 8:28 PM, Job Vranish jvran...@gmail.com wrote: I think what you probably want is something like this: class Chunckable c where cLength :: c el - Int cHead :: c el - Maybe el cMap :: (a - b) - c a - c b instance Chunckable [] where cLength [] = 0 cLength (x:xs) = 1 + cLength xs cHead [] = Nothing cHead (x:xs) = Just x cMap = map a = [4, 7, 3, 8] test1 = cLength a test2 = cHead a test3 = cMap (Just) a The class does not actually need the second type parameter. You can actually use all sorts of extra type variables in the type signatures in class declarations as long as all your instances are polymorphic across those types (not sure if that's the precise terminology). Basically, as long as cLength, cHead and cMap do the same thing regardless of what el is, then you don't need to have el as a type parameter to the class. Now if you _do_ want to have cLength, etc do something else depending el, then things get more complicated. Maybe something like this: class Chunckable2 c el where cLength2 :: c el - Int cHead2 :: c el - Maybe el cMap2 :: (Chunckable2 c el') = (el - el') - c el - c el' instance Chunckable2 [] Int where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 = map instance Chunckable2 [] Float where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 f xs = [] test4 = cMap2 (fromIntegral) (a::[Int]) :: [Float] test5 = cMap2 (id) ([3.0, 4.0, 1.0]::[Float]) :: [Float] Note that if you want things to work like this, functional dependencies wont help you out (as they don't make sense in this case) On Wed, Feb 11, 2009 at 12:34 PM, John Lato jwl...@gmail.com wrote: Hi Job, Thanks for answering. What I'm trying to do is probably very simple, and I think the biggest problem is that I don't fully understand kinds yet. Here's an example instance: instance Chunkable [a] a where cmap = map --etc. In the class I wrote, c has kind * (e.g. [a]), but then I don't see how to write a suitable map function. For that, I would want c to have kind * - *. Unfortunately then I don't know to write the others. Would I have to do something with c having kind (* - *) ? class Chunkable2 c el where cLength :: c el - Int cHead :: c el - Maybe el cMap :: (el - el') - c el - c el' Sincerely, John On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish jvran...@gmail.com wrote: What do you mean by parameterized over a different type? will c have a kind of * - * ? I don't think it has to be for what you want to work, but the idea of same instance will go out the window. Do you have a small usage example? On Wed, Feb 11, 2009 at 11:52 AM, John Lato jwl...@gmail.com wrote: Hello, I'm working on some code like the following: class Chunkable c el | c - el where cLength :: c - Int cHead :: c - Maybe el I want to be able to map over this type, like this: cMap :: Chunkable c' el' = (el - el') - c - c' but this isn't quite right. c' shouldn't be any instance of Chunkable, it should be the same instance except parameterized over a different type. Another approach would be something like: class (Functor c) = Chunkable c el ... except that's not right either. I think c has the wrong kind to be a Functor instance. I expect there's something very basic I'm missing. Could anyone point in
Re: [Haskell-cafe] Looking for pointfree version
On Mon, 9 Feb 2009, Edsko de Vries wrote: Hi, Is there a nice way to write down :: Focus - [Focus] down p = concat [downPar p, downNew p, downTrans p] down = concat . sequence [downPar, downNew, downTrans] given the Reader like Monad instance of ((-) a). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Race condition possible?
bugfact: Consider the following code stamp v x = do t - getCurrentTime putMVar v (x,t) Is it possible - with GHC - that a thread switch happens after the t - getCurrentTime and the putMVar v (x,t)? Yes. if 't' is heap allocated, there could be a context switch. If so, how would it be possible to make sure that the operation of reading the current time and writing the pair to the MVar is an atomic operation, in the sense that no thread switch can happen between the two? Would this require STM? Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or a modifyMVar in IO? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type families not as useful over functions
Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a - Return a instance Broadcast [a - r] where type Return [a - r] = a - [r] -- Conflict! broadcast fs a = [] instance Broadcast [a - b - r] where type Return [a - b - r] = a - b - [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. In this case, currying is not my friend. Unfortunately this means I'm stuck with numbered function names: bc0 :: [r] - [r] bc0 rs = rs bc1 :: [a - r] - a - [r] bc1 [] a = [] bc1 (r:rs) a = (r a):bc1 rs a bc2 rs a b = rs `bc1` a `bc1` b bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c -- etc Cheers, -John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Another point-free question (=, join, ap)
Hi, I can desugar do x' - x f x' as x = \x - f x' which is clearly the same as x = f However, now consider do x' - x y' - y f x' y' desugared, this is x = \x - y = \y' - f x' y' I can simplify the second half to x = \x - y = f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Edsko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Another point-free question (=, join, ap)
Check out liftM2. It's almost what you want. On Thu, Feb 12, 2009 at 6:36 PM, Edsko de Vries devri...@cs.tcd.ie wrote: Hi, I can desugar do x' - x f x' as x = \x - f x' which is clearly the same as x = f However, now consider do x' - x y' - y f x' y' desugared, this is x = \x - y = \y' - f x' y' I can simplify the second half to x = \x - y = f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Edsko ___ 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] Type families not as useful over functions
What do you need that for? Can you live with infixl |$| (|$|) :: [a - r] - a - [r] fs |$| x = map ($ x) fs and, instead of broadcast fs a b use fs |$| a |$| b ? On 13 Feb 2009, at 02:34, John Ky wrote: Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a - Return a instance Broadcast [a - r] where type Return [a - r] = a - [r] -- Conflict! broadcast fs a = [] instance Broadcast [a - b - r] where type Return [a - b - r] = a - b - [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. In this case, currying is not my friend. Unfortunately this means I'm stuck with numbered function names: bc0 :: [r] - [r] bc0 rs = rs bc1 :: [a - r] - a - [r] bc1 [] a = [] bc1 (r:rs) a = (r a):bc1 rs a bc2 rs a b = rs `bc1` a `bc1` b bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c -- etc Cheers, -John ___ 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] Type families not as useful over functions
On Fri, 2009-02-13 at 10:34 +1100, John Ky wrote: Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a - Return a instance Broadcast [a - r] where type Return [a - r] = a - [r] -- Conflict! broadcast fs a = [] instance Broadcast [a - b - r] where type Return [a - b - r] = a - b - [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. This solution is somewhat in-extensible in the ultimate result type (r, in your code); if the number of types r can take on is limited, it should work well, though. For expository purposes, I assume that r is always Int: -- | Conal Elliot's semantic editor combinator argument argument :: (a - a') - (a - b) - (a' - b) argument f g = g . f class Broadcast a where type Return a broadcast :: [a] - Return a instance Broadcast Int where type Return Int = [Int] broadcast ns = ns instance Broadcast r = Broadcast (a - r) where type Return (a - r) = a - Return r broadcast fs x = (map.argument) (const x) fs jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type families not as useful over functions
Hi Miguel, That's a nice way of writing it. Thanks, -John On Fri, Feb 13, 2009 at 10:42 AM, Miguel Mitrofanov miguelim...@yandex.ruwrote: What do you need that for? Can you live with infixl |$| (|$|) :: [a - r] - a - [r] fs |$| x = map ($ x) fs and, instead of broadcast fs a b use fs |$| a |$| b ? On 13 Feb 2009, at 02:34, John Ky wrote: Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a - Return a instance Broadcast [a - r] where type Return [a - r] = a - [r] -- Conflict! broadcast fs a = [] instance Broadcast [a - b - r] where type Return [a - b - r] = a - b - [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. In this case, currying is not my friend. Unfortunately this means I'm stuck with numbered function names: bc0 :: [r] - [r] bc0 rs = rs bc1 :: [a - r] - a - [r] bc1 [] a = [] bc1 (r:rs) a = (r a):bc1 rs a bc2 rs a b = rs `bc1` a `bc1` b bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c -- etc Cheers, -John ___ 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] Another point-free question (=, join, ap)
Hello, You could do: (f = x) = y ? - jeremy At Thu, 12 Feb 2009 23:36:19 +, Edsko de Vries wrote: Hi, I can desugar do x' - x f x' as x = \x - f x' which is clearly the same as x = f However, now consider do x' - x y' - y f x' y' desugared, this is x = \x - y = \y' - f x' y' I can simplify the second half to x = \x - y = f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Edsko ___ 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] Another point-free question (=, join, ap)
On Thu, 2009-02-12 at 23:36 +, Edsko de Vries wrote: Hi, I can desugar do x' - x f x' as x = \x - f x' which is clearly the same as x = f However, now consider do x' - x y' - y f x' y' desugared, this is x = \x - y = \y' - f x' y' I can simplify the second half to x = \x - y = f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Copying a bit of Applicative style, you could say join $ f `liftM` x `ap` y I've thought it would be nice to have something like app :: Monad m = m (a - m b) - m a - m b app af ax = join $ af `ap` ax in the standard library. Then you could simplify to f `liftM` x `app` y I think that's as simple as you're going to get. For more arguments, say f `liftM` x `ap` y `app` z The rule is: first application operator is `liftM` (or $ --- I always define Applicative instances for my monads); last application operator is `app`; the operators in-between are all `ap`. I think that's a pretty straight-forward rule to follow. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type families not as useful over functions
Hi Johnaton, Ah yes. That makes sense. Is there a way to define type r to be all types except functions? -John On Fri, Feb 13, 2009 at 10:44 AM, Jonathan Cast jonathancc...@fastmail.fmwrote: On Fri, 2009-02-13 at 10:34 +1100, John Ky wrote: Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a - Return a instance Broadcast [a - r] where type Return [a - r] = a - [r] -- Conflict! broadcast fs a = [] instance Broadcast [a - b - r] where type Return [a - b - r] = a - b - [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. This solution is somewhat in-extensible in the ultimate result type (r, in your code); if the number of types r can take on is limited, it should work well, though. For expository purposes, I assume that r is always Int: -- | Conal Elliot's semantic editor combinator argument argument :: (a - a') - (a - b) - (a' - b) argument f g = g . f class Broadcast a where type Return a broadcast :: [a] - Return a instance Broadcast Int where type Return Int = [Int] broadcast ns = ns instance Broadcast r = Broadcast (a - r) where type Return (a - r) = a - Return r broadcast fs x = (map.argument) (const x) fs jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Another point-free question (=, join, ap)
oops, I take that back. It only appears to work if you are sloppy: x :: (Monad m) = m a x = undefined y :: (Monad m) = m b y = undefined g :: (Monad m) = a - b - m c g = undefined ex1 :: (Monad m) :: m c ex1 = (g = x) = y But, if you try to pin down the types you find it only works because they are not all the same Monad m. a :: (Int - Int) a = return 1 b :: Maybe Int b = Just 2 h :: Int - Int - Maybe Int h a b = return (a + b) ex5 :: Maybe Int ex5 = (h = a) = b :) j. At Thu, 12 Feb 2009 18:04:45 -0600, Jeremy Shaw wrote: Hello, You could do: (f = x) = y ? - jeremy At Thu, 12 Feb 2009 23:36:19 +, Edsko de Vries wrote: Hi, I can desugar do x' - x f x' as x = \x - f x' which is clearly the same as x = f However, now consider do x' - x y' - y f x' y' desugared, this is x = \x - y = \y' - f x' y' I can simplify the second half to x = \x - y = f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Edsko ___ 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] Haddock Markup
On 12 Feb 2009, at 8:48 pm, Wolfgang Jeltsch wrote:
I don’t understand this. The way which works is conversion from
MathML to TeX.
So your suggestion would be to use MathML as the source language.
But this is
obviously not what you suggest. I’m confused.
It's explicit enough in the original message:
Use a substantial chunk of MathML
in a TeX-parseable syntax.
If you want to use a subset of TeX in Haddock comments, how would
you render them on a webpage?
I didn't say a subset of TeX but a subset of MathML.
MathML is two things: a set of labelled trees with some sort
of semantics, and a representation of those trees as XML.
Anything that can be written as
X a=b.../X
can also be written as
\X[b]{...}
with a reasonable amount of care. (Not necessarily the same X and b,
of course, and ... would be recursively transformed.)
Let's take this example from the web.
math mrow msup mix/mimn2/mn /msup mo+/mo mrow
mn4/mnmoInvisibleTimes;/momix/mi /mrow mo+/mo
mn4/mn /mrow /math
Step 1. Rule that letters c stand for \mi{c} unless otherwise
quoted. Rule that digit sequences d stand for \mn{d} unless
otherwise quoted. Rule that normal operators x stand for \mo{x}
unless otherwise quoted. Rule that x^y stands for
\msup{x}{y}. Rule that x_y stands for \msub{x}{y}.
Step 2. Introduce names for (some) things MathML has, like
InvisibleTimes; and TeX does not.
Step 3. Write a checker that enforces the conventions.
By step 3, we have the ability to write
\mathml{\mrow{x^2 + \mrow{4\itimes x} + 4}}
and have LaTeX process it directly. The advantage of this stuff
is that you can put it in your technical papers. Why bother?
Because of the checker. (I do not have such a program. This is
a design sketch on a tablecloth, not to be taken any more seriously
than that.) Why not use MathML? (La)TeX macros spring to mind as
a good reason... Not having to use XML as another.
Step 4. Based on the checker, write a program to convert this
notation to MathML. MathML was, after all, designed for machines
to write and read; it is not practical for people to write and it
couldn't be called even remotely readable by its best friend.
That makes it a pretty appalling choice for something to write
in Haddock comments in source files.
By step 4, you have something you can check better than standard
TeX, something you can cut and paste between TeX papers and
Haddock documentation without making the source code unreadable,
and at the same time something that can be converted to MathML
any time you want.
By the way, I wonder very much how much semantics people _are_
putting into their MathML? The INEX consortium of people doing
XML-based information retrieval have run into the problem that
there is very little semantic markup out there, so for getting
semantics out XML is *in practice as yet* little or no advance
on plain text. Even with an equation editor, writing formulas
on a computer is enough work that I'd expect people to do the
minimum they need for the immediate taste, even using MathML.
I don't have a body of MathML to examine, so I make no empirical
claim here, I just raise the question.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock Markup
On Fri, 2009-02-13 at 13:30 +1300, Richard O'Keefe wrote: Let's take this example from the web. math mrow msup mix/mimn2/mn /msup mo+/mo mrow mn4/mnmoInvisibleTimes;/momix/mi /mrow mo+/mo mn4/mn /mrow /math NB: This example is *precisely* why I will never adopt MathML as an authoring format. Bowing and scraping at the alter of W3C is not worth using such a terrible syntax, not ever. (Indented, that's math mrow msup mix/mi mn2/mn /msup mo+/mo mrow mn4/mn moInvisibleTimes;/mo mix/mi /mrow mo+/mo mn4/mn /mrow /math Which is still unforgivably horrible. I *think* it's trying to say $x^2 + 4x + 4$, but I'm not confident even of that. I'm also unconvinced it's actually easier to parse than $x^2 + 4x + 4$.) jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
If you have ideas for student projects that you think would benefit the Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterfaceib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_disclaimer=Tib_entity=llc [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords_Ref.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code 2009
If you have ideas for student projects that you think would benefit the Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterfaceib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_disclaimer=Tib_entity=llc [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords_Ref.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type families not as useful over functions
On Fri, 2009-02-13 at 11:15 +1100, John Ky wrote:
Hi Johnaton,
Ah yes. That makes sense. Is there a way to define type r to be all
types except functions?
Not without overlapping instances. I *think* if you turn on {-#
LANGUAGE OverlappingInstances #-} then
instance Broadcast r where
type Result = [r]
broadcast xn = xn
should do what you want (instance resolution delayed until r has a type
constructor at top level; this instance selected if no other instance is
in scope --- should be equivalent to r not a function type unless
someone else defines an instance!); but I know that's not a pretty way
of doing things.
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can this be done?
wren ng thornton w...@freegeek.org wrote in article 4993bbee.9070...@freegeek.org in gmane.comp.lang.haskell.cafe: It's ugly, but one option is to just reify your continuations as an ADT, where there are constructors for each function and fields for each variable that needs closing over. Serializing that ADT should be simple (unless some of those functions are higher-order in which case you run into the same problem of how to serialize the function arguments). In GHC's STG machine this representation shouldn't have much overhead, though it does require the developer to do the compiler's job. FWIW, this idea is called defunctionalization (due to Reynolds), and it works for higher-order functions as well (because you can defunctionalize those function arguments in the same way). People in many fields put a lot of effort into turning their programs into state machines... -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Attending a mathematics lecture is like walking through a thunderstorm at night. Most of the time you are lost, wet and miserable but at rare intervals there is a flash of lightening and the whole countryside is lit up. - Tom Koerner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Google Summer of Code 2009
So in general, think hard about missing capabilities in Haskell: * tools * libraries * infrastructure that benefit the broadest number of Haskell users or developers. Another route is to identify a clear niche where Haskell could leap ahead of the competition, with a small investment. -- Don One capability I would love to see as a SoC project is the ability to generate javascript (a small subset) as an additional output target from ghc. Something like this was already done with yhc herehttp://www.haskell.org/haskellwiki/Yhc/Javascriptbut if it could be ported to GHC and cabalized, this would really be a boon to the web dev community; javascript is quickly becoming one of the most predominant languages used for GUI creation (mainly via the web). -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type families not as useful over functions
My thoughts on type families: 1) Type families are often too open. I causes rigid variable type error messages because when I start writing open type functions, I often realize that what I really intend is not truly open type functions. It happens a lot that I had some assumptions on the arguments or the range of the type function. Then, we need help of type classes to constrain the result of open type functions. For example, try to define HList library using type families instead of type classes with functional dependencies. One will soon need some class constraints. Sometimes, we can use associated type families, but many times it may become tedious when there are multiple arguments and result have certain constraints so that we might end up associating/splitting them over multiple type classes. In such cases, it may be more simple working with functional dependencies alone, rather than using both type classes and type families. I wish we had closed kinds so that we can define closed type functions as well as open type functions. 2) Type families are not good when we need to match types back and forth (e.g. bijective functions), or even multiple ways. We need the help of functional dependencies for these relational definitions. I know that several people are working on the unified implementation for both type families and functional dependencies. Once GHC have common background implementation, type families will truly be syntactic sugar of type classes with functional dependencies, as Mark Jones advocates, or maybe the other way around too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Delimited continuations: please comment
Cristiano Paris cristiano.pa...@gmail.com wrote in article afc62ce20902120855i77acf725p1069aab21037a...@mail.gmail.com in gmane.comp.lang.haskell.cafe: In effect, this is a bit different from the syscall service routine described by Oleg, as the scheduler function reacts in different ways for subsequent calls (the first time feeds Hello!, the second one World!, in a nice monad style). Yet, I liked the separation between the scheduler and the job, which are two completely different values and which I tried to keep. It's not unheard of for the scheduler to react in different ways to the same system call -- I'm thinking of reading from a file, for example. As this is (almost) my first time using delconts, could you provide feedback, comments, opinions about my piece of code and the topic in general (convenience, performances, alternatives and so on)? You clearly understand the whole idea, and your code demonstrates it in a nice way. Oleg and I have found this programming style particularly convenient when we need to - fork processes (i.e., backtrack in the monad), - run the same processes under different schedulers (e.g., a debugger), - nest the applications of schedulers (i.e., provide virtualization). -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Attending a mathematics lecture is like walking through a thunderstorm at night. Most of the time you are lost, wet and miserable but at rare intervals there is a flash of lightening and the whole countryside is lit up. - Tom Koerner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can this be done?
On Thu, 2009-02-12 at 19:55 -0500, Chung-chieh Shan wrote: wren ng thornton w...@freegeek.org wrote in article 4993bbee.9070...@freegeek.org in gmane.comp.lang.haskell.cafe: It's ugly, but one option is to just reify your continuations as an ADT, where there are constructors for each function and fields for each variable that needs closing over. Serializing that ADT should be simple (unless some of those functions are higher-order in which case you run into the same problem of how to serialize the function arguments). In GHC's STG machine this representation shouldn't have much overhead, though it does require the developer to do the compiler's job. FWIW, this idea is called defunctionalization (due to Reynolds), and it works for higher-order functions as well (because you can defunctionalize those function arguments in the same way). People in many fields put a lot of effort into turning their programs into state machines... This paper by Ezra Cooper and Phil Wadler is an interesting recent development in the theory of defunctionalization and very relevant to this particular topic as well: http://homepages.inf.ed.ac.uk/wadler/topics/links.html#located-lambda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is this related to continuations somehow?
So, I was reading a bit about continuations the other day, and, since I've been thinking about good ways of expressing chess strategies in Haskell, I thought that I'd play around a bit with something like continuations for game-playing strategies. The idea is that you have combinators that allow you full access to the strategies which remain to be applied. In this way, strategies can activate and de-activate other strategies. Here's a simple little toy app for Tic-Tac-Toe (Naughts and Crosses): http://codepad.org/nN9JsxFK You can run main on 'example', and see that it searches every line and fails. And, as you can see, it aborts after finding a win in example2. This would be easily extensible to say things like if you've seen a blocking move, and you don't have a win, then play the blocking move, and of course the other deep intricacies of the game. My question is, is this, in fact, related to continuations somehow? Could continuations simplify it? Or am I doing something completely different? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Race condition possible?
On Thu, Feb 12, 2009 at 6:26 PM, Don Stewart d...@galois.com wrote: bugfact: Consider the following code stamp v x = do t - getCurrentTime putMVar v (x,t) Is it possible - with GHC - that a thread switch happens after the t - getCurrentTime and the putMVar v (x,t)? Yes. if 't' is heap allocated, there could be a context switch. If so, how would it be possible to make sure that the operation of reading the current time and writing the pair to the MVar is an atomic operation, in the sense that no thread switch can happen between the two? Would this require STM? Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or a modifyMVar in IO? As I understand it, withMVar or modifyMVar will protect you from extraneous exceptions, but they won't prevent another thread from writing to the MVar between the take and the put. -- 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
[Haskell-cafe] Re: Type families not as useful over functions
John Ky wrote: Is there a way to define type r to be all types except functions? Perhaps the following article How to write an instance for not-a-function http://okmij.org/ftp/Haskell/typecast.html#is-function-type answers your question. It shows several complete examples. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
+1 for some graphical tools for darcs, especially even a graphical merge tool (and a console/curses based version as well, to be sure). And +1 for darcs and xmonad applying as mentoring organizations in their own right. For that matter, it might be worthwhile for GHC to apply as well! That would ensure some dedicated compiler slots, and more could be contributed from the main haskell.org pool as appropriate. As well, I know that there's quite a nice new hackage2 almost rolled out, but I'm sure that there's at least an SoC project or two worth of feature additions to that as well. Off the top of my head, and bearing in mind that some might be further along than I think: a generalized way to search the package database, slicing and dicing by upload time, authors/maintainers, popularity, limiting views to packages that build on certain platforms, etc; some thought into security measures; a ratings system and associated reviews (thread/ wikibased); ways to mark packages as depreciated/for historic purposes. And there's bound to be more. As for numerics, I recall that Greg Wright, who knows whereof he speaks, had some particular issues that he thought no existing library addressed. I can't recall the details or do them justice, but perhaps he might care to enlighten us? Cheers, Sterl. On Feb 12, 2009, at 3:16 AM, Matthew Elder wrote: would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http:// tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don't want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com ___ 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] Is using Data.Dynamic considered a no-go?
SYB makes very heavy use of Typeable as well, although not, as I
recall dynamics as such.
Cheers,
Sterl.
On Feb 12, 2009, at 3:40 PM, Don Stewart wrote:
Notably, extensible exceptions use dynamics, in conjunction with type
classes and existentials.
A number of solutions to the 'expression problem' involve dynamics.
bugfact:
It would be interesting to see when you HAVE to use dynamics, e.g.
when no
other solution is possible in Haskell...
Right now if I use it, it feels that I'm doing so because I'm too
new to
Haskell.
On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson
lenn...@augustsson.net
wrote:
You're quite right. You should only be allowed to derive
Typeable.
(Which could be arranged by hiding the methods of typeable.)
On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive*
Typeable.
jcc
___
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
___
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] Type families not as useful over functions
Can you live with
infixl |$|
(|$|) :: [a - r] - a - [r]
fs |$| x = map ($ x) fs
and, instead of broadcast fs a b use
fs |$| a |$| b
?
map ($ x) fs
= { Applicative Functors satisfy... }
pure ($ x) * fs
= { 'interchange' rule from Control.Applicative }
fs * pure x
Thus;
fs |$| x === fs * pure x
fs |$| x |$| y === fs * pure x * pure y
- George
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
[Haskell-cafe] How to deal with utf-8?
Hi, I am using Text.CSV to read and using gtk2hs to display csv files using utf-8 encode. Well, it displays broken strings, seems like it cannot deal with utf-8. What should I do? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with utf-8?
On Fri, Feb 13, 2009 at 08:06, Magicloud magicloud.magiclo...@gmail.com wrote: Hi, I am using Text.CSV to read and using gtk2hs to display csv files using utf-8 encode. Well, it displays broken strings, seems like it cannot deal with utf-8. What should I do? You should try using functions from utf8-string package (find it on Hackage) to read UTF-8 encoded data. That's about reading data in. I'm not so sure however about the gtk2hs part. Experts should tell you if it is possible or not. (I think it is.) All best Christopher Skrzętnicki P.S. I think beginn...@haskell.org is a better place to ask such questions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
