Re: Overlapping, undecidable, incoherent -- or worse?
On Fri, May 21, 2004 at 11:04:53AM +0100, Simon Peyton-Jones wrote: > Nothing difficult in principle, but the constraint solver is one of > the more delicate parts of GHC because GHC's constraint language has > become so complex. Well, as my day job is working for a constraints lab, I feel it's my bounded duty to say, "all the better": more cross-disciplinary synergy. ;-) For my part I must admit the current restrictions aren't _that_ irksome: they're just the sort of thing I run into every so often, have to remind myself they're the way they are, and end up writing a few more instance declarations by hand than I initially imagined I 'ought' to have to. On the point of complexity: it's not immediately obvious to me that (setting aside the Hugs-style extension to H98 in the form of the instance decls.) it would cause any blowup here in principle. Granted there's a combinatorial issue, but the breadth and depth of alternatives are necessarily finite, so it seems finitely bound overall, and since HM typing is D-Exp anyway, I'd be surprised if it made it worse than that in toto. Hideousness of implementation's another matter, and certainly I don't want to be biting the hand that feeds... Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 11:06:44PM +0100, MR K P SCHUPKE wrote: > I agree, I have made it not terminate myself with undecidable-instances, Congratulations. ;-) > I also think prolog style backtacking would be a good idea... I think I said > that you either want full backtracking or you want to leave it how it is > (with dependancies ignored) - I have yet to be convinced that any partial > solution would have the elegance of full backtracking, yet would complicate > the implementation and syntax. Oh, I don't think what I'm suggesting is a 'partial solution', short of full dependency-based backtracking: I think it almost requires the latter. But having done such a thing, I'd imagine one is yet more likely to encounter situations where it's ambiguous which of a number of possible instance derivation routes is possible, which in turn is likely to make specifying which is wanted more important -- the alternative would seem to be verifying that only one possible instance can be arrived at, or examing the possibilities in some arbitrary order (such as that of the program text). (I belatedly found the more full description of 'incoherent instances' in the documentation, having initially only noticed the 'flags' section, and can see that it indeed does nothing like what I was needing...) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 09:25:20PM +0100, MR K P SCHUPKE wrote: > Thats it... Neither GHC nor Hugs pay any attention to the > dependancies when choosing which instance to use. The > dependancies are only considered after the decision has > been irrevocably made. If the dependancies don't hold, the > only option the compiler has is to bail out with a compile > time error. Let's recap. You observed that taking dependencies into account leads to "further problems of the compiler possible not terminating". I didn't dispute that ghc and hugs _do not_ take such dependencies into account, I pointed out that the type system _may already_ not terminate (and not just hypothetically, but for the option I was using and the class of instance in my original example, with or without the duplicate heads). So from a theoretical pov I didn't, and still don't, see how this would be 'worse'. That this is clearly not what ghc does or is likely in the near future to do probably puts this in the category of language list fodder, though. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 07:34:18PM +0100, MR K P SCHUPKE wrote: > that is not the case with "-fallow-undecidable-instances" ... as far as > I understand it , ghc never considers the dependancies when selecting an > instance. If you don't think so you will need to show me an example where > it clearly does... as I haven't seen one yet (but just because I haven't > seen it doesn't mean its not possible),,, Am I to understand you're asserting that GHC "undecidable-instances" are in fact decidable? Hugs explicitly documents its type system as being undecidable, and I'd presumed this was the 'make GHC behave that way too' flag. > I mean, given two instances like: > > instance a b c > instance d e f > > there is no way to tell between them... if you said choose a in preferenc > 'a' would be chosen all the time. If you were to indicate one instance declaration was preferred, and both _could otherwise yield a suitable instance_, then that would be prefered. (Though if one were to 'search' in the preference order of the rules, one wouldn't need to find more than one in any event.) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 05:58:53PM +0100, MR K P SCHUPKE wrote: > The alternative to the current situation is to take into account the > dependancies of instances when selecting. The problem here is that > the compiler may select an instance, evaluate its dependencies, only > to discover somewhere further on that the dependencies cannot be met. > At this point it has to backtrack (reverse its previous decisions) and > try another instance. This effectively means implementing a Prolog > style solver in the compiler - which leads to the further problems of > the compiler possible not terminating (ie taking forever to not > compile something)... Which is the case as soon as you use the -fallow-undecidable-instances flag in any event. My suggestion might make things worse pragmatically, but I don't see it can be any moreso theorically. You may claim that it's not an attractive change, or doesn't help in some more general case than the one I asked about; but I don't see how you can possibly maintain it immediately wrecks the type system, or that it doesn't resolve the problem in this case, which is not so much that finding a valid instance is difficult, but that there are _two_ possible such, and no way at the language level to say which is desired. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 05:27:43PM +0100, MR K P SCHUPKE wrote: > >I wasn't talking about _any_ notion of ordering of instance heads; I > >said that prioritising instance _declarations_ themselves, explicitly, > >by 'name' would suffice. > > How does that help... if you name the instances differently are they > not just ordinary functions, as they would no longer be overloaded? I thought I expounded on that, too. If there were a facility to 'name' (in a general sense, not as in the function namespace) instance declarations, it'd facilitate (by way of some further, hypothetical language extension) specifying _explicitly_ which declarations should be construed as overriding which others, when they would otherwise be seen to clash. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 05:16:45PM +0100, MR K P SCHUPKE wrote: > >That's not the notion of priority I was referring to. > > Any type of priority would not help. As I said then the instance heads > are identical (PO a) and (PO a) - no kind of priority will help > differenciate the, I wasn't talking about _any_ notion of ordering of instance heads; I said that prioritising instance _declarations_ themselves, explicitly, by 'name' would suffice. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 03:52:49PM +0100, MR K P SCHUPKE wrote: > I don't know whether this was apparent, but only the instance > pattern is used in determining which instance to use, so > "PO a" is the same as "PO a" ... you need to make them different > otherwise they don;t just overlap they are identical. > the left-hand-side of the "=>" play no part in instance selection. > > That is why I suggested using new types. (infact it is your only option) I see what you're getting at, but I'm not gone on it. It adds another constructor (and the instances will generally have at least one to start with), and it obscures the 'subclass' relationship. It'd probably be preferable to code each PO instance 'by hand' (i.e. a separate instance for each base type selecting the general semiring, c-semi-ring, or some yet more specialised (as will often be the case anyway)) definition of the partial order). I was just hoping I could avoid doing that, too... > Even priority would not help here, as the instances are identical. > (there is a priority, in that if the instances are overlapping > the most specific is used, IE choosing between (PO a) and (PO Int) > PO Int wins is 'a' is an Int. That's not the notion of priority I was referring to. Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping, undecidable, incoherent -- or worse?
On Thu, May 20, 2004 at 08:52:45AM +0100, Simon Peyton-Jones wrote: | You don't say what you are trying to achieve. However it looks as if | you mean "If you want PO T, for some type T, first try (Bounded T, Enum | T, SemiRing T) and if that fails try CSemiRing T. Or maybe the other | way round. Sorry, I suppose I was a little gnomic. I mean the other way round, ideally. The difference in the remainder of the contexts isn't significant for my purposes, so I could as well have (some redundantly) made the latter declaration: > instance (Bounded a, Enum a, CSemiRing a) => PO a where > a |= b = a + b == b which'd make it strictly more specific than the other. i.e. if it's a CSemiRing, use that, if not but is (only) a semiring If that'd help at all... | In any case, GHC simply does not implement this kind of backtracking | search. It would make sense, and some of the more exotic users of type | classes would like it, but (a) there are numerous tricky corners, and | (b) it's awkward to implement the way GHC is now. If the specification | was completely clear I might be tempted to fix (b), but it isn't. The | main difficulty is that a compiler does not solve constraints "all at | once". Instead it does a bit of solving, then then a bit more later. | If the "later" part doesn't pan out, it's jolly difficult to go back to | the original part (in another module, perhaps) and change it. I can see the possible difficulties all right. Well, enough of them for it to seem... difficult. I'd think this would be relatively easy to do if Haskell had some notion of 'naming' instance declarations, and then of specifying a 'priority' to 'em, but that'd by a pretty significant looking language extension. I'd just gotten the impression that -fallow-incoherent-instances might make some ad hoc 'forcing' choice in such circumstances that might serve my current purposes. > As a trivial example, try > > f a = a |= a > > What type shall we infer for f? > f :: (Bounded a, Enum a, SemiRing a) => a -> a > or > f :: (CSemiRing a) => a -> a I'm with Stefan on this one. Surely the type is simply PO a => a -> Bool? Or is there a 'top level binding' issue here? (Surely not, the MR doesn't apply.) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Overlapping, undecidable, incoherent -- or worse?
The following rings a faint bell from somewhere, but if there's a standard workaround I can't recall or lay my hand on it currently: > class PO a where >(|=) :: a -> a -> Bool > > class Num a => SemiRing a > > class SemiRing a => CSemiRing a > > instance (Bounded a, Enum a, SemiRing a) => PO a where >a |= b > = or [ a + c == b | c <- boundedEnumFrom minBound ] > > instance CSemiRing a => PO a where >a |= b = a + b == b The above is in any event requires the "-fallow-undecidable-instances" flag, due to the format of the instance clauses, and they're worse than merely "overlapping" due to the identical heads. But I'm not quite clear why "incoherent" doesn't help here: isn't the gist of that to allow the second to override the first, where they conflict? Is there otherwise a means to have it behave in such a way? (I can hack around this by removing the distinction betweem the two classes and encoding it as run-time property (which may get compiled out statically anyway, and I suspect what I actually want are hierarchical defaults rather than instances, but that's more like fodder for another list.) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Time profiling question.
Let me ask this question in the abstract, lest I embarrass myself
publicly with my shoddy code:
Suppose I find that -p style profiling with -auto-all attributes the
majority of the cost of my program to a single function. Naturally, I'd
like to refine this somewhat. So I add additional cost centres as
follows:
f a1 ... an
= e
where
d1 = {-# SCC "d1" #-} e1
...
d1 = {-# SCC "dn" #-} e1
I find it's still attributing almost all of the cost to the original CC
(f), so I add another SCC, before the RHS. And it _still_ attributes
the same amount to f, and effectively nothing to the body CC.
So my questions are firstly, can someone explain this; and secondly, is
there a style of adding CCs that would be more informative in such
cases? (Or if it comes down to it, transforming the code to be more
revelatory in that respect.)
Cheers,
Alex.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Question about compiling CGIs with Ghc
On Mon, Feb 17, 2003 at 11:00:13AM -, Simon Marlow wrote: > > > I have some CGI programs running with Hugs and I want to use GHC > > instead. > > > > What changes must I do to the .hs file? > > > > Is it an easy job? > > Depends on lots of things really. > > The CGI library that comes with GHC is documented here: > > http://www.haskell.org/ghc/docs/latest/html/network/Network.CGI.html This make me curious, and the following just made me curiouser... Forbidden You don't have permission to access /ghc/docs/latest/html/network/Network.CGI.html on this server. Apache/1.3.22 Server at haskell.cs.yale.edu Port 80 I don't think it's anything wrong with my browser setup, as I can access (e.g.) .../Network.html perfectly well. Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
> Alex > > As Simon M says, if you (or anyone else) felt able to write up a > standalone summary > of what the problem is, and what the solution is, I'd love to add it to > the GHC > FAQ or documentation somewhere. In my experience, simply explaining the > problem > clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in > the Building Guide, > took me ages to understand well enough to write down.) > > Simon I'll definitely defer to Claus on this one. I'm still "working through the issues" in places, but I don't yet have anything coherent to add. (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, which fell for me at the first hurdle of "first catch your hmake" in the recipe. I've now gotten as far as a _build_ of hmake, but it then runs into similar issues with its own use of the f/s (rc files and what-not). If anyone has this one down pat already, they might save my tired brain some pain, otherwise I'll summarise to the list if and when I get some sort of resolution myself.) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Thanks to all for the replies; Hal's resolution rings a bell, now that I think about it, from Ye Olde Days when cygwin was a ghc pre-req -- just didn't think of it when installing more recently on a new machine. (Install in haste, repent at leisure.) Claus' suggestion about relative paths does the ticket, though: didn't occur to me as the paths were being generated by a configure script, but yes, it was possible to override them, which works as advertised. Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc/cygwin filename resolution issue.
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as "/usr/local/hmake" (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: extra_ghc_opts syntax
> Just write the list twice, once with the quotes and commas and once > without? Alternative I guess you could try to transform one into the > other using sed, perl, python, etc. but I would just do it the easy way. Doesn't everyone on this list use Haskell for their string-processing, then? ;-) (This one is about a one-liner...) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-4.xx Alpha port?
Hi guys. Has anyone been so rash as to try this? Any indications as to the likely "degree of difficulty"? I'd have a go myself, but I'm rather busy with teaching. (Which is ironic, since teaching is what I want it for...) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
TclHaskell query.
Hi there. I fear this may end up being not so much a TclHaskell as a 'power Tcl/Tk' question, but I thought I'd try here first on the off-chance. I'm looking for a widget that acts essentially like a listbox (scrolls, selectable entries), but which isn't restricted to single lines of text in the entries. (Ideally each entry would be a arbitrary box.) Does anyone happen to have such a thing, or any advice as to how to set about implementing same, or some combination of the two? (Such as looting partially applicable code from elsewhere.) Cheers, Alex.
RE: Collection types.
SPJ: > Yes, Jeff Lewis is well advanced with adding functional dependencies > to GHC. Certainly, if you get GHC from the CVS tree you are getting > wads of his F-D code. I don't think it's completed yet, though. > Stay tuned Excellent stuff. I _think_ this solves a problem I may be about to have -- it's not Mission Critical for me at the moment, so that's as good as I would have hoped. It doesn't look to me like a perfect or general solution, mind you, but I'll blether about that elseList, if I'm going to reveal my woeful ignorance on the topic at all. > Let's hear it for Jeff! Yay! Cheers, Alex.
Re: GHC Select and Time modules - struct timeval
Keith Wansbrough: > If the Integer is greater than 2^64-1 then simply > pass NULL to select(): I think 595 000 years is near enough forever > given current operating systems... Quincentomillennium bug, anyone? ;-) Cheers, Alex.
Collection types.
I was just looking at Mark Jones' summary of his Hugs extension for disambiguating collection types (and other MPC snafus), and while I have some qualms and queries about the generality of his solution, it does appear to solve an important set of such problems. So, I was wondering... Are there plans to implement this in ghc, too? Or equally, any ohter type system extension that would finesse the issue with typing, in particular, non-type-constructor collections, such as tries, and the examples mark furnishes. Asking out of shameless self-interest, as usual. Cheers, Alex.
RE: My head just exploded too.
Me: > | Although I'd read the restriction in advance, I nevertheless > | unwittingly > | contrived to try and write a binding-group style pattern-match against > | an existentially quantified data constructor. Oops. (Actually, I did > | it twice, what's worse...) I can imagine this is indeed an irksome > | thing to TC, but OTOH, it's not a very natural language restriction > | either. What's worse, one is of course not able to use 'selectors' in > | these cases, as they're immediately ill-typed. One saving grace was SPJ: > You could always use a case expression, no? This is true. However, I dislike case expressions moderately intensely at the best of times on aesthetic grounds, and using them as a let-alike I find more than usually unspeakable. Yet more so in the midst of a do-block... > | What's worse, in the other caes, when I replaced the > | let-binding with an auxiliary function call (pattern guards no use in this > case), > | I ran into _another_ restriction: mutually recursive functions needing > | to have the same contexts. > > | (That is if one > | has a group like f (EDC x) = ... f' x ...; f' x = ... f (EDC x) ...) > > Here you are really calling f' at a fresh type, so you need > polymorphic recursion. > > If you are prepared to write the type signature for f' then there is > no difficulty in principle: as Mark has described in his Haskell workshop > paper one can typecheck the bindings without sigs first, then the bindings > with sigs. But GHC still does them all together. I don't immediately see why this is an instance of polymorphic recursion: in what sense does the call of f' involve a fresh type? But it would seem reasonable enough to require an explicit type sig. (Partial or otherwise!) > So that's two type-system things that would make your life easier. > > Hmm. > - how bad is it to use case? The existing alternatives are pretty easily liveable-with (though case happens to be my least favoured option), they just seem odd as restrictions, and look a tad peculiar. > - would pattern-matching on non-rec lets help you? It would have; I'd be happy with this, though a small part of me wonders if doing this might not enrage some future user who bumps into the thus-moved limitation in a less clearly circumscribed case. To wit, is it better to say, no recusive bindings, or, more syntactically simply, no lets or wheres? Cheers, Alex.
My head just exploded too.
Although I'd read the restriction in advance, I nevertheless unwittingly contrived to try and write a binding-group style pattern-match against an existentially quantified data constructor. Oops. (Actually, I did it twice, what's worse...) I can imagine this is indeed an irksome thing to TC, but OTOH, it's not a very natural language restriction either. What's worse, one is of course not able to use 'selectors' in these cases, as they're immediately ill-typed. One saving grace was that one _can_ use pattern guards, but since that's a non-standard feature too, I feel I'm multiplying heterodoxy upon heteredoxy when I do this. What's worse, in the other caes, when I replaced the let-binding with an auxiliary function call (pattern guards no use in this case), I ran into _another_ restriction: mutually recursive functions needing to have the same contexts. I believe, at least at first wink, that in the presence of existentials this is _not_ an entirely sensible restriction, since if one is 'unfolding' and 'folding' an existentially-typed DC, then chunks of the context can disappear and reappear accordingly. (That is if one has a group like f (EDC x) = ... f' x ...; f' x = ... f (EDC x) ...) Comments, O implementors and designers? Cheers, Alex.
RE: _ccall_
Hi there. > it is mentioned in the user's guide, > > > http://haskell.org/ghc/docs/latest/users_guide/users_guide-5.html#glasgow-fo > reign-headers Ah, that: I managed to read that entire section at least once, and completely misunderstand. I thought that was talking about something else entirely... (I'm not sure if this indicates this sections needs more idiot-proofing (maybe a sample command line?), or just less idiocy on my part...) > Alternatively, you can use -optC-femit-extern-decls to have > ghc emit the proto of the function it assumes you're interfacing > to. (You may need a fairly recent CVS snapshot to get this one > to work, as there a couple of gcc bugs to contend with.) Cool... Many thanks. Cheers, Alex.
_ccall_
Hi all. Just started playing around with ccall, and while I managed to get my toy program to Do The Right Thing, I got a mildly alarming looking warning message from gcc, re: athe lack of an explicit type for the generated C call. I don't see anything about this in the users guide, either telling me not to worry about this, or specifying how to pacify it. If it's generating a type for the given function along the lines of the C type rules, is there any sort of provision for slurping in a .h, or equivalent, to provide a 'better' type? I realize there are more sophisticated Preferred Interfaces around these days, but what I'm up to ought to be simple enough to do in a single _ccall_: I think. Cheers, Alex.
Re: New debugging option `-xc'
Keith Wansbrough: > I've just added a new RTS option to GHC in the CVS repository. Running > a program compiled with -prof with the -xc runtime option on will cause > it to display the current cost-centre stack on stderr whenever an > exception is raised. This will give you an idea of which part of the > program raised the exception, hopefully helping you to trace those > "Prelude.head: empty list" errors that can be so frustrating to find. Excellent plan. I like the sound of this idea. But, I thought profiling was still broken? Is it now fixed as of 4.04, fixed in CVS, fixed just enough to allow the above, but not actual profiling, or...? Cheers, Alex.
Oops. [RE: Existential types, save me now?]
Alex, malreported, haskell and ghc-users lists...: > It does me ego no end of good to find out that I'm right, and the > compiler is wrong (for a change, it must be said...). Unless either > ghc or hbc catch up to the Hugs extension, though, avails me little > in practice, sadly. (Hint, hint.) I take this back: ghc accepts the syntax Mark gives without complaint -- either I wasn't as unmuddled as I'd thought, or I typoed more fluently than usually. I think I was also wrong about the ghc-docs -- checking the user-guide for ghc-4.045, it seems perfectly consistent -- heaven knows what version I was looking at/thinking of originally. Slinking off before I wreak any more confusion... Slán, Alex.
Re: Existential types, save me now?
Hi Fergus. > > > data OrdFuncExist = OE (Ord a => Char -> a) > > > That's not the syntax for a existential type, > that's the syntax for a universally quantified type > with rank-2 polymorphism. With that syntax, the > argument of `OE' must be a polymorphic function > with type `forall a . Ord a => Char -> a'. That would explain a lot. There seems to be a discrepancy between ghc and the ghc user-guide, in that event. > Is this supposed to be a heterogenous list, > or a homogeneous list? Sorry, I should have been a tad less terse: it's intended to be a homogeneous list, else the maximum wouldn't be well-typed. > Hmm, I'm not sure exactly what you're trying to achieve here... > but perhaps you just need to add > > instance Ord AnyOrd where > compare (MkAnyOrd x) (MkAnyOrd y) = compare x y > > to make it work. I haven't tried this, but this is unwrapping two (potentially) _different_ types, and then trying to compare them, isn't it? (Been there, done that, didn't like the type errors, in a previous brush with existential types...) Cheers, Alex.
RE: Existential types, save me now?
Hi Mark, all: thanks for the swiftly muddle-dispelling response. > | Here's some of the threatened examples: > | > | > data OrdFuncExist = OE (Ord a => Char -> a) > | > data OrdListExist = OLE (Ord a => [a]) > > Perhaps this is a GHC/Hugs difference, but the syntax that you've > used here isn't permitted in Hugs ... and in old versions where it > might have been allowed, it would suggest *universal* quantification > rather than existential. Must be such a difference. This is what ghc accepts, and documents: the user guide even claims to following hugs, here, so that'll be a tad out of date, then... > I just rewrote the definitions to fit with the Hugs syntax for > existentials as follows: > > > data OrdFuncExist = forall a. Ord a => OE (Char -> a) > > data OrdListExist = forall a. Ord a => OLE [a] > > and now the rest of the code that you sent type checks without any > apparent problem, including emap, blah, and emax. It does me ego no end of good to find out that I'm right, and the compiler is wrong (for a change, it must be said...). Unless either ghc or hbc catch up to the Hugs extension, though, avails me little in practice, sadly. (Hint, hint.) > [We keep trying to argue that it makes sense to use the "forall" keyword > here (because the constructor function that is being defined really does > have a polymorphic type). But perhaps this is a further indication that > the time for a "exists" keyword has come!] The forall looks syntactically _unnecessary_, slap-bang next to a context, but it's not confusing in and of itself -- well, not beyond my usual level of confusion about positive and negative quantifier occurrences. (Different systems and different docs certainly are, though.) Cheers, Alex.
Re: Existential types, save me now?
Here's some of the threatened examples: > data OrdFuncExist = OE (Ord a => Char -> a) > data OrdListExist = OLE (Ord a => [a]) > emap :: OrdFuncExist -> [Char] -> OrdListExist > emap (OE f) l = OLE (map f l) Grand... (Apparently.) But now I try to define an actual OrdFuncExist: > blah = OE fromEnum Inferred type is less polymorphic than expected Quantified type variable `a' is unified with `Int' In an expression with expected type: forall a1. (Ord a1) => Char -> a1 In the first argument of `OE', namely `fromEnum' In the right-hand side of a pattern binding: OE fromEnum What? I dinnae unnerstan', captain. The other problem: > emax :: OrdListExist -> OrdListExist > emax (OLE l) = OLE [maximum l] Now, I think I see why this doesn't work: but any ideas on how to fix? Cheers, Alex.
RE: ghc-4.04 + large constant defs = *BOOM*.
> > Oh, I forget to mention -- blowup is definitely in the code-generator > > these days; seems to slide by the simplifier without much difficulty, > > so I haven't yet bother trying any flag-twiddling. > > I tried compiling a 1500-element list of 10-tuples, and it went through > (both with and without -O) in less than 10M. Could you send me your > example? Certainly will; wasn't using -O, btw. Stand by for mail-spam... Cheers, Alex.
Re: ghc-4.04 + large constant defs = *BOOM*.
Oh, I forget to mention -- blowup is definitely in the code-generator these days; seems to slide by the simplifier without much difficulty, so I haven't yet bother trying any flag-twiddling. Slán, Alex.
ghc-4.04 + large constant defs = *BOOM*.
I've observed before that ghc is a tad sluggish and hungry on modules with large data defs within, but ghc-4.04 seems especially thus; on a 1500-ish length list of 10-tuples, I need somewhere north of 200M of heap to compile in, on a Solaris2.5 machine. I can ameliorate this a fair bit by chopping up the definition, but that seems a rather brutal solution. Any reason why it's so bad? (Example furnishable on request, if this isn't considered a Known Feature.) Cheers, Alex.
Re: ghc-4.04 on Solaris, on TclHaskell.
Earlier I reported: > Compiling the TclWidgets.hs module of TclHaskell, I get the following > somewhat unpleasant crunching sound: > > > yeats.ucc.ie:~/TclHaskell/src: ghc-4.04 -O -fglasgow-exts -recomp -static > -dcore-lint -fvia-C -syslib concurrent -c TclWidgets.hs -dshow-passes > *** Parser: > *** Renamer: > *** TypeCheck: > *** Desugar > Result size = 8744 > *** Core Linted result of Desugar > *** Simplify > Segmentation Fault > > > I'm using a source-built ghc-4.04, on Solaris 2.5. I've doubtless > managed to 'nobble' the install, somehow... (All the modules before > that seem to compile OK, though.) Evidently so, since this doesn't happen with the ghc-4.04 binary-dist. Oh well. However, I still have some TclHaskell probs on Solaris. The supplied makefiles use -static liberally, but on final link of the 'demo' program, it upchucks thusly: Undefined first referenced symbol in file dlclose /usr/lib/libnsl.a(netdir.o) dlsym /usr/local/lib/libtcl8.0.a(tclLoadDl.o) dlopen /usr/local/lib/libtcl8.0.a(tclLoadDl.o) dlerror /usr/local/lib/libtcl8.0.a(tclLoadDl.o) Do I need to use statically linked versions of tcl, etc? Or is there some other build tweak I can perform? Cheers, Alex.
phase codes in ghc-4.0x docs.
I was looking for the phase code for 'force option to C compiler' a little while ago (reason: coleague braining me for not using -pipe on a mega .hc compilation that was thrashing his hard disk...), but the table for this in the recent Users' guides (frex, on the Haskell site for 4.04) seem to be missing (or at least, mangled to the point of non-utility). Could someone post a 'reminder' of these (or better yet, fix up the userguide). Slán, Alex.
Re: fromInt method in ghc-4.04 ?
Ulf Schiller writes: > I'm just starting to use ghc-4.04 coming from ghc-3.02. I wonder whether there > is still a fromInt method available. The compiler says Variable not in scope: > `fromInt'. My code works with Hugs 98. Do I have to make any additional imports? I came across this one too (with code that had allegedly been tested with 4.04, ha-ha). IIRC, it's now exported (only) from GlaExts. Cheers, Alex.
RE: Happy v1.6.
> It looks like the Happy page is out of date. The version in CVS is 1.6 or > better. If you need Linux or Solaris binaries, you can try Michael Weber's > page: Thanks, that's indeed a help. My next worry is that when I try to build ghc from source on an Alpha, I'll get bitten on the bum by the ghc-needs-Happy-needs-(recent)-ghc syndrome, or otherwise spend mucho time wrestling with the Happy build setup to get round this. (I've done this before, I'm sure, but long enough ago that each time I do it, I've long since forgotten how...) Cheers, Alex.
RE: NON-ANNOUNCEMENT: The Glasgow Haskell Compiler, version 4.05?
> After a release, the version number in the repository is bumped up by > one, that's all there's to these rumours. A release of 4.05 isn't due > anytime soon (you have to report *all* the bugs in 4.04 first :-) I had better install it first, then... > Unless you want to become a fptools CVS groupie, stick with 4.04. This depends. Is there a badge, or a hat, or something?
Happy v1.6.
Since ghc-4.04 confuguration insists one has Happy v1.6, has this actually been released? I see no link to it from the usually suspect sites. If it's Imminent, can a make the modest suggestion that it have a standalone makefile in it? Having to slot it into a ghc source build tree has always struck me as both inconvemient, and overkill. Cheers, Alex.
NON-ANNOUNCEMENT: The Glasgow Haskell Compiler, version 4.05?
I've heard mutterings about the version count having gone up to 4.05, but seen no announcement to this effect. Is it still undergoing sea trials, or something? I ask as I'm pondering doing a source build or three, and I'm wondering whether to do so from the released 4.04, or from the 4.05 CVS. Cheers, Alex.
Re: CynWinTclHaskell...?
Does anyone else have experiences of building TclHaskell under CygWin? I'm assured that it ought to be possible, but have had no luck; crib sheets greatly appreciated. (Partial credit for negative results like 'it's a bust, drop back and punt to Linux'.) Cheers, Alex.
CynWinTclHaskell...?
[I've just had a brilliant idea: why don't I send this to the _correct_ list...] I've managed to entirely confuse myself trying to install TclHaskell on a Wintel machine, via Cynwin and ghc-4.03. Poking around it looks like the problem is with the Tcl/Tk libraries, which seem to have been complied up with Visual C++. Now, is there a magic incantation that will persuade TclHaskell to work with these binaries, or do I need to re-build Tcl/Tk from source, using gcc under Cynwin, so that the ghc link-step will find it to it's liking? Tell me this isn't as tortuous as it looks, someone, please... Slán, Alex.
Calling Haskell from...
What's the state of the art as regards calling Haskell functions from 'the outside world'? I note that Haskell Direct has this in its manifesto, but says "currently unsupported". Does that mean a moderate size black hole at the centre of something still potentially usable, or nothing much at all? Sorry if this is an 'RTFM' matter, just not sure at present precisely which 'FM'. Cheers, Alex.
Re: ghc-4.02 -- space.
> > Parting shot: isAlphaNum vs. isAlphanum? Haven't we been here before? > > Don't the committee have more amusing (and less pointless and gratuitously > > program-breaking) things to tinker with? (I know, nothing to do with > > ghc, I'm just in a mood to 'give out'...) > Ah, but each new committee has to make a few gratuitous changes > to put their mark on the language. And they should be such that > the user feels it. This is not the only pointless thing we changed. ;-) No... Just the one this user has already pointlessly felt! Incidentally, are my brain ceels failing entirely, or did either the 1.3 or the 1.4 committee already make the opposite change? Cheers, Alex.
ghc-4.02 -- space.
Quite impressed with 4.02 so far -- it walks the walks, see promohype elsewhere, why should I give you all too much free advertising? ;-) It does indeed seem to be more go-faster than 3.02, _but_: No profiling! Boo, hiss. Funny space behaviour -- a module I have that contains just one king-sized constant definition (169K of structured list) now takes _much_ more heap to compile with 4.02 vs. 3.02. Details on request if this is a unduly Surprising result. Parting shot: isAlphaNum vs. isAlphanum? Haven't we been here before? Don't the committee have more amusing (and less pointless and gratuitously program-breaking) things to tinker with? (I know, nothing to do with ghc, I'm just in a mood to 'give out'...) Slan libh, Alex.
RE: Uncompiling internal names...
Hi Simon, thanks for the tips; > We havn't checked out the profiler, remember. I'm using 3.02, I should have mentioned. (For this very reason.) > Here's our convention for splitting up the interface file name space: > > d...dictionary identifiers > (local variables, so no name-clash worries) Hrm. So, whence the trailing 0's? They all seem to be 0, so admittedly this won't help me much anyway... > $m... default methods Ah! All becomes clear. Well, part becomes clear_er_... Ta much. Slan, Alex.
Uncompiling internal names...
What do "$m" identifiers correspond to? I'm getting one of these lob up in a -prof -auto cost centre, and I don't know what/where/how it corresponds to. While I'm on the general topic, any hints'n'tips on decoding $d's? In a name like $dEqPriority0, I presume the first two elements are Class and Type, but does the "0" relate to the method, or is it just a name-supply artifact? Slan, Alex.
RE: RTS flags, at compile time?
> > Ah-hah! So I should just be able to write, in rts.c:
> >
> > #include "Rts.h"
> > void defaultsHook (void) {
> > RTSflags.GcFlags.stksSize = 102 / sizeof(W_);
> > RTSflags.GcFlags.heapSize = 802 / sizeof(W_);
> > }
> Well, sort of. I forgot to mention that we changed RTSFlags to RtsFlags,
> and that you'll need to #include "RtsFlags.h" which you can find in ghc/rts/
> in the source tree, *not* in a binary distribution - you might have to copy
> it into your source directory.
I guessed both of those, actually, but it made no diff. Do I have
to actually use a -I that points to the _source tree_, rather than
the installed version, from source? (Or do some copying to that effect?)
> A clean up of the external RTS interface will be forthcoming, no doubt.
Look forward to.
Slan,
Alex.
RE: RTS flags, at compile time?
> Looks like the docs are a tad out of date, sorry about that. Patch follows
> (you want ghc/rts/RtsFlags.h and ghc/includes/Rts.h respectively).
Ah-hah! So I should just be able to write, in rts.c:
#include "Rts.h"
void defaultsHook (void) {
RTSflags.GcFlags.stksSize = 102 / sizeof(W_);
RTSflags.GcFlags.heapSize = 802 / sizeof(W_);
}
then: ghc rts.c? But, no:
swift.ucc.ie:~/check2: ghc rts.c
rts.c:3: `RTSflags' undeclared (first use this function)
rts.c:3: (Each undeclared identifier is reported only once
rts.c:3: for each function it appears in.)
What momumentally obvious blunder have I just committed? (I shouldn't
have to declare RTSflags, I thought, as it was already "stubbed"?)
Slan,
Alex.
RE: RTS flags, at compile time?
> Do you mean
>
> {-# OPTIONS -H12m #-}
That's the one. Apparently too much C code in section 2.13 for
me to make it to the end of the section, awake. ;-)
Slan,
Alex.
RE: RTS flags, at compile time?
Two small errors in my previous message... Firstly, it's not C, it's
Core. Gah! I obviously _really_ didn't make it to the end of that
section awake.
Secondly, and more to the point...
> Do you mean
>
> {-# OPTIONS -H12m #-}
>
>
> Or do you want to bake the options into GHC itself?
Neither. I mean, how do I (or indeed, can I?) get the effect of:
a.out +RTS -H12m
by
a.out
and presumably some hypothetical incantation that looks something like...
ghc Main.hs -RTS-Incantation -H12m
Slan,
Alex.
Instance contexts.
I think this has been discussed before, but I've just run into it myself. I have a MPC 'Set', in the usual bog-standard fashion, and I want to define interval arithmetic over sequences of such sets. This requires they also be partially ordered, and of a numeric type themselves, so I end up with something like: instance (Set s n, Num (s n), POrd (s n)) => Num [s n] where n + m = bigunion [ overlaps [n1 + m1 | m1 <- m] | n1 <- n] This works in 3.01, but not in 3.02. Is this restriction a sensible one? Come to that, are my classes? It seems to me that the nature of the MPC forces me to use non-variable contexts, which I think looks a bit uglky, but I don't know of another way to get the same effect. Slainte, Alex.
hslibs
Well, so far I've gathered that syslibs ghc and posix have moved and been renamed, and that the "full story" is hidden someplace within the docs -- someplace I haven't yet been able to find. Any further clues as to where I might find the dire fate that's befallen hbc and contrib? Are these no longer distrubted or supported _at all_? I had assumed they were just undergoing Yet Another Reorganisation. Slainte, Alex.
ghc/NT
Hi all. What's the current state of play with ghc (any version), on NT machines? Slainte, Alex.
overlapping instances.
SPJ: > Same issue. Show [a] exists already and overlaps with Show [Blah]. > 3.0 is a bit more restrictive than 2.xx, but it is Righter I think. > Dissenting opinions welcome. I think I semi-agree, though I think the change in ghc-3.00 ought to have been more loudly flagged. (And not denied, as happened when I reported this. (-; ) Not knowing there had been a change was the only reason I was perplexed when this bit me. My only real reservation is about the _definition_ of overlapping instances (to wit, unifiable heads). It seems to me that it would be useful to try and use the class context to "disambiguate" potentially overlapping instances -- though ghc-2.?? _didn't_ allow this, while it did allow blatant overlap, as per the above. I don't know if there's a general, sound scheme to do this, however, so this may just be pipe-dreaming. Slainte, Alex.
Re: MPC dunce question.
Simon, thanks for the explanation, that makes a bit more sense now. So the situation is that a relaxation of this rule is possible, it's just a matter of whether this would ever be any use to anyone, and indeed worth the extra pain of all those (additional) Overlapping Instance!, and Ambiguity! errors... > In the multi-paramter case things are less clear: > > class C a b where > op :: a -> a > > Here, op :: C a b => a -> a. So suppose we use op on an Int argument. > Then we need to find an instance for (C Int b). If there is an > instance > > instance C Int b where > ... > > (and of course no overlapping instances) then we are home. > Is that your stituation here? More or less. The class I was trying to define is buggy anyway, so isn't really a good example. (Effectively I was trying to re-do "Collection" with the collection _type_, rather than type constructor, as the first type parameter, which I don't think makes much sense, as it leads to an underconstrained situation between the two parameters.) Slainte, Alex.
MPC dunce question.
While hacking around with MPCs, trying to define a variant of the Collection class, mutated to suit my own fiendish ends, I ran into this: Intervals.hs:345: Class type variable `e' does not appear in method signature union2 :: s -> s -> s What's the significance of this restriction? (I presume this is caused by a requirement that all class vars appear in all methods.) I don't recall it being mentioned in the proposal for MPCs, but I may have overlooked and/or forgotten it. I don't suppose it ever really "bites" anyone, since one can always shove the appropriate constraint on the missing variable into the other methods, that do use it, but I don't instantly see why that's The Way to do it. Slainte, Alex.
Re: Pattern-matching strings.
Simon M:
> Quite possibly - pattern matching on strings involves building a
> dictionary for Eq [Char], unpacking the string (it's represented as
> packed in the object code), and performing the comparison. This is
> probably bad.
Ah-hah, I didn't realise there was unpacking going on too; that may
explain a lot. I've converted to an enumeration type, to avoid this
happening in an "inner loop", and was mildly boggled at how much
difference it make.
> Try replacing
>
> f "aa" = ...
>
> with
>
> f ('a':'a':[]) = ...
I'll bear this in mind for the _next_ time I run into this...
Ta,
Alex.
Re: ghc-3.00 language
S.D.Mechveliani: > Has ghc-3.00 to announce that it implements not Haskell-1.4. but its > certain extension? > If yes, how to call this extension? "Standard Haskell". ;-) I vote that ghc-3.00 -fgla-exts _not_ enforce the M.R., in the same spirit. (To wit, John Hughes baiting. ) Slainte, Alex.
Pattern-matching strings.
Is pattern-matching short strings (one or two characters) likely to be _vastly_ less efficient than matching against a single level of constructor? (Order of magnitude, plus.) Trying to make sense of some profiling numbers, here... Slainte, Alex.
"CodeOutput" go-slow.
Has anyone else, while playing with -dshow-passes and heap usage information, noticed how alarmingly heap-thirsty the phase CodeOutput (new to 2.05, IIRC -- previously part of CodeGen?) seems to be? For at least one program, it appears to have a greater heap residency than any other phase, which is a little surprising. Is my (Happy output) code just pathological, or is this a Real Problem? Slainte, Alex.
Not very Happy.
Further to my previous comments about ghc-2.04 and Happy output, I can report that having mangled happy-0.9 output to work with 1.4ish arrays, the situation is more dire yet. For the same happy input program as previously reported, ghc _really_ struggles to compile the -a output -- with a 100Mb heap under Solaris, it doesn't get past the DeSugar phase. (I'd tell you what happens with a 120Mb heap, but it's still trashing one of our Ultras quite senseless.) Must be a space-leak, surely? Cheers, Alex.
2.04 memory/code-bloat.
Hi all. To my horror, I've just discovered that ghc-2.04 appears to reverse the recent trend of ghc releases by being significantly less efficient on one of our Problem Child programs. In particular, it both takes (even) more memory to compile; and the object code size is (even!) bigger. The program itself is a 292-rule Happy output text, in case this rings a bell with anyone. Under 2.02, it compiles in a "mere" 80Mb (probably less, in fact), and produces a .o which is a tad over 1Mb in size. Under 2.04, it seriously struggles to compile in 100MB (sob), and the object code is nearer 2Mb. Even that requires some juggling with compiler flags; too many loops of the core2core simplifier, and it runs out of heap in that phase; too few, and it runs out of heap in the code generator. So my question is, does anyone have a clue what's going on, and better yet, how to fix it? Is there some 2.04-only optimisation that interacts badly with this particular program, or is the compiler behaving "leakily"? I'm suspecting the first is the more likely culprit at this point, from the difference in simplifier activity between the two cases. All advice gratefully received. Cheers, Alex.
The wonderful thing about Standards...
... is that there's yet another of them! Simon L Peyton Jones ordains: > Don't bother with 2.01. The trouble with regarding 2.02 as a Mere Bugfix Release are all those *term deleted* library incompatibilities. Why is the August Committee _still_ rearranging these things in seemingly incosequential ways, might I be so bold as to ask? Adding to the Libraries, or even moving things from the Prelude to libaries, as Chris suggests for the more allegedly- arcane features of "Read" is all very well; but deleting and renaming functions from modules like List and Maybe, brings to (at least this addled) mind the phrase Make an End to It. Somewhat irascible after having spent the afternoon massaging imports, Alex.
Re: Free Haggis: 1.3 Interface File Error?
> Has anyone seen the following ghc-2.01 patch 0 (Haskell 1.3) > interface file error? It's got me stumped! The eponymous individual below types: > satnam@albatross> make > ghc -fglasgow-exts -syslib hbc -c HaskellHard.lhs > > Interface-file parse error: line 1 toks= [ITinstance, ITqconid BitOps.BitClass, ITqconid Prelude.Float, ITsemi, ITinstance, ITqconid BitOps.BitClass, ITqconid Prelude.Int, ITsemi, ITinstance, ITqconid NSI.NSI] Hi Satnam, This is very much stream-of-consciousness comment, but this _looks_ rather like the sort of error I've fumbled my way into (and sometimes out of) by inadvertently having ghc-2 import a ghc-0 input file... Alex.
