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 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 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
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 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 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: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 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 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
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
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
Bracketless branch if, sugar to taste...
Yes indeed, one can further sugar Keith's suggestion to eliminate the need for brackets around the branches. Though as this means using an infix operator then and else, with corresponding mangling of the lexical appearance of same, this becomes increasingly a matter of taste (or perhaps, in need of sound dental advice). Example: ifM (return (1==1)) `then_` print (2+3) `else_` print (3+4) Of course, the type errors are going to start looking more and more mysterious if you get 'em in the wrong place... Cheers, Alex. infix 4 `then_` infix 5 `else_` data Branches a = Branches a a then_ :: (a-a-a) - Branches a - a then_ sel (Branches t e) = sel t e else_ :: a-a-Branches a else_ t e = Branches t e iff b t e = if b then t else e ifM b t e = do test - b if test then t else e ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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
Possibly ancient history non-compliance.
ghc-4.04 and ghc-4.08 both complain about the following: No instance for `Show HandlePosn' But according to the report, they should be showable (if precious little else). Haven't a version of 5.00 to hand (but will be installing 5.02, promise!) so I haven't checked if this has changed since. Cheers, Alex. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 probs.
Hi all. I've had a problem with cascade menus with TclHaskell under Solaris, running tcl and tk vs 8.0. In short, they don't (cascade, that is). Anyone else found this, and better yet, do they have a fix? The same code runs fine on Cygwintel... Cheers, Alex.
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.
Re: deleteBy
S. Alexander Jacobson: Can we stop polluting the namespace with list based function definitions? Most of these functions: delBy, filter, map, concat, length, take, takeWhile, etc. are well specified for data structures other than lists. Regardless of whether Haskell includes generic programming extensions, it would be nice to be able to use these function names for the same operation in other datastructures (even if they are implemented manually). That seems a tad harsh: given that the proposal was for an extension to the _List_ library, adding list based functions seems neither inappropriate, nor to pollute 'the' namespace. Let's hear it for qualified imports! Slán, Alex.
A case in point.
John Atwood: You have it right, except you need to 1) explicitly type test, test:: Reader [Char] Char José Romildo Malaquias: --- test = do env - ask if env == "choose a" then return 'a' else return 'b' do_test = runReader test "choose a" The very sort of thing I had in mind when I suggested some explicit typings would be more concisely expressed by a type-ap. Slán, 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: 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.
Type application: a modest proposal.
Now that rank-2 polymorphism seems to be part of the 'received standard' (at least two implementations support 'em, and I assume they're a shoo-in for Haskell 2), couldn't we really also do with type application? It seems that ambiguity is here to stay in Haskell, and in principle R2L makes the situation (at least as regards "uninferability") worse. But it also provides at least a partial solution: when one has to disambiguate a subexpression, as opposed to a top-level def., in several cases I've been bitten by, it would have been more concise to remove the ambiguity with a type-ap, than by supplying a complete signature. I'd suggest a syntax for this, but I shall refrain, on account of a) not having thought of one, and b) having an uneasy feeling I've missed something obvious and am about to have this suggestion shot down in flames. Cheers, Alex.
A case in point.
John Atwood: You have it right, except you need to 1) explicitly type test, test:: Reader [Char] Char José Romildo Malaquias: --- test = do env - ask if env == "choose a" then return 'a' else return 'b' do_test = runReader test "choose a" The very sort of thing I had in mind when I suggested some explicit typings would be more concisely expressed by a type-ap. Slán, Alex.
RE: Type application: a modest proposal.
Frank Christoph: I think he means the application term associated with second-order lambda calculus' "big lambda," usually written "M [T]" or just "M T" where M is a value term and T is a type term, e.g., "(/\X.\x.x) Int 3". Should be: "(/\X.\x:X.x) Int 3". (Doesn't make much sense if you don't say what type variable your abstracting...!) That's exactly right. Sorry if I was being over-terse in my original. Fergus is of course correct that you can write any type application as a partial type spec too, if the syntax is thusly extended. However, I think the type-ap style would in many cases still be somewhat more concise, so it's not clear to me that the two are redundant -- or that if they are, which is superior... 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.
_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: _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.
What to wish for.
Eduardo Costa on small Haskell compilers: Besides, it becomes easier to install, and uninstall. For instance, Dr. Alcimar (that you know quite well) is finishing his prosthetic arm for amputees. Clean was able to produce code that was small enough, uses heap sparingly, and was fast enough to do the pattern recognition of electric myographic signals using a novel algorithm created by Dr. Pascoarelli. The program must be small because it runs on a laptop computer, with little memory (one can not ask an amputee fetching a large computer). I'm not 100% clear if what you're describing is an embedded system (in which case as others have said, object code size seems more significant), but I don't think ghc (for example) is such a resource hog as you imply. (In saying which I'm not waiving my right to complain on ghc-users about code-bloat and other infelicitudes, Simon, Simon, and Sigbjørn. g) ghc runs pretty happily on my laptop (and would run better yet if "Mobile Pentium II" chips weren't such a misnomer). I must admit that while I'm not free from complaints about ghc, the priorities of the team seem broadly correct, from this end. Wraggling with the nuances of the type system may not the sort of snappy bullet point priority one one stress if one were seeking to flog Haskell as a 'product', but as a user of the language, they're the sorts of thing I bump my nose into fairly regularly, and if people like Simon (and Mark) aren't going to address them, who is? (I shall refrain from belly-aching about collection types and the like, for the nonce...) Cheers, 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.
Existential types, save me now?
Hi all. I'm wrestling with a typing problem, which I keep hoping that I ought to be able to solve with existentially quantified data types, but such a problem keeps eluding me, leading me to rend my hair at the prospect of instead having to use a some sort of dynamic type or universal type hack. (Ick.) The basic idea is that I want to be able to (for example): generate an existentially quantified list of some type 't', given a function (presumably itself in a existential quantifion wrapper of some sort) return a 't'; sort such an existentially quantified list (or other data structure); and other such fun stuff. I can see a problem in the latter case, in that the natural type for such a sort doesn't work (the E-bound type 'escapes'), and don't immediately see a way that it can be 'rewrapped' in type correct manner. Any pointers on how to do this? I'm not clear if this a) impossible to do with existential types, full stop, not possible with this particular scheme, or simply requires a different work- around than I've been using. (This part isn't necessarily vital, as it may be satisfactory to have a monotyped result.) The first part mystifies me, though: I can't get the 'existential map' to work, don't see why it doesn't/shouldn't, don't understand the sorts of error message I've been getting, and AFAICS, being able to do this sort of thing seems crucial for me to do anything at all useful with these things. Sorry for the vague and dufferish nature of the inquiry; I shall furnish simple examples of (non-working) code as required (and/or as I get them off another machine). Cheers, 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.
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?
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: 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: Partial Type Declarations
Koen Claessen: I want to propose a modest extension to Haskell, which would solve a common irritating problem in programming in Haskell, and on-the-fly solves the practical programming problems occuring due to the monomorphism restriction. I've banged into this more than once, so I have more than a little sympathy for your suggestion. As you imply, though, it's at its most annoying when one is forced to add types due to the MR, and at least in this case, it's something of a case of treating the symptom, rather than the disease. I'd be happy to see something like this in Haskell 2, as well as, but not instead of, a revisited/ improved/abolished MR. (Before I'm accused of aimless wish-listing, John Hughes produced a proposal for distinguishing MR-bound and non-MR-bound equations, which seemed to me to be a perfectly satisfactory treatment (unlike the status quo, which I find distintictly tiresome).) Cheers, Alex.
No Subject
The Sender field should be ignored (as per RFC 822) by mail software if there's a From field. The first From field is not legal as it is not delimited by a ':' I'd say the Pine setup is wrong. --Sigbjorn
RE: ghc-4.03 on cynwin deriving oddity.
It's a bug, which is fixed in 4.04 Ah-hah... (I could likely have tested this myself, had I had the gumption...) (a Win32 version of which is due out shortly.) Excellent. For one scary moment thoughts like 'Windoze build from source' were going through my head. Cheers, Alex.
Re: Building GHC on a PPC Mac
From UNKNOWN Received: from joyce.ucc.ie by vanuata with SMTP (MMTA) with ESMTP; Tue, 12 Oct 1999 15:45:59 +0100 Received: (from abf@localhost) by joyce.ucc.ie (8.7.3/8.7.3) id PAA11955 for [EMAIL PROTECTED]; Tue, 12 Oct 1999 15:45:02 +0100 (BST) [This is a resend; forwarding from '[EMAIL PROTECTED]' seems to be highly unwell.] Observe: BASH.EXE-2.02$ cat Enum.hs enumerate :: (Enum a, Bounded a) = [a] enumerate = [minBound .. maxBound] data Test = Foo | Bar | Blah | Nonsense deriving (Show, Enum, Bounded) main = print (enumerate :: [Test]) BASH.EXE-2.02$ ghc-4.03 -static Enum.o BASH.EXE-2.02$ ./a.exe [Foo,Foo,Foo,Foo] Whereas, with ghc-4.02, under Solaris 2.5: yeats.ucc.ie:~/LVO: a.out [Foo,Bar,Blah,Nonsense] What, as they say, gives? Cheers, Alex.
Re: ghc-4.03 on cynwin deriving oddity.
enumerate :: (Enum a, Bounded a) = [a] enumerate = [minBound .. maxBound] data Test = Foo | Bar | Blah | Nonsense deriving (Show, Enum, Bounded) main = print (enumerate :: [Test]) BASH.EXE-2.02$ ghc-4.03 -static Enum.o BASH.EXE-2.02$ ./a.exe [Foo,Foo,Foo,Foo] To be a tad more specific, the problem is the derived toEnum, which defines toEnum 0 = Foo, toEnum 1 = Foo ... Cheers, Alex.
O, O'Haskell, where are you?
Does anyone have a 'live' link to Johan Nordlander's O'Haskell? http://www.cs.chalmers.se/~nordland/ohaskell/ seems to be unwell. Cheers, Alex.
Re: OO in Haskell
Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax': I would like to be able to do the things in Haskell that I can do in C++ but currently Haskell's type system is too simple to allow me to do them. There are also some things I can't do in C++ but really wish I could, I also wish I could do those things with Haskell. I am not saying C++ is an elegant language, however it is a powerful one. I would like to have that power in Haskell. I concur that there are places, due to its desire to maintain strong typing properties that Haskell is 'less powerful' than C++. But the consensus seems to be that strong typing is worth the occassional pain (or at least we avoid the pain by not using Haskell if the task isn't well-suited, perhaps), and that we _don't_ want to abandon that in favour of C++'s inherent lack of type safety (or that if we do, we go and write C++ programs). Yes, there are areas in which it appears to be possible to make Haskell-style typing more general, without any basic loss of typing properties, but as you say in a related context, it rapidly gets Rather Technical, so the issues aren't as simple as 'Haskell's type system should immediately be made to accept everything C++ would'. And that says nothing about the desirability of Haskell syntax vs. some other system's, in cases where their power is essentially equivalent, which was the particular topic at hand. Haskell for *most* things has far cleaner syntax than just about any other language out there. However, OO is not one of them. "OO" is such a open-ended term, with such a lack of any simple definition that I think it'd be best to avoid it entirely (I mean in this sort of discussion, though 'ever' wouldn't be a bad plan either), in favour of more specific, albeit more open-ended, features of same, whether those be message-passing, ad hoc polymorphism, subtyping, inheritance, state encapulation -- et cetera, et cetera. Haskell takes a decidedly 'cafeteria' approach to that shopping list, so blanket statements like 'Haskell is good/bad for OOP' obscure more than they reveal, IMO. Slán, Alex.
Re: OO in Haskell
Me: Your 'partial' list would appear, from a initial inspection, to leave little left of either type safety or referential transparency. KA: Could explain how they could. There is a very nice paper written up on True ad-hoc polymorphism. By a build in build in dynamic type system I mean being able to safely recover types from an existential collection using a runtime check. That's immediately weakening what Haskell understands by 'type safety'. (Though not necessarily unacceptable, as Fergus Henderson says, if I can tell by the top-level type of a program whether it's statically of sound type, or not.) I can not see how State encapsulation will weaken any type system. No, that's be the 'referential transparency' part of the above. (I assume you're talking about something considerably different from state-by-monads, here.) [...] It's not clear from the above agenda, though, that it wouldn't be easier to define (C++)++ (the second ++ being lazy evaluation, HOFs, partial ap., GC). Which don't get me wrong, would be an entirely good thing, IMO. God NO, I like C++ because it is powerful but adding more features on an already ugly (but powerful languge) will make matters worse my making it more powerful but so ugly with so many pitfalls that no one will want to use it. True; my Secret Agenda is that at some point they might start taking 'features' back out... (Case in point, Java: add in one nice feature, GC, take out several ugly ones... resulting in a still pretty ugly language, but there's more rejoicing in heaven, etc, etc... g) Cheers, Alex.
Re: OO in Haskell
Kevin Atkinson: 2) More specific types, you can't _easilly_ call the more general type. For example in OO this is very commen: class Base virtual foo() do stuff class Derived, extends Base foo() call Base::foo() doo stuff You can certainly do this in Haskell; the only difference (and here we return to a well-worn point) you can't _overload_ the name of a different method between two different classes. 3) Encapsulation. You can't have private and protected members. Some of this can be done using modules. However it is more work. What exactly can't be done with classes, and how, substantively, is it more work? 4) Cleaner more natural syntax. More like C++, you mean? Slán, Alex.
Re: OO in Haskell
Kevin Atkinson: 3) Encapsulation. You can't have private and protected members. Some of this can be done using modules. However it is more work. What exactly can't be done with classes, and how, substantively, is it more work? class Foo private: -- only members of the Foo class can see this ... protected: -- only mebers of the Foo class and those derived from foo -- can see it. public: -- anyone can see it Well, the only problem I can see with doing this with modules is if you wanted 'private' and a 'protected' members of the _same_ class, which I confess I've never been mortally offended by lack of a capability to cope with. 4) Cleaner more natural syntax. More like C++, you mean? Or Java. Although many OO things can be done in Haskell C++ and Java syntax is more natural more doing OO. If I sound a tad skeptical about some of your suggestions, it may be because you do seem to have something of the running undercurrent in your posts that what Haskell _really_ needs to be is C++ with some functional bits and bobs added on, which instantly gets my defensive instincts going, as it sounds, without wanting to provoke Language Wars here, like a truly alarming prescription for a language design, and not one very compatible with Haskell as it's currently constituted. In short, I'm unaware of any way in which C++ syntax is 'more natural', other than in the sense of 'for a C++ programmer', or 'cleaner' -- at all. Slán, Alex.
Re: Where is Server Side Scripting code?
Jan Skibinski: What is available from haskell.org are two much outdated versions of CGI library: one by Erik himself and one modified (and adopted to Haskell 98) by Sven Panne. By outdated I mean that they both are based on Erik's earlier work and much predate the refined and simplified concepts, quite nicely described in the paper. I encountered this same situation several months ago; I asked around, but I'm no further forward, I'm afraid. Cheers, Alex.
ghc-4.04, Alpha.
In order to install ghc-4.04, I need to install the binary v. of 2.10 (this should be OK for doing that, right?) Immediately I come a cropper, thus: wisdom.ucc.ie:~/ghc210/fptools: gnumake in-place gnumake config-pkgs bindir=`pwd`/bin/alpha-dec-osf1/ghc-2.10 libdir=`pwd`/lib/alpha-dec-osf1 datadir=`pwd`/share/ghc-2.10 gnumake[1]: Entering directory `/usr/local/users/abf/ghc210/fptools' Configuring ghc, version 2.10, on alpha-dec-osf1 ... Creating a configured version of ghc .. Done. Creating a configured version of stat2resid .. Done. Creating a configured version of hstags .. Done. Creating a configured version of mkdependHS .. Done. Creating a configured version of hscpp .. Done. /bin/sh: syntax error at line 1: `;' unexpected gnumake[1]: *** [config-pkgs] Error 2 gnumake[1]: Leaving directory `/usr/local/users/abf/ghc210/fptools' gnumake: *** [in-place] Error 2 If this is an Alpha shell version blooper, it's not clear to me where and how to fix it: redefining SH = /bin/bash in the Makefile certainly didn't help. Also, I've been hacking my way around needing happy 1.6; I think I can 'fake' this, but it ain't gonna be pretty. Better suggestions gratefully received. Cheers, Alex.
Re: ghc-4.04, Sun Solaris 2.5.
I wrote:
syntax error at ../../ghc/driver/ghc line 1855, near "sub runLinker("
Execution of ../../ghc/driver/ghc aborted due to compilation errors.
gnumake: *** [Adjustor.o] Error 255
Evidently Perl versionitis. 5.001 no like; 5.005 likum plenty fine.
(This seems familiar, but I didn't notice an installation caveats
beyond using any-old Perl 5.)
Cheers,
Alex.
ghc-4.04, Sun Solaris 2.5.
yeats.ucc.ie:~/ghc44/build/ghc/rts: gnumake all
../../ghc/driver/ghc -I../includes -I. -Igum -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith
-optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2
-optc-fomit-frame-pointer-c Adjustor.c -o Adjustor.o
syntax error at ../../ghc/driver/ghc line 1855, near "sub runLinker("
Execution of ../../ghc/driver/ghc aborted due to compilation errors.
gnumake: *** [Adjustor.o] Error 255
Thoughts?
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?
Re: CPP is not part of Haskell
Either, cpp (or some preprocessor standard), should be made part of the Haskell language definition or Haskell files that require a preprocessor should have a different extension. Since, I assume that the hugs team has a good reason not to build in cpp functionality, I am suggesting that Haskell files with preprocessor directives have the extension .hs.cpp While I can see Alex' point, I have mixed feelings on this one: you could argue the same thing about _any_ non-standard extention to the language. Whether they're implemented by a pre-processor or not seems to me largely a secondary issue. 'Ware the slippery slope... Slán, Alex.
ghc-4.03/cygwin catch-33.
Program won't compile in default max heap; -H objects that I should instead use -M, to raise same; -M isn't a recognised option. Fixing any one of these would do. ;-) (If it's fixed in 4.04 or 4.05, extra credit for a binary build: I've just about maxed out on Windows tinkering for the week (and it's only Tuesday)...) (Incidentally, it's falling over on the simplifier, on a very non-complex module, which seems odd. (One huge datavalue, basically.) Traditionally, though, when this is a problem, tweaking simplifier flags to help just means it falls over on code-gen instead.) 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.
Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)
From [EMAIL PROTECTED] Mon Sep 27 18:50:33 1999 X-Authentication-Warning: sun00pg2.wam.umd.edu: kevina owned process doing -bs Date: Mon, 27 Sep 1999 13:50:59 -0400 (EDT) Kevin Atkinson: You have a collection of Shapes. Some of these shapes are circles, however, others are rectangle. Occasionally you will need to extract these specific shapes form the collection of generic shapes as there is no way to find the length and width of a generic shape, only its area and circumference. So I need to cast the objects in shapes that are *really* rectangles back up to rectangles. 1) test for the true type of the object 2) cast it back up to its true type There's no need for a 'cast' here, as Shape can be represented as a class. The trickier part is putting different types into a heterogenous collection, and then manipulating according to their _individual_ types. Unless you want to restrict yourself to a particular set of possible types (in which case it's straightforward, anyway), this seems to me like it _is_ a case of dynamic programming. I'm aware that Haskell doesn't precisely ape that sorts of 'OOP style' that the likes of C++ admits What I've yet to see is any argument that this is anything other than the wisest possible decision... And by this you mean... That C++ has a very poor type system. Slán, Alex.
Re: To all those who don't like ad-hoc overloading
Kevin Atkinson: I take it that you are happy with names such as: [long list] Yes. Certainly I'm more than happy that types with completely different signatures have different names.
Re: What *I* thinks Haskell Needs.
Fergus Henderson: One example is the case where you already have existing code that creates a heterogenous collection, and you want to extract an element from that heterogenous collection, and then if it is a member of a particular type class perform action A otherwise perform action B, *without* modifying the existing code. OK, it sounds like this would indeed require 'tweaking' (at least) the existing code, it the representation of the collection doesn't admit the required operations. The dynamic typing extensions in GHC/Hugs will let you cast to a particular type, but they won't let you check whether that a dynamically typed value is a member of a particular type class, or cast such a value to a type class constrained type. I had noticed that apparent limitation myself, while pondering a certain problem (to which it turns out that (I think) existential types are an adequate solution, in that case). It would be interesting to investigate adding 'dynamic classes' to Haskell, but it introduces the issue of what type to give the resulting function: I think I'd want to clearly distinguish between a genuine (boundedly) polymorphic function, and one which covertly does a case analysis of the (sub-)classes of its argument. Cheers, Alex.
Re: Mailing lists down for a while, should be back up now
Maintainer's note: The Haskell mailing list, and all the other lists served by haskell.org, have recently moved to a new machine (the "real" haskell.org). None of the addresses have changed, and the address for admin requests is still [EMAIL PROTECTED] The mail headers certainly changed, though, and in a mail-filter breaking manner. Could you give a little more notice of such changes in the future? Thanks. Slán, Alex.
Re: What *I* thinks Haskell Needs.
Kevin Atkinson, replying to me: If I understand you correctly, then the best way of doing this would be with existentially (boundedly) quantified data types, currently a non-standard extention present in hbc (and I think, ghc, these days, not sure if it's with the same generality.) existentially (boundedly) quantified data types can not cast up. 'Cast up' to what? If you can't write a class context that descibes the relatedness of everything you want to put in a heterogenous collection, then I'm inclined to doubt if it isn't more heterogenous than is sensible. In order to do that you would ALSO need to use the dramatic typing extensions found in the GHC/Hugs library. I don't see how this relates to anything other than heterogenous collections; perhaps an example? The point that class hierarchy isn't precisely _type_ hierarchy is exactly the point I am trying to get gate Haskell needs to also be able to support a class hierarchy if it is to really support OO style programming. I'm aware that Haskell doesn't precisely ape that sorts of 'OOP style' that the likes of C++ admits What I've yet to see is any argument that this is anything other than the wisest possible decision... Cheers, Alex.
Re: What *I* thinks Haskell Needs.
Kevin Atkinson: Yes but often putting things in type classes is tedious to do. I also want to be able to overload not only on the TYPE of parameters but also on the NUMBER of parameters. It IS possible to do these things and it DOES make sense in a curing system. That's far from clear. Certainly, I don't think it's likely to be reasonably possible a conversative extension. 2) Support for TRUE OO style programming. No. I mean being able to do things such as. Have a collection of object of a common base class AND be able to up cast them when necessary. If I understand you correctly, then the best way of doing this would be with existentially (boundedly) quantified data types, currently a non-standard extention present in hbc (and I think, ghc, these days, not sure if it's with the same generality.) Be able to override methods and ALSO be able for the overriding methods to call there parent methods. If by that you mean a more flexible and general means of specifying defaults, I'd agree. Method definitions don't have a strict 'parent' in the usual OO sense, since the class hierarchy isn't precisely a _type_ hierarchy (and a good thing too, IMO), so I'm not entirely confident about what you mean by parent method, though. 4) Being able to write do a - getLine b - getLine proc a b as proc getLine getLine and the like. proc getLine getLine will be interpreted as the do notion above. With a powerful enough type system it WILL be possible. I will go into details later if anyone is interested. Please do. This is something that it would be nice to do, on one level: occassionally one has to 'monadise' part of one's program, and due to the above effect, end up driving a coach and four through the rest of one's code. But it's a somewhat subtle subtle to address without either a) severely breaking the type system; and b) totally confusing the user, if the result involves quite different entities being denoted by the same symbol. The question is, if one is using the same symbol for a collection of semantics objects, then sensibly, they must be _related_ things, so, how best to capture that relatedness? The OOP answer of 'not at all' is a very poor one, IMO. Cheers, Alex.
Re: What *I* thinks Haskell Needs.
Fergus Henderson, replying to me: That's far from clear. Certainly, I don't think it's likely to be reasonably possible a conversative extension. [...] Ad-hoc overloading and type inference don't mix so well, because you can easily get ambiguities which the compiler cannot resolve. However, the user can add explicit type annotations where necessary to resolve the ambiguities. If you can can ambiguities arising in what would otherwise be a well-typed Haskell program, then that'd make it a non-conservative (which I shall spell right, this time) extension, in my book. I guess you could always choose the 'Old Haskell Compliant' option, though, in such cases, though that could be a mite confusing. (As if the MR isn't, mind you...) ghc does not offer any facility for type class casts. I'm not clear what's meant by this; are we speaking of some sort of conversion to a common _type_, in some manner? Cheers, Alex.
CynWinTclHaskell...?
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.
RE: Message repeats: Alleged WinTel v4.03 bugs?
'getEnv "PATH"' returns, not the value of PATH, but the whole environment. Which is also handy, but not what I understood the report to specify, and not what ghc-4.02 does on this 'ere Sun. Can someone comment on (esp.) the second of these? Is this reproducible, is it the case _only_ on Win32, and, is it/will it be fixed in 4.04, or thereafter? (In the meantime, I guess a work-around is fairly obvious.) Can't reproduce this here with 4.03pl1 (win32). Me neither. D'oh. I encountered a quite _different_ problem instead (I'll report this as best I can, later, but it seems highly difficult to reproduce in a simple example), but this one seems to have entirely 'gone away', to the point of making me doubt my sanity. Or at least my original 'experiment'. Re: first point, the generated .hc files aren't ANSI conformant, so I'm surprised it has worked in other contexts. I haven't tried as recent a version of ghc under Solaris, so it may be versionitis, rather than platformitis. Cheers, Alex.
Alleged WinTel v4.03 bugs?
Two oddities I've noticed with ghc-4.03, win+cygnus binary build: The -ansi flag makes gcc go berserk on the generated code. I stopped. 'getEnv "PATH"' returns, not the value of PATH, but the whole environment. Which is also handy, but not what I understood the report to specify, and not what ghc-4.02 does on this 'ere Sun. Cheers, Alex.
Re: Windows NT installer works.
Mircea Draghicescu: The other question still remains: is this 4.03 or 4.04? Having recently dl'd the same thing, looks a lot like ghc-4.03 to me... I presume there's not a binary build for 4.04 (at least, not yet).
Re: Which GUI on X11R6 ?
Wilhelm B. Kloke: has anybody there an idea which GUI is usable with Haskell 98 on a Unix/X11R6 system (FreeBSD to be complete)? It seems that all GUI stuff develepmont (Fudgets, Haggis ...) has been stalled since some years. I'd look at TclHaskell, if I were you. It's not strictly speaking under active development or support, as I understand it, but is in a usable state, and other people seem to be tweaking it, and/or working on related methodologies. Cheers, Alex.
Re: Associativity of $
Manuel Chakravarty and Olaf Chitil debate the fixity of ($): I think the idea behind $ is exactly the change of associativity. Hmm, I thought, the idea behind it is a change of precedence... I use $ a lot to save a lot of brackets. I very much prefer f $ g $ h $ i $ j $ x to f (g (h ( i ( j x and even to (f . g . h . i . j) x The latter is actually what I use in this case. Myself, I tend to use: f . g . h . i . j $ x So at least at first wink, I think I might concur that precedence is the more crucial... Slán, Alex.
Will the real CGI library please stand up?
Erik Meijer's nifty-looking CGI library, as described in his upcoming JFP paper, looks like just the very thing I'm looking for, but alas, I can't find a complete copy of the code anyplace. In particular, some of combinators in the paper have only type sigs, not complete definitions, and are not in the online version of the library. (Courtesy of Sven Panne, at http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/CGI.htm l) Anyone have a version of the paper and library that match, or say some definitions for post, get, etc? Cheers, Alex.
Error error.
The following is a genuine type error, but the first message appears
to be rather 'parasitic', not to mention not making any actual sense.
It's caused by having a spurious type context around a type with no
type vriables (as per the second error message, which is immaculate...)
Case.hs:378:
The constraint `PO b' does not mention any of
the universally quantified type variables {}
of the type `Metric HolidayR NumInf
- HolidayR - SetOf HolidayR - SetOf HolidayR'
In the type signature for `s_max2'
Case.hs:378:
The constraint `PO b'
mentions type variables that do not appear in the type
`Metric HolidayR NumInf
- HolidayR - SetOf HolidayR - SetOf HolidayR'
In the type signature for `s_max2'
Cheers,
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: Modifying the monomorphism restriction
Joe English:
I was thinking of the example from the Haskell Report:
let { len = genericLength xs } in (len, len)
which, without the MR, computes 'len' twice.
Operationally I expect that in "let x = f y in ... x ... x",
'f y' is only evaluated once, no matter what type it is.
If the types are distinct, then a recomputation _is_ necessary.
The MR does nothing to solve this, it just fails to typecheck the
program fragment.
To be candid, though, I'm not much concerned with what's done with
let-bound definitions; what really vexes me are top level instances.
Also John Hughes' warning that:
* When converting Haskell 1.x to Haskell 2, many := would need to be
inserted.
Failure to do so could make programs much less efficient.
That's why I'd prefer to keep call-by-need the default
and use new syntax for call-by-name/overloading.
This is a case of backwards compatibility with a bad feature, IMO.
In any even, if the old programs passed the 1.x MR, then a Haskell
2 compiler ought to be able to produce recomputation-free code at
least as a special case.
This way bizarre type errors remain the default, and compilers
will signal an error _somewhere else_ in the program when you
bump into the MR, if my experience is anything to go by.
Could you provide an example? Every instance of the MR
I've been able to come up with winds up giving an error message
right at the definition that would need to have a ~ or an
explicit type signature added.
In every example I've come up with (and I come up with them a lot
more often than I'd care to), if you have a MR'd definition that's
applied at two different types, you simply get an error at one
of the two instances, which doesn't mention anything about the
definition, nor about the use of the MR. This is technically
correct, it just doesn't take into account the 'difference of opinion'
that's implicitly occurring between me and the type-checker about
what the type of that function actually _is_...
If that's too vague, I'll mail-bomb you with as many examples as
you wish, of whatever length and fiendishness of debugging you wish. ;-)
Cheers,
Alex.
Re: Modifying the monomorphism restriction
Joe English: (Am I the only one who's never been bitten by the MR restriction?) If one always uses type sigs, or never/rarely uses compositional/ combinator style function definitions, it's much less likely to crop up. How about leaving the 'a = b' binding form as it is, (monomorphism restriction and all) and using 'a = ~ b' to indicate call-by-name. '~' is already a reserved symbol, and it can't currently appear on the RHS of a binding, so this new syntax would't break any existing programs. I like that much less (though I admit I wasn't all that smitten by John exact notation, either). I like it less because it looks (even) worse, IM(humble-or-otherwise)O, and more to the point because I consider it (still) to be the wrong 'default'. The symbol ':=' in John proposal can be explained as 'monotypically bind a CAF', whereas Joe's notation preserves the existing, ugly distinction between simple pattern bindings and function pattern bindings. That is, in other words, that definitions don't eta-convert. This way call-by-need remains the default, and compilers will still signal an error if the programmer accidentally bumps into the MR. This way bizarre type errors remain the default, and compilers will signal an error _somewhere else_ in the program when you bump into the MR, if my experience is anything to go by. For people reading the code, a ~ on the RHS of a binding is a signal that something out-of-the-ordinary is going on operationally, the same as when it appears on the LHS. I dispute that there's anything 'operationally out-of-the-ordinary' about an overloaded function definition, which is almost invariably what the MR is (silently) complaining at me for doing when I fall over it. It's only out-of-the-ordinary if you were depending on it being operationally a CAF, so having some sort of special CAF syntax seems reasonable to me. Certainly I will happily stipulate that ':=' may not be the definitive word on the best such syntax (give us back our 11 days -- err, I mean, our constructor operator symbol namespace!). Slan libh, Alex.
Re: Modifying the monomorphism restriction
Thomas Hallgren: The monomorphism restriction makes sure that certain values are computed at most once by restricting them to be used at only one type. Couldn't the same be achieved by * getting rid the monomorphism restriction, i.e., let all definitions to be overloaded by default, * add the language implementation requirement that overloaded values should be computed at most once for each instance they are used at. I think this is definitely feasible, but I wonder if it's entirely prudent. Could definitely lead to a quantity of code-bloat. One of the annoyances of the MR is that it _disallows_ this as a solution, even if the compiler were in a position to determine that it was pragmatically sensible. I can imagine cases where this remedy is either basically unnecessary (little shared work inside the unapplied CAF), or worse than the disease (blowup in the number of instances), so it seems excessive to require it, either. Slan libh, Alex.
Re: Haskell 2 -- MR, for Curry's sakes go.
John Launchbury: I agree that the MR is a pain. [...] Now we find that some type declarations contain more class info than type!! And some type(+class) declarations are longer than the definition! This sounds a trite point, but it gets very annoying when one is "rapid-prototyping" (aka hacking, aka not wanting to think too hard about what type is really is), and one finds a correct function definition won't compile without a type sig, which itself then becomes wrong later, when one "prototypes" elsewhere -- even if the defintion was till completely correct. I think the MR and the default mechanism are both hacks that were introduced to serve a purpose. Few people love them, but I also suspect that few people think they serve no useful purpose at all. As far as I can see, it's alleged to serve a number of purposes... o Avoiding "call by name" like behaviour on unwittingly overloaded CAFs; o Avoiding some cases where (some extra) ambiguity may arise without the MR; o Getting the best possible types in instances where there's an MR 'monomorphisation', followed by a top-level generalisation step. Sorry if I'm a bit vague on the latter two; it's been a while since I've seen a thoroughgoing Apologia for the MR. At any rate, the first is surely best taken care of as a matter of compiler pragmatics. A compiler can clearly do at least as well by treating it as a 'stiff warning message' type offence, but more importantly, this would allow a compiler to do _better_, where it can detect that there's not really such a problem, or that it can be finessed by multiple specialised instances, or whatever. The second I don't feel too concerned about: adding ambiguity to a language that doesn't suffer from it would make me worry, but this is far from the case, here... The last is the one I'm the least clear on. Is this at least helped by adding scoped type sigs, or something of that sort? Can someone racapitulate on this point, or ideally even give the low-down on the 'state of the art' for alternative solutions to this one? What we need is a general solution to managing classes and ambiguity, and then hopefully we can dispense with the hacks. That would indeed be nice. Slan libh, Alex.
RE: Strange ghc-4.02 TC bug?
Not a typechecker bug; more a bizarre consequence of overlapping instance decls. OK, a typechecker misfeature, then, so I'll cross-reply to ghc-users. ;-) The instance decl instance Holidays a = Eq a overlaps with absolutely every other instance decl for Eq. In order to make Lattice (Inv a) an instance of Eq, we have to satisfy Eq (Inv a), since Eq is a superclass of Lattice. From the data decl, we can get Eq (Inv a) if we can get Eq a. From the instance decl you commented out, we can get Eq a if we can get Holidays a. But then we get stuck. That seems a strange thing to do, really. Isn't the (apparent) lack of an instance of Eq a, rather than it being sensible to insist that the superclasses be back-propgated (if I even remotely understand what's going on here...). Admittedly, we can also get Eq a from Lattice a, but GHC's search doesn't spot that (I'm not quite certain why). Aye, there's the rub. That's why I think it's a bug, or at least, a non-optimal resolution of the overlap. Furthermore, even if this ought to be rejected, then: a) why is it OK if the above instance declaration appears in a different module; b) why is the overlap error in the reported manner, which is _really_ confusing? (I had to pretty much use 'divide and conquer' on the source program to just localise the error, never mind understand it. Slan, Alex.
Strange ghc-4.02 TC bug?
Discern that the following program is apparently well-typed: module M2 where class Eq a = Lattice a where bottom :: a data Inv a = INV a deriving Eq instance Lattice a = Lattice (Inv a) class Holidays a where holCode :: a - Int -- instance Holidays a = Eq a Now, uncomment the last line, and suddenly: ghc-4.02 -c M2.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -optC-fallow-overlapping-instances *** Reader: *** Renamer: *** TypeCheck: M2.hs:9: Warning: No explicit method nor default method for `bottom' in an instance declaration for `Lattice' M2.hs:9: Could not deduce `Holidays a' (arising from an instance declaration at M2.hs:9) from the context: (Lattice a) Probable cause: missing `Holidays a' in instance declaration context When checking the superclasses of an instance declaration What gives? Even more oddly, if this last line is moved to a different module, then the problem vanishes. Slan libh, 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: io monad binding, coding style
Greg O'Keefe: main =readFile "input-file" = \ s - writeFile "output-file" (filter isAscii s) putStr "Filtering succesful\n" [vs.] main =readFile "input-file" = \ s - writeFile "output-file" (filter isAscii s) putStr "Filtering succesful\n" My question is: is there some good reason why it is set out the way it is in the report? The latter layout is certainly what one might expect 'normally', if this were not monadic code. As Martin Norbäck says, it's intended to convey the idea that the value of the lambda-argument 's' "comes from" the expression in the first line, and the monadic-bind operator = then wraps it up so that it's then 'in scope' through the rest of the body of the definition. This way of thinking about it is even more explicit in the corresponding do-notation: main = do s - readFile "input-file" writeFile "output-file" (filter isAscii s) putStr "Filtering succesful\n" (Whether the style influenced the language feature, or the feature the style I'm not certain, but I suspect the former.) Hope that helps somewhat. Cheers, Alex.
Re: Partial Type Declarations
Patrik Jansson: I like ? better than .., but maybe the Haskell "don't care"-symbol _ could be even more suggesting: q :: a - _ - c qa_ = c Syntactically this is closer to what is currently allowed as type variables and it would easily (in the sense that such a production is in the grammar already, while ? is an operator character) extend to "named meta variables" _a, _b and so on. I definitely like this syntax better than the proposed alternatives; I was thinking along similar lines myself earlier today. Therefore it must be good. ;-) Cheers, 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?
Thanks Simon, though I'm still a tad at sea... Of course you can! Take a look at the User Guide, section 2.12: http://www.dcs.gla.ac.uk/fp/software/ghc/4.01/users_guide/users_guide-2.html #ss2.12 (under "RTS options for hackers...") That says it all, I have a nasty feeling... For a kick off, I can find neither RtsFlags.lh or rtsdefs.h files in the 4.01 distribution. Some scouting around reveals a RtsFlags.h: does that fit both bills?
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.
RTS flags, at compile time?
Is there as yet any way to "compile in" particular RTS flags (or particular defaults), when invoking ghc? Most obviously, heap size... Slan, Alex.
RE: GHC 4.01 gmake all problem
Very strange - either/both of you fans of autoheader? Dunno about Jan or Keith, but I certainly amn't! And yet, I get the same error, and what's worse, on my first (attempted) build of the compiler. However, I did re-run configure at one point; is that the root of this particular evil? i.e., did you do autoconf ./configure --yadda or autoheader autoconf ./configure ... Enquiring minds want to know. Never have, and hopefully never will. Much as I'd like to use a --yadda flag or two... Slan, Alex.
i386-unknown-solaris2?
Has anyone out there tried to install ghc (any version whatsoever) on a PC running Solaris 2.n? Results of keen interest. Slan, Alex.
Linker problem with ghc-4.01 (s-s-s binary).
An unsuspecting little program of mine crunches out the binary distrib of 4.01, with "library -lgmp: not found" (full output appended). Any clues as to what's up here? (Apologies if this is blitheringly obvious, or just a shoddy report, about to fall into bed...) Slan, Alex. _ oconnor.ucc.ie:~/filt4: gnumake OPT=-v rm -f galileo ghc-4.01 -o galileo -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -fvia-C -v TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -optl-O The Glorious Glasgow Haskell Compilation System, version 4.01, patchlevel 0 Linker: gcc -v -u PrelMain_mainIO_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_FZh_static_info -u PrelBase_DZh_static_info -u PrelAddr_AZh_static_info -u PrelAddr_WZh_static_info -u PrelAddr_I64Zh_static_info -u PrelAddr_W64Zh_static_info -u PrelForeign_StablePtr_static_info -u PrelBase_IZh_con_info -u PrelBase_CZh_con_info -u PrelBase_FZh_con_info -u PrelBase_DZh_con_info -u PrelAddr_AZh_con_info -u PrelAddr_WZh_con_info -u PrelAddr_I64Zh_con_info -u PrelAddr_W64Zh_con_info -u PrelForeign_StablePtr_con_info -u PrelBase_False_static_closure -u PrelBase_True_static_closure -u PrelPack_unpackCString_closure -O -o galileo TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/specs gcc version 2.7.2.3 /usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o galileo -u PrelMain_mainIO_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_FZh_static_info -u PrelBase_DZh_static_info -u PrelAddr_AZh_static_info -u PrelAddr_WZh_static_info -u PrelAddr_I64Zh_static_info -u PrelAddr_W64Zh_static_info -u PrelForeign_StablePtr_static_info -u PrelBase_IZh_con_info -u PrelBase_CZh_con_info -u PrelBase_FZh_con_info -u PrelBase_DZh_con_info -u PrelAddr_AZh_con_info -u PrelAddr_WZh_con_info -u PrelAddr_I64Zh_con_info -u PrelAddr_W64Zh_con_info -u PrelForeign_StablePtr_con_info -u PrelBase_False_static_closure -u PrelBase_True_static_closure -u PrelPack_unpackCString_closure /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crt1.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtbegin.o -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtn.o ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) ld: fatal: library -lgmp: not found ld: fatal: File processing errors. No output written to galileo real3.6 user2.9 sys 0.2 deleting... galileo rm -f /tmp/ghc12060* gnumake: *** [galileo] Error 1 oconnor.ucc.ie:~/filt4:
RE: What's happening here?
Picking up the wrong "ghc", perhaps? Hard to tell - what does 'ghc --version' report? 4.01 (which wasn't what I had intended, btw, and Simon has already avised is a Bad Idea -- more inter-machine configuration confusion on my part, sorry). What puzzled me was that it was just invoking "ghc", whereas for some reason I was expecting config to have selected ghc-some version. I may be misrembering what happened with previous versions, though (or else I configured differently). Anyhoo, reconfig with --with-ghc-hc=ghc-3.02, all seems well. Actually getting someplace now, it looks like! (Thanks for the help, especially to Simes, at the risk of tempting fate...) Slan, Alex.
ghc-4.00, s-s-s binary.
Note the Strange behaviour below... Module in question compiles without -O, but not with... Slainte, Alex. _ oconnor.ucc.ie:~/filt4: make OPT=-O ghc-4.00 -c GalileoModules.lhs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -fvia-C -O *** Reader: *** Renamer: GalileoModules.lhs:1: Warning: Failed to find (optional) interface decl for `PrelException!catchIO' desired at PrelIOBase.hi:99 GalileoModules.lhs:1: Could not find valid interface file `PrelException' Compilation had errors *** Error code 1 make: Fatal error: Command failed for target `GalileoModules.o' oconnor.ucc.ie:~/filt4: make ghc-4.00 -c GalileoModules.lhs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -fvia-C *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: *** Desugar *** Core2Core: *** Simplify *** Tidy Core *** Core2Stg: *** Stg2Stg: *** CodeGen: *** CodeOutput: ghc-4.00: module version changed to 2; reason: usages changed
Non-variable instance contexts.
I hate this error. Whilst arguably this is an "untested" extension to Standard Haskell, it seemed pretty sound in practice. Can't we at least have it back as a GlaExt? (MSExt?) I'm starting to feel more than a little Quaint having to use ghc-3.01, just to get my programs to compile... (If anyone has a good systematic workaround to suggest, I'm all ears.) ghc-4.00 -c Intervals.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -fvia-C Intervals.hs:460: Illegal constaint `Ord (s e)' in instance context (Instance contexts must constrain only type variables) [etc, etc] Slainte, Alex.
Re: reply to `I hate this error'
Sergey writes: Is not this due to omitting -optC-fallow-undecidable-instances -optC-fallow-overlapping-instances ? Sorry, if i am missing the point. No, I was! ;-) And thanks to Simon(s) for pointing this out, too. Mind you, I somewhat object to the "undecidable" bit: I thought the current thinking was that "simple" non-variable contexts were a sound, decidable extension? [ The proof's in the post. ;-) ] Slan, Alex.
4.00, s-s-s bug.
Here's a very cut down version of the bug-exhibiting program mentioned earlier. Sorry, if I cut it down any more, it compiles! Slan, Alex. _ swift.ucc.ie:~/filt4: ghc M.lhs MachRegs.lhs:563: Non-exhaustive patterns in function baseRegOffset swift.ucc.ie:~/filt4: cat M.lhs module M where data T = C Int f a b c d e f g h = s a b s x (C _ ) = ()
RE: 4.00, s-s-s, linker errors.
Or you may have picked up a dodgy binary dist.
That was the one... One last (?) problem... This program:
module Main where
import IOExts
main = trace "Boogger" print 1
ain't playin', as follows (maxi-spam version).
Slainte,
Alex.
_
oconnor.ucc.ie:~/filt4: ghc -v -syslib misc Trc.hs
The Glorious Glasgow Haskell Compilation System, version 4.00, patchlevel 0
Effective command line: -v -syslib misc
Ineffective C pre-processor:
echo '{-# LINE 1 "Trc.hs" -}' /tmp/ghc25004.cpp cat Trc.hs
/tmp/ghc25004.cpp
real0.0
user0.0
sys 0.0
ghc:compile:Interface file Trc.hi doesn't exist
Haskell compiler:
/usr/local/ghc-4.00/lib/ghc-4.00/hsc ,-W ,/tmp/ghc25004.cpp
-fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [
-ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -fdo-case-elim
-freuse-con -fpedantic-bottoms -fclone-binds -fmax-simplifier-iterations4 ]
-fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-duplicate-exports
-fhi-version=400
-himap=.%.hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/exts%.hi:/usr/local/ghc-4.
00/lib/ghc-4.00/imports/misc%.hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/exts%.
hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/misc%.hi:/usr/local/ghc-4.00/lib/ghc
-4.00/imports/std%.hi -v -hifile=/tmp/ghc25004.hi -S=/tmp/ghc25004.s -F= -FH=
+RTS -H600 -K100
Glasgow Haskell Compiler, version 4.00, for Haskell 1.4
real1.8
user1.6
sys 0.0
Pin on Haskell consistency info:
echo '
.text
hsc.Trc.hs.40.0..:' /tmp/ghc25004.s
real0.0
user0.0
sys 0.0
*** New hi file follows...
_interface_ Main 400
_instance_modules_
IO PrelAddr PrelArr PrelBounded PrelCCall PrelForeign PrelIOBase PrelNum
PrelNumExtra PrelTup
_usages_
IO 1 :: print 1;
IOExts 1 :: trace 1;
PrelBase 1 :: $dEq0 1 $dEq1 1 $dEqBool0 1 $dEqChar0 1 $dEqInt0 1 $dEqInteger0 1
$dNumInt0 1 $dShow0 1 $dShow1 1 $dShow2 1 $dShowBool0 1 $dShowChar0 1 $dShowInt0
1 $m- 1 $m/= 1 $mfromInt 1 $mshowList 1 addr2Integer 1 foldr 1 int2Integer 1
integer_0 1 integer_1 1 integer_2 1 integer_m1 1 Eq 1 Num 1 Show 1 String 1;
PrelIOBase 1 :: IO 1;
PrelNum 1 :: $dNumInteger0 1 $dShowInteger0 1;
PrelNumExtra 1 :: $dEqDouble0 1 $dNumDouble0 1 $dShowDouble0 1;
PrelPack 1 :: packCString# 1 unpackAppendCString# 1 unpackCString# 1
unpackFoldrCString# 1 unpackNBytes# 1;
_exports_
Main main;
_declarations_
main _:_ PrelIOBase.IO PrelBase.() ;;
ghc: module version unchanged at 2
Replace .hi file, if changed:
cmp -s Main.hi /tmp/ghc25004.hi-new || ( rm -f Main.hi cp
/tmp/ghc25004.hi-new Main.hi )
real0.0
user0.0
sys 0.0
Unix assembler:
gcc -o Trc.o -c -I. -I/usr/local/ghc-4.00/lib/ghc-4.00/includes
-I/usr/local/ghc-4.00/lib/ghc-4.00/includes /tmp/ghc25004.s
real0.1
user0.0
sys 0.0
Linker:
gcc -v -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u
PrelBase_False_static_closure -u PrelBase_True_static_closure -u
PrelMain_mainIO_closure Trc.o -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00 -lHSmisc
-lHSmisc_cbits -lnsl -lsocket -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket
-lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/specs
gcc version 2.7.2.3
/usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -u PrelBase_IZh_static_info
-u PrelBase_CZh_static_info -u PrelBase_False_static_closure -u
PrelBase_True_static_closure -u PrelMain_mainIO_closure
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crt1.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtbegin.o
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/usr/local/lib Trc.o -lHSmisc -lHSmisc_cbits -lnsl -lsocket
-lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts
-lgmp -lm -lgcc -lc -lgcc
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtend.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning)
Undefined first referenced
symbol in file
IOExts_trace_closureTrc.o
ld: fatal: Symbol referencing errors. No output written to a.out
real0.6
user0.4
sys 0.1
deleting... a.out
rm -f /tmp/ghc25004*
ghc-4.00
Still can't build 4.00 from source (see bug report, elselist), and it's also not yet on the ftp site in binary form. *whinge!* Slainte, Alex.
Re: ghc-4.00 build problems.
I whinged about: [stuff] Other people seem to have got further than I did in sun-sparc builds -- is there a workaround that I could be using, pending an actual fix? [ Or enough ftp space for the binary version. ;-) ] Slan, Alex.
