- Glasgow-haskell-users

RE: Partial application of type constructors?
by Simon Peyton-Jones 20 Apr '05

20 Apr '05

Allowing partially applied type synonyms amounts to allowing lambda at the type level, and that requires higher-order unification, and loses principal types (I think). So as of today, they are definitely out. If you look at the paper about "boxy types" on my home page, you'll see ways of extending type inference to support higher rank types and impredicativity. Next on the list is lambdas at the type level, in the same spirit: that is, support type inference by asking the programmer to help at "key moments". But don't hold your breath. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Conal Elliott | Sent: 19 April 2005 05:21 | To: glasgow-haskell-users(a)haskell.org | Subject: Partial application of type constructors? | | GHC 6.4 objects to the following simple program, pointing to the partial | application of the type constructor AddL. Is there a work-around? | | {-# OPTIONS -fglasgow-exts #-} | data LMap a b | type AddL arr a b = a `arr` LMap a b | data DFunA arr a b = DFunA (a `arr` b) (DFunA (AddL arr) a b) | | The complete error message: | | Type synonym `AddL' should have 3 arguments, but has been given 1 | When checking the data constructor: | forall arr a b. DFunA (arr a b) (DFunA (AddL arr) a b) | In the data type declaration for `DFunA' | | Is there a serious difficulty with handling partial type applications? | | - Conal | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

How to write an interpreter?
by Santoemma Enrico 20 Apr '05

20 Apr '05

Hello, may somebody give the directions to write an interpreter in Haskell? Is the parsec package enough, or I'll also need to write a 'grammar' and feed some tool with it? I want to put the language's source into xml and parse the file at runtime, so an embedded language isn't the right choice, I guess. Thanks, Enrico

2 1

RE: Edison Libraries in ghc 6.4
by Simon Marlow 20 Apr '05

20 Apr '05

On 17 April 2005 11:28, Carlos Areces wrote: > We are using Glasgow Haskell for the implemenation of a theorem > prover. > We use the Edison Libraries for efficient implementations of Sets and > Heaps. > We have a stable version of the prover with no problems and fairly > good performance working on ghc 6.2. > We have just installed ghc 6.4 and when compiling the source code > we've > received many warnings like the following one: > > ./src/hylores/ComplClauseSet.hs:51:0: > Warning: Deprecated use of type constructor or class `Min' > (imported from MinHeap) > This module is unmaintained, and will disappear soon > > We are making heavy use of types from the Edison library, so we > get quite a number of warnings, implying changes all over our code to > correct them. > > Which are exactly the problems with the Edison Library? And > what's its future with respect to ghc? Edison hasn't been converted to use hierarchical modules, and it doesn't have an active maintainer. Also, we're trying to slim down the default GHC install and move more libraries into external packages. We don't have any plans to replace it, except that we will provide a few of the more common concrete data structures (eg. Data.Map, Data.Set). We hope that third-party data structure libraries will fill the gap. Cheers, Simon

2 1

Why this happens?
by Santoemma Enrico 19 Apr '05

19 Apr '05

I've always thought that compilers for functional languages were able to recognize tail recursion and to transform it into a loop. So, why this line eats all my machine's memory (and then runs out of stack space)? sum [1..10000000] -- ten millions Enrico

2 1

RE: runghc badly broken
by Simon Marlow 19 Apr '05

19 Apr '05

On 18 April 2005 19:33, Niklas Broberg wrote: >> I'm trying to use runghc (6.4 release version, redhat linux), but it >> appears to be badly broken. It only processes the first argument >> given to it... > [snip] > > As a friend pointed out to me, some of this behavior may not be so > strange. Clearly, if you give arguments _after_ the specified source > file, you expect these to be arguments to that source file and not to > runghc itself. Thus the example > --------------------------- >> runghc Foo.hs -v1 > hello > --------------------------- > > executes as expected, since Foo.hs makes no use of -v1. That leaves > the other case, when the argument(s) is given _before_ the file > argument. It's obviously possible to give flags to runghc, shown by > runghc being verbose in the example > --------------------------- >> runghc -v1 Foo.hs > Loading package base-1.0 ... linking ... done. > > <interactive>:1:78: > Failed to load interface for `Main': > Could not find module `Main': > it is not a module in the current program, or in any known > package. Leaving GHCi. > --------------------------- > > but only the first one is processed. IMHO the preferred behavior is > that any arguments given before the single file argument is given to > runghc itself, while any given after the file argument is given to the > script in that file. Comments? Ok, I can make this change unless there are any objections? Cheers, Simon

1 0

RE: runghc and .ghci
by Simon Marlow 19 Apr '05

19 Apr '05

On 16 April 2005 04:58, John Meacham wrote: > I notice that my .ghci is sourced for programs run via runghc > (runhaskell). This is causing trouble because I have things like >> set +t +s and other options which mess up the running of many >> scripts. Yes, runghc should ignore .ghci. I'll fix that. Cheers, Simon

1 0

RE: Porting the GHC to GNU/Hurd
by Simon Marlow 19 Apr '05

19 Apr '05

On 14 April 2005 10:48, Ross Paterson wrote: > On Sun, Apr 10, 2005 at 10:39:08PM +0100, Simon Marlow wrote: >> On 10 April 2005 14:20, Thomas Schwinge wrote: >>> [ Grrr. Why do I have to subscribe just to post this message? ] >> >> Sorry for the inconvenience, it's because I don't have time to wade >> through all the spam. > > Is it possible to allow subscribers of any haskell.org lists (or just > haskell) to post to all other lists? Making it easier for people to > post to the appropriate list is another kind of spam control. It doesn't look lke Mailman provides a way to do this, though I agree it would be a good idea. Cheers, Simon

1 0

RE: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat
by Simon Marlow 19 Apr '05

19 Apr '05

On 12 April 2005 15:22, Bulat Ziganshin wrote: > mingw32 have 32-bit off_t type; access to large files are supported > with special functions and structures defined in msvcrrt.dll: > > _CRTIMP __int64 __cdecl _lseeki64(int, __int64, int); > _CRTIMP __int64 __cdecl _telli64(int); > _CRTIMP int __cdecl _fstati64(int, struct _stati64 *); > _CRTIMP int __cdecl _stati64(const char *, struct _stati64 *); > struct _stati64 { > .... > __int64 st_size; > .... > }; > > so, we need either > 1) define COff to __int64 instead of off_t and rewrite existing > functions to work with 64 bit filesizes > or > 2) define new set of low-level functions to work with 64 bit > filesizes. define high-level functions in terms of these 64-bit > functions on Win32 > > what solution will be better? in the first case COff no longer will be > equal to off_t, what some applications can imply. in the second case > we will add a lot of duplicating code COff should be the same as off_t, because it is expose to the via Foreign.C.Types. For the I/O library, however, you could use the 64-bit interfaces explicitly (probably confininng the changes to System.Posix.Internals). Unix systems ususally require you to #define something to get access to the 64-bit off_t, we rely on autoconf to tell us what this is. Cheers, Simon > is there any other (GHC-supported) environments supporting 64 bit > filesizes, but having only 32-bit off_t? > > (sorry for my bad English, i'm too far from native speaker) > > > > Friday, April 08, 2005, 3:33:36 PM, you wrote: > >> By all means. If someone cares to send us a patch, we'll incorporate >> it. > >>> While GHC I/O library on mingw32 platform perfectly reads and writes >>> files larger than 4 GB, functions hFileSize/c_fstat, >>> hSetFileSize/c_ftruncate and c_stat are still tied to C functions >>> returning 32 bit values and as a result truncate larger sizes to >>> their low 32 bits. Can this behaviour be fixed in the next bug-fix >>> version?

1 0

RE: hi-boot and dependencies bug?
by Simon Marlow 19 Apr '05

19 Apr '05

I expect this is the same bug we fixed in 6.4 recently. One workaround is to mention the missing module explicitly on the ghc command line, to force it to be included in the program. Cheers, Simon On 16 April 2005 17:30, Simon Peyton-Jones wrote: > 6.4 does mutual recursion much much better. See the manual. Don't > expend much effort on mutual recn in 6.2 > > S > >> -----Original Message----- >> From: glasgow-haskell-users-bounces(a)haskell.org >> [mailto:glasgow-haskell-users- bounces(a)haskell.org] On Behalf Of >> Isaac Jones >> Sent: 16 April 2005 01:46 >> To: GHC-users list >> Cc: Simon Marlow >> Subject: hi-boot and dependencies bug? >> >> Greetings. >> >> I haven't tested this with ghc 6.4 yet, and I don't know if this is a >> known problem. I noticed this while building support for cabal. >> >> I have two mutually recursive modules, prepared as described in the >> GHC 6.2 user's manual: A and B >> >> I create A.hi-boot >> in B, in import {-source-} A >> >> This works fine. But now I create C, which imports B (not A). When >> I compile with --make, A does not get built, and I get a link-time >> error. >> >> However, if C imports A directly, it builds everything just fine. >> >> I've attached a tarball with the example. Test it like this: >> >> % ghc --make C.hs >> Chasing modules from: C.hs >> Compiling B ( ./B.hs, ./B.o ) >> Compiling Main ( C.hs, C.o ) >> Linking ... >> ./B.o(.text+0x1b): In function `__stginit_B_': >>> undefined reference to `__stginit_A_' >> collect2: ld returned 1 exit status >> >> >> >> peace, >> isaac >> >> p.s. please CC me on replies; i'm not subscribed to this mailing list

1 0

Partial application of type constructors?
by Conal Elliott 19 Apr '05

19 Apr '05

GHC 6.4 objects to the following simple program, pointing to the partial application of the type constructor AddL. Is there a work-around? {-# OPTIONS -fglasgow-exts #-} data LMap a b type AddL arr a b = a `arr` LMap a b data DFunA arr a b = DFunA (a `arr` b) (DFunA (AddL arr) a b) The complete error message: Type synonym `AddL' should have 3 arguments, but has been given 1 When checking the data constructor: forall arr a b. DFunA (arr a b) (DFunA (AddL arr) a b) In the data type declaration for `DFunA' Is there a serious difficulty with handling partial type applications? - Conal

2 1