May 2004 - Glasgow-haskell-users

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

>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, Keean.

2 1

Namespace trouble
by Jorge Adriano Aires 20 May '04

20 May '04

Hello, I have the following structure: > MyProgram/A.hs > MyProgram/Aux/B.hs > MyProgram/Aux/C.hs and: > A imports C > B imports C Can I make this work using namespaces only (i.e. no -i flag)? I expected this to work: > MyProgram/A.hs name: A import Aux.C > MyProgram/Aux/B.hs name: Aux.B import C > MyProgram/Aux/C.hs name: Aux.C But complains when importing C from B since its name is Aux.C. What is the most elegant way to deal with such cases? J.A.

3 5

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

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) 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. Keean.

2 1

RE: Overlapping, undecidable, incoherent -- or worse?
by Simon Peyton-Jones 20 May '04

20 May '04

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. 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. 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 Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Alex Ferguson | Sent: 20 May 2004 00:53 | To: glasgow-haskell-users(a)haskell.org | Subject: 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 | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

1 0

RE: Prelude/main magicks?
by Simon Marlow 20 May '04

20 May '04

> I could even volunteer to try to add these features to GHC, if the > team would accept the help. There are still the issues of > update-compatibility for the team to deal with, but I stubbornly > believe that they won't be that bad. ;) Of course, if you send us a patch the chances are we'll incorporate it. Adding a -fprelude-is= flag should be less than 50 lines, and don't forget to document it. It shouldn't be too hard to figure out what to do. Just look for where the -fno-implicit-prelude flag turns up for clues, and we'll be happy to answer any questions. Cheers, Simon

1 0

Overlapping, undecidable, incoherent -- or worse?
by Alex Ferguson 19 May '04

19 May '04

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.

1 0

Re: Prelude/main magicks?
by Niklas Broberg 19 May '04

19 May '04

I wrote: > > Taking Lava, a hardware description language, as my example, I would >argue > > that many users of Lava don't really care if it's embedded in Haskell or > > whereever it comes from, they would just use it. .... > > > > lavac Main.hs > > > > where lavac is could simply be a script alias of > > ghc -fprelude-is Lava > > > > By using an explicit Lava compiler you declare that this is indeed a >Lava > > program, and you don't expect it to work in any other setting, in >particular > > not with a Haskell compiler like GHC. > > > > And in the same line of thinking, I would want a way of specifying >suffixes > > of input source files. It would be much neater to call your files >Foo.lava > > or similar, and be able to tell GHC to treat them as normal .hs files, >i.e. > > > > lavac <== ghc -hssuf lava -fprelude-is Lava > Malcolm Wallace wrote: >Very intriguing ideas. However, I'm sure there are easier ways >of implementing a 'lavac' (or other domain-specific compiler) than >adding new flags to ghc (and by implication, to every other Haskell >compiler as well). > >All you really need is to hook up a rather simple pre-processor. >For instance, > > #!/bin/sh > { echo 'module Main where\nimport Lava\n' ; cat $1 } >`basename $1 >.lava`.hs > >If you want an automatic file association based on suffix, then >something like hmake can do the mapping of .lava onto .hs via this >little pre-processor script. This solution has the additional benefit >that it is compiler-agnostic. Aye, it would be simpler, I sure won't argue that. But then I might have to create another pre-processor to make it work on Windows, and a third for some other system. And then for the next EDSL that comes up, the designer of that will have to do the same thing. Is the sum of all that work still simpler? Clearly it would be better for the EDSL designer to know that someone else has thought of these things once and for all. I'd like to see my approach as the high-level one where the designer just has to think about _what_ he wants, whereas your suggestion would be the low-level approach where the designer must also know _how_ to get what he wants. >From my perspective what it comes down to is, is this a recurring pattern? If a new EDSL comes around once in a blue moon, then one might argue that the work needed to add these flags to GHC would be ill-spent. But if EDSLs are a more common development pattern, then surely it must be the supreme goal of any compiler writer to make life easier on the users? =) And if we think one step ahead, then it isn't all that difficult to imagine that such a feature might even encourage the design of more EDSLs, which in my book would be a Really Good Thing (tm). As for being compiler agnostic, then sure, that would be a good thing for any library. But there are already tons of nice extensions added to GHC that aren't implemented by other compilers, making any code that makes use of these extensions compiler-specific. Why would this be different? And as for those users of Lava I mentioned in my example, I doubt that they would even know of or care about the existence of other compilers and/or interpreters than the one(s) the language designer provides them with. After all, from their perspective those other tools are for Haskell, not Lava! That said, I sure wouldn't mind seeing these features added to other compilers as well. =) I could even volunteer to try to add these features to GHC, if the team would accept the help. There are still the issues of update-compatibility for the team to deal with, but I stubbornly believe that they won't be that bad. ;) I'm starting to get a bit worried though, am I completely alone in this? I would have thought at least someone would agree with me and support me in wanting such features, so please, anyone? =) /Niklas _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/

1 0

reaching Happy parser
by Serge D. Mechveliani 17 May '04

17 May '04

Please, who knows how to download and install in the easiest way the Happy parser (today, within 3-4 hours) ? The situation is as follows * RedHat linux (version about 8), libc-2.2, i386-unknown, * (configure: error: Happy version 1.13 or later is required to compile GHC ) * www.haskell.org is through the Yale machine and is not reachible today from our www.botik.ru Maybe, you now some mirrors ... ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

ghci and ld scripts
by Duncan Coutts 16 May '04

16 May '04

So here's the problem: We have a Haskell binding to a C library (one of the gtk extension libs) which uses the pthread library. So we put "pthread" in the extra_libraries section of our ghc package conf file. This works fine when building standalone programs, however when we try and use this package in ghci we get this error: ... Loading package gtk2 ... linking ... done. Loading package sourceview ... ghc-6.2.1: can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: invalid ELF header) Inspecting /usr/lib/libpthread.so we find that indeed it is not a .so file but a gnu ld script: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) So we should get ghci to dynamically load /lib/libpthread.so.0, however there is no way to specify this in the package.conf file. It turns out that we don't need ghci to load this .so because it is a dep of another .so that we do load, however if I leave it out then building standalone progs would fail to link. Has anyone come across this before? How do you deal with it? Duncan

1 0