headers
Amanda Clare | 6 May 2003 19:52
Picon

getContents/hGetContents bug?

Hello nhc-team,

The following doesn't work under nhc98 1.14 (made with hmake 3.05)

[afc <at> pcburum mipsmanual]$ nhc98 --version
/usr/local/funcprog/bin/nhc98: v1.14 (2002-06-13)
   [ config: ix86-Linux/ghc by malcolm <at> pc173 on 13 Jun 2002 ]

The program does nothing, and returns immediately without waiting for 
input. Just using getContents does the same.

--------------------------

module Main where
import IO

parse accum []       = [accum]
parse accum ('*':cs) = accum:parse [] cs     -- finished this expression
parse accum ('%':cs) = [accum]               -- end input here
parse accum (c:cs)   = parse (c:accum) cs

main = do text <- hGetContents stdin
           putStr (unlines (parse [] text))

--------------------------

Amanda
Permalink | Reply | 1 comment |
headers
malcolm | 6 May 2003 23:10
Picon

Re: getContents/hGetContents bug?

> The following doesn't work under nhc98 1.14

I just tried it with nhc98-1.14, and I couldn't reproduce the
problem.  Same on a freshly built 1.16.  I see your version of
nhc98 was from a binary distribution, so maybe it is some kind
of Linux-related C-library incompatibility?  My best suggestion
is to build nhc98 from source on the machine in question.

> main = do text <- hGetContents stdin
>            putStr (unlines (parse [] text))

Assuming that the extra space before putStr is a typo...

Regards,
    Malcolm
Permalink | Reply | 0 comments |
headers
love | 11 May 2003 06:04

http://bigwuhan.com

Éí´¦¡°·Çµä¡±Ê±ÆÚ£¬Ñ¡ÔñÉÏÍøÕÒ°®Ç飺http://bigwuhan.com µ¥ÉíÅóÓѵÄÁµ°®¼ÒÔ°¡­¡­
Permalink | Reply | 0 comments |
headers
v163@163.com | 12 May 2003 01:42
Favicon

nhc-bugs

你要的网页给你找到了
http://www.creatonly.com/sohusms.htm
Permalink | Reply | 0 comments |
headers
Ross Paterson | 21 May 2003 16:48
Picon
Favicon

newForeignPtr

How about renaming newUnsafeForeignPtr as newForeignPtr to conform to
the FFI spec?  GHC 6.0 calls the one that takes a Haskell finalizer
newConcForeignPtr.  (Similarly addForeignPtrFinalizer, though it doesn't
work in NHC as yet.)
Permalink | Reply | 0 comments |
headers
Thomas Hallgren | 21 May 2003 23:58
Picon

"hmake +RTS" loops

Hi,

Today I accedentally typed

    hmake +RTS -K5M Big.hs

instead of

    hmake -K5M Big.hs

To my surprise, the mistake caused hmake to loop!

I was using the binary nhc98-1.16 package for ix86-Linux [1].

--

-- 
Thomas H

[1] ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98-1.16-ix86-Linux.tar.gz
Permalink | Reply | 1 comment |
headers
Thomas Hallgren | 22 May 2003 00:08
Picon

nhc98 rejects legal rebinding

Hi,

When I compile the following module,

    module Rebind where

    f x = x
      where
        x = True

nhc98-1.16 [1] produces the error message

    ======  Errors when renaming:
    Redefinition of Identifier x at 5:5

While this is not completely unreasonable, it seems to be a deviation 
from the Haskell 98 report and the behaviour of other Haskell 
implementations.

(If I understand the Haskell 98 report correctly, function bindings 
translate to simpler bindings with case expressions in the rhs, and case 
branches with "where" clauses translate to simpler branches with "let" 
bindings in the rhs. Thus, variables introduced in "where" clauses 
should shadow variables in patterns, not clash with them.)

--

-- 
Thomas H

[1] ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98-1.16-ix86-Linux.tar.gz
(Continue reading)

Permalink | Reply | 1 comment |
headers
Malcolm Wallace | 27 May 2003 10:55
Picon

Re: "hmake +RTS" loops

Thomas Hallgren <hallgren <at> cse.ogi.edu> writes:

> Today I accedentally typed
>     hmake +RTS -K5M Big.hs
> instead of
>     hmake -K5M Big.hs
> To my surprise, the mistake caused hmake to loop!

Here's a patch.
Regards,
    Malcolm

diff -u -r1.31 script/hmake.inst
--- script/hmake.inst	6 Mar 2003 10:32:51 -0000	1.31
+++ script/hmake.inst	27 May 2003 08:54:10 -0000
 <at>  <at>  -109,7 +109,7  <at>  <at> 

     # Run-time flags to hmake itself
     +RTS) shift
-          while [ "$1" != "-RTS" ]
+          while [ -n "$1" -a "$1" != "-RTS" ]
           do hmrtflags=$hmrtflags" $1"
              shift
           done ;;
Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 27 May 2003 11:15
Picon

Re: nhc98 rejects legal rebinding

Thomas Hallgren <hallgren <at> cse.ogi.edu> writes:

>     module Rebind where
>     f x = x
>       where
>         x = True
> 
> nhc98-1.16 [1] produces the error message
> 
>     ======  Errors when renaming:
>     Redefinition of Identifier x at 5:5
> 
> While this is not completely unreasonable, it seems to be a deviation 
> from the Haskell 98 report and the behaviour of other Haskell 
> implementations.

It is quite difficult to be sure exactly what the Haskell Report
says on this matter, but I think you are probably right.  There is
no explicit section giving the semantics of `where' clauses at all!
As you say though, there is one rule in the formal semantics for
pattern matching that translates a `where' clause to a `let' binding.

However, I do not propose to fix this bug in nhc98.  The example
you give is extremely likely to be a programmer's mistake, so in
my opinion the error message from the compiler is more useful than
the strange runtime behaviour that might otherwise occur.  When the
rebinding is deliberate, it is easy for the author to find a different
way of coding the intended semantics.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 27 May 2003 12:18
Picon
Favicon

RE: nhc98 rejects legal rebinding


Malcolm writes: 
> However, I do not propose to fix this bug in nhc98.  The example
> you give is extremely likely to be a programmer's mistake, so in
> my opinion the error message from the compiler is more useful than
> the strange runtime behaviour that might otherwise occur.  When the
> rebinding is deliberate, it is easy for the author to find a different
> way of coding the intended semantics.

While the behaviour might arguably be wrong, I believe it's more
important to stick to the letter of the Haskell 98 spec, at least so
that Haskell 98 compilers are compatible with each other.  By all means
emit a warning in this case (GHC does if you add -fwarn-name-shadowing),
but it shouldn't be an error.  

Besides, it's inconsistent: I'm allowed to shadow 'f', but not 'x'.
This is allowed:

>     module Rebind where
>     f x = x
>       where
>         f = True

Cheers,
	Simon
Permalink | Reply | 501 comments |

Gmane