headers
Simon Peyton-Jones | 1 Oct 2002 09:48
Picon
Favicon
Gravatar

RE: External Core typechecker

| There is a typechecker for Ext Core already, in
| fptools/ghc/utils/ext-core. It would probably take some work to adapt
it
| to be used with GHC, and to change it so it doesn't have the module
names and
| primitives from GHC 4.08 wired into it, but would adapting it be the
right
| thing to do? If so, I might have time to do it sometime.

That's true.  Its architecture is rather different to the rest of GHC's
type checker, and I'd been thinking that the obvious thing to do would
be to use the same monad and style as the main type checker.  For
example, the utils/ext-core one reports only one error, and doesn't
track line numbers.  Still, it has the merit of existing!  Presumably
you can always use it stand-alone to check your core progs?

I'm not sure what the best approach is.   

Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Oct 2002 11:36
Picon
Favicon

RE: bug/feature/? of ghci with concurrency


> Maybe this is by design, but in case it isn't: I was a little
> suprprised when I came across this behavior of ghci:
> 
>    ghci
>    ...  GHC Interactive, version 5.04.1, for Haskell 98. ...
> 
>    Prelude> :m Concurrent
>    Prelude Concurrent> let loop c = putChar c >> loop c
>                        in forkIO (loop 'a') >> (loop 'z')
>    
> zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza
> zazazazazazaza
>    
> zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza
> zazazazazazaza
>    
> zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza
> zazazazazazaza
>    Interrupted.
>    aPrelude Concurrent> sum [1..100]
>    aaaaaaaaaaaaa5050
>    aPrelude Concurrent>  1+2
>    aaaaaaaa3

This is really a design choice: there is no inter-thread structure other
than what you program yourself, there are no "process groups", and
pressing ^C sends an exception to the main thread only.  We don't
currently have a way for a Haskell program to get access to *all* the
current threads running, so there's no easy way for GHCi to stop
(Continue reading)

Permalink | Reply | 0 comments |
headers
noreply | 1 Oct 2002 17:47
Picon
Favicon

[ ghc-Bugs-617082 ] ghc -O generates faulty c code

Bugs item #617082, was opened at 2002-10-01 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=617082&group_id=8032

Category: Compiler
Group: 5.04
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc -O generates faulty c code

Initial Comment:
I have the following file:

Bug.hs
--------------------------
module Bug where

foo :: Double -> Double
foo x = x - (-1.0) 
--------------------------

> ghc -c -O Bug.hs
/tmp/ghc25320.hc: In function `s3Ny_ret':
/tmp/ghc25320.hc:14: invalid lvalue in decrement
/tmp/ghc25320.hc:14: parse error before `1.0'

Cause
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kirsten Chevalier | 1 Oct 2002 19:33
Picon
Picon

Re: External Core typechecker

On Tue, Oct 01, 2002 at 08:48:00AM +0100, Simon Peyton-Jones wrote:
> 
> That's true.  Its architecture is rather different to the rest of GHC's
> type checker, and I'd been thinking that the obvious thing to do would
> be to use the same monad and style as the main type checker.  For
> example, the utils/ext-core one reports only one error, and doesn't
> track line numbers.  Still, it has the merit of existing!  Presumably
> you can always use it stand-alone to check your core progs?
>

Not right now, though, because it doesn't handle code produced by GHC 5,
since some of the primitive module names are different. (That would probably
be easy to change, I just haven't done it.)

> I'm not sure what the best approach is.   

Perhaps writing a new typechecker in the style of the GHC typechecker,
but using the Core typechecker as a guide to what the type rules actually
are, would be best. I'll think about it more after I get back from ICFP.

--

-- 
Kirsten Chevalier * krc <at> uclink.berkeley.edu * Often in error, never in doubt
Permalink | Reply | 0 comments |
headers
noreply | 3 Oct 2002 14:06
Picon
Favicon

[ ghc-Bugs-209351 ] deriving show with unboxed types gives nonsense

Bugs item #209351, was opened at 2000-07-12 13:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=209351&group_id=8032

Category: Compiler (Type checker)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Seward (sewardj)
>Assigned to: Simon Marlow (simonmar)
Summary: deriving show with unboxed types gives nonsense

Initial Comment:
deriving show with unboxed types gives nonsense --
specifically, a wierd kind error, which doesn't make it
clear what the problem is

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=209351&group_id=8032
Permalink | Reply | 0 comments |
headers
noreply | 3 Oct 2002 14:23
Picon
Favicon

[ ghc-Bugs-617082 ] ghc -O generates faulty c code

Bugs item #617082, was opened at 2002-10-01 17:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=617082&group_id=8032

Category: Compiler
Group: 5.04
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc -O generates faulty c code

Initial Comment:
I have the following file:

Bug.hs
--------------------------
module Bug where

foo :: Double -> Double
foo x = x - (-1.0) 
--------------------------

> ghc -c -O Bug.hs
/tmp/ghc25320.hc: In function `s3Ny_ret':
/tmp/ghc25320.hc:14: invalid lvalue in decrement
/tmp/ghc25320.hc:14: parse error before `1.0'

Cause
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Fondren | 4 Oct 2002 13:22
Picon
Favicon

[GHCi 5.04.1] the `impossible' happened


  [Indented text is me; unindented text is GHCi]

  Initial experience with the bug:

*Autoexi> let x e = do putStrLn "hmm..."; return 'c'
*Autoexi> y <- catch (getChar) (x)

  here, I hit ^C several times, hoping to catch that as an exception.
  This didn't seem to happen, and GHCi appeared to still be waiting
  for a key, so I pressed 'h'

hInterrupted.
*Autoexi> y
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1):
        rdrNameModule y

Please report it as a compiler bug to glasgow-haskell-bugs <at> haskell.org,
or http://sourceforge.net/projects/ghc/.

  With a fresh GHCi:

Prelude> let x e = return 'c'
Prelude> y <- catch (getChar) (x)

  GHCi responded immediately to my first ^C, here.

Interrupted.
Prelude> y
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alastair Reid | 8 Oct 2002 13:43
Picon

implicit parameter bindings in do notation


Using   

  do
    let ?x=... 
    ...

doesn't seem to be allowed in GHC.

I've previously reported that implicit parameter bindings aren't
allowed in 'where' bindings either.

Is there any good reason for these inconsistencies?  Wouldn't it be
easier if let bindings, do-let bindings, where bindings, list
comprehension let-bindings, etc. all allowed the same syntax?

--
Alastair Reid                 alastair <at> reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/
Permalink | Reply | 0 comments |
headers
noreply | 8 Oct 2002 16:46
Picon
Favicon

[ ghc-Bugs-620264 ] rdrNameModule it

Bugs item #620264, was opened at 2002-10-08 07:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=620264&group_id=8032

Category: Compiler
Group: 5.04.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: rdrNameModule it

Initial Comment:
I´m new in this, and probably this is known... or maybe 
irrelevant:
What I´ve done: (in Prelude)

let x = error "help!"
print x
id x
print it

I did not understand why x isn´t printed (id x works...), 
but the serious ghc.exe panic! message after trying 
to 'print it' told me to report this ^_^
I just went through the manual and tried some lines out 
of it...

system: Win XP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Thaller | 9 Oct 2002 00:42
Picon

Object Splitting and the Base Package Makefile

When building the library archive libHSbase.a, the makefile system 
includes not only all the split object files, but also the file 
PrimopWrappers.o. Consequently [at least on Mac OS X], ranlib generates 
a warning about duplicate symbols and fails to generate a sorted symbol 
table for the library (it generates an unsorted symbol table instead, 
which leads to slower linking).
Happens with the current HEAD.

Cheers,

Wolfgang
Permalink | Reply | 1 comment |

Gmane