[ ghc-Bugs-1156554 ] GHCi: No instance for (Show (IO ()))
Bugs item #1156554, was opened at 2005-03-04 10:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1156554group_id=8032 Category: GHCi Group: 6.4 Status: Open Resolution: None Priority: 4 Submitted By: Simon Marlow (simonmar) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi: No instance for (Show (IO ())) Initial Comment: From Wolfgang Thaller: This behaviour (from today's stable branch) is slightly confusing: Prelude print id Top level: No instance for (Show (IO ())) arising from use of `print' at Top level Probable fix: add an instance declaration for (Show (IO ())) In a 'do' expression: print it interactive:1:0: No instance for (Show (a - a)) arising from use of `print' at interactive:1:0-4 Probable fix: add an instance declaration for (Show (a - a)) In the definition of `it': it = print id The second message makes sense, but the first one doesn't. Also, what's the difference between Top level and interactive:1:0? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1156554group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
adjustor creation not supported on x86_64
Hi, I built and installed wxhaskell-0.9 with ghc-6.2.2 on x86_64. When I link a sample program and try to run it however, I get: wxhaskell-0.9/samples/wx% ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ Jens ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-6.4 -M does not respect {-# OPTIONS -fglasgow-exts #-} pragma
On 03 March 2005 22:18, Duncan Coutts wrote:
In ghc 6.4 using -M mode it appears to be stricter when parsing the
files looking for dependencies. In particular importing things with
'#' suffixes eg:
import GHC.Really.Really.Internal.Dont.Touch (unsafeNastyThing#)
did not require the -fglasgow-exts option. In ghc 6.4 it does require
this (which is not unreasonable).
However then it does not look at the {-# OPTIONS -fglasgow-exts #-}
pragma at the top of the file.
I'll go fix my build system to always supply -fglasgow-exts when
calculating dependencies.
Strange... it works for me. ghc -M now uses the same machinery as
--make when calculating the dependency graph, so {-# OPTIONS #-} should
work as normal.
Can you send us the source file that fails?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1153674 ] #line pragmas not respected inside nested comments
Bugs item #1153674, was opened at 2005-02-28 18:09
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
Category: Compiler (Parser)
Group: 6.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Simon Marlow (simonmar)
Summary: #line pragmas not respected inside nested comments
Initial Comment:
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
[EMAIL PROTECTED]
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * string
main = putStrLn $ show c
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * string
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx filename
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen [EMAIL PROTECTED]
--
Comment By: Simon Marlow (simonmar)
Date: 2005-03-04 11:17
Message:
Logged In: YES
user_id=48280
Thanks for the report.
GHC does recognise the #line pragmas generated by gcc/cpp,
but unfortunately it doesn't respect them inside {- -} comments.
To fix your example, just remove the {- -} comments around
the C comment.
It isn't an easy fix, so I've renamed the bug and downgraded
it for now.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1156596 ] Simplifier doesn't preserve bottoms sometimes
Bugs item #1156596, was opened at 2005-03-04 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1156596group_id=8032 Category: Compiler Group: 6.4 Status: Open Resolution: None Priority: 4 Submitted By: Simon Marlow (simonmar) Assigned to: Simon Peyton Jones (simonpj) Summary: Simplifier doesn't preserve bottoms sometimes Initial Comment: Here's a test due to Iavor Diatchki [EMAIL PROTECTED]: test2 :: Bool test2 = stops (bot ()) where stops :: Int# - Bool stops _ = True ghc 6.4 gives the value True for test2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1156596group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1122207 ] EVACUATED object entered!
Bugs item #1122207, was opened at 2005-02-14 08:11 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1122207group_id=8032 Category: None Group: 6.2.2 Status: Closed Resolution: None Priority: 5 Submitted By: Manpreet Singh (manpreet) Assigned to: Nobody/Anonymous (nobody) Summary: EVACUATED object entered! Initial Comment: darcs.exe: internal error: EVACUATED object entered! Please report this as a bug to glasgow-haskell-bugs@haskell.org, http://www.sourceforge.net/projects/ghc/ -- Comment By: Simon Marlow (simonmar) Date: 2005-03-04 11:22 Message: Logged In: YES user_id=48280 No chance to reproduce. -- Comment By: Manpreet Singh (manpreet) Date: 2005-02-15 16:57 Message: Logged In: YES user_id=79084 I am using darcs 1.0.2 on Windows XP SP2. I've since deleted the setup. I will try to see if it happens again but the chances are slim. -- Comment By: Simon Marlow (simonmar) Date: 2005-02-15 12:48 Message: Logged In: YES user_id=48280 What platform are you on? Do we have any hope of reproducing this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1122207group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1153674 ] #line pragmas not respected inside nested comments
Bugs item #1153674, was opened at 2005-02-28 18:09
Message generated for change (Comment added) made by malcolmwallace
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
Category: Compiler (Parser)
Group: 6.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Simon Marlow (simonmar)
Summary: #line pragmas not respected inside nested comments
Initial Comment:
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
[EMAIL PROTECTED]
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * string
main = putStrLn $ show c
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * string
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx filename
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen [EMAIL PROTECTED]
--
Comment By: Malcolm Wallace (malcolmwallace)
Date: 2005-03-04 11:31
Message:
Logged In: YES
user_id=129223
Just to mention that cpphs would be a solution - by default,
it leaves
the C comment intact within a Haskell comment. Even with
the --strip and --text options, it replaces the C comment
with equivalent whitespace to preserve the layout.
--
Comment By: Simon Marlow (simonmar)
Date: 2005-03-04 11:17
Message:
Logged In: YES
user_id=48280
Thanks for the report.
GHC does recognise the #line pragmas generated by gcc/cpp,
but unfortunately it doesn't respect them inside {- -} comments.
To fix your example, just remove the {- -} comments around
the C comment.
It isn't an easy fix, so I've renamed the bug and downgraded
it for now.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-6.4 -M does not respect {-# OPTIONS -fglasgow-exts #-} pragma
On Fri, 2005-03-04 at 10:49 +, Simon Marlow wrote:
However then it does not look at the {-# OPTIONS -fglasgow-exts #-}
pragma at the top of the file.
Strange... it works for me. ghc -M now uses the same machinery as
--make when calculating the dependency graph, so {-# OPTIONS #-} should
work as normal.
Can you send us the source file that fails?
Ah, you're quite right. The reason the option is not recognised is
because there is a comment on the same line:
{-# OPTIONS -fglasgow-exts #-} --due to use of unsafeCoerce#
When I strip off the comment it works.
I didn't notice it was not working previously since the Makefile
specifies -fglasgow-exts when compiling the file (but not when
calculating deps).
Duncan
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
calling MacOS X experts
Calling MacOS X experts... Sorry to pollute the ghc list with nhc98 questions, but AFAIK most of the relevant people inhabit here. Any help would be gratefully received. I am having problems with getting nhc98 to work under Mac OS 10.3.x. It builds just fine with ghc (6.2.2), and appears to compile programs just fine, but the resulting executables sometimes crash with Bus Error. (make test gives 55 runtime failures + 55 successes, out of 110 tests.) The evidence is that there is some incompatibility between Apple's latest gcc (3.3) and nhc98, because if I set the configuration to use gcc2 (2.95.2) instead, there are no failures and all 110 tests succeed. So, what subtle incompatibilities might be lurking between versions of gcc here? I know that Apple introduced some interesting dead-code stripping stuff which could conceivably be responsible here. Other Apple-specific features include lazy dynamic loading of symbols. Are there any other likely culprits? Might I need to link against some frameworks? Any ideas how to track this down further? Regards, Malcolm ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: calling MacOS X experts
On Fri, Mar 04, 2005 at 04:37:27PM +, Malcolm Wallace wrote: I am having problems with getting nhc98 to work under Mac OS 10.3.x. It builds just fine with ghc (6.2.2), and appears to compile programs just fine, but the resulting executables sometimes crash with Bus Error. (make test gives 55 runtime failures + 55 successes, out of 110 tests.) The evidence is that there is some incompatibility between Apple's latest gcc (3.3) and nhc98, because if I set the configuration to use gcc2 (2.95.2) instead, there are no failures and all 110 tests succeed. FWIW I also had problems on powerpc Linux (Debian). IME compiling with ghc rather than gcc tends to have a better chance of succeeding, but if compiling with gcc wouldn't have succeeded then the ghc-compiled nhc98 doesn't work properly either. Compiling with gcc 3 I got a segfault compiling DErrNo.hs: http://buildd.debian.org/fetch.php?pkg=nhc98ver=1.16-12arch=powerpcstamp=1099697591file=logas=raw For now I just use gcc-2.95 on powerpc. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4 snapshot installer available
Hi Sigbjorn. I wrote: I built CVS head GHC with this package and mucked around a little bit. The only problem I've come across so far is that an objectio library application I have crashes on take-off when built with this compiler (not necessarily to do with objectio of course). It does not crash with GHC 6.2.1 Woops. It turns out that I missed a blatantly obvious error message which 6.2.1 did not give: Starting program: c:\data\source\ghc\grass/./objectio/geo.exe grass/./objectio/geo.exe: main.hs:23:8-70: Irrefutable pattern failed for patter n [fileMenuID, mapMenuID, grassDBMenuID] after I shortened a list of ids. Luckily this afternoon I took delivery of a pair of reading glasses which will hopefully help me to avoid such errors in future. Thumbs up for that installer. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1155875 ] Arbitrary function sections
Feature Requests item #1155875, was opened at 2005-03-03 16:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1155875group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Dinko Tenev (a0s) Assigned to: Nobody/Anonymous (nobody) Summary: Arbitrary function sections Initial Comment: For operators we have the following shorthand: op :: a - b - c (`op` y) === \x - x `op` y (x `op`) === \y - x `op` y It would be nice to have a similar facility for functions, e.g.: f :: a - b - c - d - e f _ y _ t === \x z - f x y z t f x _ z _ === \y t - f x y z t f x _ z === \y - f x y z === \y t - f x y z t Because _ is currently not allowed as an identifier in contexts where this facility could possibly be in effect, it seems safe to use it to indicate omitted parameters in function application. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1155875group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 02 March 2005 14:15, John Goerzen wrote: Kip Macy kip.macy at gmail.com writes: I've followed the instructions to the letter. Debian has had a working amd64 package of ghc for some time now. It is built out of the standard source base for it. You can find that at: http://ftp.debian.org/debian/pool/main/g/ghc6 You'll want to grab the orig.tar.gz and the diff.gz files. If you want to grab an amd64 .deb to try, go to: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/ Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
I think GHC's behaviour is right here. To use the flag settings from
the source module on the command-line would be wrong: for example, when
the module is compiled, its implementation (and therefore flag settings)
must be hidden.
Also, as Simon pointed out, there might be multiple modules in scope at
the prompt, so how do you resolve the flag settings if they're
contradictory?
In general, flag settings affect the current source file only. The flag
settings at the GHCi prompt are those given on the command line and from
:set - it's simple, no worrying about where did that option come from?
I don't want overlapping instances!.
Cheers,
Simon
On 02 March 2005 18:33, Keean Schupke wrote:
Erm, what is the module context of GHCi? I thought ghci
used the context of the loaded module:
ghci Test.hs
*Test
I though the 'Test' in the prompt indicated you were in the context of
the Test module. In which case the pragma at the top of the test
module should be in force?
Keean.
Simon Peyton-Jones wrote:
Ah, yes. In 6.2, overlap errors were checked and reported eagerly
at the instance declaration. So instance C Int a
instance C b Bool
was rejected. Now it isn't. Instead the program is only rejected
if a constraint arises that matches two instance decls, and neither
is more specific. For example (C Int Bool)
But many constraints are fine e.g. C Int Char
However this does have the consequence that the overlapping-instance
flag must be on in the module that calls the function rather than the
one that defines the instances. It'd be better if the info
travelled with the instance decl, but it doesn't (yet). A good
feature request.
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of
Keean Schupke
Sent: 02 March 2005 17:20
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: GHC 6.4 release candidates available
In the past having:
{-# OPTIONS -fallow-overlapping-instances #-}
in a module was enough to get ghci to allow the overlaps.
so we do:
ghci Test.hs
now it does not work (but it did in 6.3), but:
ghci -fallow-overlapping-instances Test.hs
does... Even it Test.hs is the top level module.
Keean.
Simon Peyton-Jones wrote:
Ralf
You have a pragma -fallow-overlapping-instances in Test.hs, and
indeed it is honoured when compiling Test.hs. But it's not taken
into account when compiling top-level expressions, or, indeed, if
you were to import Test into another module.
If you say :set -falllow-overlapping-instances it'll work fine.
Now, maybe you'd like the flag to attach permanently to the
*instance*, so that if an instance decl is compiled with
-fallow-overlapping-instances, then no complaint will ever be
issued for its overlaps, even if it is imported into a module that
doesn't have -fallow-overlapping-instances. That would make
sense, I think, but it's not implemented and never has been.
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of
Ralf Lammel
Sent: 02 March 2005 08:45
To: glasgow-haskell-users@haskell.org
Subject: RE: GHC 6.4 release candidates available
I think this is an old bug,
or at least I have seen it months back.
The overlapping instances directive does not make it to the
top-level. See attached sample with the offending session.
Thanks for fixing.
Ralf
___
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
___
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
ANNOUNCE: The GHC Survey 2005
Just ahead of the 6.4 release, we've put together a GHC user survey. The idea is to help us get a better understanding of who uses GHC, what for, what aspects of GHC they consider most valuable, and what they would most like to see improved. The survey is anonymous (if you wish), and should take about 5 minutes to complete. We will use the information to help guide what we do in future, and to help justify what to do. Have your say! We'll also be publishing lots of cool stats once we have enough responses. Here's the link: http://www.haskell.org/ghc/survey/start.cgi Many thanks to Tomasz Zielonka for putting together the survey, which is implemented using WASH on GHC (of course). Simon M, on behalf of the GHC Team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
Simon Marlow ([EMAIL PROTECTED]) wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... :- As soon as you have some pre-alpha release, I'm ready to test ;) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. The whole point of putting options at the top of the source file is so that the user/compiler of the code does not need to know which specific options are required. If the code specifies overlapping instances, I don't expext to have to specify it on the command line as well. Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Also, as Simon pointed out, there might be multiple modules in scope at the prompt, so how do you resolve the flag settings if they're contradictory? Only the flags from the top level (the one named before the prompt) would be in scope. If I type: ghci Test.hs Then I would expect the options pragma in Test.hs to be in effect. In general, flag settings affect the current source file only. The flag settings at the GHCi prompt are those given on the command line and from :set - it's simple, no worrying about where did that option come from? I don't want overlapping instances!. I really don't like GHCi users needing to know what flags they must use to get code to work. There must be some way of code asserting top level options. If the options pragma cannot be used for this purpose I suggest there should be another way for code to assert top level options of ghci... this method should be in the source file so that extra options files are not required... Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 04 March 2005 12:58, Keean Schupke wrote: There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. No, you can have multiple top-level module scopes in effect. See the GHCi documentation. Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back. Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope). If you could specify overlapping on a per-instance basis, then that would be a way around the problem. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... That would be great! I just assembled an amd64 box and I am mssing ghci badly. Let me know if I can be of any help (testing ..). Cheers, Ralf ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available (breakage on x86-64)
On 02 March 2005 05:08, Brian Strand wrote: Donald Bruce Stewart wrote: bstrand: Donald Bruce Stewart wrote: bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don Using SplitObjs=NO gives out many warnings then finally dies with: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks. Try building unregisterised: GhcUnregisterised=YES just as the .hc bootstrap compiler was built. -- Don Well, I don't know much about how the bootstrap compiler was built (I just downloaded it from http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/), but building with GhcUnregisterised=YES and SplitObjs=NO died with: ==fptools== make all -wr; in
Re: x86_64 port
On Fri, Mar 04, 2005 at 09:38:47AM -, Simon Marlow wrote: Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Simon Marlow wrote: On 04 March 2005 12:58, Keean Schupke wrote: There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. No, you can have multiple top-level module scopes in effect. See the GHCi documentation. But I can also have just one top level module ... Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back. But what if it is an application and not a library... you definitely do not wantr to have to explain in the user manual that ghci needs to be started with: ghci -fglasgow-exts -fallow-overlapping-instances ... Further more it is the _importing_ module that needs to have overlapping instances defined, therefore there is absolutely no chance of them being turned on behind your back. Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope). It would not... All I am saying is if the top level module in GHCi (the one named in the prompt) has OPTIONS pagmas these should be in effect. If you could specify overlapping on a per-instance basis, then that would be a way around the problem. This worked in all GHCi before 6.4 - so something has broken the (in mu opinion) correct behavior. Was this a deliberate decision - or has something just changed without anyone realising? Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4 Release Candidate Binary for Mac OS X
I've uploaded a Mac OS X installer based on the stable tree from March 2nd + the patches I committed yesterday at: http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip This package is built with support for dynamic libraries (some human intervention was required to build it). Mac users, please start testing and send lots of feedback to me and to the list. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 14:04, John Goerzen wrote: On Fri, Mar 04, 2005 at 09:38:47AM -, Simon Marlow wrote: Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). I don't know if I can work around it yet. We'll see. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 Release Candidate Binary for Mac OS X
Wolfgang Thaller [EMAIL PROTECTED] wrote: I've uploaded a Mac OS X installer based on the stable tree from March 2nd + the patches I committed yesterday at: http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip $ ghc --version dyld: /usr/local/lib/ghc-6.4/ghc-6.4 can't open library: /Users/wolfgang/GHC/stable-build/libraries/readline/libHSreadline_dyn.dylib (No such file or directory, errno = 2) Trace/BPT trap Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 16:59, John Goerzen wrote: On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
On 4-Mar-05, at 11:57 AM, Simon Marlow wrote: Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). So maybe this will be the first NCG-only port of GHC :-). Death to the Mangler! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Further to my last point, what if the top level module is Main... ghci Main.hs and that includes a main function, and pragmas, so that main runs when ghci is finished loading (automatically). If main runs automatically then the context of ghci must be the Main module, so why would the options pragmas not be in effect? for example: ghc -o test Main.hs needs no flags and I can then run test with no flags (./test). But: ghci Main.hs Now all of a sudden you are telling me I need to provide command line flags to get it to run (in the interpreter) but I do not need to if I use the compiler... (remember this worked fine in 6.3 and 6.3 included the new lazy instance overlap detection) This seems very inconsistant to me... I really like the ability to put any flags code might need into the source using the OPTIONS pragmas... but it seems to undermine the usefulness of this if ghci ignores the flags. Keean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4 snapshot installer available
New installer available that includes all STABLE changes up until 20:00 UTC today: http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050304.msi ( md5.sig: 022bfcaae335b718bdc59014d58b39a0 ) --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: GHC users glasgow-haskell-users@haskell.org Sent: Tuesday, March 01, 2005 15:37 Subject: 6.4 snapshot installer available http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) the only known omission from the bits intended to be included in the release proper is the PDF version of the user's guide. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: The GHC Survey 2005
Just ahead of the 6.4 release, we've put together a GHC user survey. The idea is to help us get a better understanding of who uses GHC, what for, what aspects of GHC they consider most valuable, and what they would most like to see improved. The survey is anonymous (if you wish), and should take about 5 minutes to complete. We will use the information to help guide what we do in future, and to help justify what to do. Have your say! We'll also be publishing lots of cool stats once we have enough responses. Here's the link: http://www.haskell.org/ghc/survey/start.cgi Many thanks to Tomasz Zielonka for putting together the survey, which is implemented using WASH on GHC (of course). Simon M, on behalf of the GHC Team ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] integration of functional and imperative programming concepts
for my diploma thesis, I need to find information about integration of functional and imperative programming concepts. Could somebody of you point me to good websites, papers, etc. about this topic? You haven't been too specific about what kinds of things you are looking for. One thing that you might find useful is, http://www.mm.informatik.tu-darmstadt.de/~kuehne/fps/. Also there are plenty of functional-object-oriented languages. Checking the paper listings of FOOL conferences should provide many other papers. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
On Sunday 20 February 2005 14:19, Keean Schupke wrote: TH has supported multi-parameter classes for a while... new in 6.4 is support for fundeps. Yes, but unfortunately TH cannot create instances for them which is usually the boilerplate you want to avoid. From Language.Haskell.TH: data Dec = ... ClassD Cxt Name [Name] [FunDep] [Dec] InstanceD Cxt Type [Dec] ... Only one 'Type' can be given for an instance. Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
On Fri, 4 Mar 2005 15:26:52 +0100, Benjamin Franksen [EMAIL PROTECTED] wrote: On Sunday 20 February 2005 14:19, Keean Schupke wrote: TH has supported multi-parameter classes for a while... new in 6.4 is support for fundeps. Yes, but unfortunately TH cannot create instances for them which is usually the boilerplate you want to avoid. From Language.Haskell.TH: data Dec = ... ClassD Cxt Name [Name] [FunDep] [Dec] InstanceD Cxt Type [Dec] ... Only one 'Type' can be given for an instance. And there _should_ only be one type. Checkout 'appT'. Some real documentation for TH would clear misconceptions such as this. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
Lemmih wrote: On Fri, 4 Mar 2005 15:26:52 +0100, Benjamin Franksen [EMAIL PROTECTED] wrote: On Sunday 20 February 2005 14:19, Keean Schupke wrote: TH has supported multi-parameter classes for a while... new in 6.4 is support for fundeps. Yes, but unfortunately TH cannot create instances for them which is usually the boilerplate you want to avoid. From Language.Haskell.TH: data Dec = ... ClassD Cxt Name [Name] [FunDep] [Dec] InstanceD Cxt Type [Dec] ... Only one 'Type' can be given for an instance. And there _should_ only be one type. Checkout 'appT'. Some real documentation for TH would clear misconceptions such as this. Is that really how this is done? That doesn't seem like it can be right: instance X (a b) -- single parameter class where 'a' has an arrow kind is very different from: instance X a b-- multiple parameter class I would expect a type constructed with 'appT' to correspond to the first declaration, and not to the second. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
robert dockins wrote: Is that really how this is done? That doesn't seem like it can be right: instance X (a b) -- single parameter class where 'a' has an arrow kind is very different from: instance X a b-- multiple parameter class I would expect a type constructed with 'appT' to correspond to the first declaration, and not to the second. Yup, thats how it is done, I have some complex working TH that generates multi parameter classes with fundeps instances etc... and I can say for definite it all works fine: For the above examples appT X (appT a b) -- X is applied once (to a applied to b) appT (appT X a) b -- X is applied twice first to a then to b Keean. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
On Friday 04 March 2005 16:32, Keean Schupke wrote: robert dockins wrote: Is that really how this is done? That doesn't seem like it can be right: instance X (a b) -- single parameter class where 'a' has an arrow kind is very different from: instance X a b-- multiple parameter class I would expect a type constructed with 'appT' to correspond to the first declaration, and not to the second. Yup, thats how it is done, I have some complex working TH that generates multi parameter classes with fundeps instances etc... and I can say for definite it all works fine: For the above examples appT X (appT a b) -- X is applied once (to a applied to b) appT (appT X a) b -- X is applied twice first to a then to b But this has nothing to do with the instance question. I agree with Robert that AppT a b definitely sounds like type constructor application. How can this help with multi parameter class instances? Consider: class Bogus a b instance Bogus Int Char How do you express the /instance/ in TH? Using AppT? AppT would make sense for instance Show a = Show [a] where ... where one would express the '[a]' in TH as AppT ListT (VarT mkName a) Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
On Friday 04 March 2005 23:44, Keean Schupke wrote: Benjamin Franksen wrote: Consider: class Bogus a b instance Bogus Int Char How do you express the /instance/ in TH? Using AppT? That would be: (using 6.4 syntax) AppT (AppT (ConT (mkName Bogus)) (ConT ''Int)) (ConT ''Char) If the instance is using type variables: instance Bogus Int a you get: AppT (AppT (ConT (mkName Bogus)) (ConT ''Int)) (VarT (mkName a)) OK, I can see now that this makes sense syntactically. Still, it is strange that the class name is handled as if it were a type constructor. Anyway, thanks. Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Corba and Haskell
Hi, Have you guys used any Corba library for Haskell? Which one would you recommend (if there are more than one)? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State Monad
On Fri, 4 Mar 2005, Mark Carroll wrote: (snip) Enclosed is a programme that asks for two ints from standard input, adds (snip) Let me try again. (-: -- Markmodule StackMTest where import StackM import Control.Monad import Control.Monad.Trans import System.IO import System.Random add :: Num a = StackM a IO () add = do x - popM y - popM pushM (x + y) throwTenDie :: StackM Int IO () throwTenDie = lift (getStdRandom (randomR (1, 10))) = pushM stackMTest :: StackM Int IO Int stackMTest = do pushNumber pushNumber throwTenDie add add popM where pushNumber = do text - lift $ getLine pushM (read text) main :: IO () main = runStackM stackMTest = print ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State Monad
Thinking of stacks, I've often wondered if Haskell would be a good language for implementing a PostScript interpreter. I actually have the beginning of a PostScript interpreter somwhere... And the core of a Joy interpreter is extremely small. It's pretty much 'foldl compose . map interpretWord'. Of course, I implemented a Joy interpreter in the slightly sugared lambda calculus that lambdabot's @eval module supports so... (Crap, I actually want to find it (the PostScript interpreter) now.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Joy Combinators (Occurs check: infinite type)
Recently, while investigating the (non-statically typed) stack-based
functional language Joy (http://www.latrobe.edu.au/philosophy/phimvt/joy.html),
I became interested in seeing if I could implement Joy's combinators in
Haskell. I started with a stack based implementation using nested
tuples as the stack. Things worked out well until I got to the
recursion combinators. Even then, things didn't seem that bad, since
Haskell was able to infer types for the the linrec and genrec
combinators. Trouble popped up when I tried to apply the recursion
operators to a function (in this case calculating the humble factorial).
In the code below, fact3,4 5 all fail with an Occurs check that
looks something like the following...
joy3.hs:24:
Occurs check: cannot construct the infinite type: t = (a, t)
Expected type: ((a5 - (a, (a, t)), a5) - (a, t),
((a1, t3) - (a1, (a1, t3)),
((a2, t2) - (a2, t2), ((a3, t1) - (Bool, t1),a4
- c
Inferred type: ((a5 - (a, (a, t)), a5) - (a, (a, t)),
(a5 - a5, (a5 - (a, (a, t)), (a5 - (Bool, b),a5
- (a, (a, t))
...Normally, I would have given up and declared that Joy wasn't an easily
typed language, but I'm motivated to dig further because if you remove
the type signature from fact below, it also fails with an Occurs
check. So, can anyone direct me towards more information on exactly
what an Occurs check is, or does anyone see an easy fix to my
problems?
Thanks,
Greg Buchholz
P.S. The first thing you should note about the code below is the
definition of the reverse composition operator (!), which I used to give
the program a more Joy-like feel. (i.e. (!) f g = g.f)
--Joy combinators in Haskell
main = do print $ ((lit 6) ! fact) bot-- factorial of 6
print $ ((lit 2) ! square ! fact2) bot -- factorial of 4
bot = EOS -- end of stack
square = dup ! mult
cube = dup ! dup ! mult ! mult
--In Joy: factorial == [0 =] [pop 1] [dup 1 - factorial *] ifte
fact :: (Integer, a) - (Integer, a)
fact = (quote ((lit 0) ! eq)) !
(quote (pop ! (lit 1))) !
(quote (dup ! (lit 1) ! sub ! fact ! mult)) !
ifte
--In Joy: [1 1] dip [dup [*] dip succ] times pop
fact2 = (quote ((lit 1) ! (lit 1)))
! dip ! (quote (dup ! (quote mult) ! dip ! suc))
! times ! pop
{- fact3,4 5 don't type check, fails with...
-- Occurs check: cannot construct the infinite type:
--In Joy: [null] [succ] [dup pred] [i *] genrec
fact3 :: (Integer, a) - (Integer, a)
fact3 = (quote nul) ! (quote suc) ! (quote (dup ! pre)) ! (quote (i ! mult))
! genrec
fact4 :: (Integer, a) - (Integer, a)
fact4 = genrec.quote(mult.i).quote(pre.dup).quote(suc).quote(nul)
--In Joy: [null] [succ] [dup pred] [*] linrec
fact5 :: (Integer, a) - (Integer, a)
fact5 = quote(nul) ! quote(suc) ! quote(dup ! pre) ! quote(mult) ! linrec
--}
nul = (lit 0) ! eq
suc = (lit 1) ! add
pre = (lit 1) ! sub
linrec (rec2, (rec1, (t, (p, stack
| fst (p stack) == True = (t stack)
| otherwise = rec2 (linrec (rec2, (rec1, (t, (p, (rec1 stack))
genrec (rec2, (rec1, (t, (b, stack
| fst (b stack) == True = (t stack)
| otherwise = (rec2.quote(genrec.quote(rec2).quote(rec1).
quote(t).quote(b))) (rec1 stack)
times (p, (n, stack)) | n0 = times (p, (n-1, (p stack)))
| otherwise = stack
(!) f g = g.f
i(a, b) = (a b)
add (a, (b, c)) = (b+a, c)
sub (a, (b, c)) = (b-a, c)
mult (a, (b, c)) = (b*a, c)
swap (a, (b, c)) = (b, (a, c))
pop (a, b) = b
dup (a, b) = (a, (a, b))
dip (a, (b, c)) = (b, (a c))
eq (a, (b, c)) | a == b= (True, c)
| otherwise = (False,c)
ifte (f, (t, (b, stack))) | fst (b stack) == True = (t stack)
| otherwise = (f stack)
lit val stack = (val, stack) -- push literals on the stack
quote = lit
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HAppS -- Haskell Application Server v 0.3
HAppS is a Haskell library for building Internet applications, featuring: * HAppS.ACID: Guarantee application integrity in the face of unplanned outages using this module's integrated write-ahead logging and checkpointing framework. * HAppS.DBMS: Do relational operations in Haskell (rather than SQL) on Haskell sets (outside the IO Monad). Define custom indices for your Haskell datatypes (e.g. geographic/geometric types). Use in combination with ACID for a robust relational DBMS customized for your application. * HAppS.Protocols: Expose your application using as an HTTP server and/or by recieving and sending SMTP. Changes since 0.2: HAppS Changes * Much cleaner interface for ACID transaction handlers * DBMS operators that look more like HaskellDB operators * SMTP send errors are exposed for use in future reliable deliver implementation * ACID callbacks disabled. Framework in place for total order on callbacks. * SideEffect queues are now algrebraic types rather than strings. * Parametrized HTTP using XML ToElement and HTTP ToMessage FromMessage and ToURI classes (you write transaction handlers in terms of Haskell types and the system takes care of exposing them for HTTP) * Parametrized HTTP response now has type (ToURL url,ToMessage msg)=Response url message Framework takes care of automatically translating relative URLs to absolute URLs. Answers to questions a few people have asked: * Compare HAppS.DBMS with HaskellDB HaskellDB is really optimal if you want to talk to external databases. HAppS.DBMS is really good if you want to do relational operations on Haskell Sets without going to the IO monad. * Compare HAppS.ACID to STM Use STM if all your IO operations have a two-phase-commit interface. Use HAppS.ACID if your IO interfaces are not transactional. Instead HAppS.ACID gives you multi-queue, at-least-once execution of side-effects, and a total order on their callbacks. There is no rollback semantic because you can't unsend email. * Compare HAppS.Protocols.SMTP to Peter Simon's Postmaster Postmaster is trying to be a full fledged MTA. SMTP is trying simply to give you SMTP receive/send functionality in your applications. Neither yet has a queuehandler. We both hope to merge lessons learned soon. * Compare HAppS.Protocols.HTTP to Warrick Gray's Network.HTTP module Network.HTTP is more oriented towards building HTTP clients. HAppS..HTTP is more oriented towards building HTTP servers. Network.HTTP enforces a stronger separation between headers and body. HAppS..HTTP delivers a MIME message back to the app. With infrastructure to enable transparent conversion to and from application datatypes. -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
