headers
Neil Mitchell | 1 Dec 2005 21:56
Picon
Gravatar

-fwarn-incomplete-patterns, not always warns

Hi,

I have been playing around with -fwarn-incomplete-patterns under GHC
6.4.1 on Windows.

-- no warning
ex1 x = ss
    where (s:ss) = x

-- no warning
ex2 x = let (s:ss) = x in ss

--    Warning: Pattern match(es) are non-exhaustive
--             In a case alternative: Patterns not matched: []
ex3 x = case x of ~(s:ss) -> ss

I have translated all 3 functions using the rules supplied in the
Haskell 98 report, so they all have the same meaning, but only one
gives an error. Is it intentional to ignore where/let pattern matches?

Thanks

Neil
Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 2 Dec 2005 10:12
Picon
Favicon
Gravatar

RE: -fwarn-incomplete-patterns, not always warns

It's a GHC weakness.  I've added your example to the currently-open bug
for it:

http://sourceforge.net/tracker/index.php?func=detail&aid=1075259&group_i
d=8032&atid=108032

Simon
| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org
[mailto:glasgow-haskell-users-
| bounces <at> haskell.org] On Behalf Of Neil Mitchell
| Sent: 01 December 2005 20:56
| To: glasgow-haskell-users <at> haskell.org
| Subject: -fwarn-incomplete-patterns, not always warns
| 
| Hi,
| 
| I have been playing around with -fwarn-incomplete-patterns under GHC
| 6.4.1 on Windows.
| 
| -- no warning
| ex1 x = ss
|     where (s:ss) = x
| 
| -- no warning
| ex2 x = let (s:ss) = x in ss
| 
| --    Warning: Pattern match(es) are non-exhaustive
| --             In a case alternative: Patterns not matched: []
| ex3 x = case x of ~(s:ss) -> ss
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keean Schupke | 3 Dec 2005 13:20
Picon

GHCI and archive libraries.


GHCI does not load archive libraries. Is it possible (easy?) to get it 
to load (.a) archive libraries as well as .o and .so files? The problem 
is some optimized "cblas" libraries are not available as shared 
libraries due to the performace loss.

    Regards,
    Keean.
Permalink | Reply | 6 comments |
headers
Lennart Augustsson | 3 Dec 2005 14:48
Favicon
Gravatar

Re: GHCI and archive libraries.

Can't you unpack the ar library and then link the object files
into a shared library?

	-- Lennart

Keean Schupke wrote:
> 
> GHCI does not load archive libraries. Is it possible (easy?) to get it 
> to load (.a) archive libraries as well as .o and .so files? The problem 
> is some optimized "cblas" libraries are not available as shared 
> libraries due to the performace loss.
> 
>    Regards,
>    Keean.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
Permalink | Reply | 5 comments |
headers
Sven Panne | 3 Dec 2005 15:10
Picon

Re: GHCI and archive libraries.

Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson:
> Can't you unpack the ar library and then link the object files
> into a shared library?

On most platforms the code in a *.a library is not shared library code, e.g. 
it is not PIC or something like that. Nevertheless, I think that the *.o 
files GHCi loads are not exactly shared libraries, they are incrementally 
linked relocatable object code (correct me if I'm wrong here, the details of 
shared libraries are still a kind of black art...). So you might have luck 
with unpacking and re-linking like that:

   ar x libblah.a
   ld -r -x -o /my/new/blah.o *.o

The linker flags for doing this vary, depending on the platform, you can have 
a look at GHC's autoconf magic for hints if it doesn't work like mentioned 
above.

Cheers,
   S.
Permalink | Reply | 4 comments |
headers
Lennart Augustsson | 3 Dec 2005 15:17
Favicon
Gravatar

Re: GHCI and archive libraries.

And on many platforms (well, at least a few years ago) a "shared"
library doesn't have to be PIC.  The dynamic loader can do relocation
when it loads the file.  (Then it can't be shared.)

But this was a few years ago on Solaris and BSDs, it could be
different now.

	-- Lennart

Sven Panne wrote:
> Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson:
> 
>>Can't you unpack the ar library and then link the object files
>>into a shared library?
> 
> 
> On most platforms the code in a *.a library is not shared library code, e.g. 
> it is not PIC or something like that. Nevertheless, I think that the *.o 
> files GHCi loads are not exactly shared libraries, they are incrementally 
> linked relocatable object code (correct me if I'm wrong here, the details of 
> shared libraries are still a kind of black art...). So you might have luck 
> with unpacking and re-linking like that:
> 
>    ar x libblah.a
>    ld -r -x -o /my/new/blah.o *.o
> 
> The linker flags for doing this vary, depending on the platform, you can have 
> a look at GHC's autoconf magic for hints if it doesn't work like mentioned 
> above.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sven Panne | 3 Dec 2005 15:29
Picon

Re: GHCI and archive libraries.

Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson:
> And on many platforms (well, at least a few years ago) a "shared"
> library doesn't have to be PIC.  The dynamic loader can do relocation
> when it loads the file.  (Then it can't be shared.)
>
> But this was a few years ago on Solaris and BSDs, it could be
> different now.

After a quick look this seems to be the case on current x86 Linux systems, 
too: "Real" shared libraries consist of PIC to enhance sharing code at 
runtime, but nevertheless the dynamic loader seems to be able to load and 
relocate non-PIC, at the cost of less sharing, but often slightly better code 
quality. So the mentioned repacking of a static library into a partially 
linked object file might work for most common platforms.

Cheers,
   S.
Permalink | Reply | 2 comments |
headers
Frederik Eaton | 4 Dec 2005 01:45

recommended build system

Hi all,

I'm looking for a build system for my projects which will correctly
handle all of ghc's dependencies. I.e. every time I ask it to rebuild
an output file, it will only do the minimum amount of compilation
necessary. This is important to me because "ghc --make" and cabal
currently (AFAICT) will always relink an executable even when it is
not necessary to do so; thus if I have a project with a bunch of
libraries and executables, the cost of making a small modification and
recompiling is very high, and it becomes hard to maintain focus on my
projects after the initial design phase. I've just been playing around
with GNU coreutils and was impressed with how well the build system
works, and how fast the recompilation goes.

Anyway, the system that darcs uses seems to work pretty well, should I
copy that, or do people recommend other alternatives?

Frederik
Permalink | Reply | 1 comment |
headers
John Meacham | 4 Dec 2005 01:50
Favicon

ghc --make and make

I was thinking it would be nice if ghc --make could touch the output
file with the timestamp of the most recently modified source file.

As it is, if you edit a file in between when ghc --make starts and it
finishes (a substantial amount of time in some cases) then 'make' will
not realize the dependencies have changed.

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply | 0 comments |
headers
John Meacham | 4 Dec 2005 02:53
Favicon

exhaustive pattern warning bug with irrefutable patterns


the following gives a 'non-exhaustive pattern matching' error when it
shouldn't. the ~-pattern always matches. It is not the function that is
non-exhausitive, but the irrefutable binding, which are necessarily
always non-exhausive so warning about it is the wrong thing to do.

f :: [a] -> a
f [x] = x
f ~(_:xs) = f xs   

John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply | 0 comments |

Gmane