headers
Lennart Augustsson | 1 Oct 2011 07:46
Favicon
Gravatar

Re: Two Proposals

What are the defaulting rules for IsList?  It needs to be backwards compatible.

   -- Lennart (iPhone)

On Sep 30, 2011, at 19:28, George Giorgidze <giorgidze <at> gmail.com> wrote:

> GHC Users,
> 
> I would like to make to the following two proposals:
>  * Eliminate the default grouping close from SQL-like comprehensions
>  * Introduce a GHC extension for list literal overloading
> 
> OK, let me start with the first proposal.
> 
> Currently, the SQL-like comprehension notation (both in its list comprehension and monad
comprehension variants) features the following five clauses:
> 
> then f
> then f by e
> then group by e
> then group using f
> then group by e using f
> 
> The first two clauses are used for specifying transformations of type [a] -> [a] (or Monad m => m a-> m a for
monad comprehensions). The following three clauses are used for specifying transformations of type [a]
-> [[a]] (or Monad m, Functor f => m a -> m (f a) for monad comprehensions). See [1] for further details.
> 
> Note that the third clause does not mention which function is used for grouping. In this case
GHC.Exts.groupWith function is used as a default for list comprehensions and the mgroupWith function
from the MonadGroup class is used as a default for monad comprehensions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Volker Wysk | 1 Oct 2011 08:30
Picon

Getting the file descriptor from a handle, without closing it

Hello!

I need to get the file descriptors of some handles, but the handles should not 
be modified. They should not be closed by the operation.

I guess, that the handle gets closed for a reason. But I'm using the revealed 
file descriptors in a way which should pose no problems for the integrity of 
the GHC library.

In order to make a non-closing handleToFd function, I'm studying GHC's library 
source code. But there's a lot which I can't make much sense, because it uses 
non-standard language features (GHC extensions), which I'm not familiar with.

I don't mean you to explain these GHC extensions to me. I just want to give an 
impression of the problems I encounter:

1.

data FD = FD {
  fdFD :: {-# UNPACK #-} !CInt,
  fdIsNonBlocking :: {-# UNPACK #-} !Int
 }

What is that exclamation mark? And that "{-# UNPACK #-}"?

2.

handleToFd' :: Handle -> Handle__ -> IO (Handle__, Fd)
handleToFd' h h_ <at> Handle__{haType=_,..} = do
  case cast haDevice of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Volker Wysk | 1 Oct 2011 08:43
Picon

Re: Getting the file descriptor from a handle, without closing it


On Saturday 01 October 2011 08:30:40 Volker Wysk wrote:
> If anyone can point out to me, how this non-blocking handleToFd function
> should be made, I would be grateful.

This should be "non-CLOSING handleToFd function". Sorry.

Volker
Permalink | Reply | 0 comments |
headers
Bas van Dijk | 1 Oct 2011 10:38
Picon
Gravatar

Re: Getting the file descriptor from a handle, without closing it

On 1 October 2011 08:30, Volker Wysk <pf3 <at> volker-wysk.de> wrote:
> 1.
>
> data FD = FD {
>  fdFD :: {-# UNPACK #-} !CInt,
>  fdIsNonBlocking :: {-# UNPACK #-} !Int
>  }
>
> What is that exclamation mark?

That's a strictness annotation and is haskell98/2010:

http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2

And that "{-# UNPACK #-}"?

To quote:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#unpack-pragma

"The UNPACK indicates to the compiler that it should unpack the
contents of a constructor field into the constructor itself, removing
a level of indirection"

> 2.
>
> handleToFd' :: Handle -> Handle__ -> IO (Handle__, Fd)
> handleToFd' h h_ <at> Handle__{haType=_,..} = do
>  case cast haDevice of
>       -- ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Volker Wysk | 1 Oct 2011 13:31
Picon

REQ: add a non-closing version of handleToFd

Hello

The function to extract a file descriptor from a handle, handleToFd, closes 
the handle as a side effect. This appears to be necessary in the general 
case, otherwise the implementers wouldn't have made it this way.

But there are cases in which it isn't necessary to close the handle.

For instance, this little function needs to extract the file descriptor, but 
there is no need to close, or change, the handle.

isatty :: Handle        -- ^ Handle to check
       -> IO Bool       -- ^ Whether the handle is connected to a terminal
isatty h = do
   fd <- handleToFd_noclose h
   isterm <- {# call isatty as hssh_c_isatty #}    -- this is c2hs
                   ((fromIntegral fd) :: CInt)
   return (isterm /= (0::CInt))

handleToFd_noclose :: Handle -> IO Fd
-- to be implemented

The isatty above can't be implemented with things the way they are. To me, 
this is a serious drawback.

The cases, in which the handle needs to be closed, should be identified, and 
documented. Then, a version of handleToFd, which doesn't close the handle can 
be implemented.

Cheers
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chris Smith | 2 Oct 2011 06:58
Picon

mkTopLevEnv: not interpreted main:Main

So I'm trying to fix a bug in a web application that's using the GHC API
with GHC 7.2.  If it helps, the application is gloss-web, source code at
https://github.com/cdsmith/gloss-web and the relevant module is
src/Source.hs.

The error I'm getting is

    <no location info>: mkTopLevEnv: not interpreted main:MyModule

I get this occasionally when two pieces of source code happen to get
compiled at approximately the same time, but most of the time everything
works fine.  The module name there is whichever one I've defined in the
source code I'm compiling.  It's correct that the module is not
interpreted; I'm specifying options

    hscTarget = HscAsm
    ghcLink = LinkInMemory

But it's unclear to me why GHC occasionally decides to require that it
be interpreted and complain, when compiling the code works fine in any
other circumstance.  Anyone else seen anything like this, or know what
the cause is?

A few notes:

1. It doesn't appear to be a straight-forward reentrancy issue, as
wrapping uses of the GHC API with an MVar lock doesn't affect it at all.
However, it definitely *is* correlated with multiple compiles at
approximately the same time.  Very odd there.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Florian Weimer | 2 Oct 2011 19:54
Picon

Re: Records in Haskell

* Simon Peyton-Jones:

> Provoked the (very constructive) Yesod blog post on "Limitations of
> Haskell", and the follow up discussion, I've started a wiki page to
> collect whatever ideas we have about the name spacing issue for
> record fields.
>
>                 http://hackage.haskell.org/trac/ghc/wiki/Records

I think there are is an additional approach: nested modules (multiple
modules in a single source file) combined with local imports applying
to a specific lexical scope only.  I think this is how Ocaml tackles
this issue.  It is more explicit than the approaches presented so far.
Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 3 Oct 2011 15:24
Picon
Favicon
Gravatar

RE: mkTopLevEnv: not interpreted main:Main

I don't have a good answer here.  FWIW

* I believe that the only call to mkTopLevEnv is in InteractiveEval.findGlobalRdrEnv,
  which in turn only calls mkTopLev on imports which are specified by an IIModule
  specification (see HscTypes.InteractiveImport).

* I think that IIModule things should always be interpreted modules
  else we don't *know* their full top-level environment

* I can't account for how you are getting an IIModule of your main:MyModule,
  because all the places that create IIModule specs check that the module
  is interpreted. Could you be creating that IIModule yourself?  (If so use
  IIDecl instead.)

It's hard to say more without a reproducible test case -- and I'm not too keen on trying to build your entire
project unless there is no alternative -- usually there are lots of other dependencies.

maybe others have ideas too.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-users-
| bounces <at> haskell.org] On Behalf Of Chris Smith
| Sent: 02 October 2011 05:59
| To: glasgow-haskell-users <at> haskell.org
| Subject: mkTopLevEnv: not interpreted main:Main
| 
| So I'm trying to fix a bug in a web application that's using the GHC API
| with GHC 7.2.  If it helps, the application is gloss-web, source code at
(Continue reading)

Permalink | Reply | 10 comments |
headers
Chris Smith | 3 Oct 2011 15:42
Picon

RE: mkTopLevEnv: not interpreted main:Main

Thanks, Simon.

I will work on building a smaller complete test case that reproduces the
issue, and I could have done a better job of at least pointing out the
relevant code for you.  Sorry about that.

I'm definitely not building my own IIModule.  The use of the GHC API is
as follows.  (I'm fairly sure you can ignore doWithErrors, so I haven't
included it; it just sets up some log actions and exception and signal
handlers, runs its argument in the Ghc monad, and converts the result
from a Maybe to an Either that reports errors).

doWithErrors :: GHC.Ghc (Maybe a) -> IO (Either [String] a)

compile :: String -> String -> FilePath -> IO (Either [String] t)
compile vname tname fn = doWithErrors $ do
    dflags <- GHC.getSessionDynFlags
    let dflags' = dflags {
        GHC.ghcMode = GHC.CompManager,
        GHC.ghcLink = GHC.LinkInMemory,
        GHC.hscTarget = GHC.HscAsm,
        GHC.optLevel = 2,
        GHC.safeHaskell = GHC.Sf_Safe,
        GHC.packageFlags = [GHC.TrustPackage "gloss",
                            GHC.ExposePackage "gloss-web-adapters" ]
        }
    GHC.setSessionDynFlags dflags'
    target <- GHC.guessTarget fn Nothing
    GHC.setTargets [target]
    r <- fmap GHC.succeeded (GHC.load GHC.LoadAllTargets)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Roman Cheplyaka | 4 Oct 2011 08:39
Gravatar

Unwanted eta-expansion

Suppose I want a foldl which is evaluated many times on the same
list but with different folding functions.

I would write something like this, to perform pattern-matching on the
list only once:

    module F where
    myFoldl :: [a] -> (b -> a -> b) -> b -> b
    myFoldl [] = \f a -> a
    myFoldl (x:xs) = let y = myFoldl xs in \f a -> y f (f a x)

However, for some reason GHC eta-expands it back. Here's what I see in
the core:

  % ghc -O2 -ddump-simpl -fforce-recomp -dsuppress-module-prefixes \
    -dsuppress-uniques -dsuppress-coercions F.hs

    ==================== Tidy Core ====================
    Rec {
    myFoldl [Occ=LoopBreaker]
      :: forall a b. [a] -> (b -> a -> b) -> b -> b
    [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType SLL]
    myFoldl =
      \ ( <at>  a) ( <at>  b) (ds :: [a]) (eta :: b -> a -> b) (eta1 :: b) ->
        case ds of _ {
          [] -> eta1; : x xs -> myFoldl  <at>  a  <at>  b xs eta (eta eta1 x)
        }
    end Rec }

Why does it happen and can it be suppressed?
(Continue reading)

Permalink | Reply | 7 comments |

Gmane