Re: [Haskell-cafe] compressed pointers?
Don Stewart <[EMAIL PROTECTED]> writes: > One small upside (performance wise), is that the bottom 3 bits of the > pointer are now used to encode the constructor on 64 bits, so 'case' gets a > good percent cheaper. Well - my experience (which is from before this optimization was added, I think) is that 64bit Haskell is slower than 32bit Haskell. Anyway, I think this is an orthogonal issue - by limiting your program to 4GB RAM, 4-byte alignment could give you two bits for pointer tagging and 32 bit pointers. If you still do 8-byte alignment, there's no difference. In extremis, you could imagine several different models based on heap size, with optimal choices for pointer size, alignment and tag bits. If you shift the pointer, you could address up to 16G from 32 bits (by using 8-byte alignment and one tag bit). This probably becomes too complicated, but I thought it was interesting that the Java people are making use of 32bit pointers on a 64bit system, and are seeing a good performance benefit from it. -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] Wrong Answer Computing Graph Dominators
Dan Weston wrote: > Here, "any path" means all paths, a logical conjunction: > > and [True, True] = True > and [True ] = True > and [ ] = True Kim-Ee Yeoh wrote: > Hate to nitpick, but what appears to be some kind of a > limit in the opposite direction is a curious way of arguing > that: and [] = True. > > Surely one can also write > > and [False, False] = False > and [False ] = False > and [ ] = False ??? No. I think what Dan meant was that for all non-null xs :: [Bool], it is clearly true that: and (True:xs) == and xs -- (1) It therefore makes sense to define (1) to hold also for empty lists, and since it is also true that: and (True:[]) == True We obtain: and [] == True Since we can't make any similar claim about the conjuctions of lists beginning with False, there is no reasonable argument to the contrary. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
Dan Weston wrote: > > Here, "any path" means all paths, a logical conjunction: > > and [True, True] = True > and [True ] = True > and [ ] = True > Hate to nitpick, but what appears to be some kind of a limit in the opposite direction is a curious way of arguing that: and [] = True. Surely one can also write and [False, False] = False and [False ] = False and [ ] = False ??? -- Kim-Ee -- View this message in context: http://www.nabble.com/Wrong-Answer-Computing-Graph-Dominators-tp16714477p16760156.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] incompatibility issues in installing wxHaskell 0.10.3 with GHCi 6.8.2 on Windows XP Pro
I just solved the problem by myself: It was a problem with paths including spaces. Originally, I had installed wxhaskell-register.bat in the following directory: C:\Documents and Settings\Benjamin\My Documents\Haskell\Libraries\wxHaskell\wxhaskell-0.10.3\bin However, the directory "Documents and Settings" includes two spaces, and "My Documents" includes a space as well. Therefore, I moved the wxhaskell-0.10.3 directory to the C:\ top-level directory, thus creating a path without spaces; viz: C:\wxhaskell-0.10.3\bin Running wxhaskell-register.bat there caused it to run successfully (some of the returned messages are in Japanese, which I shall translate accordingly below): - installation messages begin immediately after this line - 1 個のファイルをコピーしました。 1 個のファイルをコピーしました。 1 個のファイルをコピーしました。 - register packages Reading package info from "C:\\wxhaskell-0.10.3\\bin\\wxcore.pkg" ... done. WARNING: unversioned dependencies are deprecated, and will NOT be accepted by GH C 6.10: base haskell98 Saving old package config file... done. Writing new package config file... done. Reading package info from "C:\\wxhaskell-0.10.3\\bin\\wx.pkg" ... done. Saving old package config file... done. Writing new package config file... done. - copy wxc-msw2.6.4-0.10.3.dll to the windows system directory (C:\WINDOWS\syste m32) 1 個のファイルをコピーしました。 - done! 続行するには何かキーを押してください . . . - installation messages end immediately before this line - The first three messages above mean the following: "1 file copied. 1 file copied. 1 file copied." The last two messages above mean the following: "1 file copied. Press any key to continue" ( I wish that the error messages had been more helpful, though; "Documents and Settings" is a standard location for many settings in Windows XP, and the previous error message "Maybe you have an incompatible version of ghc installed?" had not been very informative. Also, there are no instructions on the "wxHaskell - Download" page (http://wxhaskell.sourceforge.net/download.html) to run the installation batch file in a directory with no spaces in the path. It seems designed by someone who never steps outside the world of Linux/UNIX/*NIX (nothing against UNIX here; I use Mac OS X, which is a UNIX-based OS, at home myself, but if they are going to provide an automated Windows installer, they should at least explain how to use it from the standpoint of a user used to working in that environment). ) Benjamin L. Russell --- "Benjamin L. Russell" <[EMAIL PROTECTED]> wrote: > Perhaps this is not the best mailing list for this > issue, but since this problem involves a library for > Haskell and is not a bug of GHC proper, I thought > this > would be a better place than the > Glasgow-haskell-bugs > mailing list > > I tried installing wxHaskell 0.10.3 with GHCi 6.8.2 > already installed on Windows XP Professional Service > Pack 2, but every time I run the > wxhaskell-register.bat script to install the > library, > the following error message appears (I am installing > on the Japanese version of Windows XP at work, so > some > of the error messages are in Japanese, which I shall > translate accordingly below): > > - error message begins immediately after this > line > - > 1 [EMAIL PROTECTED] > R}hÌ\¶ªëÁĢܷB > R}hÌ\¶ªëÁĢܷB > - register packages > Reading package info from "C:\\Documents and > Settings\\Benjamin\\My Documents\\H > askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wxcore.pkg" > ... done. > WARNING: unversioned dependencies are deprecated, > and > will NOT be accepted by GH > C 6.10: base haskell98 > ghc-pkg: C:\Documents doesn't exist or isn't a > directory (use --force to overrid > e) > Reading package info from "C:\\Documents and > Settings\\Benjamin\\My Documents\\H > askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wx.pkg" > ... done. > ghc-pkg: dependency wxcore-0.10.3 doesn't exist (use > --force to override) > error: > Unable to register the package using "ghc-pkg". > Maybe you have an incompatible version of ghc > installed? > > ±s·éÉͽ©L[ðµÄ¾³¢ . . . > - error message ends immediately before this > line > - > > The first paragraph above means the following: > > "1 file copied. > Syntax error in command. > Syntax error in command." > > The final line above means the following: > > "Press any key to continue" > > However, there do not seem to be any errors in my > unmodified wxhaskell-register.bat file, quoted > below: > > - text of wxhaskell-register.bat file begins > immediately after this line - > @SET wxclibname=wxc-msw2.6.4-0.10.3 > @SET generate=yes > @ECHO OFF > > IF "%1"=="" GOTO noarg > IF "%1"=="--help" GOTO help > IF "%1"=="-?" GOTO help > IF "%1"=="/?" GOTO help > GOTO installarg > > :installarg > SET installdir=%1 > GOTO check > > :noarg > COPY /B /Y setcd setcd.bat > CD .. > CD >> bin\set
[Haskell-cafe] incompatibility issues in installing wxHaskell 0.10.3 with GHCi 6.8.2 on Windows XP Pro
Perhaps this is not the best mailing list for this issue, but since this problem involves a library for Haskell and is not a bug of GHC proper, I thought this would be a better place than the Glasgow-haskell-bugs mailing list I tried installing wxHaskell 0.10.3 with GHCi 6.8.2 already installed on Windows XP Professional Service Pack 2, but every time I run the wxhaskell-register.bat script to install the library, the following error message appears (I am installing on the Japanese version of Windows XP at work, so some of the error messages are in Japanese, which I shall translate accordingly below): - error message begins immediately after this line - 1 [EMAIL PROTECTED] R}hÌ\¶ªëÁĢܷB R}hÌ\¶ªëÁĢܷB - register packages Reading package info from "C:\\Documents and Settings\\Benjamin\\My Documents\\H askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wxcore.pkg" ... done. WARNING: unversioned dependencies are deprecated, and will NOT be accepted by GH C 6.10: base haskell98 ghc-pkg: C:\Documents doesn't exist or isn't a directory (use --force to overrid e) Reading package info from "C:\\Documents and Settings\\Benjamin\\My Documents\\H askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wx.pkg" ... done. ghc-pkg: dependency wxcore-0.10.3 doesn't exist (use --force to override) error: Unable to register the package using "ghc-pkg". Maybe you have an incompatible version of ghc installed? ±s·éÉͽ©L[ðµÄ¾³¢ . . . - error message ends immediately before this line - The first paragraph above means the following: "1 file copied. Syntax error in command. Syntax error in command." The final line above means the following: "Press any key to continue" However, there do not seem to be any errors in my unmodified wxhaskell-register.bat file, quoted below: - text of wxhaskell-register.bat file begins immediately after this line - @SET wxclibname=wxc-msw2.6.4-0.10.3 @SET generate=yes @ECHO OFF IF "%1"=="" GOTO noarg IF "%1"=="--help" GOTO help IF "%1"=="-?" GOTO help IF "%1"=="/?" GOTO help GOTO installarg :installarg SET installdir=%1 GOTO check :noarg COPY /B /Y setcd setcd.bat CD .. CD >> bin\setcd.bat CD bin CALL setcd.bat DEL setcd.bat SET installdir=%CURDIR% GOTO check :check IF "%generate%"=="yes" GOTO generate GOTO checkfile :generate IF NOT EXIST %installdir%\bin\wx-partial.pkg GOTO notfound COPY /Y %installdir%\bin\wx-partial.pkg %installdir%\bin\wx.pkg ECHO import-dirs:%installdir%\lib\imports >> %installdir%\bin\wx.pkg ECHO library-dirs:%installdir%\lib>> %installdir%\bin\wx.pkg COPY /Y %installdir%\bin\wxcore-partial.pkg %installdir%\bin\wxcore.pkg ECHO import-dirs:%installdir%\lib\imports >> %installdir%\bin\wxcore.pkg ECHO library-dirs:%installdir%\lib>> %installdir%\bin\wxcore.pkg GOTO checkfile :checkfile IF NOT EXIST "%installdir%\bin\wx.pkg" GOTO notfound :install ECHO - register packages SET wxhlibdir=%installdir%\lib ghc-pkg update "%installdir%\bin\wxcore.pkg" ghc-pkg update "%installdir%\bin\wx.pkg" IF ERRORLEVEL 1 GOTO regerror ECHO. IF "%OS%"=="Windows_NT" GOTO copyNT ECHO - copy %wxclibname%.dll to the windows system directory (%WINDIR%\system) COPY %installdir%\lib\%wxclibname%.dll %WINDIR%\system\%wxclibname%.dll GOTO checkcopy :copyNT ECHO - copy %wxclibname%.dll to the windows system directory (%WINDIR%\system32) COPY %installdir%\lib\%wxclibname%.dll %WINDIR%\system32\%wxclibname%.dll :checkcopy IF ERRORLEVEL 1 GOTO copyerror ECHO - done! GOTO end :regerror ECHO error: ECHO Unable to register the package using "ghc-pkg". ECHO Maybe you have an incompatible version of ghc installed? ECHO. goto end :copyerror ECHO error: ECHO Unable to copy dynamic link libraries to the system folder. ECHO This is not a real problem but you will have to add the wxHaskell ECHO library directory to your PATH environment variable. ECHO. ECHO The library directory is: %installdir%\lib ECHO. goto end :notfound ECHO error: ECHO Unable to find the wxHaskell packages (bin\wx.pkg) ECHO Maybe the installation directory is not properly specified? ECHO. GOTO help :help ECHO usage: ECHO wxhaskell-register [installdir] ECHO. ECHO (or just double click on the batch file from the explorer) ECHO. GOTO end :end PAUSE - text of wxhaskell-register.bat file ends immediately before this line - Any ideas? Has anybody else encountered this bug? Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Embedding newlines into a string?
Ariel, --- "Ariel J. Birnbaum" <[EMAIL PROTECTED]> wrote: > > Common Misunderstandings - HaskellWiki > > > http://www.haskell.org/haskellwiki/Common_Misunderstandings > I didn't find this one... maybe it should be in a > more prominent place? > > > Things to avoid - HaskellWiki > > http://www.haskell.org/haskellwiki/Things_to_avoid > I thought of this but it has more discussions about > style than pitfalls... > it seems to me more oriented to people who know > Haskell well and want to > write better. > Maybe a link from here to the above would be a good > idea. Added: Things to avoid - HaskellWiki - 7 Related Links: http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links > Thanks for adding this case to the wiki =) My pleasure! Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] compressed pointers?
jhc packs data into pointers when possible. so for instance data Foo = Foo !Word16 !Word32 gets encoded as --- | 16 bits | 32 bits | ... | 10| --- This particularly helps strings, where the character can often be encoded in the space of the pointer itself. (even on 32 bit architecturs, as Char is only 24 bits in jhc) 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] looking for examples of non-full FunctionalDependencies
Sorry to be picky but there is no violation of the FD here. Note that the class D has only a single ground instance and to violate an FD you need at least two. perhaps you are thinking of functional dependencies as being defined extensionally, over the extent of the type relations specified by multiparameter type classes? somewhat counterintuitively, this isn't quite the case (just as instance selection doesn't take contexts into account..). to get an FD conflict, it is sufficient to have two conflicting constraints, no need for any instances. consider module Fail(Fail) where class X a class X a => Fail a module Main where import Fail class C a b | a -> b instance Fail a => C [a] Bool since superclass X has no instances and is not exported from module Fail, class Fail, though exported, can have no instances. so the instance declaration given for C seems entirely useless, as far as the relation over types is concerned - there are no ground instances of C. nevertheless, it is taken into account when considering functional dependencies: Hugs: :t undefined :: C [a] b => (a,b) undefined :: C [a] Bool => (a,Bool) and so adding an instance for 'C [a] Char' would lead to an FD conflict. just checking, claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
> I'm not sure I agree this is the common definition of dominators Is one undefeated if one has never fought? > I should only ask for the dominators of nodes which I know are > reachable from the source node, right? Yes. Denis Bueno wrote: On Thu, Apr 17, 2008 at 5:52 PM, Dan Weston <[EMAIL PROTECTED]> wrote: Your reasoning differs from the usual understanding of a null product (1 or True), as compared to a null sum (0 or False): > the list of nodes for which > *any path* from source to x must touch, i.e., the list of dominators > of x. Here, "any path" means all paths, a logical conjunction: I'm not sure I agree this is the common definition of dominators, but supposing it is: the upshot is that to get what I expect, I should only ask for the dominators of nodes which I know are reachable from the source node, right? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
On Thu, Apr 17, 2008 at 5:52 PM, Dan Weston <[EMAIL PROTECTED]> wrote: > Your reasoning differs from the usual understanding of a null product (1 or > True), as compared to a null sum (0 or False): > > > > the list of nodes for which > > *any path* from source to x must touch, i.e., the list of dominators > > of x. > > Here, "any path" means all paths, a logical conjunction: I'm not sure I agree this is the common definition of dominators, but supposing it is: the upshot is that to get what I expect, I should only ask for the dominators of nodes which I know are reachable from the source node, right? -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shim: finding modules
2008/4/17 Gour <[EMAIL PROTECTED]>: > > "Graham" == Graham Fawcett <[EMAIL PROTECTED]> writes: > > Graham> Equally glad that it's being supported! Thank you. > > Where one can found it? > > Few days ago I was told on #haskell that shim is dead :-/ The original, I believe: http://mapcar.org/haskell/shim/ Mark Weber's fork is here (discussed April 8 on haskell-cafe): http://mawercer.de/~publicrepos/shim/ Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
Your reasoning differs from the usual understanding of a null product (1 or True), as compared to a null sum (0 or False): > the list of nodes for which > *any path* from source to x must touch, i.e., the list of dominators > of x. Here, "any path" means all paths, a logical conjunction: and [True, True] = True and [True ] = True and [ ] = True The empty case of all sources touching is True, so 12 is a valid dominator for 20 if there is no path from 12 to 20. Dan Denis Bueno wrote: On Thu, Apr 17, 2008 at 11:32 AM, Denis Bueno <[EMAIL PROTECTED]> wrote: On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer <[EMAIL PROTECTED]> wrote: > No. Data.Graph.Inductive.Query.Dominators is just buggy. I have one more problem. For the attached graph, the dominators of the -20 node are computed correctly (namely, [-20,-1,11,12]). But the list of dominators for 20 is present, when in fact 20 isn't reachable from 12. I think 20 should be absent from the return value of `dom graph 12'. (And hence a call to `lookup 20 (dom graph 12)' should return Nothing.) Instead it returns [-20,-1,-3,11,12,-14,17]. Is my reasoning correct? I'd try to fix the code, but, I don't understand how it works. ___ 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] looking for examples of non-full Functional Dependencies
To reuse a favorite word, I think that any implementation that distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :) It does not implement FD, but something else. Maybe this something else is useful, but if one of the forms is strictly more powerful than the other then I don't see why you would ever want the less powerful one. -- Lennart On Thu, Apr 17, 2008 at 7:06 AM, Martin Sulzmann <[EMAIL PROTECTED]> wrote: > Mark P Jones wrote: > > > Martin Sulzmann wrote: > > > > > We're also looking for (practical) examples of "multi-range" > > > functional dependencies > > > > > > class C a b c | c -> a b > > > > > > Notice that there are multiple (two) parameters in the range of the > > > FD. > > > > > > It's tempting to convert the above to > > > > > > class C a b c | c -> a, c -> b > > > > > > but this yields a weaker (in terms of type improvement) system. > > > > > > > I agree with Iavor. > > > > In fact, the two sets of dependencies that you have given here > > are provably equivalent, so it would be decidedly odd to have > > a "type improvement" system that distinguishes between them. > > > > > Consider > > class C a b c | a -> b, a -> c > > instance C a b b => C [a] [b] [b] > > Suppose we encounter the constraint > > C [x] y z > > What results can we expect from type improvement? > > 1) Single-range non-full FDs in GHC following the FD-CHR formulation: > > The first FD C a b c | a -> b in combination with > the instance head C [a] [b] [b] will yield > > C [x] y z improved by y = [b1] for some b1 > > A similar reasoning yields > > C [x] y z improved by z = [b2] for some b2 > > So, overall we get > > C [x] y z improved by y= [b1] and z = [b2] > > Unfortunately, we couldn't establish that b1 and b2 are equal. > Hence, we can *not* apply the instance. > > 2) Alternative design: > > We could now argue that the improvement implied by the FD > is only applicable if we are in the "right" context. > > That is, > C [x] y z doesn't yield any improvement because > the context y is still underspecified (doesn't match > the instance). > > In case of C [x] [y] z we get z = [y] > (and C [x] z [y] yields z = [y]) > > > 3) Multi-range FDs > > Consider > > class C a b c | a -> b c > > instance C a b b => C [a] [b] [b] > > This time it's straightforward. > > C [x] y z yields the improvement y = [b] and z = [b] > which then allows us to apply the instance. > > 4) Summary. > > With multi-range FDs we can derive "more" improvement. > >C [x] y z yields y = [b] and z = [b] > > Based on the FD-CHR formulation, for the single-range FD case we get > >C [x] y z yields y = [b1] and z = [b2] > > which is clearly weaker. > > The alternative design is even weaker, from C [x] y z we can derive > any improvement. > > So, I conclude that in the Haskell type improvement context > there's clearly a difference among single-range and multi-range FDs. > > Of course, we could define multi-range FDs in terms of single-range FDs > which then trivially solves the "equivalence" problem (but some user > may be disappointed that their multi-range FDs yield weaker improvement). > > Thanks for your pointers below but I believe that FDs in the Haskell > context > can be quite different from FDs in the database context. > > - Martin > > > While you're looking for unusual examples of fundeps, you > > might also want to consider things like: > > > > class C a b c | a -> b, b -> c > > > > Note that this is subtly different from a -> b c because > > > > {a -> b, b -> c} |= {a -> b c} > > > > while the reverse does not hold. Instead of type classes, > > I'll give you some more down-to-earth examples of relations > > that satisfy these dependencies: > > > > {Paper, Conference, Year} > > {Professor, University, Country} > > {Person, FavoriteFood, FoodGroup} > > ... > > > > For further insight, you might want to take a look at the theory > > of relational databases to see how functional dependencies are > > used there. In that context, some sets of dependencies (such > > as {a -> b, b -> c}) can be interpreted as indicators of bad > > design. This, in turn, might give you some ideas about the kinds > > of dependencies you can expect to encounter in well-designed > > Haskell code. (Of course, you might still find examples in other > > Haskell code of dependencies that would make a database person > > wince :-) > > > > > ___ > 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] announce: Glome.hs-0.3 (Haskell raytracer)
A new version of my raytracer is out. It now supports cones, cylinders, disks, boxes, and planes as base primitives (previously it only supported triangles and spheres), as well as transformations of arbitrary objects (rotate, scale, translate) and the CSG operations difference and intersection. Perlin noise and Blinn highlights have been added, as well. http://syn.cs.pdx.edu/~jsnow/glome/ Glome can parse NFF-format scene files (see http://tog.acm.org/resources/SPD/), but many features are only accessible via raw Haskell, since NFF doesn't support very many kinds of primitives. I included a TestScene.hs file that demonstrates how to create a scene with various kinds of geometry (including a crude attempt at a recursively-defined oak tree) in haskell. There isn't any documentation yet, but many of the primitives have constructors that resemble their equivalents in povray, so anyone familiar with povray's syntax should be able to figure out what's going on. -jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
On Thu, Apr 17, 2008 at 11:32 AM, Denis Bueno <[EMAIL PROTECTED]> wrote: > On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer > <[EMAIL PROTECTED]> wrote: > > No. Data.Graph.Inductive.Query.Dominators is just buggy. I have one more problem. For the attached graph, the dominators of the -20 node are computed correctly (namely, [-20,-1,11,12]). But the list of dominators for 20 is present, when in fact 20 isn't reachable from 12. I think 20 should be absent from the return value of `dom graph 12'. (And hence a call to `lookup 20 (dom graph 12)' should return Nothing.) Instead it returns [-20,-1,-3,11,12,-14,17]. Is my reasoning correct? I'd try to fix the code, but, I don't understand how it works. -- Denis bad-dominators2.ps Description: PostScript document ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Shim: finding modules
> "Graham" == Graham Fawcett <[EMAIL PROTECTED]> writes: Graham> Equally glad that it's being supported! Thank you. Where one can found it? Few days ago I was told on #haskell that shim is dead :-/ Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpTpUIuDZsV0.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Iavor Diatchki wrote: Hello, On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann <[EMAIL PROTECTED]> wrote: leads to an instance improvement/instance improvement conflict, like in the single-range FD case class D a b | a -> b instance D a a => D [a] [a] instance D [Int] Char Sorry to be picky but there is no violation of the FD here. Note that the class D has only a single ground instance and to violate an FD you need at least two. As in the previous example, we can add an instance like this: instance D Char Char This results in more ground instances: { D [Int] Char, D Char Char, D [Char] [Char], ... } but again, there is no violation of the FD. I think that a lot of the confusion in discussions such as this one (and we've had a few of those :-) stems from the fact that the term "functional dependency" seems to have become heavily overloaded. Often, the basic concept is mixed with (i) concepts related to checking that the basic concept holds (e.g., various restrictions on instances, etc), (ii) concepts related to how we might want to use the basic concept (e.g., what improvement rules to use). Of course, (i) and (ii) are very important, and there are a lot possible design choices. However, a number of the discussions I have seen go like this: 1) In general, it is hard to check if instances violate the stated functional dependencies. 2) So we have more restrictive rules, that are easier to check. 3) These more restrictive rules give us stronger guarantees, so we have more opportunity for improvement. While there is nothing inherently wrong with this, it is important to note that the extra improvement is not a result of the use of FDs but rather, from the extra restrictions that we placed on the instances. I think that this distinction is important because (i) it avoids mixing concepts, and (ii) points to new things that we may want to consider. For example, I think that there is an opportunity for improvement in situations where is class is not exported from a module. Then we know the full set of instances for the class, and we may be able to compute improvement rules. Hope this helps! -Iavor Can you pl specify the improvement rules for your interpretation of FDs. That would help! I'm simply following Mark Jones' style FDs. Mark's ESOP'00 paper has a consistency condition: If two instances match on the FD domain then the must also match on their range. The motivation for this condition is to avoid inconsistencies when deriving improvement rules from instances. For class D a b | a -> b instance D a a => D [a] [a] instance D [Int] Char we get D [a] b ==> b =[a] D [Int] b ==> b=Char In case of D [Int] b we therefore get b=Char *and* b =[a] which leads to a (unification) error. The consistency condition avoids such situations. The beauty of formalism FDs with CHRs (or type functions/families) is that the whole improvement process becomes explicit. Of course, it has to match the programmer's intuition. See the discussion regarding multi-range FDs. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcing DarcsWatch (with link)
Hi, sorry for the spam, but what I forgot in the first mail: You can find DarcsWatch at: http://darcswatch.nomeata.de/ A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet. So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you’ll find a nice overview of your patches with diffs and download links. For an example, see: http://darcswatch.nomeata.de/[EMAIL PROTECTED] If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation at http://darcs.nomeata.de/darcswatch/documentation.html There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch’s repository, found at http://darcs.nomeata.de/darcswatch/ Enjoy, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Hello, On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann <[EMAIL PROTECTED]> wrote: > leads to an instance improvement/instance improvement conflict, > like in the single-range FD case > > class D a b | a -> b > > instance D a a => D [a] [a] > instance D [Int] Char Sorry to be picky but there is no violation of the FD here. Note that the class D has only a single ground instance and to violate an FD you need at least two. As in the previous example, we can add an instance like this: instance D Char Char This results in more ground instances: { D [Int] Char, D Char Char, D [Char] [Char], ... } but again, there is no violation of the FD. I think that a lot of the confusion in discussions such as this one (and we've had a few of those :-) stems from the fact that the term "functional dependency" seems to have become heavily overloaded. Often, the basic concept is mixed with (i) concepts related to checking that the basic concept holds (e.g., various restrictions on instances, etc), (ii) concepts related to how we might want to use the basic concept (e.g., what improvement rules to use). Of course, (i) and (ii) are very important, and there are a lot possible design choices. However, a number of the discussions I have seen go like this: 1) In general, it is hard to check if instances violate the stated functional dependencies. 2) So we have more restrictive rules, that are easier to check. 3) These more restrictive rules give us stronger guarantees, so we have more opportunity for improvement. While there is nothing inherently wrong with this, it is important to note that the extra improvement is not a result of the use of FDs but rather, from the extra restrictions that we placed on the instances. I think that this distinction is important because (i) it avoids mixing concepts, and (ii) points to new things that we may want to consider. For example, I think that there is an opportunity for improvement in situations where is class is not exported from a module. Then we know the full set of instances for the class, and we may be able to compute improvement rules. Hope this helps! -Iavor -Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples ofnon-fullFunctional Dependencies
a little more experimentation leaves me confused. consider [4] class C a b c | a -> b -- , a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined :: C [x] y z => (x,y,z) undefined :: C [a] [b] c => (a,[b],c) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] z) => (x, [b], z) both systems improve 'y' to '[b]', but not to '[b] where z=[b]'. ok, the third parameter is not in range of an FD, so cannot be instantiated by improvement, and without that, 'y' cannot be instantiated as far as the FD would suggest. it is slightly surprising that 'y' get partially instantiated at this stage. My understanding of an FD a -> b is to improve, or in other words instantiate, b as much as possible based on information from a. With C [x] y z we know for sure that y must be [b] for some b. Improvement adds (propagates) this information we know for sure. With our limited information, we may not know what b is, but just knowing the list type constructor [] may already be useful. For instance, if we had a second type class constraint D y for which there is an instance instance D [a] where ... Then inferring that y = [b] will allow us to figure out that we can use the above instance for it. however, if we try to help the process along by instantiating 'z' to '[b]' ourselves, we get: [5] Hugs: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [a] [b] [c] => (a,[b],[c]) GHCi: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [x] y [b] => (x,y,[b]) :: (C [x] [b1] [b]) => (x, [b1], [b]) i would have expected 'C a c c => (a,[c],[c])' here, as only instantiation of 'y' is required; so my intuition is still off, and neither [A] nor [B] seems to capture Hugs' interpretation. You did not provide the FD a -> c (or even a -> b c). That means that you did not allow the type checker to improve c based on a. Nor did you provide the FD a c -> b. For that reason the type checker does not use any information from the third parameter to improve the second parameter. It does indeed feel somewhat strange, because there is no alternative for y (except if you allow overlapping instances and add e.g. an instance C [a] [b] [Int]). Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: [EMAIL PROTECTED] url: http://www.cs.kuleuven.be/~toms/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ann: Emping 0.5 in Hackage
Emping is a utility which derives the shortest rules from a table of rules. For example, in a list of 8000 different mushrooms, it finds 21 single predicates that determine the mushroom is poisonous, and 23 that it is edible. But it also finds all combinations of two, three and more predicates that determine this property. Each shorter rule is a generalization of an original one. So, if r1 covers {a,b,c} and r2 {a,b}, then r2 implies r1 (r1 entails r2). The shorter rules are partially ordered. Thanks to the functional graphs library, which comes with ghc, the reduced rules are now displayed as graphs which can be viewed with a Graphviz viewer. Also new in 0.5 is that the reduced rules, and the reduced rules in an equivalence class, are ordered by length. Lastly, the GUI has been improved. Testing has also shown some bugs and issues, most importantly when the data contains ambiguous rules. Ambiguities are rules with the same antecedent, but a different consequent. You can test for them, but if the user turns the checks off and run Emping without correcting the data, the program could hang, in a special case. See http://home.telfort.nl/sp969709/emp/empug.html for more info and a few screenshots. Thank you all, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] export question (GHC.Handle)
On Thu, Apr 17, 2008 at 4:46 PM, Bertram Felgenhauer < [EMAIL PROTECTED]> wrote: > > Assuming you're writing a cabal package, you could separate the interface > from the actual implementation: [..] > > HTH, Magic. Thanks a lot! cheers, Fraser. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcing DarcsWatch
Hi, (Hi again to those on haskell-cafe, but things have changed since the other announcement) A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet. So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you’ll find a nice overview of your patches with diffs and download links. For an example, see: http://darcswatch.nomeata.de/[EMAIL PROTECTED] If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation at http://darcs.nomeata.de/darcswatch/documentation.html There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch’s repository, found at http://darcs.nomeata.de/darcswatch/ Enjoy, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Hackage Haddock fails where local succeeds
2008/4/17, John Goerzen <[EMAIL PROTECTED]>: > On Thu April 17 2008 7:01:18 am Ross Paterson wrote: > > On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > > > My local haddock, 0.8, parses this file fine. Is Hackage running and > > > older version? Could it be upgraded? Or is there something else going > > > on here? > > > > No, it's running haddock 2.1.0, which understands all the GHC > > extensions, but is more picky about comments. > > > OK. I have been able to replicate this behavior with Haddock 2.0.0.0, which > is the latest according to www.haskell.org/haddock. Where did 2.1.0 come > from? > > Although I can replicate the behavior, I can't explain it. My reading of the > Haddock docs leads me to believe I have done the correct thing. Is this a > bug in Haddock or am I missing something? It's a bug. Comments on type synonyms were missed when Haddock support was added to the GHC parser. This might be fixed in future versions of GHC. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Iavor Diatchki wrote: Hello, On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann <[EMAIL PROTECTED]> wrote: 3) Multi-range FDs Consider class C a b c | a -> b c instance C a b b => C [a] [b] [b] This time it's straightforward. C [x] y z yields the improvement y = [b] and z = [b] which then allows us to apply the instance. I don't think that this improvement rule is justified (unless there are some assumptions that are added to the system that go beyond FD?). By the way, note that the above example does not have any instances for C, so lets first add a base case like this: instance C Char Bool Bool Now the instances for C are: { C Char Bool Bool, C [Char] [Bool] [Bool], ... }. Certainly, if you just consider these instances, then the improvement rule that you suggest is valid. However, suppose that we also add the instance: instance C [Int] Char Bool Note that this instance does not violate the FD: if we know the first argument, then we know exactly what are the other two arguments. In this context, it is not OK to improve C [x] y z as you suggest because 'x' may be instantiate to 'Int' There possible points of view here. Consider a -> b c as a short-hand for a -> b, a -> c. That's fine. But we may also want to go beyond (single-range) FDs. That's why I have in mind. Therefore, a -> b, a -> c is a short-hand for a -> b, c. (At least there's one supporter, Ganesh, assuming that Tom and I are neutral :) ) Suppose we encode the multi-range FD a -> b, c as defined in the FD-CHR paper. Then, class C a b c | a -> b c instance C a b b => C [a] [b] [b] instance C [Int] Char Bool leads to an instance improvement/instance improvement conflict, like in the single-range FD case class D a b | a -> b instance D a a => D [a] [a] instance D [Int] Char All of the above design choices make sense. There's no right or wrong. But it's wrong to simply ignore possible FD variants which go beyond single-range FDs. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Hello, On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann <[EMAIL PROTECTED]> wrote: > 3) Multi-range FDs > > Consider > > class C a b c | a -> b c > > instance C a b b => C [a] [b] [b] > > This time it's straightforward. > > C [x] y z yields the improvement y = [b] and z = [b] > which then allows us to apply the instance. I don't think that this improvement rule is justified (unless there are some assumptions that are added to the system that go beyond FD?). By the way, note that the above example does not have any instances for C, so lets first add a base case like this: instance C Char Bool Bool Now the instances for C are: { C Char Bool Bool, C [Char] [Bool] [Bool], ... }. Certainly, if you just consider these instances, then the improvement rule that you suggest is valid. However, suppose that we also add the instance: instance C [Int] Char Bool Note that this instance does not violate the FD: if we know the first argument, then we know exactly what are the other two arguments. In this context, it is not OK to improve C [x] y z as you suggest because 'x' may be instantiate to 'Int'. -Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Embedding newlines into a string?
> Common Misunderstandings - HaskellWiki > http://www.haskell.org/haskellwiki/Common_Misunderstandings I didn't find this one... maybe it should be in a more prominent place? > Things to avoid - HaskellWiki > http://www.haskell.org/haskellwiki/Things_to_avoid I thought of this but it has more discussions about style than pitfalls... it seems to me more oriented to people who know Haskell well and want to write better. Maybe a link from here to the above would be a good idea. Thanks for adding this case to the wiki =) -- Ariel J. Birnbaum ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ interface with Haskell
Well Isaac...I became now a little bit smarter then yesterday!!! I show you the example that I found and on which I´m working with. File: foo.hs module Foo where foreign export ccall foo :: Int -> IO Int foo :: Int -> IO Int foo n = return (length (f n)) f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) To get the C wrapper you insert the following command: ghc -ffi -fvia-C -C foo.hs After execution you will have these following additional files: foo.hc foo.hi foo_stub.c foo_stub.h foo_stub.o What I did next was to create a file named: myfoo_c.c, where I will call the foo function (implemented in Haskell). (you can see this example on http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) But the problem is to compile with gcc (must I put any flag or whatever set something) The gcc output is: myfoo_c.c:2:19: error: HsFFI.h: No such file or directory I downloaded this header file from: (I know that is not the correct way, but it was the only idea that occurs at the moment) http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx I compiled again and the following return error appears: myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' myfoo_c.c:(.text+0x31): undefined reference to `foo' myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' collect2: ld returned 1 exit status These functions are necessary to setup GHC runtime (see: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! Chears, Miguel Lordelo. On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: > perhaps > > haskell: > foreign export "foo_func" foo :: Int -> IO Int > -- I forget the rest of the syntax here > > C++: > > extern "C" { > int foo_func(int i); > } > > int some_cplusplus_function() { > int bat = 3; > int blah = foo_func(bat); > return blah; > } > > > Is that all you need to do? > > > Miguel Lordelo wrote: > > > Hi all, > > > > Well...somehow I'm a beginner in Haskell. But actually my interest in > > Haskell will increase if it is possible to call a haskell function in > > C++. > > Something like GreenCard ( http://www.haskell.org/greencard/ ) > > simplifying > > the task of interfacing Haskell programs to external libraries > > (usually). > > But is there also a task to interface a foreign language with Haskell, > > but > > calling Haskell functions. Or c2hs which is an interface generator that > > simplifies the development of Haskell bindings to C libraries. > > > > I want to know this, because in my company some guys are doing some > > testing > > with Frotran and MatLab and I want to show them the power of haskell and > > the > > software which we are using is implemented in C++ (there is the reason > > to > > make Haskel -> C++). > > > > I read somewhere that the only way for C++ calling a haskell function is > > to > > create a binding between Haskell and C and from C to C++, but a easy > > "Hello > > World" example was not there. > > Unfortunatelly I couldn't found anything usefull, like an complete > > example, > > or how to compile the code from haskell to C to C++. > > > > Can sombody help me, please :P > > > > Chears, > > Miguel Lordelo. > > > > > > > > > > > > ___ > > 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] looking for examples ofnon-fullFunctional Dependencies
a little more experimentation leaves me confused. consider [4] class C a b c | a -> b -- , a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined :: C [x] y z => (x,y,z) undefined :: C [a] [b] c => (a,[b],c) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] z) => (x, [b], z) both systems improve 'y' to '[b]', but not to '[b] where z=[b]'. ok, the third parameter is not in range of an FD, so cannot be instantiated by improvement, and without that, 'y' cannot be instantiated as far as the FD would suggest. it is slightly surprising that 'y' get partially instantiated at this stage. however, if we try to help the process along by instantiating 'z' to '[b]' ourselves, we get: [5] Hugs: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [a] [b] [c] => (a,[b],[c]) GHCi: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [x] y [b] => (x,y,[b]) :: (C [x] [b1] [b]) => (x, [b1], [b]) i would have expected 'C a c c => (a,[c],[c])' here, as only instantiation of 'y' is required; so my intuition is still off, and neither [A] nor [B] seems to capture Hugs' interpretation. in particular, i don't see how to account for [5], even with a refined ruleset that accounts for [4]. suggestions?-) claus - Original Message - From: "Claus Reinke" <[EMAIL PROTECTED]> To: "Martin Sulzmann" <[EMAIL PROTECTED]>; "Mark P Jones" <[EMAIL PROTECTED]> Cc: "Tom Schrijvers" <[EMAIL PROTECTED]>; "Haskell-cafe Café" Sent: Thursday, April 17, 2008 2:57 PM Subject: Re: [Haskell-cafe] looking for examples ofnon-fullFunctional Dependencies class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Suppose we encounter the constraint C [x] y z interesting example. splitting improvement into two rules seems to lose the (b1=b2) constraint that spans both: [O] C [x] y z => y=[b1]. C [x] y z => z=[b2]. my first thought was that the improvement rules look too general as the instance only applies if (y=z), so i was tempted to add that constraint via guards or patterns: [A] C [x] y [b] => y=[b]. C [x] [b] z => z=[b]. but the FD states that knowing a is sufficient to know both b and c, so one could argue that (y=z), just like (y=[b]) and (z=[b]) should be a consequence rather than a condition for these improvements: [B] C [x] y z => y=z, y=[b]. C [x] y z => y=z, z=[b]. it is interesting to observe Hugs (20051031) vs GHCi (6.9.20080217) on this example and some slight variations (see below). it appears [1] that Hugs follows [B] while GHCi follows [A], and that [2,3] GHCi generally treats structural and unification constraints differently. i have no idea how GHCi comes up with the type (x, [Bool], [Char]) in [2]. btw, Ross started a survey of FD examples/requirements a while ago on the Haskell prime list - it would be nice to have any results of his and your's online (on the wiki perhaps?), especially as documentation regarding different interpretations of the same language extensions between Hugs and GHC (overlap resolution & FDs comes to mind as being fairly similar to this example): http://www.haskell.org/pipermail/haskell-prime/2006-April/001334.html http://www.haskell.org/pipermail/haskell-prime/2006-April/001440.html claus [1] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined::C [x] y z => (x,y,z) undefined :: C [a] [b] [b] => (a,[b],[b]) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] [b1]) => (x, [b], [b1]) [2] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] [Bool] [Char] Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] [Bool] [Char] *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: Ok, modules loaded: Main. :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (x, [Bool], [Char]) [3] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] Bool Char Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] Bool Char *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: C:\Documents and Settings\cr3\Desktop\C.hs:7:0: Functional dependencies conflict between instance declarations: instance (C a b b) => C [a] [b] [b] -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:7:0-32 instance C [a] Bool Char -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:8:0-23 Failed, modules loaded: none. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-C
Re: [Haskell-cafe] Wrong Answer Computing Graph Dominators
On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer <[EMAIL PROTECTED]> wrote: > No. Data.Graph.Inductive.Query.Dominators is just buggy. [...] > Here's a quick fix: Thanks! This fixes my problem. Have you submitted a bug and your patch to the appropriate tracker? If not, would someone point me to the appropriate one? Would in be the GHC trac, or is there a libraries-specific one? I'll be happy to submit your patch and credit you for it, if someone will point me in the right direction. -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shim: finding modules
On Thu, Apr 17, 2008 at 10:41 AM, Marc Weber <[EMAIL PROTECTED]> wrote: > > I'd like to be able to tell Shim that 'App' is the root of my project, > > and to locate modules from that root. Is this possible? > If adding the cabal file does'nt work contact me and we'll try to > reslove this issue. It did work, but thanks for the offer of help. > Are you willing to test new versions/ extensions? Are you already using > ghc-6.8 ? Yes, and I don't need ghc-6 support. I'm not sure how much I can help, but I would be a willing tester (on Emacs, particularly). > Anyway it's nice to see that shim is beeing used. Equally glad that it's being supported! Thank you. Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] export question (GHC.Handle)
On Thu, Apr 17, 2008 at 10:38 AM, Bertram Felgenhauer <[EMAIL PROTECTED]> wrote: > > Graham Fawcett wrote: > > I notice in the source for GHC.Handle that certain functions (e.g. > > fdToHandle_stat) are in the export list, but are not actually exported > > (at least, it seems you cannot import them). What mechanism causes > > these functions to be "hidden", and are they still accessible in some > > way? > > which ghc version are you using, and which sources are you looking at? > > import GHC.Handle (fdToHandle_stat) > > works fine in ghc 6.8.2. In the base library shipped with ghc 6.6.1, > it wasn't exported (or even defined). Ah, I was looking at GHC 6.8.2 sources, but I may have been running 6.6.1. PEBKAC, sorry for the noise. Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] export question (GHC.Handle)
Fraser Wilson wrote: > Good question. I often need to export a name to other modules within the > hierarchy, but without making them visible outside it. I've "solved" this > problem by giving them funky names and adding a comment, but is there a more > structured way to do this? A quick google hasn't found one yet. Assuming you're writing a cabal package, you could separate the interface from the actual implementation: module Hello ( hello ) where import Hello.Impl module Hello.Impl ( hello, hello_internal ) where hello, hello_internal :: String hello = "Hello, world!" hello_internal = "The secret word is 'puddleplum'." and then list Hello.Impl under extra-modules instead of exposed-modules in the cabal file, which will hide it from external users. Internal users can just use Hello.Impl directly. HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shim: finding modules
> I'd like to be able to tell Shim that 'App' is the root of my project, > and to locate modules from that root. Is this possible? If adding the cabal file does'nt work contact me and we'll try to reslove this issue. Are you willing to test new versions/ extensions? Are you already using ghc-6.8 ? Must shim still work for ghc-6.6 ? > On a related note, it seems that Shim is moribund (though others have No it is not / won't in the near future Benedikt (author) has even takled to me on irc for 20min I'm the one who has asked and forked because of vim. But I don't plan to keep it forked. That time I didn't knew how to contribute and didn't got any feedback. That's why I've put another shim repository on my server. Maybe you also want to help? It would be cool to get shim integrated into the EclipseFP as well. But there is still a lot to do. Anyway it's nice to see that shim is beeing used. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] export question (GHC.Handle)
Graham Fawcett wrote: > I notice in the source for GHC.Handle that certain functions (e.g. > fdToHandle_stat) are in the export list, but are not actually exported > (at least, it seems you cannot import them). What mechanism causes > these functions to be "hidden", and are they still accessible in some > way? which ghc version are you using, and which sources are you looking at? import GHC.Handle (fdToHandle_stat) works fine in ghc 6.8.2. In the base library shipped with ghc 6.6.1, it wasn't exported (or even defined). HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-fullFunctional Dependencies
class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Suppose we encounter the constraint C [x] y z interesting example. splitting improvement into two rules seems to lose the (b1=b2) constraint that spans both: [O] C [x] y z => y=[b1]. C [x] y z => z=[b2]. my first thought was that the improvement rules look too general as the instance only applies if (y=z), so i was tempted to add that constraint via guards or patterns: [A] C [x] y [b] => y=[b]. C [x] [b] z => z=[b]. but the FD states that knowing a is sufficient to know both b and c, so one could argue that (y=z), just like (y=[b]) and (z=[b]) should be a consequence rather than a condition for these improvements: [B] C [x] y z => y=z, y=[b]. C [x] y z => y=z, z=[b]. it is interesting to observe Hugs (20051031) vs GHCi (6.9.20080217) on this example and some slight variations (see below). it appears [1] that Hugs follows [B] while GHCi follows [A], and that [2,3] GHCi generally treats structural and unification constraints differently. i have no idea how GHCi comes up with the type (x, [Bool], [Char]) in [2]. btw, Ross started a survey of FD examples/requirements a while ago on the Haskell prime list - it would be nice to have any results of his and your's online (on the wiki perhaps?), especially as documentation regarding different interpretations of the same language extensions between Hugs and GHC (overlap resolution & FDs comes to mind as being fairly similar to this example): http://www.haskell.org/pipermail/haskell-prime/2006-April/001334.html http://www.haskell.org/pipermail/haskell-prime/2006-April/001440.html claus [1] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined::C [x] y z => (x,y,z) undefined :: C [a] [b] [b] => (a,[b],[b]) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] [b1]) => (x, [b], [b1]) [2] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] [Bool] [Char] Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] [Bool] [Char] *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: Ok, modules loaded: Main. :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (x, [Bool], [Char]) [3] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] Bool Char Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] Bool Char *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: C:\Documents and Settings\cr3\Desktop\C.hs:7:0: Functional dependencies conflict between instance declarations: instance (C a b b) => C [a] [b] [b] -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:7:0-32 instance C [a] Bool Char -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:8:0-23 Failed, modules loaded: none. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage Haddock fails where local succeeds
On Thu April 17 2008 7:01:18 am Ross Paterson wrote: > On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > > My local haddock, 0.8, parses this file fine. Is Hackage running and > > older version? Could it be upgraded? Or is there something else going > > on here? > > No, it's running haddock 2.1.0, which understands all the GHC > extensions, but is more picky about comments. OK. I have been able to replicate this behavior with Haddock 2.0.0.0, which is the latest according to www.haskell.org/haddock. Where did 2.1.0 come from? Although I can replicate the behavior, I can't explain it. My reading of the Haddock docs leads me to believe I have done the correct thing. Is this a bug in Haddock or am I missing something? Is there some different syntax for a "type" declaration that defines an alias for a function? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shim: finding modules
On Thu, Apr 17, 2008 at 4:26 AM, pepe <[EMAIL PROTECTED]> wrote: > > On 16/04/2008, at 22:15, Graham Fawcett wrote: > > I'd like to be able to tell Shim that 'App' is the root of my project, > > and to locate modules from that root. Is this possible? > > Shim already does this. All it requires is that your project is a Cabal > project. Shim will locate the Cabal descriptor and auto configure itself > from there. Does that solve your problem ? It does! Thanks very much. Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Sittampalam, Ganesh wrote: Why not instead transform single-range FDs into multi-range ones where possible? That's a perfectly reasonable assumption and would establish the logical property that a -> b /\ a -> c iff a -> b /\ c for FDs (by definition). But what about programmers who'd like that C [x] y z yields the improvement y = [b], z =[b] where class C a b c | a -> b c instance C a b b => C [a] [b] [b] Isn't that precisely what you earlier said would happen with multi-range FDs? Either I'm missing some difference or we're talking at cross-purposes. My suggestion is that "class C a b c | a -> b c" and "class C a b c | a -> b, a -> c" be both treated as the former case, leading to both cases having the y=[b],z=[b] improvement as above. Misunderstanding. I see what you mean. Yes, I agree let's consider a -> b, a -> c as equivalent to a -> b c (I argued the other direction in my earlier email). One subtle point (Tom and I just discussed). It could happen that the programmer writes class SuperCtxt => C a b c | a -> b but there could be an implicit dependency a -> c arising from the super class context SuperCtxt. Hence, you suddenly get a -> b c. The problem is to generate the proper improvement rules. Well, it's not hard to generate these rules we just need to make sure that the rules generated match the programmers intuition how functional dependencies behave. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies
> > Why not instead transform single-range FDs into multi-range ones where > > possible? > That's a perfectly reasonable assumption and would establish the logical > property that > a -> b /\ a -> c iff a -> b /\ c > for FDs (by definition). > But what about programmers who'd like that > C [x] y z yields the improvement y = [b], z =[b] > where > class C a b c | a -> b c > instance C a b b => C [a] [b] [b] Isn't that precisely what you earlier said would happen with multi-range FDs? Either I'm missing some difference or we're talking at cross-purposes. My suggestion is that "class C a b c | a -> b c" and "class C a b c | a -> b, a -> c" be both treated as the former case, leading to both cases having the y=[b],z=[b] improvement as above. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help with associated types
Hello! I'm trying to rewrite some FD classes to use associated types instead. The Port class is for type structures whose leaves have the same type: class Port p where type Leaf p type Struct p toList :: p -> [Leaf p] fromList :: [Leaf p] -> p (Leaf p) gives the leaf type, and (Struct p) gives a canonical representation of the structure regardless of leaf type. Here we just instantiate two leaf types: instance Port Int where type Leaf Int = Int type Struct Int = () toList a = [a] fromList [a]= a instance Port Bool where type Leaf Bool = Bool type Struct Bool = () toList a = [a] fromList [a] = a There's also a function for mapping over ports: mapPort :: ( Port pa , Port pb , Struct pa ~ Struct pb ) => (Leaf pa -> Leaf pb) -> (pa -> pb) mapPort f = fromList . map f . toList The equality constraint makes sure that we're mapping between equal structures. When I try to run this, I get: *Main> mapPort even (5::Int) :1:8: No instance for (Integral (Leaf Int)) ... because as it stands, mapPort is not able to infer (pb = Bool) from (Struct pb = ()) and (Leaf pb = Bool). What's the easiest way to encode that pb can be inferred from (Struct pb) and (Leaf pb)? Thanks, / Emil PS. I used to have a class class SameStruct pa a pb b | pa -> a, pa b -> pb, pb -> b, pb a -> pa In the example above, we'd have pa=Int and b==Bool, so the second dependeny would infer pb=Bool. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage Haddock fails where local succeeds
On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > My local haddock, 0.8, parses this file fine. Is Hackage running and older > version? Could it be upgraded? Or is there something else going on here? No, it's running haddock 2.1.0, which understands all the GHC extensions, but is more picky about comments. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage Haddock fails where local succeeds
Hi folks, Over at http://hackage.haskell.org/packages/archive/MissingH/1.0.1.2/logs/failure/ghc-6.8 the build has failed in the Hackage step with this output: src/Data/BinPacking.hs:78:32: parse error on input `-- ^ The sizes of bins' haddock: Failed to check module: Data.BinPacking That section of code looks like this: {- | The primary type for bin-packing functions. These functions take a list of size of bins. If every bin is the same size, you can pass @(repeat binSize)@ to pass an infinite list of bins if the same size. Any surplus bins will simply be ignored. -} type BinPacker = (Num size, Ord size, Show size, Show obj) => [size]-- ^ The sizes of bins -> [(size, obj)] -- ^ The sizes and objects -> Either (BinPackerError size obj) [[(size, obj)]] -- ^ Either error or results (the last line got artificially wrapped in my mail client) My local haddock, 0.8, parses this file fine. Is Hackage running and older version? Could it be upgraded? Or is there something else going on here? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Sittampalam, Ganesh wrote: Martin Sulzmann wrote: Mark P Jones wrote: In fact, the two sets of dependencies that you have given here are provably equivalent, so it would be decidedly odd to have a "type improvement" system that distinguishes between them. Based on the FD-CHR formulation, for the single-range FD case we get [...] which is clearly weaker. [...] So, I conclude that in the Haskell type improvement context there's clearly a difference among single-range and multi-range FDs. This seems like a flaw in FD-CHR, rather than a fundamental difference between the dependencies. Of course, we could define multi-range FDs in terms of single-range FDs which then trivially solves the "equivalence" problem (but some user may be disappointed that their multi-range FDs yield weaker improvement). Why not instead transform single-range FDs into multi-range ones where possible? That's a perfectly reasonable assumption and would establish the logical property that a -> b /\ a -> c iff a -> b /\ c for FDs (by definition). But what about programmers who'd like that C [x] y z yields the improvement y = [b], z =[b] where class C a b c | a -> b c instance C a b b => C [a] [b] [b] It's hard to say who's right or wrong but there's a design space which needs to be explored further. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intro to functional dependencies in Haskell?
Not so long ago, I had difficulties to understand functional dependecies. Due to the (sometimes well-grounded) prejudgement of considering research papers as an unfriendly and obscure source of information, I stupidly ruled out reading Mark P Jones original paper. Then I learned I was totally wrong, it is written in a friendly way, with lots of examples, allowing me to finally understand how functional dependencies work and what was the reason to introduce them: http://web.cecs.pdx.edu/~mpj/pubs/fundeps.html On Thu, Apr 17, 2008 at 7:21 AM, Alexis Hazell <[EMAIL PROTECTED]> wrote: > Hi all, > > i'm having some trouble 'getting' functional dependencies in the Haskell > context (although my understanding of them in the context of relational > database theory isn't that great either). Could someone please point me > to an introduction / tutorial in this regard? > > Thanks! > > > Alexis. > ___ > 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] looking for examples of non-full Functional Dependencies
hackageDB has a substantial sample of code these days, which is handy for questions like this. Thanks, Ross. These examples are perfect! Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: [EMAIL PROTECTED] url: http://www.cs.kuleuven.be/~toms/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shim: finding modules
On 16/04/2008, at 22:15, Graham Fawcett wrote: Hi folks, I'm a newbie, so please forgive any terminological mistakes. I've been using Shim in Emacs with great success, but there's one issue I've encountered, and I don't know if it's configuration problem or something fundamental. Consider a module 'App' and submodules 'App.Front' and 'App.Back'. When editing code in App that depends on the submodules, Shim works well at resolving the location of the submodules, and validates my code. But when editing App.Front, which depends on App.Back, Shim fails to validate -- my working directory is App.Front, and Shim doesn't seem able to find the location of App.Back. I'd like to be able to tell Shim that 'App' is the root of my project, and to locate modules from that root. Is this possible? Shim already does this. All it requires is that your project is a Cabal project. Shim will locate the Cabal descriptor and auto configure itself from there. Does that solve your problem ? Cheers pepe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intro to functional dependencies in Haskell?
On Thu, Apr 17, 2008 at 03:21:16PM +1000, Alexis Hazell wrote: > Hi all, > > i'm having some trouble 'getting' functional dependencies in the Haskell > context (although my understanding of them in the context of relational > database theory isn't that great either). Could someone please point me > to an introduction / tutorial in this regard? I think you've already tried www.haskell.org -> wiki search ? http://haskell.org/haskellwiki/Functional_dependencies You can express this by specifying a functional dependency, or fundep for short: class Mult a b c | a b -> c where (*) :: a -> b -> c This tells Haskell that c is uniquely determined from a and b. So there you can't implement instances Mult Int Char Sting and Mult Int Char MyString of course, your programs will work withou t that | a b -> c as well, but you need to tell the compiler the result type of (*) fac1 fac2 wheeras using fundeps it knows the result type becaus there can only be one instance. (Which is what you want in this case when multiplying matrizes as well. HTH Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies
Martin Sulzmann wrote: > Mark P Jones wrote: > > In fact, the two sets of dependencies that you have given here are > > provably equivalent, so it would be decidedly odd to have a "type > > improvement" system that distinguishes between them. > Based on the FD-CHR formulation, for the single-range FD case we > get [...] which is clearly weaker. > [...] > So, I conclude that in the Haskell type improvement context > there's clearly a difference among single-range and multi-range FDs. This seems like a flaw in FD-CHR, rather than a fundamental difference between the dependencies. > Of course, we could define multi-range FDs in terms of single-range FDs > which then trivially solves the "equivalence" problem (but some user > may be disappointed that their multi-range FDs yield weaker improvement). Why not instead transform single-range FDs into multi-range ones where possible? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intro to functional dependencies in Haskell?
Hello Alexis, Thursday, April 17, 2008, 9:21:16 AM, you wrote: > i'm having some trouble 'getting' functional dependencies in the Haskell ghc 6.8 manual contains good introduction into FDs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe