Re: Type Families and enhanced constraints (at run-time)
insert :: Char - Set t Char - Set t Char insert c (Set tinfo cs) = case c of 'A' - Set (InsA tinfo) (c:cs) _ - error not a label gives me the error: Occurs check: cannot construct the infinite type: t = A t When generalising the type(s) for `insert' Failed, modules loaded: none. To do what you are trying to do, it seems that you would also need to be able to write a function whose return type depended on a simple parameter value: foo :: Char - ??? Seems impossible. With GADTs, you can of course go the other way: data A data B data Chr a where AChr :: Chr A BChr :: Chr B toChar :: Chr a - Char toChar AChr = 'A' toChar BChr = 'B' So perhaps insert should have a type something more like: type family ChrSetIns a t :: * insert :: Chr a - ChrSet t - ChrSet (ChrSetIns a t) I'm not sure how to make the set type parametric in the element type, though. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cabal for ghc 6.8.2, package upgrade warnings, please?
assuming that ghc 6.8.2 is not too far away, is there any chance of cabal becoming a bit friendlier wrt old .cabal and Setup files, before that release? you've heard me say before that i'd have preferred a backwards compatibility module, but if that isn't possible, couldn't cabal at least detect that a .cabal file is probably outdated (==not obviously up to date), and issue a warning with a helpful url? something like: $ runhaskell Setup configure *** warning: this .cabal/Setup file might be out of date; *** if you run into issues, please contact the *** package maintainer, and have a look at *** http://haskell.org/haskellwiki/Upgrading_packages .. (either it works or you get errors here, but you already know something is not quite right, and what to do about it) btw, i knew that page existed, but had quite a bit of trouble finding it. shouldn't there be prominent links to it from cabal and hackage home pages? as in: concerning recent cabal updates (look here first if you have trouble with old .cabal packages). in the longer term, that could become the start of a cabal/hackage faq section.. claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC generated dll makes Excel crash on exit.
Sorry if I'm talking to myself, but I found a solution and thought it could
be interesting for other people who need to call GHC created DLLs from
Excel.
The solution is based on the information found in :
http://haskell.org/haskellwiki/GHC/Using_the_FFI#Debugging_Haskell_DLLs.
As suggested, I added two extra functions in my dllMain.c file (adder_Begin,
adder_End) and removed the startupHaskell call from the dllMain function.
adder_Begin contains the startupHaskell call and adder_End the
shutdownHaskell. dllMain just returns true. I also adapted the Excel VBA
code to call adder_Begin on a WorkBook_Open event and adder_End on a
WorkBook_BeforeClose event.
The VBA looks like this:
Public functions in a new Module1 module (cannot declare Public functions
in the ThisWorkbook module):
Public Declare Function adder Lib adder.dll Alias [EMAIL PROTECTED] (ByVal
x As
Long, ByVal y As Long) As Long
Public Declare Function adder_Begin Lib adder.dll () As Boolean
Public Declare Sub adder_End Lib adder.dll ()
Private functions the the ThisWorkbook module:
Private Sub Workbook_BeforeClose(Cancel As Boolean)
adder_End
End Sub
Private Sub Workbook_Open()
adder_Begin
End Sub
The GHC dllMain.c looks like this:
#include windows.h
#include Rts.h
#define __ADDER_DLL_EXPORT
#define ADDER_API _declspec(dllexport)
extern void __stginit_Adder(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL STDCALL DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
){
return TRUE;
}
ADDER_API BOOL adder_Begin(){
startupHaskell(1, args, __stginit_Adder);
return HS_BOOL_TRUE;
}
ADDER_API void adder_End(){
shutdownHaskell();
}
If somebody wants the code and Excel file, just ask, I'll be happy to
provide it.
Thanks,
Olivier.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddocumentation of 6.8.1
Am Freitag, 30. November 2007 15:23 schrieb Daniel Fischer: Question 2: When I build a package via Cabal, is there a way to merge the documentation into the installed library docs (and if yes, how do I do it)? I think, if you do runhaskell Setup.[l]hs haddock before runhaskell Setup.[l]hs install then the latter installs the Haddock-generated API documentation and this documentation will be linked to by future Haddock-generated documentations when using Cabel to make them. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
Lemmih wrote: On Nov 30, 2007 12:36 PM, Simon Marlow [EMAIL PROTECTED] wrote: Alex Jacobson wrote: $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskell haskell/Main.hs Prelude :r I don't see any unnecessary reloading here: Ok, modules loaded: [snip]. *Main :r Ok, modules loaded: [snip]. Tried this on both x86_64/Linux (Fedora 6) and x86/Linux (RedHat 7). Any idea what might be different about your setup? It reloads all modules after an error has occurred. Wow! You're right. Thanks for the tip, I'm investigating. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type Families and enhanced constraints (at run-time)
On Fri, 2007-11-30 at 13:37 +1100, Manuel M T Chakravarty wrote: [...] In other words, first you need to decide what properties you want to enforce and what information you need to decide those properties. Coming back to your set example, what properties do you want to enforce/check and what information do you need to do that? In the extreme case, you could reflect the entire contents of each set at the type-level using a singleton set type (and corresponding singleton types for the set elements). However, that also would mean that all your value-level set operations will already have to be completely executed by the type checker at compile time, which is probably not what you want. Does this make sense? Yes, and thanks for your reply. What I really need are both ends of the spectrum! It's reasoning with these sets that is important to me and the contents are arbitrary, so operations on them should become proof-carrying code, but they should be constructable at run-time. This will obviously require that two sets with different elements have different types so I thought about carrying around the extra info alongside the regular collection: data N ; data A tail ; data B tail data TInfo t where Nil :: TInfo N InsA :: TInfo t - TInfo (A t) InsB :: TInfo t - TInfo (B t) empty = Nil a_empty = InsA empty data Set t a = Set (TInfo t) [a] So a value of type Set t Char might have the type Set (TInfo (A (B N))) ['a', 'b'] and I can start creating type families to enforce constraints. But this doesn't work: insert :: Char - Set t Char - Set t Char insert c (Set tinfo cs) = case c of 'A' - Set (InsA tinfo) (c:cs) _ - error not a label gives me the error: Occurs check: cannot construct the infinite type: t = A t When generalising the type(s) for `insert' Failed, modules loaded: none. I can see why that would be, but what type should the final t be? Is there a way to get round it or is this type of thing restricted to the type-level only? Thanks, Jim Manuel Jim Burton: Hi, I hope this is the right place to ask about working with type families...I want to make a library of Set operations that carries proofs at the type level, e.g. to make things like this possible, insert :: Member e s' T = e - Set s - Set s' union :: Union s t u = Set s - Set t - Set u The trouble is designing the Set datatype so it can be used in type constraints *and* in run-time functionsSomething similar is of course possible with fun deps, and I knocked something up following the example of Conrad Parker's 'Instant Insanity' but, crucially, that code is 'trapped' in the type system with no populated types. I want term-level/run-time functions with enhanced constraints, such as in the example Manuel posted in haskell-cafe: data Z data S a data SNat n where Zero :: SNat Z Succ :: SNat n - SNat (S n) zero = Zero one = Succ zero type family (:+:) n m :: * type instance Z :+: m = m type instance (S n) :+: m = S (n :+: m) add :: SNat n - SNat m - SNat (n :+: m) add Zero m = m add (Succ n) m = Succ (add n m) This seems like the best of both worlds -- maybe it could be a general strategy for making for making these enhanced constraints at the term-level? Make a (populated) GADT and parameterise it with a phantom type (perhaps amongst other things). Make a type operator that can be used to express the constraint on the phantom types carried around by the regular populated type. When the type operator appears in the codomain of the function it's a compile-time check on the implementation of that function and when in the domain it checks the user at run- time. However, (SNat n) can be put very succinctly because it doesn't need to carry a value around other than the Peano number in the phantom type. What about Sets? In my case the values in the sets are just labels and could well be empty: data A ; data B ; data C And I also need to express the cons-ness -- I don't think that needs fancy constraints so it can be done with terms, e.g., an underlying sequence such as in the Collects example. Generally I need to work out what needs to be run-time and what compile-time but I think that would follow from getting the combinations of types and terms in the Set abstraction right...could someone give me a pointer with this? Many thanks, Jim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haddocumentation of 6.8.1
Yesterday, doing runghc ./Setup.hs haddock in zlib.0.4.0.1, I noticed that no Haddock docs have been built for my 6.8.1. I followed the usual building steps, which worked with previous GHCs, set XMLDocWays=html, then ./configure make make install make install-docs No library docs (users guide and Cabal manual are fine). I looked around in a couple of Makefiles, tried 'make doc' in libraries, that built docs, but Haddock couldn't make any cross-package links and libraries/index.html links to package/Package-Name.html, which doesn't exist, because it's package/dist/doc/html/package/Package-Name.html. Question 1: How do I get proper library documentation? Question 2: When I build a package via Cabal, is there a way to merge the documentation into the installed library docs (and if yes, how do I do it)? Feature request: Could the README in future please contain information on how to build library documentation properly? Thanks, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
On Nov 30, 2007 12:36 PM, Simon Marlow [EMAIL PROTECTED] wrote: Alex Jacobson wrote: $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskell haskell/Main.hs Prelude :r I don't see any unnecessary reloading here: Ok, modules loaded: [snip]. *Main :r Ok, modules loaded: [snip]. Tried this on both x86_64/Linux (Fedora 6) and x86/Linux (RedHat 7). Any idea what might be different about your setup? It reloads all modules after an error has occurred. -- Cheers, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
Alex Jacobson wrote: $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskell haskell/Main.hs Prelude :r I don't see any unnecessary reloading here: Ok, modules loaded: [snip]. *Main :r Ok, modules loaded: [snip]. Tried this on both x86_64/Linux (Fedora 6) and x86/Linux (RedHat 7). Any idea what might be different about your setup? Also, HAppS.Server.Facebook takes forever to compile. I don't understand why. That module did take about 15 seconds to load up in GHCi. It looks like it contains quite a few datatypes and a lot of derived instances (derived using TH), so my guess is it's just large. Does it take significantly longer to compile with 6.8.1, or has it always been slow? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC porting to FreeBSD-amd64 progress report
W.B. Kloke wrote: In my effort to produce a working FreeBSD-amd64 compiler I made some progress. Now I have a working stage1/ghc-inplace (which is a 32bit executable producing 64bit code). But the compilation of rts fails in file Apply.cmm with the following message: == gmake all -r; in /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/rts ../compiler/ghc-inplace -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o In file included from Apply.cmm:13:0: /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/includes/Cmm.h:333:2: error: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake[1]: *** [Apply.o] Error 1 gmake: *** [stage1] Error 1 This is, of course, because the derived constants SIZEOF_mp_limb_t is wrong. Is there a way to get to a working system from this intermediate stage? Are you following the porting instructions in http://hackage.haskell.org/trac/ghc/wiki/Building/Porting? I would expect SIZEOF_mp_limb_t to be correct, as it is generated by mkDerivedConstants. Perhaps you compiled mkDerivedConstants as a 32-bit executable? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC porting to FreeBSD-amd64 progress report
Simon Marlow [EMAIL PROTECTED] schrieb: Perhaps you compiled mkDerivedConstants as a 32-bit executable? Yes. I was not attentive enough. But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is interested, I shall prepare a package of the installed binaries. The compiler is good enough to compile itself now. Though there are problems remaining. One the programs I tested the computation of Meertens numbers from Bird/Wadler's book. This program segfaults on amd64, but not on i386. Here it is: module Main(main,primes,sieve,meertens) where -- a Meertens number is one whose decimal representation conincides with -- its Gödel number -- The 1st is 81312000 = 2^8*3*5^3*7*11^2 main :: IO() main = do putStr ( show ( meertens 8 ) ) -- putStr ( show ( meertens 9 ) ) primes= sieve [2..] sieve (p : nos) = p: sieve(remove (multsof p) nos ) where multsof p n = n `rem` p == 0 remove p= filter (not.p) powers p= iterate (p*) 1 meertens k = [n| (n,g) - candidates (0,1),n == g ] where candidates= concat . map ( search pps ) . tail . labels ps ps : pps = map powers ( take k primes ) search [] x = [x] search (ps : pps) x = concat ( map ( search pps ) (labels ps x )) labels ps (n,g) = zip ( map (m+) ds)(chop(map(g*)ps)) where m = 10 * n chop = takeWhile( 100) ds= [0..9] -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC generated dll makes Excel crash on exit.
Just a short addition to my previous e-mail: I just found an old thread which looks very similar to the problem I just described: http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs:-Bug-in-shutdownHaskell--t1206938.html I also tried to prevent the RTS from installing signal handers (it was mentionned in bug report #804 as something that could crash a dll). I put 'char *ghc_rts_opts = --install-signal-handlers=no;' in a c file and linked it to the DLL. But it doesn't solve the problem. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
