[Haskell-cafe] instance MonadFix GenParser
I want to write a parser for a Haskell-like type language. Amongst
other things this means having a symbol table of top-level
declarations. So for instance I want to be able to write in my type
language:
type Foo = Bar Int
data Bar a = Bar String a
I can come up with a parser that identifies Bar in the type synonym as
the name of another type. I could define a type to return from the
parser which just has that as a string, but then I would have to write
another data type which is essentially the same but replaces the string
name with the actual data type, and a mapping function to use a symbol
table to convert one into the other, like this:
data ParsedTypeExpr = ParsedTypeExpr {parsedBaseType :: String,
parsedTypeArgs :: [String]}
data TypeExpr = TypeExpr {baseType :: MyType, typeArgs :: [String]}
convertTypeExpr :: (String - MyType) - ParsedTypeExpr - TypeExpr
I want to short-circuit this by looking up the definition of Bar in the
parser. But that requires the symbol table to exist during the parse.
I have to admit I haven't quite got my head around MonadFix yet, but if
I understand it correctly I should be able to have a top level parser
something like this:
parseDeclarations :: Parser [Declaration]
parseDeclarations = mdo
decls - many ParseDeclaration symbols
let symbols = makeSymbolTable decls
return decls
Unfortunately GenParser isn't an instance of MonadFix, so this won't work.
Is there a good reason why GenParser can't be an instance of MonadFix?
If not, what would the instance declaration be?
Thanks,
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance MonadFix GenParser
Oops. The last code sample should have been parseDeclarations :: Parser [Declaration] parseDeclarations = mdo decls - many ParseDeclaration symbols let symbols = makeSymbolTable decls return decls ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] pkgenv - disposable, isolated pkg environments
Hi all, I've been recently toying with a small tool inspired by the Python tool virtualenv [1]. What it basically allows to do is to setup isolated, disposable package environments. You can find a small session example in: http://www.haskell.org/haskellwiki/PkgEnv The main benefits should be: 1. allowing experimenting with package installations without polluting or breaking the default user package DB. When you're done you can simply remove the pkgenv directory = disposable 2. starting from a clean, fresh pkg configuration containing only system packages. This make cabal-install dependency analysis job much easier and predictable = isolated pkgenv now only runs on unix, even if it could be possible to port it to windows... To test it, download it from http://bitbucket.org/pao/pkgenv/raw/488bfe8e58dd/pkgenv chmod a+x and drop to an executable directory. Any feedback would be really appreciated. Is this useful at all? Are there better ways to reach the same goals? Pao 1. http://pypi.python.org/pypi/virtualenv ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking StateTs
test3 :: MonadState Integer m = String - m String Good point. It's interesting that this allows the signature of test5b to become MonadState Integer m = m Integer (instead of (Monad m) = StateT Integer (StateT String m) Integer) which is more general, and (surprisingly to me) does not mention String. Thank! Luis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] jhc speed
Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Such a factoring would be one way the community could help, and if successful, it would allow you to better focus on the really important stuff. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 20, 2009, at 4:14 PM, John Meacham wrote: On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote: On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote: Hello John, Saturday, February 21, 2009, 1:33:12 AM, you wrote: Don't forget jhc: i was pretty sure that jhc will be as fast as gcc :) unfortunately, jhc isn't our production compiler Why not? There's nothing stopping you from choosing any Haskell compiler you like. If jhc gives you the performance you need – use it. Heh. He probably meant something more like jhc is not a production compiler which is true for a lot of projects. For projects of substantial size or that require many extensions, jhc falls somewhat short. It is getting better though. Of course, help is always appreciated. :) John -- John Meacham - ⑆repetae.net⑆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] jhc speed
Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Most likely this is nice in theory but hard in practice? On Sun, Feb 22, 2009 at 3:25 PM, John A. De Goes j...@n-brain.net wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Such a factoring would be one way the community could help, and if successful, it would allow you to better focus on the really important stuff. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 20, 2009, at 4:14 PM, John Meacham wrote: On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote: On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote: Hello John, Saturday, February 21, 2009, 1:33:12 AM, you wrote: Don't forget jhc: i was pretty sure that jhc will be as fast as gcc :) unfortunately, jhc isn't our production compiler Why not? There's nothing stopping you from choosing any Haskell compiler you like. If jhc gives you the performance you need – use it. Heh. He probably meant something more like jhc is not a production compiler which is true for a lot of projects. For projects of substantial size or that require many extensions, jhc falls somewhat short. It is getting better though. Of course, help is always appreciated. :) John -- John Meacham - ⑆repetae.net⑆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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Well, it wouldn't really be useful sandwiched between the front and back end of ghc, the main advantages jhc has over ghc's model are in its lower level optimizations closer to the back end. Feeding ghc core into jhc shouldn't be impossible. Oddly enough, I have written a ghc back end for jhc, mainly for testing purposes rather than a serious back end. The tricky part isn't so much the translation of ghc to jhc core, the type system and representation are quite similar, but the difference in the primitives that the two systems expect to exist. for instance, ghc has high level primitives, such as operations on Integers and primitive types that high signedness. While jhcs primitives are much lower level, it has no special concept of Integer for instance, you implement Integer either in pure haskell code or FFI bindings to GMP or some other way, and jhc's primitive numerical types are simply bit patterns with no interpretation, for instance data Int = I Bits32_ data Word = W Bits32_ and the only thing that makes Int signed and Word not is in the 'Num' instances for those types. That said, i don't see any reason a ghc-core front end for jhc wouldn't be possible, an adapter library could be written to provide ghc style primitives on top of the jhc ones. It would certainly be an interesting project. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance MonadFix GenParser
On Sun, Feb 22, 2009 at 3:31 AM, Paul Johnson p...@cogito.org.uk wrote: parseDeclarations :: Parser [Declaration] parseDeclarations = mdo decls - many ParseDeclaration symbols let symbols = makeSymbolTable decls return decls Given a MonadFix instance, keep in mind that you should do this only if the success of the parse does not depend in any way on the symbol table -- otherwise you will be in bottom city. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 8:15 AM, John Meacham j...@repetae.net wrote: On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. By the way, coming up pretty soon, I will need a desugared *annotated*Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆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] jhc speed
I think doing this work would improve the design of GHC by improving modularity and factoring out generalized abstractions. The richest possible core language makes the most sense for a common core, because what's not needed can always be discarded. From your description, it sounds like such a common core language would be a hybrid of jhc and ghc core, because each contains more information for particular subsets of the language. Layering higher-level primitives on lower-level primitives also makes sense, as it's a very flexible approach. How much support and direction can you provide if we get enough people interested in this? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 22, 2009, at 7:45 AM, John Meacham wrote: On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Well, it wouldn't really be useful sandwiched between the front and back end of ghc, the main advantages jhc has over ghc's model are in its lower level optimizations closer to the back end. Feeding ghc core into jhc shouldn't be impossible. Oddly enough, I have written a ghc back end for jhc, mainly for testing purposes rather than a serious back end. The tricky part isn't so much the translation of ghc to jhc core, the type system and representation are quite similar, but the difference in the primitives that the two systems expect to exist. for instance, ghc has high level primitives, such as operations on Integers and primitive types that high signedness. While jhcs primitives are much lower level, it has no special concept of Integer for instance, you implement Integer either in pure haskell code or FFI bindings to GMP or some other way, and jhc's primitive numerical types are simply bit patterns with no interpretation, for instance data Int = I Bits32_ data Word = W Bits32_ and the only thing that makes Int signed and Word not is in the 'Num' instances for those types. That said, i don't see any reason a ghc-core front end for jhc wouldn't be possible, an adapter library could be written to provide ghc style primitives on top of the jhc ones. It would certainly be an interesting project. John -- John Meacham - ⑆repetae.net⑆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] pkgenv - disposable, isolated pkg environments
On Sun, 2009-02-22 at 13:22 +0100, Paolo Losi wrote: To test it, download it from http://bitbucket.org/pao/pkgenv/raw/488bfe8e58dd/pkgenv chmod a+x and drop to an executable directory. Any feedback would be really appreciated. Is this useful at all? Are there better ways to reach the same goals? Would it be useful to have cabal-install check a env var for its config file? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[haskell-cafe] Finding a PID in Windows
Quick question. In Linux, if you want to find the PID of a process, you use getProcessID from System.Posix.Process. How do you do the same under Windows? I cannot find the equivalent function in System.Win32 and searching Google does not yield any useful results. Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Finding a PID in Windows
Hello Alexandru, Sunday, February 22, 2009, 7:38:31 PM, you wrote: In Linux, if you want to find the PID of a process, you use getProcessID from The GetCurrentProcessId function returns the process identifier of the calling process. DWORD GetCurrentProcessId(VOID) you need to make FFI import yourself. look Win32 package sources for examples of how to do it. in this case: foreign import stdcall unsafe winbase.h GetCurrentProcessId c_GetCurrentProcessId :: IO DWORD if you are going to use win32 system calls, i recommend you to find helpfiles from win32 sdk, they contain all those info. or you may use msdn on the web and search there -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pkgenv - disposable, isolated pkg environments
Duncan Coutts wrote: Would it be useful to have cabal-install check a env var for its config file? Definitely yes. This would allow dropping the dependency on bash aliasing and make porting to Windows fairly easy. Thanks Paolo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking StateTs
On Sun, Feb 22, 2009 at 9:20 AM, Luis O'Shea los...@gmail.com wrote: test3 :: MonadState Integer m = String - m String Good point. It's interesting that this allows the signature of test5b to become MonadState Integer m = m Integer (instead of (Monad m) = StateT Integer (StateT String m) Integer) which is more general, and (surprisingly to me) does not mention String. Odd. If I break up test5b like so: test5b = flip execStateT 0 . flip evalStateT $ test5bImpl test5bImpl = do modifyM test3 lift . modify $ \x - x*2 + 1 modifyM test3 lift . modify $ \x - x*x modifyM test3 and ask GHCi for the types, I get: *Main :t test5bImpl test5bImpl :: (MonadState Integer m) = StateT String m () *Main :t test5b test5b :: (Monad m) = m Integer -- 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: [Haskell] ANNOUNCE: X Haskell Bindings 0.2
Felipe Lessa felipe.le...@gmail.com wrote: On Sun, Feb 22, 2009 at 2:08 AM, Antoine Latter aslat...@gmail.com wrote: The goal of XHB is to provide a Haskell implementation of the X11 wire protocol, similar in spirit to the X protocol C-language Binding (XCB). [snip] Related projects: X C Bindings: http://xcb.freedesktop.org/ I wonder how XHB is related to Xmonad, specially the need for compositing. Sorry if this is a dumb question :). It could be used for it. I once thought of hacking away on exactly that, but got demotivated by the fact that all that xlib code would have to be replaced (including xmonad-contrib). While nowadays xlib programs are compatible with xcb, because xlib itself is now based on xcb, the haskell xlib bindings aren't based on xhb... we'd need xcb bindings, which kinda defeats the purpose of xhb. Then there's of xcompmgr, which works fine enough for what I want to have, and I fail to come up with any useful application of compositing in a twm in addition to transparency for focus indication. OTOH, writing a separate compositing manager using xhb is certainly possible, fits better into the UNIX world, and would, most likely, be easily be snarfed into xmonad in case it's going to happen to be ported over to xhb. If you want to know how, have a look at the xcompmgr sources, it's straight forward. -- (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] Stacking StateTs
Am Sonntag, 22. Februar 2009 18:53 schrieb David Menendez: On Sun, Feb 22, 2009 at 9:20 AM, Luis O'Shea los...@gmail.com wrote: test3 :: MonadState Integer m = String - m String Good point. It's interesting that this allows the signature of test5b to become MonadState Integer m = m Integer (instead of (Monad m) = StateT Integer (StateT String m) Integer) which is more general, and (surprisingly to me) does not mention String. Odd. If I break up test5b like so: test5b = flip execStateT 0 . flip evalStateT $ test5bImpl test5bImpl = do modifyM test3 lift . modify $ \x - x*2 + 1 modifyM test3 lift . modify $ \x - x*x modifyM test3 and ask GHCi for the types, I get: *Main :t test5bImpl test5bImpl :: (MonadState Integer m) = StateT String m () *Main :t test5b test5b :: (Monad m) = m Integer Okay, you've found a bug in the type checker, 6.4.2 infers the types test5b :: (Monad (StateT [Char] (StateT s m)), MonadState s (StateT s m), Num s, Monad m) = m s test5bImpl :: (Monad (StateT [Char] m), MonadState s m, Num s) = StateT [Char] m () as does 6.6.1. That does look more reasonable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking StateTs
On Sun, Feb 22, 2009 at 3:17 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: test5b :: (Monad (StateT [Char] (StateT s m)), MonadState s (StateT s m), Num s, Monad m) = m s Doesn't 'Monad m' imply 'MonadState s (StateT s m)' which implies 'Monad (StateT s m)' which implies 'Monad (StateT [Char] (StateT s m))'? This signature could be simplified to just test5b :: (Num s, Monad m) = m s test5bImpl :: (Monad (StateT [Char] m), MonadState s m, Num s) = StateT [Char] m () Here 'MonadState s m' implies 'Monad m' which implies 'Monad (StateT [Char] m)', simplifying the signature to test5bImpl :: (Num s, MonadState s m) = StateT [Char] m () Now, note that Menendez' signatures didn't have 'Num s' because a type signature was given to 'test3' forcing the number to be Integer. If you remove all type signatures (and the monomorphism restriction), GHC 6.10 infers modifyM :: (Monad m) = (s - m s) - StateT s m () test3 :: (Num s, MonadState s m) = [Char] - m [Char] test5b :: (Num b, Monad m) = m b test5b' :: (Num b, Monad m) = m b impl :: (Num s, MonadState s m) = StateT [Char] m () Did I make any mistakes? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pkgenv - disposable, isolated pkg environments
On Sun, 2009-02-22 at 18:38 +0100, Paolo Losi wrote: Duncan Coutts wrote: Would it be useful to have cabal-install check a env var for its config file? Definitely yes. This would allow dropping the dependency on bash aliasing and make porting to Windows fairly easy. Ok, I've filed a ticket so hopefully someone will pick it up. It should be pretty easy. Just a few lines of code. http://hackage.haskell.org/trac/hackage/ticket/505 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking StateTs
Am Sonntag, 22. Februar 2009 19:29 schrieb Felipe Lessa: Did I make any mistakes? No, I did. I didn't read it properly, saw the MonadState s ... there and thought it was MonadState s m instead of MonadState s (StateT s m). Sorry, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Practise of hiding contsructors and serialization
While working on extending scion I got some trouble and wonder which is
the best way to do this?
I have to pass a compilation result from a scion process instance to the
scion daemon process. Of course I'd just like to use a simple Read Show
for that. However I can't because two datatypes are NominalDiffTime and
Bag ErrMsg:
newtype NominalDiffTime = MkNominalDiffTime Pico deriving (Eq,Ord)
data ErrMsg = ErrMsg {
errMsgSpans :: [SrcSpan],
errMsgContext :: PrintUnqualified,
errMsgShortDoc :: Message,
errMsgExtraInfo :: Message
}
Both are fine and both don't export all contstructors so you can't just
let ghc derive instances for it?
So the only way is to duplicate those datatypes in order to derive some
Show, Read instances?
On the one hand I do understand that you don't want users to access
constructors directly. On the other hand it would be desirable to derive
Read, Show instances here.
Is there a way to get all?
a) hiding constructors so that you don't have to expose implementation
details to the user.
b) still allow deriving serialization instances?
Is there a better way than using toRational to get a type which can be
serialzied quickly? I don't like Rational because the unit information
1e-12[s] is no longer included in the type..
Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Practise of hiding contsructors and serialization
On Sun, Feb 22, 2009 at 12:55 PM, Marc Weber marco-owe...@gmx.de wrote:
While working on extending scion I got some trouble and wonder which is
the best way to do this?
I have to pass a compilation result from a scion process instance to the
scion daemon process. Of course I'd just like to use a simple Read Show
for that. However I can't because two datatypes are NominalDiffTime and
Bag ErrMsg:
newtype NominalDiffTime = MkNominalDiffTime Pico deriving (Eq,Ord)
data ErrMsg = ErrMsg {
errMsgSpans :: [SrcSpan],
errMsgContext :: PrintUnqualified,
errMsgShortDoc :: Message,
errMsgExtraInfo :: Message
}
Both are fine and both don't export all contstructors so you can't just
let ghc derive instances for it?
So the only way is to duplicate those datatypes in order to derive some
Show, Read instances?
On the one hand I do understand that you don't want users to access
constructors directly. On the other hand it would be desirable to derive
Read, Show instances here.
Is there a way to get all?
a) hiding constructors so that you don't have to expose implementation
details to the user.
b) still allow deriving serialization instances?
I usually use Data.Binary for serialization. There is a cultural standard
not to do anything with Binary instances other than to pass the result of
encode to decode. They are opaque blobs of bits, perfect for
serialization.
(I think the only righter way would be to pass the information over a typed
channel that respected privacy)
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: X Haskell Bindings 0.2
On Sun, Feb 22, 2009 at 11:58 AM, Achim Schneider bars...@web.de wrote: I once thought of hacking away on exactly that, but got demotivated by the fact that all that xlib code would have to be replaced (including xmonad-contrib). While nowadays xlib programs are compatible with xcb, because xlib itself is now based on xcb, the haskell xlib bindings aren't based on xhb... we'd need xcb bindings, which kinda defeats the purpose of xhb. xlib is based on xcb in the sense that libxcb owns the conection, and xlib takes it when it wants it. This approach has recently been generalized, so it should be possible (in principle) for XHB to ride on top of libxcb in the same way: http://lists.freedesktop.org/archives/xcb/2008-March/003347.html But I haven't looked into this approach too deeply, though. Questions I don't have answers to: + How do I get events/errors back into Haskell-land? + How do I get my FFI bindings to xlib to cooperate in all of this? But it would be great if we could use native Haskell where we can, but still call into C-libs where we can't. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle and Network.Socket
Hi I don't want to get in to a platform war (which I certainly don't have time to engage in - plus its not nearly as much fun over email vs sitting in a pub with some beer having a platform war). Martijn's thoughts of +windows, +unix, +os is exactly right, I'm happy to let users say oh, please show me these packages, but there are trade-offs in Hoogle design. If someone has some clear viewpoint on the answers, I'd love to hear them. The three problems are: 1) What packages should Hoogle search by default? All of hackage? The base libraries? Only the packages a user has installed? Only packages that make it in to the Haskell Platform? 2) What groups of packages should Hoogle have available? Each package individually? All packages which compile on Windows? All packages by a certain author? All packages whose minor version number is even? 3) What UI should Hoogle show? Should there be checkboxes for each os's package? Should their be a checkbox for each compiler/version? Should their be no UI but some documentation? And the trade offs are: 1) The packages have to be divided under sensible and clear lines - I don't want to (and shouldn't) arbitrate divisions like good or popular. 2) The more packages you search, the less relevant the results will be. 3) The fewer packages you search, the more chance that you miss something. 4) The more UI that is added the more confusing things get. 5) My development time for Hoogle derives Bounded, Finite and increasingly also derives Small. Thoughts and suggestions welcome. I've set up a wiki page to track peoples thoughts, so if you want to comment on the list it might be best to summarise your final thoughts on the page too: http://haskell.org/haskellwiki/Hoogle/Packages Thanks Neil On Sun, Feb 22, 2009 at 4:38 AM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: John A. De Goes: I think the (valid) concern is that too many people are choosing platform-specific packages when there are alternatives available (albeit not as convenient in some cases), and this really hurts the Windows community because Windows is so radically different from all the other operating systems. Its apparent that Neil has the legitimate concern of general purpose libraries becoming or being built on platform specific pieces - a situation I also want to avoid seeing as I work on three different platforms. The point I'm trying to make is that some programs and libraries perform platform specific taskes and that's ok - there is no loss of portability because it wouldn't make sense to port them anyway. Examples include Debian/Arch packaging, X.org bindings / Window Managers, Xen system call bindings, etc. Tom ___ 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] Hoogle and Network.Socket
sitting in a pub with some beer having a platform war). Martijn's thoughts of +windows, +unix, +os is exactly right, I'm happy to let users say oh, please show me these packages, but there are trade-offs in Hoogle design. If someone has some clear viewpoint on the answers, I'd love to hear them. The three problems are: 1) What packages should Hoogle search by default? All of hackage? The base libraries? Only the packages a user has installed? Only packages that make it in to the Haskell Platform? Why not make that configurable, similar to trac's custom queries, defining several default configurations with short names (+windows, +hackage, +hp, ..), rather than trying to define one default config? The kinds of configuration option available could be taken from information available to hackage/cabal (which presumably will specify/show platforms at some point). Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle and Network.Socket
On Sun, Feb 22, 2009 at 1:04 PM, Neil Mitchell ndmitch...@gmail.com wrote: 1) What packages should Hoogle search by default? At the very least - all of the Haskell Platform. If/when it searches more (+hackage flag?), perhaps the results could be ordered to place the HP functions first. 2) What groups of packages should Hoogle have available? Each package individually? All packages which compile on Windows? All packages by a certain author? All packages whose minor version number is even? All of the most recent packages on hackage should be indexed by Hoogle. 3) What UI should Hoogle show? For local installs (command line) basic --help documentation and flags/switches should do. Flags such as +windows +nix +osx etc would be fine by me. For a web GUI I care less, but feel that even if check-boxes exist the flags should still work (for using hoogle in the search bar). I still prefer showing all platform results sorted into separate sections with headers, but understand that I am in the minority. And the trade offs are: 1) The packages have to be divided under sensible and clear lines - I don't want to (and shouldn't) arbitrate divisions like good or popular. Agreed - and this is why a division between the HP and all of hackage is good - it seems to be a reasonable and natural division that the community will already deal with. 2) The more packages you search, the less relevant the results will be. But searches can still be organized - such as my suggestion placing the HP results first. 4) The more UI that is added the more confusing things get. In this proposal I have advocated or backed: +windows +nix +osx +hackage Which means there are only five flags I'd care about with hoogle (counting +network) - I feel that is reasonable. 5) My development time for Hoogle derives Bounded, Finite and increasingly also derives Small. Right - and I continue to appreciate the time you do donate. Going to add some to that wiki now. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Fri, 20 Feb 2009, Louis Wasserman wrote: Hmmm. That's probably a better framework to draw on for the general array interface. For a list of all such low-level arrays, see: http://www.haskell.org/haskellwiki/Storable_Vector StorableVectors can also be manipulated in ST monad.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error on instance of Control.Exception.Exception
Hi, I read here: www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html that this is declared: --- class (Typeable e, Show e) = Exception e where toException :: e - SomeException fromException :: SomeException - Maybe e --- I understand this means Excepton is a class. But after I try: --- instance Exception DbError where --- GHC says: Type constructor `Exception' used as a class In the instance declaration for `Exception DbError' Isn't Exception a class? If it is, what is the proper way to have an Exception instance for my type? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error on instance of Control.Exception.Exception
On Sun, Feb 22, 2009 at 9:41 PM, Maurício briqueabra...@yahoo.com wrote: www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html These are the docs for the latest GHC version. Type constructor `Exception' used as a class In the instance declaration for `Exception DbError' What GHC version do you have? Old base packages ( 4, IIRC) don't have extensible exceptions and 'Exception' is just an ADT. HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Practise of hiding contsructors and serialization
I usually use Data.Binary for serialization. Sure. But you can't derive Data.Binary easily for NominalDiffTime. That's the point. You can only do so by using toReal or by adding data MyOwnPico = MyOwnPico only to create serialization instances. I don't like this kind of code duplication.. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Practise of hiding contsructors and serialization
On Sun, Feb 22, 2009 at 5:23 PM, Marc Weber marco-owe...@gmx.de wrote: I usually use Data.Binary for serialization. Sure. But you can't derive Data.Binary easily for NominalDiffTime. That's the point. You can only do so by using toReal or by adding data MyOwnPico = MyOwnPico only to create serialization instances. I don't like this kind of code duplication.. Marc One advantage of the current system is that is preserves data abstraction. For example, right now NominalDiffTime is declared newtype NominalDiffTime = MkNominalDiffTime Pico so it would be possible for GHC or another automated tool to derive an instance of Read, Show, Binary, whatever for it. However, what if, in the future, the maintainer of the Time library wanted to change this to newtype NominalDiffTime = MkNominalDiffTime Double ? Now your derived instance wouldn't be the same, so your serialized data would not be compatible even between the same version of your library even if the version of your library stayed the same because the time library version had same. Even worse, what if the Time library maintainer changed it to newtype NominalDiffTime = MkNominalDiffTime (Int - Pico) ? Now you can't make a derived instance at all! There's no really good reason why they would make these changes; it seems reasonable that the Time library will stay in much the same form for the forseeable future. However, the whole point of abstract datatypes is that the maintainer can change the internals without disrupting dependent packages, as long as the accessor functions has the same semantics. In order for this to work, you can't have any external code - even derived instances - relying on the internal structure of abstract datatypes. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: cabal-install and bash scripts in windows- Was: Re: pkgenv - disposable, isolated pkg environments
Forwarded to the list: By the way, there are important packages such are haskell plugins, that have also this same single obstacle for workining under Windows. Many have basically the same bash script that test the type of c compiler, which fails miserably under windows: example output: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. cabal: Error: some packages failed to install: plugins-1.4.0 failed during the configure step. The exception was: exit: ExitFailure 77 Could be possible to check if this problem can be solved with cabal-install?. 2009/2/22 Duncan Coutts duncan.cou...@worc.ox.ac.uk On Sun, 2009-02-22 at 18:38 +0100, Paolo Losi wrote: Duncan Coutts wrote: Would it be useful to have cabal-install check a env var for its config file? Definitely yes. This would allow dropping the dependency on bash aliasing and make porting to Windows fairly easy. Ok, I've filed a ticket so hopefully someone will pick it up. It should be pretty easy. Just a few lines of code. http://hackage.haskell.org/trac/hackage/ticket/505 Duncan ___ 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
