From s-thapa-11@alumni.uchicago.edu Mon Jan 1 02:35:41 2001
Date: Sun, 31 Dec 2000 20:35:41 -0600
From: Suchandra Thapa s-thapa-11@alumni.uchicago.edu
Subject: Problems compiling hugs with glibc 2.2
The Gnu libc v2.2 changes the type definition
of fpos_t from a long to a struct with a
long int(__pos) and a structure dealing with conversions
of multibyte characters(_mbstate). This causes the compilation
of iomonads.c to fail with errors at lines 715 and
736 since fpos_t seems to be treated as a long. A quick fix
that seems to work is to change config.h to comment out the
defines for fgetpos and fseekpos. I tried making the
appropriate changes in the references to variables of type
fpos_t but I got a compilation error and didn't investigate
further. Also the pos member of the fpos_t is a 64 bit
integer so that files greater than 2GB can be manipulated.
It seems that the current typecast from fpos_t to int seems
to have the potential for problems with files greater than
2GB on 32bit platforms. FYI, glibc is currently only used on
redhat 7 systems but other linux distributions will probably migrate
to it in the future.
Shop Safely Online Without a Credit Card
http://www.rocketcash.com
From haberg@matematik.su.se Wed Jan 3 18:01:38 2001
Date: Wed, 3 Jan 2001 19:01:38 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: GHC/Happy on MacOS X/Darwin
[Replies please cc me or the hugs-bugs list, as I currently is not on the
Haskell list.]
At 11:05 +0100 1-01-03, Atze Dijkstra wrote:
>On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc
>(4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded.
>However, a few remarks do apply: this version of ghc is not a completely
>ported version but built with generic settings and meant as a
>bootstrapping compiler. It also is distributed as binaries for a specific
>location (/usr/local/{ghc,happy}) in the UNIX directory structure. The
>main reasons for distributing it in this unfinished form are:
>- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>problems with asm statements) which hinder progress.
Isn't this related to the "munging" that GHC makes use of on other platforms?
>- I consider 'unfinished' availability now of greater importance than
>'perfect' availability later, so people can play with it.
>- The compiler seems to run ok, that is, after minimal testing (compiling
>ghc libraries and a local AG + parsercombinator system).
Otherwise it sounds great: As no-one before has been able to port anything
of GHC to MacOS (as far as I know), any kind of progress is important. (I
do not have access to MacOS X right now, so unfortunatley I cannot try out
your port.)
Hans Aberg
From atze@cs.uu.nl Wed Jan 3 19:48:59 2001
Date: Wed, 3 Jan 2001 20:48:59 +0100
From: Atze Dijkstra atze@cs.uu.nl
Subject: GHC/Happy on MacOS X/Darwin
At 19:01 +0100 03/01/2001, Hans Aberg wrote:
> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>problems with asm statements) which hinder progress.
>
>Isn't this related to the "munging" that GHC makes use of on other platforms?
Apple's cc (actually gcc) does not accept 'asm' statements the way the manual describes it (it fails to parse them). asm statements are used to map GHC runtime pseudo registers to actual powerpc machine registers. The assembly source postprocessing does not work either (it is turned off) but is not related to this problem (to my knowledge).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From haberg@matematik.su.se Wed Jan 3 20:03:56 2001
Date: Wed, 3 Jan 2001 21:03:56 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: GHC/Happy on MacOS X/Darwin
At 20:48 +0100 1-01-03, Atze Dijkstra wrote:
>At 19:01 +0100 03/01/2001, Hans Aberg wrote:
>> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>>problems with asm statements) which hinder progress.
>>
>>Isn't this related to the "munging" that GHC makes use of on other platforms?
>
>Apple's cc (actually gcc) does not accept 'asm' statements the way the
>manual describes it (it fails to parse them). asm statements are used to
>map GHC runtime pseudo registers to actual powerpc machine registers. The
>assembly source postprocessing does not work either (it is turned off) but
>is not related to this problem (to my knowledge).
I think that it was Will Partain that described the problem as though one
had to do some assembly local to the CPU in order to get put the munging
through (perhaps I misunderstood it). -- So even if Apple's gcc accepted
asm, there would some (hard) work to do, in figuring out how the PPC (G3 &
G4) assmebly worked.
Hans Aberg
From jpiitula@ling.helsinki.fi Mon Jan 8 16:00:08 2001
Date: 08 Jan 2001 18:00:08 +0200
From: Jussi Piitulainen jpiitula@ling.helsinki.fi
Subject: No runhugs for Macintosh?
Hello,
not really a bug, but either there is an omission on a Macintosh, or I
failed to find the way. I would like to run a completed program
without the need to talk to it: just click a script that launches Hugs
with one program after another, and I'd go away for a while or at
least take my fingers off the keyboard and mouse.
There doesn't seem to be an option to run a main function
automatically. When I open Hugs with Control or Command, I can tell it
to read its standard input from a file, which would be fine, if I
didn't need to be in the loop myself.
A separate application like the runhugs in unixen might be best. An
option to run a main function or to read commands from a file might be
second best. Well, the best would be to learn that I just overlooked
something and it can already be done. Help?
By the way <http://www.haskell.org/implementations> still doesn't
mention Macintosh.
--
Jussi
From haberg@matematik.su.se Mon Jan 8 18:14:06 2001
Date: Mon, 8 Jan 2001 19:14:06 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: No runhugs for Macintosh?
At 18:00 +0200 1-01-08, Jussi Piitulainen wrote:
>I would like to run a completed program
>without the need to talk to it: just click a script that launches Hugs
>with one program after another, and I'd go away for a while or at
>least take my fingers off the keyboard and mouse.
>
>There doesn't seem to be an option to run a main function
>automatically. When I open Hugs with Control or Command, I can tell it
>to read its standard input from a file, which would be fine, if I
>didn't need to be in the loop myself.
>
>A separate application like the runhugs in unixen might be best. An
>option to run a main function or to read commands from a file might be
>second best. Well, the best would be to learn that I just overlooked
>something and it can already be done. Help?
The MacOS replacement of UNIX command line arguments is AppleEvent's: High
level events that programs can use to communicate with each other (as
opposed to low level events that the OS uses to communicate with programs).
There is an experimental MacHugs implementation that can accept and send
arbitrary AppleEvent's.
I think you might achieve what you want by writing an AppleScript that
first opens this experimental MacHugs with suitable source files, and then
sends to it a suitable AppleEvent. When MacHugs receives this event, a
special function
receive :: Event -> IO ()
is executed that has the AppleEvent translated into a string as an
argument. You then define this function "receive" to call whatever other
function you want to be executed.
This MacHugs version is experimental, because the Hugs kernel isn't thread
safe, so if it receives several ApppleEvent's to be executed in parallel or
while it is already computing something, something might break. In your
case, I think it would work OK, but know you know of it.
If you want, I can send you the sources or a binary (but you will have to
do the AppleScript programming yourself).
Hans Aberg
From jpiitula@ling.helsinki.fi Mon Jan 8 19:43:54 2001
Date: 08 Jan 2001 21:43:54 +0200
From: Jussi Piitulainen jpiitula@ling.helsinki.fi
Subject: No runhugs for Macintosh?
Hans Aberg <haberg@matematik.su.se> writes:
> At 18:00 +0200 1-01-08, Jussi Piitulainen wrote:
>> I would like to run a completed program without the need to talk to
>> it: just click a script that launches Hugs with one program after
>> another, and I'd go away for a while or at
[...]
> There is an experimental MacHugs implementation that can accept and
> send arbitrary AppleEvent's.
This sounds very good.
[...]
> This MacHugs version is experimental, because the Hugs kernel isn't
> thread safe, so if it receives several ApppleEvent's to be executed
> in parallel or while it is already computing something, something
> might break. In your case, I think it would work OK, but know you
> know of it.
Is it otherwise stable?
It seems like it should be sufficient. I'd only need to send it one
event - gotta learn about that anyway, but an example or two would be
nice - and perhaps there's a way for the sender to wait for the
recipient to finish or something.
> If you want, I can send you the sources or a binary (but you will
> have to do the AppleScript programming yourself).
Can I have a binary, please, and I'll struggle with AppleScript by
myself. I've already been able to start Hugs from a script. This is
an iMac, I have Stuffit Expander, mail comes to a Unix machine, and
I'm a bit confused but usually lucky about moving things between here
and there.
Thanks a lot,
--
Jussi
From haberg@matematik.su.se Tue Jan 9 09:36:16 2001
Date: Tue, 9 Jan 2001 10:36:16 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: No runhugs for Macintosh?
At 21:43 +0200 1-01-08, Jussi Piitulainen wrote:
>> This MacHugs version is experimental, because the Hugs kernel isn't
>> thread safe, so if it receives several ApppleEvent's to be executed
>> in parallel or while it is already computing something, something
>> might break. In your case, I think it would work OK, but know you
>> know of it.
>
>Is it otherwise stable?
If one does not send it an AppleEvent it behaves exactly as before, and I
do not think there is any problem if it is not already computing.
Otherwise, you will have to figure it out; that's why it is experimental.
>It seems like it should be sufficient. I'd only need to send it one
>event - gotta learn about that anyway, but an example or two would be
>nice - and perhaps there's a way for the sender to wait for the
>recipient to finish or something.
You will have to figure this out.
>> If you want, I can send you the sources or a binary (but you will
>> have to do the AppleScript programming yourself).
>
>Can I have a binary, please, and I'll struggle with AppleScript by
>myself.
Next email (not posted to this list).
Hans Aberg
From wli@holomorphy.com Thu Jan 11 04:07:57 2001
Date: Wed, 10 Jan 2001 20:07:57 -0800
From: William Lee Irwin III wli@holomorphy.com
Subject: hugs compilation error on Debian woody
--dWYAkE0V1FpFQHQ3
Content-Type: text/plain; charset=us-ascii
Content-Description: brief message
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In file included from builtin.c:1431:
iomonad.c: In function `primHGetPosn':
iomonad.c:715: aggregate value used where an integer was expected
iomonad.c: In function `primHSetPosn':
iomonad.c:730: invalid initializer
iomonad.c:736: incompatible types in assignment
is the error I'm encountering. It seems to be that the semantics of
fgetpos and fsetpos in glibc have changed. What I've come up with is
a hack, but it appears to restore hugs to a state where it can compile.
A unified diff which appears to repair these errors follows:
diff -urN --exclude=3D*.in --exclude=3Dconfigure --exclude=3D*.h --exclude=
=3Dhugs.* hugs98/src/iomonad.c hugs98-98.200002/src/iomonad.c
--- hugs98/src/iomonad.c Tue Feb 29 02:29:00 2000
+++ hugs98-98.200002/src/iomonad.c Wed Jan 10 19:10:05 2001
@@ -709,7 +709,7 @@
Int h;
HandleArg(h,3);
if (handles[h].hmode!=3DHCLOSED) {
-#if HAVE_FGETPOS
+#if HAVE_FGETPOS && !defined(__linux__)
fpos_t pos;
if (fgetpos(handles[h].hfp,&pos)) {
IOReturn(mkInt((Int)pos));
@@ -726,7 +726,7 @@
}
=20
primFun(primHSetPosn) { /* Set file position */
-#if HAVE_FSETPOS
+#if HAVE_FSETPOS && !defined(__linux__)
fpos_t pos =3D 0;
#elif HAVE_FSEEK
long pos =3D 0;
@@ -735,7 +735,7 @@
HandleArg(h,3);
IntArg(pos,4);
if (handles[h].hmode!=3DHCLOSED) {
-#if HAVE_FSETPOS
+#if HAVE_FSETPOS && !defined(__linux__)
if (fsetpos(handles[h].hfp,&pos)) {
IOReturn(nameUnit);
}
--dWYAkE0V1FpFQHQ3
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6XTGdD5IAOwBGvKIRAm+JAJ9H41YYktJxwBZJjHAmDJbSgZCmeQCfSXEq
4CTJsc7ea25r8DZltSWXoF8=
=zSkg
-----END PGP SIGNATURE-----
--dWYAkE0V1FpFQHQ3--
From mpj@cse.ogi.edu Mon Jan 15 10:01:27 2001
Date: Mon, 15 Jan 2001 02:01:27 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Yet more on functional dependencies
| I am finding functional dependencies confusing. (I suspect I am=20
| not alone.) Should the following code work?
|=20
| class HasConverter a b | a -> b where
| convert :: a -> b
|=20
| instance (HasConverter a b,Show b) =3D> Show a where
| show value =3D show (convert value)
It's a separate issue. There's no reason why a system using
functional dependencies *should* support this. But it is an
attractive and useful extension that such a system would
probably *want* to include. (i.e., it's a desirable feature,
not a requirement.)
I typed your example into Hugs on my machine and it seemed to
accept the syntax (which suggests that the implementation is
intended to allow this kind of thing). But then it choked on
the definition with a curious error message that I suspect is
an indication of a bug in Hugs' treatment of functional
dependencies. And, for that reason, I'm crossposting this
message to hugs-bugs. [Let me take the opportunity to remind
good readers of these lists that it is now more than a year
since I retired from the joys of maintaining Hugs, so I'm not
planning to try and track down the source of this bug myself!]
Of course, it could be that my version of Hugs is out of date!
All the best,
Mark
From med018509@nacom.es Sat Jan 13 20:08:45 2001
Date: Sat, 13 Jan 2001 21:08:45 +0100
From: Roberto Barrios med018509@nacom.es
Subject: Bug?
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C07DA5.03FC0DE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi. I'm a computer engineering student and use with Hugs98, which helps =
me a lot in learning fuctional programming.
I've noticed that the WinHugs application eats 100% of the available CPU =
even when it isn't doing any work, just blinking the cursor!!!=20
I use CPUIddle to cool-down my processor and I saw a noticeable increase =
in CPU temperature whenever WinHugs was opened, although out of focus =
and without any task running.
This is not a major problem, but if it could be solved easily, =
overclocked CPUs would not crash under WinHugs and batteries in LapTops =
would last longer.
Thanks !!!!!!!!!
Roberto Barrios,=20
Facultad de Inform=E1tica, Universidad Complutense de Madrid
------=_NextPart_000_0005_01C07DA5.03FC0DE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi. I'm a computer engineering student =
and use with=20
Hugs98, which helps me a lot in learning fuctional =
programming.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I've noticed that <STRONG>the WinHugs =
application=20
eats 100% of the available CPU </STRONG>even when it isn't doing any =
work, just=20
blinking the cursor!!! </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I use CPUIddle to cool-down my =
processor and I saw=20
a noticeable increase in CPU temperature whenever WinHugs was opened, =
although=20
out of focus and without any task running.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>This is not a major problem, but if it =
could be=20
solved easily, overclocked CPUs would not crash under WinHugs and =
batteries in=20
LapTops would last longer.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks !!!!!!!!!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Roberto Barrios, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Facultad de Inform=E1tica, Universidad =
Complutense de=20
Madrid</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01C07DA5.03FC0DE0--
From jeff@galconn.com Mon Jan 15 16:36:52 2001
Date: Mon, 15 Jan 2001 08:36:52 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Yet more on functional dependencies
Mark P Jones wrote:
> | I am finding functional dependencies confusing. (I suspect I am
> | not alone.) Should the following code work?
> |
> | class HasConverter a b | a -> b where
> | convert :: a -> b
> |
> | instance (HasConverter a b,Show b) => Show a where
> | show value = show (convert value)
>
> It's a separate issue. There's no reason why a system using
> functional dependencies *should* support this. But it is an
> attractive and useful extension that such a system would
> probably *want* to include. (i.e., it's a desirable feature,
> not a requirement.)
>
> I typed your example into Hugs on my machine and it seemed to
> accept the syntax (which suggests that the implementation is
> intended to allow this kind of thing). But then it choked on
> the definition with a curious error message that I suspect is
> an indication of a bug in Hugs' treatment of functional
> dependencies. And, for that reason, I'm crossposting this
> message to hugs-bugs. [Let me take the opportunity to remind
> good readers of these lists that it is now more than a year
> since I retired from the joys of maintaining Hugs, so I'm not
> planning to try and track down the source of this bug myself!]
> Of course, it could be that my version of Hugs is out of date!
Could you share the error message please. Boy, even old maintainers don't know how to submit a bug report... ;-)
Actually, I suspect whatever the problem was has been fixed, because (with -98 +o), it compiles fine. (I'm using the bleeding edge, out-of-the-repository version.)
--Jeff
From haberg@matematik.su.se Mon Jan 15 19:43:31 2001
Date: Mon, 15 Jan 2001 20:43:31 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Bug?
At 21:08 +0100 1-01-13, Roberto Barrios wrote:
> Hi. I'm a computer engineering student and use with Hugs98, which
>helps me a lot in learning fuctional programming. I've noticed that the
>WinHugs application eats 100% of the available CPU even when it isn't
>doing any work, just blinking the cursor!!! I use CPUIddle to
>cool-down my processor and I saw a noticeable increase in CPU temperature
>whenever WinHugs was opened, although out of focus and without any task
>running.
This sounds as though it could be due to the fact MSOS uses cooperative
multitasking, and WinHugs doesn't release any time to other programs. (In
which case it is not a "bug", but a "feature".)
Hans Aberg
From mpj@cse.ogi.edu Mon Jan 15 22:41:33 2001
Date: Mon, 15 Jan 2001 14:41:33 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Bug?
Hi Roberto,
| I've noticed that the WinHugs application eats 100% of the available =
CPU even
| when it isn't doing any work, just blinking the cursor!!!
This is a well-known problem with the WinHugs user interface, and is one
of the reasons why use of WinHugs has been discouraged. The user manual
comments on this, for example, but perhaps the wording should be =
stronger!
WinHugs was even left out of the Hugs distribution at one stage because
these problems were felt to be too severe. But people still asked for =
it
and so WinHugs made it back into the distribution ...
The WinHugs interface eats CPU because of the style in which it was =
written.
The original author of the WinHugs GUI, Pepe Gallardo, did produce a =
newer
version that avoided these problems, but I don't know what happened to =
it;
I'm not aware of a source for it on the web. Pepe, if you're out there,
I'm sure folks like Roberto would be happy to hear from you!
In the meantime, I wouldn't recommend using WinHugs for everyday use.
All the best,
Mark
From pepeg@lcc.uma.es Tue Jan 16 10:57:21 2001
Date: Tue, 16 Jan 2001 11:57:21 +0100
From: Pepe Gallardo pepeg@lcc.uma.es
Subject: Bug?
You can get the version that solves this problem from
http://www.lcc.uma.es/~pepeg/software/winhugsFeb2000exe.zip
--pepeg
>
> ----- Original Message -----
> From: "Mark P Jones" <mpj@cse.ogi.edu>
> To: "Roberto Barrios" <med018509@nacom.es>; <hugs-bugs@haskell.org>
> Cc: "Mark P. Jones" <mpj@cse.ogi.edu>
> Sent: Monday, January 15, 2001 11:41 PM
> Subject: RE: Bug?
>
>
> Hi Roberto,
>
> | I've noticed that the WinHugs application eats 100% of the available CPU
> even
> | when it isn't doing any work, just blinking the cursor!!!
>
> This is a well-known problem with the WinHugs user interface, and is one
> of the reasons why use of WinHugs has been discouraged. The user manual
> comments on this, for example, but perhaps the wording should be stronger!
> WinHugs was even left out of the Hugs distribution at one stage because
> these problems were felt to be too severe. But people still asked for it
> and so WinHugs made it back into the distribution ...
>
> The WinHugs interface eats CPU because of the style in which it was
written.
> The original author of the WinHugs GUI, Pepe Gallardo, did produce a newer
> version that avoided these problems, but I don't know what happened to it;
> I'm not aware of a source for it on the web. Pepe, if you're out there,
> I'm sure folks like Roberto would be happy to hear from you!
>
> In the meantime, I wouldn't recommend using WinHugs for everyday use.
>
> All the best,
> Mark
>
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-bugs
>
>
From kahl@heraklit.informatik.UniBw-Muenchen.de Wed Jan 17 14:44:58 2001
Date: 17 Jan 2001 14:44:58 -0000
From: kahl@heraklit.informatik.UniBw-Muenchen.de kahl@heraklit.informatik.UniBw-Muenchen.de
Subject: ``Magic'' Ord defaulting?
Hi all,
a student of mine was puzzled by the following output,
where, what appears to be equivalent expressions,
yields non-equivalent results:
========================================================================
kahl@dionysos:/tmp/will > hugs Tree.hs
__ __ __ __ ____ ___ _________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: February 2000 _________________________________________
Haskell 98 mode: Restart with command line option -98 to enable extensions
Reading file "/usr/global/share/hugs/lib/Prelude.hs":
Reading file "Tree.hs":
Hugs session for:
/usr/global/share/hugs/lib/Prelude.hs
Tree.hs
Type :? for help
Main> printH (listToTree [1,2,3,4,5])
[]
[1]--|
[]
[2]--|
[]
[3]--|
[]
[5]--|
[]
[4]--|
[]
Elapsed time (ms): 20 (user), 10 (system)
Main> listToTree [1,2,3,4,5]
Node 5 (Node 4 (Node 3 (Node 2 (Node 1 Empty Empty) Empty) Empty) Empty) Empty
Elapsed time (ms): 20 (user), 0 (system)
Main> printH (Node 5 (Node 4 (Node 3 (Node 2 (Node 1 Empty Empty) Empty) Empty) Empty) Empty)
[]
[5]--|
[]
[4]--|
[]
[3]--|
[]
[2]--|
[]
[1]--|
[]
Elapsed time (ms): 30 (user), 0 (system)
========================================================================
for the following definitions:
========================================================================
data Tree a = Empty | Node a (Tree a) (Tree a)
deriving Show
insert :: (Ord a, Show a) => Tree a -> a -> Tree a
insert Empty a = Node a Empty Empty
insert (Node a left right) new
| new < a = Node a (insert left new) right
| otherwise = Node a left (insert right new)
listToTree :: (Ord a, Show a) => [a] -> Tree a
listToTree [] = Empty
listToTree (x:xs) = insert (listToTree xs) x
printH :: ((Ord a, Show a) => Tree a) -> IO() -- Problem here!
printH t = putStr (hilf1 t 0)
hilf1 :: (Ord a, Show a) => Tree a -> Int -> String
hilf1 Empty space = replicate space ' ' ++ "[]\n"
hilf1 (Node a left right) space =
hilf1 right newspace
++ replicate space ' ' ++ "[" ++ show a ++ "]--|\n"
++ hilf1 left newspace
where newspace = space + length (show a ++ "[]-|")
========================================================================
I know the problem lies in the illegal parentheses on line 14,
and I suspect this triggers defaulting.
The following seems to support this at least partially:
Main> printH (listToTree [1::Integer,2,3,4,5])
[]
[1]--|
[]
[2]--|
[]
[3]--|
[]
[5]--|
[]
[4]--|
[]
Main> printH (listToTree [1::Int,2,3,4,5])
[]
[5]--|
[]
[4]--|
[]
[3]--|
[]
[2]--|
[]
[1]--|
[]
However, I still have
Main> (4 :: Integer) < (5 :: Integer)
True
Main> (5 :: Integer) < (4 :: Integer)
False
So it does not seem to be a bug in Integer comparison.
In addition I do not understand
1) why Hugs accepts these parentheses (without -98) (btype has no context)
2) why this is the result of accepting them.
I am not on hugs-bugs.
Best regards,
Wolfram
From emed11@libero.it Wed Jan 17 23:09:19 2001
Date: Wed, 17 Jan 2001 23:09:19
From: emed11@libero.it emed11@libero.it
Subject: Obtain Biotech IPOs! 39
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title></title>
</head>
<body bgcolor="#CCCCCC">
<div align="center">
<table border="2" width="550" cellpadding="14" cellspacing="5" bordercolor="#003366" bordercolorlight="#003366" bordercolordark="#003366">
<tr>
<td width="100%" bgcolor="#FFFFFF">
<p class="MsoBodyText" align="center"><b><font color="#003399" size="4" face="Verdana">Help Beta Test Our Site and Be Eligible to Purchase Shares of Future IPOs
In Which We Participate**</font></b></p>
<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities
has selected you as a possible participant to help test our online stock-trading
engine for knowledge-based investing in the life sciences. For your cooperation,
<b> you will be eligible to purchase shares of future IPOs</b> in which
we participate, for as long as
you maintain your account with us. This is limited to only <b>50 qualified
testers! </b> <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>
<p class="MsoBodyText" align="center"><b><font size="3" face="Verdana" color="#003399">eMedsecurities… The Cure for the Common Portfolio!</font></b></p>
<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities provides you with a wealth of information, all compiled
in a single, easy-to-use resource. Learn about new research and upcoming treatments
for muscular dystrophy, multiple sclerosis, Parkinson's disease, Huntington's
chorea and much more. Obtain critical investment
information about the companies that are developing these treatments. eMedsecurities empowers you to make more informed investment decisions.
<a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>
<p class="MsoNormal"><b><font size="2" face="Arial">Participation in eMedsecurities’ Beta Test allows you:</font></b></p>
<ul>
<li>
<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Eligibility to purchase shares
of IPOs in which eMedsecurities participates for as long as you maintain your account**</font></b></li>
<li>
<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Valuable research of the entire
product pipeline of companies, including stages of clinical development, by industry or specific disease</font></b></li>
<li>
<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Useful information about industry trends, recent developments and upcoming IPOs</font></b>
</li>
<li>
<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Commitment to customer service featuring our Live Customer Service Online</font></b></li>
<li>
<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Dedication to fast trade executions at the best possible
price.</font></b></li>
</ul>
<p align="left"><font size="2" face="Arial">The following guidelines will explain what we expect from an eMedsecurities Beta Tester:</font></p>
<ul>
<li>
<p align="left"><font size="2" face="Arial">Open a funded eMedsecurities account</font></li>
<li>
<p align="left"><font size="2" face="Arial">Visit our online trading site once a
week</font></li>
<li>
<p align="left"><font size="2" face="Arial">Execute trades through our web site in accordance with your normal
practice</font></li>
<li>
<p align="left"><font size="2" face="Arial">Submit feedback to eMedsecurities' development team through a
questionnaire sent via email</font></li>
<li>
<p align="left"><font size="2" face="Arial">Provide us with additional feedback regarding the site as needed.</font></li>
</ul>
<p align="left"><font size="2" face="Arial">The test is limited to only 50 Beta Testers so sign up now to be
considered! <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font>
<p align="left"><b><font size="2" face="Arial">Please note:</font></b><font size="2" face="Arial">
All applications for the Beta Test must be
submitted by January 24, 2001 to be considered.</font>
<p align="left"><font face="Arial" size="2"><span style="mso-bidi-font-size: 12.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Please
be advised that your information will stay in our proprietary database and will
not be sold, traded, given or otherwise provided to outside vendors. We respect
your privacy.</span></font>
<p align="left">
<p align="left" style="line-height: 100%"><font face="Arial" size="1"><span style="mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">By
submitting your information, you implicitly state that this is something that
interests you and that you<br>
agree to receive periodic emails from
eMedsecurities.</span></font>
<p class="MsoNormal"><font size="1" face="Arial">Research indicated that you might benefit from
our offer. To be removed instantly and permanently from our database, simply
<a href="mailto:emed11@libero.it">click here</a>.
We respect all removal requests.</font></p>
<font size="1" face="Arial">**<b> Restrictions Apply:</b> <span style="color:red"><b>Beta
test not open to residents of: HI, IL, MI, MN, MS, NE, NH, TN, TX.</b></span>
Initial Public Offerings are considered speculative investments and as such may not be appropriate for every
investor. If an investor chooses to participate in IPOs, there are certain restrictions that apply: <b><span style="color:red">Flipping</span>- </b>The first time an investor sells his/her shares within the first 30 days the issue is trading in the secondary market, that investor will not be allocated
shares for the next 90 days following the sale. The second time that investor “flips”, they will not be allocated IPO shares for 180 days. The third time that investor “flips”, they lose their IPO allocations permanently. <span style="color:red">
<b>Transferring shares</b></span><b>- </b>If
the investor transfers IPO shares out of their account within the first 30 days the issue is trading in the secondary market, they will permanently lose their IPO allocations.
<b>Beta investors will be chosen from all the applicants based on their income, net worth and investing experience. </b>
IPO shares will only be allocated from transactions in which eMedsecurities
participates in the underwriting.
A0008-1-A2</font>
</td>
</tr>
</table>
</div>
</body>
</html>
From aejm1@ukc.ac.uk Thu Jan 18 22:49:27 2001
Date: Thu, 18 Jan 2001 22:49:27 -0000
From: Alex Meaden aejm1@ukc.ac.uk
Subject: 3 bugs?
When using Hugs 98, I have come across 3 what appear to be bugs.
1. When I use attempt to import another .hs file from an .hs file I have
created, I usually get the error message:
"ERROR "c:\folder1\file1.hs": Module "c:\folder2\file2.hs" not previously
loaded." This means I cannot import files. My Haskell lecturer and class
teachers are unable to find a solution. This occurs both in the DOS-mode and
GUI versions of Hugs 98. I used to be able to fix the problem by loading the
files from the Script Manager, but now I also get the error when loading by
these means. The chase imports setting is enabled.
2. When a associate .hs files with WinHugs.exe (in Windows 2000), they do
not open when double-clicked. Hugs/Win2k seems to put an extra set of "
marks round the file name, with the result that the file cannot be found.
3. When I attempt to load files using Script Manager, the Open dialog box
does not display files based upon the file extension selected in the
combo-box. For example, if select to open Haskell files .hs & .lhs from the
list of file types, nothing appears in the file list. The .hs files only
appear if I select All files *.*.
I hope this has been helpful!
Alex Meaden,
Computer Science BSc Student,
University of Kent at Canterbury, UK.
From dkrustev@hotmail.com Mon Jan 22 13:22:37 2001
Date: Mon, 22 Jan 2001 13:22:37
From: Dimitur Krustev dkrustev@hotmail.com
Subject: Infinite loop in an error message
The following script causes an infinite loop when printing the error message
provoked by the evaluation of main. Tested with Hugs98 February 2000, both
in +98 and -98 mode.
>type E s = [T s]
>data T s = S s | SE (E s) deriving (Show, Eq)
>p (S s1) (S s2) | s1==s2 = True
>p t1 (SE e2) = all (q t1) e2
>-- p _ _ = error "error in p"
>q t1 t2 = if p t1 t2 then True else p t2 t1
>f (x:xs) (y:ys) | p x y = 1
>f _ _ = 2
>main = f [S "a"] [SE [S "b"]]
Main> main
Program error: {p (Make.Eq (instEq_v23_v1175 instEq_v14) (Eq_default_==
(Make.Eq
(instEq_v23_v1175 instEq_v14) (Eq_default_== (Make.Eq (instEq_v23_v1175
instEq_
v14) (Eq_default_== (Make.Eq (instEq_v23_v1175 instEq_v14) (Eq_default_==
(Make.
...{Interrupted!}
Uncommenting the last line in the definition of p fixes the problem, of
course.
(Although the script is quite contrived, it has been derived from a larger
and more realistic program.)
Best regards,
Dimitur
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
From meurig@dcs.gla.ac.uk Wed Jan 24 18:07:00 2001
Date: Wed, 24 Jan 2001 18:07:00 -0000
From: Meurig Sage meurig@dcs.gla.ac.uk
Subject: bug in dupChan
This is a multi-part message in MIME format.
------=_NextPart_000_02DA_01C08630.72DDBAE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi=20
I think that there's a bug in dupChan in Chan.lhs
I tried the following program.=20
main =3D do
chan <- newChan
ch <- dupChan chan
writeChan chan "done"
x <- readChan chan
y <- readChan ch
prnt ("Got "++x ++" "++y)
Now if I remember correctly this should print "Got done done".
Instead it exits with=20
C:\Test\test.exe: no threads to run: infinite loop or deadlock?
I looked for the code for dupChan in hslibs and it says
dupChan :: Chan a -> IO (Chan a)
dupChan (Chan _read write) =3D do
new_read <- newEmptyMVar
hole <- readMVar write
putMVar new_read hole
return (Chan new_read write)
Shouldn't this instead be=20
dupChan :: Chan a -> IO (Chan a)
dupChan (Chan _read write) =3D do
new_read <- newEmptyMVar
hole <- readMVar write
putMVar new_read hole
** putMVar write hole **
return (Chan new_read write)
That's at least what the Concurrent haskell paper says.
Hugs 98 seems to have the same bug with its library.
Meurig
------=_NextPart_000_02DA_01C08630.72DDBAE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I think that there's a bug in dupChan =
in=20
Chan.lhs</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I tried the following program. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT> </DIV><FONT face=3DArial size=3D2>main =3D =
do<BR> chan <-=20
newChan<BR> ch <- dupChan chan<BR> writeChan chan =
"done"<BR> x=20
<- readChan chan<BR> y <- readChan ch<BR> prnt ("Got =
"++x ++"=20
"++y)</FONT>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Now if I remember correctly this should =
print "Got=20
done done".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Instead it exits with </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>C:\Test\test.exe: no threads to =
run: infinite=20
loop or deadlock?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I looked for the code for dupChan in =
hslibs and it=20
says</FONT></DIV><FONT face=3DArial size=3D2>
<DIV><BR>dupChan :: Chan a -> IO (Chan a)<BR>dupChan (Chan _read =
write) =3D=20
do<BR> new_read <- newEmptyMVar<BR> =20
hole <- readMVar write<BR> =
putMVar=20
new_read hole<BR> return (Chan new_read write)</DIV>
<DIV> </DIV>
<DIV>Shouldn't this instead be </DIV>
<DIV></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>dupChan :: Chan a -> IO (Chan =
a)<BR>dupChan=20
(Chan _read write) =3D do<BR> new_read <-=20
newEmptyMVar<BR> hole <- readMVar =
write<BR> putMVar new_read hole</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>** putMVar write hole =
**<BR> =20
return (Chan new_read write)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>That's at least what the Concurrent =
haskell paper=20
says.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Hugs 98 seems to have the same bug with =
its=20
library.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Meurig</FONT></DIV></BODY></HTML>
------=_NextPart_000_02DA_01C08630.72DDBAE0--
From haberg@matematik.su.se Sun Jan 28 14:58:10 2001
Date: Sun, 28 Jan 2001 15:58:10 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: .y & precedence
Once an operator has been defined using the INFIX.. tokens in the parser.y
grammar, how does that grammar handle the parsing of later occurrences of
the operator symbol in order to get the precedence right? -- Does Hugs
handle that internally (externally to the .y grammar)?
Hans Aberg
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 28 17:43:51 2001
Date: Sun, 28 Jan 2001 18:43:51 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: .y & precedence
Hans Aberg wrote:
> [...] Does Hugs handle that [ i.e. infix & friends ] internally
> (externally to the .y grammar)?
That's correct, IIRC. It uses the standard technique here:
* Remember fixity/precedence declarations in a table, but ignore them
during pattern/expression parsing
* A simple operator precedence parser rearranges the expression/pattern
part of the parse tree afterwards, using the collected table
This is only from the top of my head, so I may be wrong, but given the
inflexibility of yacc & friends in this respect, I doubt there is a
fundamentally different way of doing this.
Note that "expanding out" the grammar w.r.t. fixity/precedence would
lead to a *huge* parser, and is no help at all when there are
infinitely many precedence levels, like in Prolog (IIRC).
Cheers,
Sven
From lennart@mail.augustsson.net Sun Jan 28 17:52:15 2001
Date: Sun, 28 Jan 2001 12:52:15 -0500
From: Lennart Augustsson lennart@mail.augustsson.net
Subject: .y & precedence
Sven Panne wrote:
> Hans Aberg wrote:
> > [...] Does Hugs handle that [ i.e. infix & friends ] internally
> > (externally to the .y grammar)?
>
> That's correct, IIRC. It uses the standard technique here:
>
> * Remember fixity/precedence declarations in a table, but ignore them
> during pattern/expression parsing
>
> * A simple operator precedence parser rearranges the expression/pattern
> part of the parse tree afterwards, using the collected table
>
> This is only from the top of my head, so I may be wrong, but given the
> inflexibility of yacc & friends in this respect, I doubt there is a
> fundamentally different way of doing this.
>
> Note that "expanding out" the grammar w.r.t. fixity/precedence would
> lead to a *huge* parser,
It's not that bad. Hbc uses the expanded grammar. It's very easy to write
with yacc, and the tables are not that big. (But I doubt you can actually
parse Haskell to the letter of what the report says using this technique.
But nobody does that anyway since it's practically infeasible.)
> and is no help at all when there are
> infinitely many precedence levels, like in Prolog (IIRC).
Prolog has a 1000 levels (IIRC).
-- Lennart
From haberg@matematik.su.se Sun Jan 28 20:32:33 2001
Date: Sun, 28 Jan 2001 21:32:33 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: .y & precedence
At 18:43 +0100 1-01-28, Sven Panne wrote:
>[Hugs] uses the standard technique here:
>
> * Remember fixity/precedence declarations in a table, but ignore them
> during pattern/expression parsing
>
> * A simple operator precedence parser rearranges the expression/pattern
> part of the parse tree afterwards, using the collected table
...
>Note that "expanding out" the grammar w.r.t. fixity/precedence would
>lead to a *huge* parser, and is no help at all when there are
>infinitely many precedence levels, like in Prolog (IIRC).
Actually, the question came up on the Bison help list, somebody (novice to
Bison) wanting to write an extensible grammar.
At 12:52 -0500 1-01-28, Lennart Augustsson wrote:
>It's not that bad. Hbc uses the expanded grammar. It's very easy to write
>with yacc, and the tables are not that big.
So I guess one can recommend starting with the simple one.
Hans Aberg
From byron@prover.com Mon Jan 29 21:52:53 2001
Date: Mon, 29 Jan 2001 13:52:53 -0800 (PST)
From: Byron Cook byron@prover.com
Subject: hugs won't compile for me.....
i get the following error when trying to compile Hugs Feb2000:
gcc -c -g -O2 builtin.c
In file included from builtin.c:1432:
iomonad.c: In function `primHGetPosn':
iomonad.c:715: aggregate value used where an integer was expected
iomonad.c: In function `primHSetPosn':
iomonad.c:730: invalid initializer
iomonad.c:736: incompatible types in assignment
make: *** [builtin.o] Error 1
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
$
From nordland@cse.ogi.edu Mon Jan 29 20:43:34 2001
Date: Mon, 29 Jan 2001 12:43:34 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: hugs won't compile for me.....
Byron Cook wrote:
>
> i get the following error when trying to compile Hugs Feb2000:
>
> gcc -c -g -O2 builtin.c
> In file included from builtin.c:1432:
> iomonad.c: In function `primHGetPosn':
> iomonad.c:715: aggregate value used where an integer was expected
> iomonad.c: In function `primHSetPosn':
> iomonad.c:730: invalid initializer
> iomonad.c:736: incompatible types in assignment
> make: *** [builtin.o] Error 1
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.0)
> $
This has been fixed in the current version, which will be released as a beta
on Jan 30. It's also available via anonymous cvs if you don't want to hold
your breath. A third alternative is to grab Jeff's interim build from July
last year:
http://www.galconn.com/hugs/hugs98-Jul2000-1.i386.rpm
http://www.galconn.com/hugs/hugs98-Jul2000-1.src.rpm
-- Johan
From simonpj@microsoft.com Fri Jan 26 09:31:38 2001
Date: Fri, 26 Jan 2001 01:31:38 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: bug in dupChan
=20
Shouldn't this instead be=20
=20
dupChan :: Chan a -> IO (Chan a)
dupChan (Chan _read write) =3D do
new_read <- newEmptyMVar
hole <- readMVar write
putMVar new_read hole
** putMVar write hole **
return (Chan new_read write)
No: readMVar is defined to be take-followed-by-put. I think you
mis-read
the "readMVar write" as "takeMVar write".
=20
Nevertheless, there is a bug in dupChan, but it's in the code for
readChan,
where "takeMVar read_end" should be "readMVar read_end". As you'll
have seen if you are on the Haskell mailing list. Shame on me!
=20
Simon
From herrmann@infosun.fmi.uni-passau.de Wed Jan 31 14:32:01 2001
Date: Wed, 31 Jan 2001 15:32:01 +0100 (MET)
From: Ch. A. Herrmann herrmann@infosun.fmi.uni-passau.de
Subject: What does "Compiled code too complex" error message of Hugs mean?
Hi,
>>>>> "Jan" == Jan Kort <kort@wins.uva.nl> writes:
Jan> 400, you should increase it to 1000 or so. I have it at 10000,
Jan> but that's probably not necesary in your case and if you
Jan> increase constants too much starting up Hugs will become
Jan> slower.
that's a general problem with hugs that you have a lot of definitions
which determine the size of arrays. I've got problems with the code
and the stack size yet, so I have hugs installed with different
settings which is not very convenient.
Maybe hugs will become obsolete by the new fast interactive ghc,
but if not I would suggest to implement as many arrays as possible
dynamically and make all other settings available as a program
parameter. You also could have an option which selects a
permanent check of the control stack to avoid overflows
where safety is more important than speed.
The following piece of C code duplicates the size of an array
and could be applied in the case that both the pointer to the array
and its size reside in a single variable. **data is a pointer to
the variable carrying the former and *size a pointer to the variable
carrying the latter value. elemsize is the memory requirement of
a single array element.
void array_expand(void **data, int elemsize, int *size)
{
void *newdata;
newdata = (void *)malloc(elemsize*2*(*size));
memcpy(newdata,*data,elemsize*(*size));
free(*data);
*data=newdata;
(*size)*=2;
}
Bye
--
Christoph Herrmann
E-mail: herrmann@fmi.uni-passau.de
WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
From thiemann@informatik.uni-freiburg.de Wed Jan 31 17:06:39 2001
Date: 31 Jan 2001 18:06:39 +0100
From: Peter Thiemann thiemann@informatik.uni-freiburg.de
Subject: more on functional dependencies and overlapping instances
Hi again,
as I said before, the fix was only partial.
I also had to modify instImprove in subst.c, but it is clearly a
hack because it assumes that more specific instances are given first,
so I'm not sending it along.
[I hope this is the right forum for talking about this:]
I don't know about the current state of the implementation, but the
following looks like a viable approach:
* keep an "improved" tag with each predicate pi
* in instImprove, if pi.improved then terminate immediately with
result FALSE
* check all instances for improvement candidates (but don't do
anything, yet)
* if there is exactly one candidate, go for it: improve pi, set the
flag, and exit
* if there is more than one candidate, find the most specific
* if pi MATCHES the most specific one, go for it: ...
* otherwise, no improvement possible, yet
Doing this properly would require digging much deeper in the code than
I can afford to right now. I'd appreciate any help (or alpha release:-)
to solve this problem.
And a widely related question: how exactly does the overlapping
instances mechanism deal with specificity? I mean, what
happens if there are two instances which are unifiable, but there is a
third instance that covers the unifier? The feb2000 release definitely
cannot handle this since instances are added and checked
incrementally.
-Peter
From thiemann@informatik.uni-freiburg.de Wed Jan 31 15:16:42 2001
Date: 31 Jan 2001 16:16:42 +0100
From: Peter Thiemann thiemann@informatik.uni-freiburg.de
Subject: functional dependencies and overlapping instances
--=-=-=
Hi,
this reports two bugs in Hugs98-feb2000 and provides a fix for the
first and a proposed fix for the second.
1. Given the definitions
> class NextState s t s' | s t -> s'
> instance NextState EMPTY t EMPTY
> instance NextState EPSILON t EMPTY
> instance NextState (ATOM t) t EPSILON
> instance NextState (ATOM t) t' EMPTY
hugs -98 +o complains that
ERROR "REGEXP.hs" (line 76): Instances are not consistent with dependencies
*** This instance : NextState (ATOM a) b EMPTY
*** Conflicts with : NextState EMPTY a EMPTY
*** For class : NextState a b c
*** Under dependency : a b -> c
Oops, the "Conflicts with" line is not right, it should rather be
*** Conflicts with : NextState (ATOM a) a EPSILON
The patch below corrects this.
2. But actually, since we are allowing overlapping instances and the
> instance NextState (ATOM t) t EPSILON
is definitely more specific than
> instance NextState (ATOM t) t' EMPTY
the above definitions should be perfectly ok.
The patch below fixes the generation of the error message, but other
fixes might be necessary, too.
Cheers
Peter
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=static.patch
Content-Description: Patch for src/static.c
*** static.c.orig Tue Feb 29 11:29:00 2000
--- static.c Wed Jan 31 16:14:31 2001
***************
*** 2890,2906 ****
if (nonNull(cclass(c).fds)) { /* Check for conflicts with fds */
List ins1 = cclass(c).instances;
for (; nonNull(ins1); ins1=tl(ins1)) {
List fds = cclass(c).fds;
substitution(RESET);
for (; nonNull(fds); fds=tl(fds)) {
Int alpha = newKindedVars(inst(in).kinds);
! Int beta = newKindedVars(inst(hd(ins1)).kinds);
List as = fst(hd(fds));
Bool same = TRUE;
for (; same && nonNull(as); as=tl(as)) {
Int n = offsetOf(hd(as));
same &= unify(nthArg(n,inst(in).head),alpha,
! nthArg(n,inst(hd(ins1)).head),beta);
}
if (isNull(as) && same) {
for (as=snd(hd(fds)); same && nonNull(as); as=tl(as)) {
--- 2890,2921 ----
if (nonNull(cclass(c).fds)) { /* Check for conflicts with fds */
List ins1 = cclass(c).instances;
for (; nonNull(ins1); ins1=tl(ins1)) {
+ Inst in1 = hd(ins1);
List fds = cclass(c).fds;
substitution(RESET);
for (; nonNull(fds); fds=tl(fds)) {
Int alpha = newKindedVars(inst(in).kinds);
! Int beta = newKindedVars(inst(in1).kinds);
List as = fst(hd(fds));
Bool same = TRUE;
+ /* <PJT> */
+ Int alpha_bef = newKindedVars(inst(in).kinds);
+ Int beta_bef = newKindedVars(inst(in1).kinds);
+ Int alpha_aft = newKindedVars(inst(in).kinds);
+ Int beta_aft = newKindedVars(inst(in1).kinds);
+ Bool bef = TRUE;
+ Bool aft = TRUE;
+ /* </PJT> */
for (; same && nonNull(as); as=tl(as)) {
Int n = offsetOf(hd(as));
same &= unify(nthArg(n,inst(in).head),alpha,
! nthArg(n,inst(in1).head),beta);
! /* <PJT> */
! bef &= matchType(nthArg(n,inst(in).head),alpha_bef,
! nthArg(n,inst(in1).head),beta_bef);
! aft &= matchType(nthArg(n,inst(in1).head),beta_aft,
! nthArg(n,inst(in).head),alpha_aft);
! /* </PJT> */
}
if (isNull(as) && same) {
for (as=snd(hd(fds)); same && nonNull(as); as=tl(as)) {
***************
*** 2908,2921 ****
same &= sameType(nthArg(n,inst(in).head),alpha,
nthArg(n,inst(hd(ins1)).head),beta);
}
! if (!same) {
ERRMSG(inst(in).line)
"Instances are not consistent with dependencies"
ETHEN
ERRTEXT "\n*** This instance : "
ETHEN ERRPRED(inst(in).head);
ERRTEXT "\n*** Conflicts with : "
! ETHEN ERRPRED(inst(hd(ins)).head);
ERRTEXT "\n*** For class : "
ETHEN ERRPRED(cclass(c).head);
ERRTEXT "\n*** Under dependency : "
--- 2923,2941 ----
same &= sameType(nthArg(n,inst(in).head),alpha,
nthArg(n,inst(hd(ins1)).head),beta);
}
! if (!same
! /* <PJT> */
! && !(allowOverlap && !haskell98
! && (bef && !aft || aft && !bef))
! /* </PJT> */
! ) {
ERRMSG(inst(in).line)
"Instances are not consistent with dependencies"
ETHEN
ERRTEXT "\n*** This instance : "
ETHEN ERRPRED(inst(in).head);
ERRTEXT "\n*** Conflicts with : "
! ETHEN ERRPRED(inst(in1).head);
ERRTEXT "\n*** For class : "
ETHEN ERRPRED(cclass(c).head);
ERRTEXT "\n*** Under dependency : "
--=-=-=--
From simonpj@microsoft.com Fri Jan 26 10:42:33 2001
Date: Fri, 26 Jan 2001 02:42:33 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Yet more on functional dependencies
| | I am finding functional dependencies confusing. (I suspect I am=20
| | not alone.) Should the following code work?
| |=20
| | class HasConverter a b | a -> b where
| | convert :: a -> b
| |=20
| | instance (HasConverter a b,Show b) =3D> Show a where
| | show value =3D show (convert value)
|=20
| It's a separate issue. There's no reason why a system using
| functional dependencies *should* support this. But it is an
| attractive and useful extension that such a system would
| probably *want* to include. (i.e., it's a desirable feature,
| not a requirement.)
There are two things going on here
a) The 'head' of the instance declaration is just "Show a", so this
purports to give an instance declaration for all types "a". So it
overlaps with other instance declarations, and GHC currently rejects
it for that reason. (Arguably, if you accept overlapping instance=20
declarations, then this should be acceptable too.)
b) There's a "b" in the instance declaration context that doesn't
appear in the head. This is quite OK, because the functional dependency
ensures that "a" uniquely determines "b". =20
So here's a variant that works in the (as-yet-unreleased) GHC 5.0:
data Foo a =3D MkFoo a
instance (HasConverter a b,Show b) =3D> Show (Foo a) where
show (MkFoo value) =3D show (convert value)
[Incidentally, functional dependencies don't work at all in GHC 4.08;
don't
even try.]
Simon