Re: [Haskell-cafe] QuickCheck
2008/3/16 Sebastian Sylvan [EMAIL PROTECTED]: featureGenNormal = do id - stringGen name - stringGen featuretype - arbitrary grouptype - arbitrary children - arbitrary properties - listGen stringGen return (Feature id name featuretype grouptype children properties) Note that we use arbitrary to generate the list of children recursively. Also, you can shorten this significantly with liftM or ap (from Control.Monad): featureGenNormal = liftM6 Feature stringGen stringGen arbitrary arbitrary arbitrary (listGen stringGen) featureGenNormal = return Feature `ap` stringGen `ap` stringGen `ap` arbitrary `ap` arbitrary `ap` listGen stringGen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building HaXML 1.13.3 on Windows fails
Dusan Kolar [EMAIL PROTECTED] wrote: I'm trying to build HaXML 1.13.3 on Windows using build.bat $ ghc-pkg register pkg.conf Reading package info from pkg.conf ... ghc-pkg.exe: Line 68: The field main-is was already defined on line 62 Taking a look into the pkg.conf says there are several lines main-is. I'm using ghc 6.6 to build the stuff. What shall I do? Try deleting all of the executable stanzas from the pkg.conf file. When the library is being registered with ghc, these are not needed anyway. (I am not sure why ghc-pkg-6.6 rejects them, rather than ignoring them.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck
Sebastian Sylvan: featureGenNormal = do id - stringGen name - stringGen featuretype - arbitrary grouptype - arbitrary children - arbitrary properties - listGen stringGen return (Feature id name featuretype grouptype children properties) Ryan Ingram wrote: Also, you can shorten this significantly with liftM or ap (from Control.Monad): True, but in this case I like being able to see meaningful names for each parameter of the constructor. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building HaXML 1.13.3 on Windows fails
Hello all, I'm trying to build HaXML 1.13.3 on Windows using build.bat - I have modified it even on places referred as should work (SRCS and OBJS variables); now it works till the last command: ghc-pkg register pkg.conf The error is: Reading package info from pkg.conf ... ghc-pkg.exe: Line 68: The field main-is was already defined on line 62 Taking a look into the pkg.conf says there are several lines main-is. I'm using ghc 6.6 to build the stuff. What shall I do? Thanks and regards, Dusan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
Hi Adam, sorry for late answer. Here is my example [1], but yours doesn't work on my PC too. And it's strange it works on yours. According to documentation for Control.Concurrent module [2] every other thread should be blocked. With the -threaded option, only foreign calls with the unsafe attribute will block all other threads. And after changing in the network package FFI declaration for c_recvfrom from unsafe to safe both examples start working. There are two solutions I see now. The first is to copy-paste definitions from the network package to mine with changing unsafe to safe for FFI declaration. The second is to use unblocking sockets. This by the way will help to get rid of hack-like solution of stopping server by closing listening socket, but it will get more effort. [1] http://hpaste.org/6426 [2] http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4 2008/3/14, Adam Langley [EMAIL PROTECTED]: On Fri, Mar 14, 2008 at 8:51 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. Then everything should Just Work(tm). You might need to paste in code in order to figure out why this wouldn't be so. See [1] for an example which works for me. It starts a thread which prints working... once a second and, in another thread, listens for UDP packets on port 4112. I can use `nc -u 127.0.0.1 4112` to get this: working... working... (testing\n,8,127.0.0.1:36179) working... working... (testing two\n,12,127.0.0.1:36179) working... [1] http://hpaste.org/6362 -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck
Hi all, Is it possible to define a limit for the size of children list bellow? I've tried: children - resize (10 (listGen featureGenNormal)) But it didn't work. Thanks a lot, Rodrigo. Sebastian Sylvan: featureGenNormal = do id - stringGen name - stringGen featuretype - arbitrary grouptype - arbitrary children - arbitrary properties - listGen stringGen return (Feature id name featuretype grouptype children properties) Ryan Ingram wrote: Also, you can shorten this significantly with liftM or ap (from Control.Monad): True, but in this case I like being able to see meaningful names for each parameter of the constructor. --- Rodrigo Bonifácio de Almeida Universidade Católica de Brasília - Grupo de Engenharia de Software - JavaComBr (www.ucb.br/java) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck
On Mon, 17 Mar 2008, rodrigo.bonifacio wrote: Hi all, Is it possible to define a limit for the size of children list bellow? take 10 ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck
On 17 mar 2008, at 14.37, rodrigo.bonifacio wrote: Hi all, Is it possible to define a limit for the size of children list bellow? I've tried: children - resize (10 (listGen featureGenNormal)) You are calling a number as a function. Also, listGen has to use the size argument. Try something like (not tested): listGen = sized (\maxSize - do n - arbitrary x - g xs - frequency [ (1, return []), (n, listGen g) ] return (x:xs) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 55, Issue 20
Thanks Sterl, you're right, this was because I have don´t compiled with the -threaded flag, this works fine now. This answer may be way off base, but if differences appear between ghci and compiled versions, I've often found its as simple as remembering to compile with the -threaded flag. The ghci runtime is threaded by default, as I understand it, while compiled binaries are not, and IO operations will block in very different fashions (i.e. in their own thread, or stalling the entire app) depending on the runtime. Regards, sterl. Alvaro __ ¿Con Mascota por primera vez? Sé un mejor Amigo. Entra en Yahoo! Respuestas http://es.answers.yahoo.com/info/welcome___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2
I'm pleased to announce a new release for the haskell-src-exts package. Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src-exts Cheers, /Niklas haskell-src-exts 0.3.2 === haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy = 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal = 1.2 Patches are more than welcome. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2-level type analysis of introducing naming into data types
2008/3/15 Greg Meredith [EMAIL PROTECTED]: All, The following Haskell code gives a 2-level type analysis of a functorial approach to introducing naming and name management into a given (recursive) data type. The analysis is performed by means of an What's the upshot of this? That is, what does this analysis give you? I mostly follow the argument but I don't understand the benefits. I feel like I'm missing something. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and getCookies
On Sun, Mar 16, 2008 at 10:21 AM, Adam Smyczek [EMAIL PROTECTED] wrote: Somehow I cannot get cookies from the Response using Network.Browser module (HTTP 3001.0.4). The cookie header part seams to be empty and getCookies returns empty list as well. Network.Browser comes with a built-in HTTP trace facility - I'd first make sure you are getting the HTTP responses you expect. I believe it's setErrHandler and setDebugHandler - use putStrLn to get a trace of HTTP traffic on your console. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need Cabal/library building help for windows
For reference, I'm using GHC6.8.1 on WinXP. I'm trying to package up some code into a library. But cabal fails to configure my project: runhaskell setup.hs configure Configuring Prompt-1.0... setup.hs: ld is required but it could not be found. Prompt.cabal contains: name:Prompt version: 1.0 cabal-version: = 1.2 build-type: Simple library exposed-modules: Control.Monad.Prompt Does GHC require additional tools in order to build libraries on Win32? If so, I hope this can be remedied; it builds executables without additional tools after all. What do I need to do next? -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Wed, Mar 12, 2008 at 9:27 PM, Don Stewart [EMAIL PROTECTED] wrote:
You could consider binding directly to the C functions, if needed,
{-# OPTIONS -fffi -#include math.h #-}
import Foreign.C.Types
foreign import ccall unsafe math.h log10
c_log10 :: CDouble - CDouble
log10 :: Double - Double
log10 x = realToFrac (c_log10 (realToFrac x))
Actually, you could almost certainly just use
foreign import ccall unsafe math.h log10 log10 :: Double - Double
since in ghc CDouble and Double are identical.
It's a bit sloppier, but shouldn't cause any trouble. And I've no
idea how realToFrac is implemented, but would worry about it behaving
oddly... for instance when given NaNs.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] floating point operations and representation
Hello David, Monday, March 17, 2008, 7:59:09 PM, you wrote: foreign import ccall unsafe math.h log10 c_log10 :: CDouble - CDouble log10 :: Double - Double log10 x = realToFrac (c_log10 (realToFrac x)) It's a bit sloppier, but shouldn't cause any trouble. And I've no idea how realToFrac is implemented, but would worry about it behaving oddly... for instance when given NaNs. it should be nop (no operation) in such cases -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
On Mon, Mar 17, 2008 at 2:29 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: Hi Adam, sorry for late answer. Here is my example [1], but yours doesn't work on my PC too. And it's strange it works on yours. Are you running Windows? Because you're hpaste example works, nonblocking for me too. And after changing in the network package FFI declaration for c_recvfrom from unsafe to safe both examples start working. The important point here is that the recvFrom calls in Network.Socket[1] don't block. They are non-blocking calls so, although other threads may be suspended while in the FFI call, the FFI call returns -EAGAIN if it would block and blocking is passed to the RTS to handle. While sleeping in the RTS (with threadWaitRead etc), other Haskell threads can read. See the code in [1] (esp throwErrnoIfMinus1Retry_repeatOnBlock) So, the only reason that other threads would be blocked is if the socket wasn't marked as non-blocking. Here's a snippet of strace output from compiling your hpaste example: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 You can see that the socket is set to non-blocking immediately. [1] http://haskell.org/ghc/docs/latest/html/libraries/network/src/Network-Socket.html#recvFrom -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On 17 Mar 2008, [EMAIL PROTECTED] wrote: Hello David, Monday, March 17, 2008, 7:59:09 PM, you wrote: foreign import ccall unsafe math.h log10 c_log10 :: CDouble - CDouble log10 :: Double - Double log10 x = realToFrac (c_log10 (realToFrac x)) It's a bit sloppier, but shouldn't cause any trouble. And I've no idea how realToFrac is implemented, but would worry about it behaving oddly... for instance when given NaNs. it should be nop (no operation) in such cases A related issue: http://hackage.haskell.org/trac/ghc/ticket/2110 Presumably everyone is aware of decodeFloat :: (RealFloat a) = a - (Integer, Int) which really is a canonical representation of a floating point number. As for realToFrac, this really isn't okay: *GHCi 0/0 NaN *GHCi realToFrac (0/0) -Infinity Also, this one might surprise a few people. *GHCi realToFrac (realToFrac 0.2 :: Ratio Int) -Infinity *GHCi realToFrac 0.2 :: Ratio Int (-858993459)%0 Jed pgpkz5RfasGnc.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
daveroundy:
On Wed, Mar 12, 2008 at 9:27 PM, Don Stewart [EMAIL PROTECTED] wrote:
You could consider binding directly to the C functions, if needed,
{-# OPTIONS -fffi -#include math.h #-}
import Foreign.C.Types
foreign import ccall unsafe math.h log10
c_log10 :: CDouble - CDouble
log10 :: Double - Double
log10 x = realToFrac (c_log10 (realToFrac x))
Actually, you could almost certainly just use
foreign import ccall unsafe math.h log10 log10 :: Double - Double
since in ghc CDouble and Double are identical.
It's a bit sloppier, but shouldn't cause any trouble. And I've no
idea how realToFrac is implemented, but would worry about it behaving
oddly... for instance when given NaNs.
It's a no-op (from the core I was looking at), and then you're not worrying
about coercing newtypes.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck
On Mon, Mar 17, 2008 at 1:54 PM, Thomas Schilling [EMAIL PROTECTED] wrote: On 17 mar 2008, at 14.37, rodrigo.bonifacio wrote: Hi all, Is it possible to define a limit for the size of children list bellow? I've tried: children - resize (10 (listGen featureGenNormal)) You are calling a number as a function. Also, listGen has to use the size argument. Try something like (not tested): listGen = sized (\maxSize - do n - arbitrary x - g xs - frequency [ (1, return []), (n, listGen g) ] return (x:xs) In retrospect, this function isn't very good at all, because it never generates the empty list... Something like this is probably better (untested): listGen g = sized (\maxSize - do count - choose (0, maxSize - 1) replicateM count g ) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Mon, Mar 17, 2008 at 12:59:09PM -0400, David Roundy wrote: foreign import ccall unsafe math.h log10 log10 :: Double - Double since in ghc CDouble and Double are identical. It's a bit sloppier, but shouldn't cause any trouble. And I've no idea how realToFrac is implemented, but would worry about it behaving oddly... for instance when given NaNs. Yes. 'realToFrac' is inherently pretty broken and should be avoided whenever possible. It is not all all obvious to me what the correct primitive should be.. but we really should do something better for haskell'. relying on RULES firing as ghc currently does doesn't seem ideal.. hmm.. maybe a 'FloatMax' type and have 'fromFloatMax' and 'toFloatMax' in 'Fractional' and 'Real' respectively? hmm.. hc has 'fromDouble' and 'toDouble' there, but jhc also supports a 'Float128' type (when the underlying hardware does). so this still isn't quite right. 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] STM example code
2008/3/9 Galchin Vasili [EMAIL PROTECTED]: I am playing around with the STM API. I would like to see examples of STM other than the Santa.hs as I am having problems with STM vs IO. Here's my implementation of the Dining Philosophers in STM: http://computationalthoughts.blogspot.com/2008/03/some-examples-of-software-transactional.html I hope you'll find it helpful. Josef ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: floating point operations and representation
On 2008-03-17, John Meacham [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 12:59:09PM -0400, David Roundy wrote: foreign import ccall unsafe math.h log10 log10 :: Double - Double since in ghc CDouble and Double are identical. It's a bit sloppier, but shouldn't cause any trouble. And I've no idea how realToFrac is implemented, but would worry about it behaving oddly... for instance when given NaNs. Yes. 'realToFrac' is inherently pretty broken and should be avoided whenever possible. It is not all all obvious to me what the correct primitive should be.. but we really should do something better for haskell'. relying on RULES firing as ghc currently does doesn't seem ideal.. hmm.. maybe a 'FloatMax' type and have 'fromFloatMax' and 'toFloatMax' in 'Fractional' and 'Real' respectively? hmm.. hc has 'fromDouble' and 'toDouble' there, but jhc also supports a 'Float128' type (when the underlying hardware does). so this still isn't quite right. Well, the whole numeric hierarchy needs to be redone to support proper mathematical structures like groups, rings, and fields. Once that's done, this might end up being clarified a bit. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2-level type analysis of introducing naming into data types
Justin, Thanks for the query. Here are the considerations/concerns i with which i was working. - Data is *not* native to either lambda or pi-calculi - operational encodings for simple types (Bool and Nat) were given near the inception of these calculi - embeddings of these types took several decades to work out semantically (full abstraction for PCF is an example of the difficulty in the case of lambda; i submit that we haven't really figured out the corresponding story for concurrency, yet) - On the other hand, naming is necessary for effective work with any moderately complex recursive data structure - this is so common we are like fish to this water -- we don't even recognize when we're doing it (as an example see Conway's original presentation of numbers as games -- he starts using naming but does not acknowledge this very subtle shift in the mathematics) - Lambda and pi-calculi are the best name management technology we know - Is there a natural and elementary way to provide the benefits of these name management technologies for dealing with these concrete data structures? Yes, it turns out that the simplest way finds solutions as sitting between least and greatest fixpoints of the functor that pops out of the 2-level type analysis (hence the pretty domain equations that are expressed as Haskell data types). Moreover, it also gives a freebie way to embed data types in these decidedly operational calculi. Further, as i only recently realized it gives a way to compare Brian Smith style reflection with the reflection Matthias Radestock and i identified with the rho-calculus. See thishttp://svn.biosimilarity.com/src/open/mirrororrim/rho/trunk/src/main/haskell/grho.hsnew code. Best wishes, --greg On Mon, Mar 17, 2008 at 8:52 AM, Justin Bailey [EMAIL PROTECTED] wrote: 2008/3/15 Greg Meredith [EMAIL PROTECTED]: All, The following Haskell code gives a 2-level type analysis of a functorial approach to introducing naming and name management into a given (recursive) data type. The analysis is performed by means of an What's the upshot of this? That is, what does this analysis give you? I mostly follow the argument but I don't understand the benefits. I feel like I'm missing something. Justin -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need Cabal/library building help for windows
Ryan Ingram wrote: For reference, I'm using GHC6.8.1 on WinXP. setup.hs: ld is required but it could not be found. I did have the same issue with GHC 6.8.1 on Windows. It is fixed in version 6.8.2. http://haskell.org/ghc/download_ghc_682.html#windows Regards, Felix ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need Cabal/library building help for windows
Thanks, I was hoping it would be something simple like that! I'll give it a try when I get home. -- ryan On 3/17/08, Felix Martini [EMAIL PROTECTED] wrote: Ryan Ingram wrote: For reference, I'm using GHC6.8.1 on WinXP. setup.hs: ld is required but it could not be found. I did have the same issue with GHC 6.8.1 on Windows. It is fixed in version 6.8.2. http://haskell.org/ghc/download_ghc_682.html#windows Regards, Felix ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with type equality constraints
On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: Your are completely right. Unfortunately, superclass equalities (ie, the Id a ~ ida in the class declaration of Foo) aren't fully implemented yet. OK, thanks. Is there any rough idea of when they will be? If I am not mistaken, superclass equalities, class defaults for associated type families, and GADT data instances are the three major features of type families/equality constraint saga that aren't fully implemented yet. Even with the rough edges, type families are really nice, thanks! Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type parameters in type families
Hi, I am trying to understand some differences of parameterizing or not some arguments of type families. I have some code such as *type family G a :: * - * instance Functor (G Int) where fmap f (Left ()) = Left () fmap f (Right x) = Right (f x) ggg :: Functor (G a) = G a x - G a x ggg = fmap id* and it works fine. However, I need to parameterize one extra argument (due to type equality): *type family F a x :: * class FunctorF d where fmapF :: (x - y) - F d x - F d y fff :: (FunctorF a) = F a b - F a b fff = fmapF id* This second scenario fails to compile because the compiler cannot unify types a and b with types d and x from the fmapF declaration. Is there any other option than passing dummy variables to fmapF? * class FunctorF d where fmapF :: d - x - (x - y) - F d x - F d y fff :: (FunctorF a) = a - b - F a b - F a b fff a b = fmapF a b id* Thanks, hugo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2
Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. It would also be nice to add support for the arrows syntax :-) Cheers, Peter Verswyvelen www.anygma.com Niklas Broberg wrote: I'm pleased to announce a new release for the haskell-src-exts package. Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src-exts Cheers, /Niklas haskell-src-exts 0.3.2 === haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy = 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal = 1.2 Patches are more than welcome. :-) Cheers, /Niklas ___ 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: ANN: haskell-src-exts 0.3.2
On 17 mar 2008, at 23.53, Peter Verswyvelen wrote: Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. HaRe - http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html It would also be nice to add support for the arrows syntax :-) Cheers, Peter Verswyvelen www.anygma.com Niklas Broberg wrote: I'm pleased to announce a new release for the haskell-src-exts package. Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http:// hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src- exts Cheers, /Niklas haskell-src-exts 0.3.2 === haskell-src- exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http:// hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/ haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy = 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal = 1.2 Patches are more than welcome. :-) Cheers, /Niklas ___ 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] Re: Type parameters in type families
I wonder if I am dealing with bugs in the type checker (replying to myself). Curiously if I have class FunctorF d where fmapF :: d - (x - y) - F d x - F d y fff a = fmapF a id it compiles correctly. If I infer the type signature of fff I get fff :: forall d x. (FunctorF d) = d - F d x - F d x On the other side, it fails to compile when this signature is explicit: fff :: forall d x. (FunctorF d) = d - F d x - F d x fff a = fmapF a id I am repeating myself in http://hackage.haskell.org/trac/ghc/ticket/2157#comment:6. Sorry for the cascaded messages, hugo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2
Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-) It would also be nice to add support for the arrows syntax :-) Right, that's one of the few extensions missing, and as such it's pretty high on the todo list. I'll see what/ I can do about it (or when rather), or if anyone would send me a patch I'd be happy to include it. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type parameters in type families
But by doing so I am changing type equality to the same as having type family F a :: * - * F' a x ~ F' b y = F' a ~ F' b /\ x ~ y (equality for ADTs) and I would like this decomposition rule not to apply so. Thanks though, hugo On Tue, Mar 18, 2008 at 1:12 AM, Ryan Ingram [EMAIL PROTECTED] wrote: On 3/17/08, Hugo Pacheco [EMAIL PROTECTED] wrote: type family G a :: * - * type instance G Int = Either () -- you forgot this line instance Functor (G Int) where fmap f (Left ()) = Left () fmap f (Right x) = Right (f x) One thing that you don't seem to be clear about is that there is something slightly magic going on in this Functor definition; you are not declaring Functor (G Int) but rather Functor (whatever (G Int) turns into). This is using a GHC extension TypeSynonymInstances. The extension allows you to use type synonyms when declaring instances, but only if they are fully applied, and the compiler is simply applying the substitution for you. That is to say, this code is no different than the following: type family G a :: * - * type instance G Int = Either () instance Functor (Either ()) where fmap f (Left ()) = Left () fmap f (Right x) = Right (f x) Once you declare a more complicated type function, such as type family F a x :: * this extension can no longer come into play. You can get around this restriction with a newtype: type family F a x :: * type instance F Int x = Either () x newtype F' a b = F' (F a b) instance Functor (F' Int) where fmap f (F' (Left ())) = F' (Left ()) fmap f (F' (Right x)) = F' (Right $ f x) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2
On 17 Mar 2008, at 23:41, Niklas Broberg wrote: Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-) I believe that the limitation is that they use Programatica's parser to get an AST to run their refactorings on. I think they've looked several times at using ghc's apis to do this, but hit various problems. I think that the main problem is that no other parser preserves things like code layout and commenting, which is of course pretty critical to refactoring programs in a sane kind of way. Thanks Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with type equality constraints
Ganesh Sittampalam: On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: Your are completely right. Unfortunately, superclass equalities (ie, the Id a ~ ida in the class declaration of Foo) aren't fully implemented yet. OK, thanks. Is there any rough idea of when they will be? That's a bit difficult to say. The main problem is that the current handling of evidence for classes and access to superclass evidence doesn't mix well with the fact that the evidence for equalities are coercions (ie, type-level things, rather than value level things). It's high up on the list, but some other things like the interaction between GADTs and type families (basically done now) were higher up. If its important to you, I'd try to get to it earlier than if nobody is really waiting for it. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and getCookies
Thanks for the tip. Turned out to be a server problem. Adam On Mar 17, 2008, at 8:55 AM, Justin Bailey wrote: On Sun, Mar 16, 2008 at 10:21 AM, Adam Smyczek [EMAIL PROTECTED] wrote: Somehow I cannot get cookies from the Response using Network.Browser module (HTTP 3001.0.4). The cookie header part seams to be empty and getCookies returns empty list as well. Network.Browser comes with a built-in HTTP trace facility - I'd first make sure you are getting the HTTP responses you expect. I believe it's setErrHandler and setDebugHandler - use putStrLn to get a trace of HTTP traffic on your console. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with type equality constraints
On Tue, 18 Mar 2008, Manuel M T Chakravarty wrote: Ganesh Sittampalam: On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: Your are completely right. Unfortunately, superclass equalities (ie, the Id a ~ ida in the class declaration of Foo) aren't fully implemented yet. OK, thanks. Is there any rough idea of when they will be? It's high up on the list, but some other things like the interaction between GADTs and type families (basically done now) were higher up. If its important to you, I'd try to get to it earlier than if nobody is really waiting for it. Well, I am waiting for it, but I'm not exactly desperate. There are also other things restricting me from a wholesale conversion from fundeps which I'll write up into questions on here over the next few days. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
