RE: ghc-CVS 001024: minor hslibs dependency bug
The dependency "concurrent" should be added to line 11 of /hslibs/net/Makefile so that it becomes: HSLIB_DEPS = lang text concurrent After that fix, 'make boot' goes through. Thanks, I've applied your fix. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
False duplicate or overlapping instances message
When I compile the attached file on Linux with 4.08.1: /home/ger/ghc-4.08.1-binary/bin/ghc -c Instances.hs -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances I get the message: Instances.hs:1: Duplicate or overlapping instance declarations for `HasConfig (arcTypeConfig value) (arcTypeParms value)' defined at Instances.hs:19 and defined at Instances.hs:11 This is not fair, because while the instances for HasConfig have the potential to conflict in the future, they will only do so should the classes NodeTypeConfigParms and ArcTypeConfigParms overlap. Instances.hs
Re: False duplicate or overlapping instances message
Instances.hs:1:
Duplicate or overlapping instance declarations
for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
defined at Instances.hs:19 and defined at Instances.hs:11
This is not fair, because while the instances for HasConfig have the
potential to conflict in the future, they will only do so should the classes
NodeTypeConfigParms and ArcTypeConfigParms overlap.
It is fair. Let's rename your type variables to make what's going on a little clearer:
main = return ()
class HasConfig a b where
($$) :: a - b - b
class NodeTypeConfigParms a b where
nodeTypeConfig :: a c - b c - b c
instance (NodeTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = nodeTypeConfig
class ArcTypeConfigParms a b where
arcTypeConfig :: a c - b c - b c
instance (ArcTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = arcTypeConfig
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
If you do -fallow-undecidable-instances, I think your program will
work (in the Prolog-ish backtracking way), but note that if
NodeTypeConfigParms and ArcTypeConfigParms are ever given instances at
the same pair of types, the value of ($$) will be undefined.
--KW 8-)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False duplicate or overlapping instances message
Keith Wansbrough wrote:
Instances.hs:1:
Duplicate or overlapping instance declarations
for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
defined at Instances.hs:19 and defined at Instances.hs:11
This is not fair, because while the instances for HasConfig have the
potential to conflict in the future, they will only do so should the classes
NodeTypeConfigParms and ArcTypeConfigParms overlap.
It is fair. Let's rename your type variables to make what's going on a little
clearer:
main = return ()
class HasConfig a b where
($$) :: a - b - b
class NodeTypeConfigParms a b where
nodeTypeConfig :: a c - b c - b c
instance (NodeTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = nodeTypeConfig
class ArcTypeConfigParms a b where
arcTypeConfig :: a c - b c - b c
instance (ArcTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = arcTypeConfig
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
and ArcTypeConfigParms a b. Which there aint.
If you do -fallow-undecidable-instances, I think your program will
work (in the Prolog-ish backtracking way), but note that if
NodeTypeConfigParms and ArcTypeConfigParms are ever given instances at
the same pair of types, the value of ($$) will be undefined.
As a matter of fact I DID use -fallow-undecidable-instances, as you can see
from my original contribution . . .
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False duplicate or overlapping instances message
Keith Wansbrough wrote:
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
and ArcTypeConfigParms a b. Which there aint.
Haskell makes the "open world" assumption... there may be new
instances added later, and the behaviour of a well-typed program
should not change if this occurs.
I'll defer further discussion of this to the experts (Mark Jones?).
I think I've worked out what's going on now. But I don't like it.
When I use -fallow-undecidable-instances and -fallow-overlapping-instances
(as I did) I was assuming (like Keith Wansbrough did) that GHC would do a
Prolog-style backtracking search when it was time to resolve an overloading,
and would only complain if there were more or fewer than one chain of inferences.
Instead Haskell eagerly tries to anticipate possible conflicts, which is a nuisance
when it is obvious (as it is to me in this case) that such conflicts are unlikely
to arise. For a simpler example, imagine that we have two classes
Integral a (things corresponding to integers) and String a (things corresponding to
strings). It is a pity that we cannot write
instance Integral a = Show a
and
instance String a = Show a
just because someone may come along later on and try to show something which is an
instance of both Integral and String. (Though obviously if they do, we DO need an
error message.)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
group theory. Reply
Hi, all, To Eric Allen Wohlstadter's ([EMAIL PROTECTED]) : Are there any Haskell libraries or programs related to group theory? I am : taking a class and it seems like Haskell would be a good programming : language for exploring/reasoning about group theory. What I had in mind : was perhaps you could have a function which takes a list(set) and a : function with two arguments(binary operator) and checks to see whether or : not it is a group. I think it might be a fun exercies to write myself but : I'd like to see if it's already been done or what you guys think about it. Marc van Dongen [EMAIL PROTECTED] writes I think Sergey Mechveliani's docon (algebraic DOmain CONstructor) has facilities for that. Have a look at: http://www.cs.bell-labs.com/who/wadler/realworld/docon.html Sorry, DoCon (http://www.botik.ru/pub/local/Mechveliani/docon/2.01/) really supports the Commutative Rings, but provides almost nothing for the Group theory. For example, for the domain(Integer,Integer) it would set automatically (IsGroup,Yes) for the Additive semigroup and (IsGroup,No) for the Multiplicative semigroup. For the additive case, it would also set the group generator list [(1,0),(0,1)]. In both cases, it would also set cardinality = Infinity. Similar attributes are formed for the constructors of Permutation, Vector, Matrix, Polyninomial, Fraction, ResidueRing. And that is all. It does not provide so far any real algorithmic support for the Group theory, except some operations on permutations. But one may develop the program by adding the needed algorithms and introducing new attributes. : What I had in mind : was perhaps you could have a function which takes a list(set) and a : function with two arguments(binary operator) and checks to see whether or : not it is a group. I think it might be a fun exercies to write myself but : I'd like to see if it's already been done or what you guys think about it. I never programmed this. It looks like some exercise in algorithms. There are also books on the combinatorial group theory, maybe, they say something about efficient procedures for this. Regards, -- Sergey Mechveliani [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: group theory. Reply
S.D.Mechveliani wrote: Hi, all, To Eric Allen Wohlstadter's : Are there any Haskell libraries or programs related to group theory? ... Marc van Dongen [EMAIL PROTECTED] writes I think Sergey Mechveliani's docon (algebraic DOmain CONstructor) has facilities for that. ... Sorry, DoCon (http://www.botik.ru/pub/local/Mechveliani/docon/2.01/) really supports the Commutative Rings, but provides almost nothing for the Group theory. EAW again: : ... I think it might be a fun exercies to write myself but : I'd like to see if it's already been done or what you guys : think about it. SM: I never programmed this. It looks like some exercise in algorithms. There are also books on the combinatorial group theory, maybe, they say something about efficient procedures for this. == "Some exercise in algorithms". Hm. There is more to that than this... This issue has been recently stirred a bit in the comp.functional newsgroup, in a larger context, general Math, not necessarily the group theor. There are at least two people *interested* in it, although they didn't do much yet (for various reasons...) Suggestion: Take GAP! ( http://www-history.mcs.st-and.ac.uk/~gap/ ) Plenty of simply coded algorithms, specifically in this domain. I coded just for fun a few simple things in Haskell some time ago, and it was a real pleasure. The code is cleaner and simpler. Its presentation is also much cleaner than the original algorithms written in GAP language. But I discarded all this stuff, thinking that I would have never time enough to get back to it... This is a nice project, and I would participate with pleasure in it, although the time factor is still there... Dima Pasechnik ([EMAIL PROTECTED]; does he read it?) - apparently - as well. Jerzy Karczmarczuk Caen, France ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell Programming Environment
Hello, I'm writing my master thesis. Its subject is 'Haskell Programming Environment'. It is (or rather will be) an extended text editor working i= n graphical (XFree86) environment designed for Haskell programmers. It will= be implemented using Fudgets library. I'm wondering what features would you like to find in such environment. W= hat should be neccessary, what would help, what would make writing programs easier, etc. I have some concepts, but I would like to hear some suggestions from you. Thanks for all answers. a) the ablility to highlight an area of code and get its type (be it a function, or some well-formed chunk of code b) the ability to highlight a function and get its definition in another area (think multiple text editing in vim) c) interaction with hugs/stg-hugs so that just written code can be pasted into a "hugs window" for evaluation. d) Debug mode which automatically adds "deriving show" to all datatypes which are not showable/adds exporting of all Datatypes as non-abstract for use in hugs to just allow things to be tried out. e) Debug mode which invisibly replaces functions such as "fromJust" with error making versions (... fromJust' "the file and line at which I'm invoked" ...) to make it easier to find the cause of the error (fromJust Nothing just comes up with an error telling you that it's fromJust that failed. Last time that happened, I hacked hugs to dump the evaluation stack, from which I guessed which possible fromJusts it could have been). f) Use ghc's .hi file to allow strictness of arguments to appear if you leave the mouse over an argument. g) For bonus points (harder, but really useful when stuck): given an expression, show me (possibly using daVinci) how it gets evaluated: Lazyness behaviour is not always obvious, I'd like to see it. I've been wanting to code one of these myself, but have had no time. Try and see if stg-hugs is useable yet since that would be a much better environment to do it in. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell Programming Environment
I've been wanting to code one of these myself, but have had no time. Try and see if stg-hugs is useable yet since that would be a much better environment to do it in. It's now called GHCi, and is being written right now by the GHC team. Not sure when the estimated completion time is, but it can't be that far off. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
cpp superior to ghc . . .
Why does the Haskell language not allow "type" declarations to appear in the declaration parts of where and let clauses? I've just been writing a huge functions which requires lots and lots of repetitive internal type annotations (to disambiguate some complicated overloading) but I can't abbreviate them with "type" because they depend on things only in scope inside the function. In the end I abbreviated them with a few #define's but I don't really think it should be that way . . . ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: cpp superior to ghc . . .
Wed, 25 Oct 2000 22:08:55 +0200, George Russell [EMAIL PROTECTED] pisze:
Why does the Haskell language not allow "type" declarations to
appear in the declaration parts of where and let clauses?
Because you can always lift them to the top level.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
