tryAllIO in compiler/rename/RnHiFiles.lhs?
Hi, When I compile a HEAD version from this morning with GHC 5.02.2, there is a deprecated warning for the use of 'tryAllIO' by compiler/rename/RnHiFiles.lhs. But when I compile it with a HEAD version, it gives an error and says that Exception doesn't export 'tryAllIO' any more. When I replace 'tryAllIO' with try in both places in RnHiFiles.lhs, the HEAD compiling HEAD works ok. -- Nick Nethercote [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: tryAllIO in compiler/rename/RnHiFiles.lhs?
When I compile a HEAD version from this morning with GHC 5.02.2, there is a deprecated warning for the use of 'tryAllIO' by compiler/rename/RnHiFiles.lhs. But when I compile it with a HEAD version, it gives an error and says that Exception doesn't export 'tryAllIO' any more. When I replace 'tryAllIO' with try in both places in RnHiFiles.lhs, the HEAD compiling HEAD works ok. I have a fix for this in my tree, which I'll commit shortly. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Weird Activation Records (Fixed!)
If got the mangler to produce working code at least in some cases - I still have to chase after a segfault in one larger program that I tried to compile. That's great news! Due too my lack of Perl knowledge, I didn't yet manage to remove the jumps from the slow to the fast entry points, and a function called __DISCARD__ must be present for linking (it's never called, though). Should the old PowerPC code in the mangler be kept there? It assumes a slightly different assembler dialect and a completely different linker, and as it just asks for $TargetPlatform =~ /^powerpc|rs6000/, it keeps getting in the way... Sure, by all means remove this code. It hasn't been used for years, and we can always resurrect it from the repository if necessary. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Build problem under cygwin
I'm trying to build ghc 5.02.2 under cygwin (2.125.2.10), using gcc rather than an existing Haskell compiler. I'm running with gnu make version 3.79.1 I configured with --prefix=D:/haskell/ghc (where I've installed the package), and --enable-win32-dlls. The make process is failing (ultimately) because the genprimopcode command is being invoked before (apparently) it has been compiled. Looking back through the trace, the makefile in genprimcode is running, but then failing: should this not have terminated the entire build? syslib text -O-c Main.hs -o Main.o syslib: not found make[3]: [Main.o] Error 127 (ignored) o genprimopcode -syslib text -O Main.o o: not found make[3]: [genprimopcode] Error 127 (ignored) M -optdep-f -optdep.depend -osuf o-syslib text -O Main.hs M: not found make[3]: [depend] Error 127 (ignored) Somehow, it looks like the syslib compiler option is being incorrectly intrpreted as a make command. Looking further into the make result, a number of other commands are also failing with an ignored error 127, e.g. ==fptools== make boot - --unix - --no-print-directory -r; in /cygdrive/d/haskell/ghc/ghc/utils/hsc2hs M -optdep-f -optdep.depend -osuf o-package util -cpp -O Config.hs KludgedSy stem.hs Main.hs Config.hs M: not found make[3]: [depend] Error 127 (ignored) Again, it looks somehow that a command issued from a makefile is being truncated. I would be grateful for any comments or suggestions. thanks, David Duke -- Dr. David DukeEmail: [EMAIL PROTECTED] Department of Computer ScienceWeb: www.bath.ac.uk/~masdad/ University of BathTel: +44 1225 323 407 Bath, BA2 7AY U.K.Fax: +44 1225 323 493 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Great investment for foreign residents 4986chZG8-753WYWl15
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00E0_11B85D5D.A2864B31
class hierarchies inmature in hugs
I just saw someone misusing [EMAIL PROTECTED] for bug reports. I am going to join especially - it is a funny one, - the bug hasn't been fixed since Sep. 2001, - it is not even put in the list of known bugs since then. --- The following code works with ghc but not with hugs (incl. Dec. 2001 release) import Monad class Monad m = C1 m x -- Monad m is implied by C1 but test diverges if constraint not present class (C1 m x) = C2 m x where c2 :: x - m x instance Monad m = C1 m Bool instance C2 Maybe Bool where c2 = return test :: Maybe Bool test = c2 True --- So you see, C1 is a kind of derived from Monad. C2 is derived from C1 and hence implicitly from Monad. This is a kind of minimal example. Just attempt to evaluate test. hugs will loop. There is a way to help hugs. Add Monad m as a further class constraint to C2. Then it will work. Please note both programs do type check, and this is in fact fine. More generally, I get these looping programs whenever I have non-trivial class hierarchies with three or more layers. I guess more people should have suffered from that? Ralf -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Rectification Hugs bug
Dear all, After intensive investication of several people here at Utrecht University, these are the results 1. The very latest Hugs version doesn't have the bug 2. All before-december-2001 versions don't have the bug I were using a version downloaded some weeks ago. After installing the current distribution, the problems disappeared Therefore, I suspect there have been one or more bug-fix updates after December 2001, fixing this problem. However, I couldn't find that documented on the Hugs site. Can anyone confirm such an update? Where can I find last- minute distribution information? Thanks, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Rectification Hugs bug
Dear all, After intensive investication of several people at Utrecht University, these are the results: 1. The very latest Hugs version doesn't have the bug 2. All before-december-2001 versions don't have the bug I were using a version downloaded some weeks ago. After installing the current distribution, the problems disappeared. Therefore, I suspect there have been one or more bug-fix updates after December 2001, fixing this problem. However, I couldn't find that documented on the Hugs site. Can anyone confirm such an update? Where can I find last-minute distribution information? Thanks, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
type aliases in instances
In Haskell type aliases are not allowed in instance definitions. Is there a particular reason for this? For example, is there a problem with type inference? I noticed that when composing monads (in the Moggi/Wadler style) one easily ends up with a cascade of coercions enforced by datatype declarations. Looks a bit tedious. This can be avoided by using type aliases but then the monads in use cannot be instances of the Monad class. Phil uses aliases in his Essence of functional programming paper too. But not declaring the monads to be in class Monad can hardly be good style, can it? Many thanks for your help in advance. Bernhard --- Bernhard Reus, COGS University of Sussex ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
new version of Parser Combinators and Syntax Macros's (beta)
Title: new version of Parser Combinators and Syntax Macros's At: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing you will find the latest/greatest version of our combinators, that are: - faster (faster than Parsec) - correct much faster - compute results lazily, and produce error messages online in the IO monad while parsing (using unsafeInterleavedIO) - are compatible with the syntax macro mechanism we have implemented (beta): http://www.cs.uu.nl/~arthurb/index.html Doaitse -- -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ tel: +31 30 253 3962 fax: +31 30 251 3791 mobile: +31 6 2880 1680 __
rank-n polymorphism
Dear all, GHC 5.0.3 supports rank-n polymorphism. Could anyone please point me to a paper that describes type inference algorithm used. Thanks in advance Artem Alimarine ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
On Thursday 07 March 2002 08:26 am, you wrote:
Dear all,
GHC 5.0.3 supports rank-n polymorphism.
Could anyone please point me to a paper that describes type inference
algorithm used.
The main paper is Putting Type Annotations to Work by Odersky and Laufer:
@InProceedings{Odersky-Laufer96,
author = Martin Odersky and Konstantin L{\a}ufer,
title =Putting Type Annotations to Work,
key = Odersky \ Laufer,
pages =54--67,
booktitle =Conference Record of POPL '96: The 23rd ACM
SIGPLAN-SIGACT Symposium on Principles of Programming
Languages, St. Petersberg Beach, Florida,
year = 1996,
organization = ACM,
address = New York, NY,
month =jan,
annote = 31 references.,
}
Cheers,
Andy
--
Andy Moran Ph. (503) 526 3472
Galois Connections Inc. Fax. (503) 350 0833
3875 SW Hall Blvd.http://www.galois.com
Beaverton, OR 97005[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
Someone already sent you the Odersky paper, but in brief, there is no type inference (as it is undecidable). Rank-n polymorphism can only happen via explicit type signatures. My understanding is that if these type signatures are not there, GHC will automatically lift all the foralls to the front in type inference. - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Thu, 7 Mar 2002, Artem S Alimarine wrote: Dear all, GHC 5.0.3 supports rank-n polymorphism. Could anyone please point me to a paper that describes type inference algorithm used. Thanks in advance Artem Alimarine ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
GHC 5.0.3 supports rank-n polymorphism. Could anyone please point me to a paper that describes type inference algorithm used. Rank-n polymorphism can only happen via explicit type signatures. SPJ and I are working on a formal description of how all of this works, and should have a manuscript ready in few weeks. Yes: the inference is based on Odersky Laufer, and yes: the trick is to exploit type annotations. The full system, however, has required quite a few innovations beyond this. Our manuscript also describes how to extend Haskell with first-class existentials, in the style described in our FOOL 9 paper First-class modules for Haskell. Fun for all the family. Regards, Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Question: Database access in Haskell
Dear Sir/Madam, I am considering implement a system using Haskell. I need to use database to manage data there. How can I access the data records in database from Haskell? Thanks for your advice! Best Regards, Dianne __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
pattern-matching with labelled types
If I have:
data MyType = MT {
x :: Int,
y :: Char
}
How do I update the Int value of MyType leaving the Char value unaffected? I
tryied something like:
MT {x = newValue}
but GHC gave me a warning about the Char value and it indeed caused strange
effects. Of course, it is possible to do something like
update :: MyType - Int - MyType
update mt newValue = MT {x = newValue, y = oldValue}
where oldValue = y mt
but this really annoys me when MyType has too many fields. Suggestions?
Thanks a lot,
-- Andre
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
pattern-matching with labelled types
Andre W B Furtado writes:
:
| Of course, it is possible to do something like
|
| update :: MyType - Int - MyType
| update mt newValue = MT {x = newValue, y = oldValue}
| where oldValue = y mt
|
| but this really annoys me when MyType has too many fields. Suggestions?
update mt newValue = mt {x = newValue}
HTH.
Tom
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
labelled types efficiency
Another question about labelled types, this time concerning about
efficiency: is there any efficiency differences between functions f and g
below?
data RType = R Int Char
data Stype = S {x :: Int, y :: Char}
f :: RType - Int
f (R x _) = x
g :: SType - Int
g s = x s
Thanks again,
-- Andre
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: labelled types efficiency
Hello!
On Fri, Mar 08, 2002 at 12:52:58AM -0300, Andre W B Furtado wrote:
Another question about labelled types, this time concerning about
efficiency: is there any efficiency differences between functions f and g
below?
data RType = R Int Char
data Stype = S {x :: Int, y :: Char}
f :: RType - Int
f (R x _) = x
g :: SType - Int
g s = x s
Thanks again,
-- Andre
In principle, the representation of RType and Stype is the same.
The only difference of Stype over RType is the implicit definition
of the functions (accessors) x and y, as well as the syntactic
sugar for constructing values, pattern matching and functional
update using field names. But as said, that's just functional
sugar and should be just exactly as efficient as using the manual
translation of those constructs on RType.
Now, that said, g *looks* a bit more lazy than f, as in f, you
don't evaluate the right side if the parameter isn't
R _|_ _|_ or more. However, I said *looks*, but if one checkes,
it's thus, desugared:
f (R x _) = x
g s = x s
where
x (S xElem _yElem) = xElem
And if you just evaluate both at _|_, the result is _|_ for both
f and g. So in fact, there equally strict. Finally, the code
for f and g should, save for renaming, be just the same.
Kind regards,
Hannah.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Question: Database access in Haskell
Dear Sir/Madam, I am considering implement a system using Haskell. I need to use database to manage data there. How can I access the data records in database from Haskell? Thanks for your advice! Best Regards, Dianne __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Date Sorting...
On Fri, Mar 08, 2002, Ketil Z. Malde wrote: I don't think it's either functional nor imperative by itself. The question is how you structure it, do you say something like buffer x list y x = readFile ... y = parse x quickSort y print y (which would be imperative), or do you say something like print (quickSort (parse (readFile ...))) Unfortunately, this is wrong. You'd have to do something more like readFile ... = print . sort . parse which would be functional. Note that the only really imperative part is the sorting, which actually changes the content of y for the following part of the program. A functional implementation wouldn't destroy y, but create a new list with the elements from y in sorted order. yah. I'm not sure if that made things clearer :-) (If you really want to implement it, look at the Prelude for some help, some of the things you wish to do is pretty standard fare. And sorting is perhaps made easier if you rearrange the list of dates a bit?) Sorting is probably easiest if you use the standard sort function. I'm still kind of interested in whether anyone has done work on which purely-functional sorts are efficient, and particularly which ones are efficient in GHC. David Feuer ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
