From bulat.ziganshin at gmail.com  Tue Feb 10 16:20:50 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Feb 10 16:11:03 2009
Subject: FFI and fixed-size integer types
Message-ID: <1352129308.20090211002050@gmail.com>

Hello ,

<citating letter from cafe>

>>> After reading an ISO draft for standard C, I found
>>> a few types that could be usefull when binding to
>>> libraries (these are from <stdint.h>):
>>>
>>> int8_t, uint8_t, int16_t, uint16_t, int32_t,
>>> uint32_t, int64_t, uint64_t

i propose to change FFI addendum so that haskell compilers guarantee
correspondence between Int16 and int16_t types and so on
  

-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin@gmail.com

From rmm-haskell at z.odi.ac  Tue Feb 10 16:25:29 2009
From: rmm-haskell at z.odi.ac (Ross Mellgren)
Date: Tue Feb 10 16:15:16 2009
Subject: FFI and fixed-size integer types
In-Reply-To: <1352129308.20090211002050@gmail.com>
References: <1352129308.20090211002050@gmail.com>
Message-ID: <5EAE5804-4B72-4C2C-9716-D40FBB97E592@z.odi.ac>

Reading the FFI spec and information about stdint.h, it looks like  
this guarantee holds already -- FFI guarantees that Int<n> and Word<n>  
will be n bits wide and will operate with 2^n arithmetic. It looks  
like C99 correspondingly defines the same kind of thing for int<n>_t  
and uint<n>_t. I guess the only missing piece is there is no  
specification of the byte order, though I would be surprised if they  
were not both in host byte order.

-Ross

On Feb 10, 2009, at 4:20 PM, Bulat Ziganshin wrote:

> Hello ,
>
> <citating letter from cafe>
>
>>>> After reading an ISO draft for standard C, I found
>>>> a few types that could be usefull when binding to
>>>> libraries (these are from <stdint.h>):
>>>>
>>>> int8_t, uint8_t, int16_t, uint16_t, int32_t,
>>>> uint32_t, int64_t, uint64_t
>
> i propose to change FFI addendum so that haskell compilers guarantee
> correspondence between Int16 and int16_t types and so on
>
>
> -- 
> Best regards,
> Bulat                          mailto:Bulat.Ziganshin@gmail.com
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime

From simonpj at microsoft.com  Thu Feb 12 04:22:31 2009
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu Feb 12 04:12:16 2009
Subject: Newtype unwrapping in the FFI
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399201B40@EA-EXMSG-C334.europe.corp.microsoft.com>

[This email concerns an infelicity in the FFI spec. I'm directing it primarily to the Haskell Prime mailing list, but ccing the libraries list so that people there know about the thread. I suggest that replies go to Haskell Prime only.]

Consider this program (see http://hackage.haskell.org/trac/ghc/ticket/3008)

  module NT( N ) where
     newtype N = MkN Int

  module FFI where
     foreign import "f" :: N -> IO ()

Is module FFI OK?  It would definitely be OK if N was defined in the module FFI: the FFI spec says that the compiler must automatically unwrap any newtype arguments.
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2

But it's less clear when N is defined in another module *and* its representation isn't exported.  The author of NT might believe that because N's representation is hidden, she can change it to, say
        data N = MkN Int
without affecting the rest of the world.  But she can't.  This is a nasty failure of abstraction.  It is, I believe the only way in which a client of a NT could be affected by N's representation, even though that representation is allegedly hidden.  (ToDo: check on generalised newtype deriving.) This seems Bad to me.

Indeed, the cause of the above bug report is that GHC's implementation assumes that the representation is fully hidden if the constructor is not exported, and does not expose the representation of N even to separately-compiled modules (at least when you are not using -O).

But the point here is not what GHC stumbles on but what is supposed to happen.

Maybe we should fix it.  Proposal:

  * Clarify the spec to say that a newtype can only be automatically
    unwrapped if the newtype constructor (MkN in this case) is in scope

It happens that a large set of types from Foreign.C.Types, such as CInt and friends, are exported without their constructors, so adopting this new rule would require us to change Foreign.C.Types to expose the representation of CInt and friends.  (As it happens, nhc requires this already, so there's some #ifdeffery there already.)

Simon
From duncan.coutts at worc.ox.ac.uk  Thu Feb 12 07:01:06 2009
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Feb 12 06:51:02 2009
Subject: Newtype unwrapping in the FFI
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33399201B40@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <638ABD0A29C8884A91BC5FB5C349B1C33399201B40@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <1234440066.4025.14.camel@localhost>

On Thu, 2009-02-12 at 09:22 +0000, Simon Peyton-Jones wrote:
> [This email concerns an infelicity in the FFI spec. I'm directing it
> primarily to the Haskell Prime mailing list, but ccing the libraries
> list so that people there know about the thread. I suggest that
> replies go to Haskell Prime only.]
> 
> Consider this program (see
> http://hackage.haskell.org/trac/ghc/ticket/3008)
> 
>   module NT( N ) where
>      newtype N = MkN Int
> 
>   module FFI where
>      foreign import "f" :: N -> IO ()
> 
> Is module FFI OK?  It would definitely be OK if N was defined in the
> module FFI: the FFI spec says that the compiler must automatically
> unwrap any newtype arguments.
> http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2
> 
> But it's less clear when N is defined in another module *and* its
> representation isn't exported.  The author of NT might believe that
> because N's representation is hidden, she can change it to, say
>         data N = MkN Int
> without affecting the rest of the world.  But she can't.  This is a
> nasty failure of abstraction.  It is, I believe the only way in which
> a client of a NT could be affected by N's representation, even though
> that representation is allegedly hidden.  (ToDo: check on generalised
> newtype deriving.) This seems Bad to me.
> 
> Indeed, the cause of the above bug report is that GHC's implementation
> assumes that the representation is fully hidden if the constructor is
> not exported, and does not expose the representation of N even to
> separately-compiled modules (at least when you are not using -O).
> 
> But the point here is not what GHC stumbles on but what is supposed to
> happen.
> 
> Maybe we should fix it.  Proposal:
> 
>   * Clarify the spec to say that a newtype can only be automatically
>     unwrapped if the newtype constructor (MkN in this case) is in
> scope

I agree up to here. For user-defined types, not exporting the
constructor should be a guarantee of abstraction.

> It happens that a large set of types from Foreign.C.Types, such as
> CInt and friends, are exported without their constructors, so adopting
> this new rule would require us to change Foreign.C.Types to expose the
> representation of CInt and friends.  (As it happens, nhc requires this
> already, so there's some #ifdeffery there already.)

The thing about CInt though is that it is supposed to be abstract *and*
an FFI type. I want to think of it as a primitive FFI type (though it is
not a "basic" type as defined by the FFI). We don't want to know that on
some system it is Int32 and on others it is Int64. We do not want access
to the constructor here.

Duncan

From simonpj at microsoft.com  Thu Feb 12 07:35:35 2009
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu Feb 12 07:25:17 2009
Subject: Newtype unwrapping in the FFI
In-Reply-To: <1234440066.4025.14.camel@localhost>
References: <638ABD0A29C8884A91BC5FB5C349B1C33399201B40@EA-EXMSG-C334.europe.corp.microsoft.com>
	<1234440066.4025.14.camel@localhost>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399201D6A@EA-EXMSG-C334.europe.corp.microsoft.com>

| >   * Clarify the spec to say that a newtype can only be automatically
| >     unwrapped if the newtype constructor (MkN in this case) is in
| > scope
|
| I agree up to here. For user-defined types, not exporting the
| constructor should be a guarantee of abstraction.
|
| > It happens that a large set of types from Foreign.C.Types, such as
| > CInt and friends, are exported without their constructors, so adopting
| > this new rule would require us to change Foreign.C.Types to expose the
| > representation of CInt and friends.  (As it happens, nhc requires this
| > already, so there's some #ifdeffery there already.)
|
| The thing about CInt though is that it is supposed to be abstract *and*
| an FFI type. I want to think of it as a primitive FFI type (though it is
| not a "basic" type as defined by the FFI). We don't want to know that on
| some system it is Int32 and on others it is Int64. We do not want access
| to the constructor here.

Trouble is, there are a zillion types in Foreign.C.Types, and another zillion in Foreign.Posix.Types. Do you want to list them all as "blessed" in the FFI addendum?

S
From chak at cse.unsw.edu.au  Thu Feb 12 18:49:23 2009
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Thu Feb 12 18:39:17 2009
Subject: Newtype unwrapping in the FFI
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33399201D6A@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <638ABD0A29C8884A91BC5FB5C349B1C33399201B40@EA-EXMSG-C334.europe.corp.microsoft.com>
	<1234440066.4025.14.camel@localhost>
	<638ABD0A29C8884A91BC5FB5C349B1C33399201D6A@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <3181B0E1-0D2E-45AD-9CEF-A74F0A965DF6@cse.unsw.edu.au>

Simon Peyton-Jones:
> | >   * Clarify the spec to say that a newtype can only be  
> automatically
> | >     unwrapped if the newtype constructor (MkN in this case) is in
> | > scope
> |
> | I agree up to here. For user-defined types, not exporting the
> | constructor should be a guarantee of abstraction.

I also don't really see an alternative.  The ability to pass a type to  
a foreign function tells us something about the type; there is not  
much we can do about that.

> | > It happens that a large set of types from Foreign.C.Types, such as
> | > CInt and friends, are exported without their constructors, so  
> adopting
> | > this new rule would require us to change Foreign.C.Types to  
> expose the
> | > representation of CInt and friends.  (As it happens, nhc  
> requires this
> | > already, so there's some #ifdeffery there already.)
> |
> | The thing about CInt though is that it is supposed to be abstract  
> *and*
> | an FFI type. I want to think of it as a primitive FFI type (though  
> it is
> | not a "basic" type as defined by the FFI). We don't want to know  
> that on
> | some system it is Int32 and on others it is Int64. We do not want  
> access
> | to the constructor here.
>
> Trouble is, there are a zillion types in Foreign.C.Types, and  
> another zillion in Foreign.Posix.Types. Do you want to list them all  
> as "blessed" in the FFI addendum?

The types in Foreign.C.Types are already listed in the FFI addendum  
(it actually specifies the whole module, just like the report  
specifies what is in the Prelude).

However, I think an argument can be made that hiding the  
implementation of the types in C.Foreign.Types is a Bad Thing.  FFI  
code is inherently architecture dependent due to the varying sizes and  
representations of C types.  Hiding that variation behind a newtype  
serves only to obscure that dependency, it certainly doesn't resolve  
it.  I know that Section 6.2 of the FFI addendum requires these  
exports to be abstract, but I now tend to think that this was a mistake.

Manuel

From Christian.Maeder at dfki.de  Fri Feb 27 05:53:22 2009
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Feb 27 05:42:15 2009
Subject: Suggestion for bang patterns documentation
In-Reply-To: <BAY122-W55ED84FDD3E048FA42F0ECFEAA0@phx.gbl>
References: <BAY122-W55ED84FDD3E048FA42F0ECFEAA0@phx.gbl>
Message-ID: <49A7C622.5010200@dfki.de>

Brian Bloniarz wrote:
> I got confused by the GHC documentation recently, I was wondering how
> it could be improved. From:
> http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html

Seeing the rule
 pat ::= !pat

you'll probably want to avoid patterns like: "!!pat", "! ! pat", or "~ !
~ pat".

Even the current http://www.haskell.org/onlinelibrary/exps.html#sect3.17.1

  apat -> ~ apat

allows "~ ~x". (Note the space!) So maybe a separate non-terminal "bpat"
should be used with:

 bpat -> [~|!] apat

(and bpat used within pat). You may also want to exclude "v@ ~(...)" in
favor of "~v@(...)".

>> A bang only really has an effect if it precedes a variable or wild-card pattern:
>> f3 !(x,y) = [x,y]
>> f4 (x,y)  = [x,y]
>> Here, f3 and f4 are identical; putting a bang before a pattern that
>> forces evaluation anyway does nothing.

Maybe the duality (if it is one) should be added that an irrefutable
pattern above would make a difference but not within the let below.

> The first sentence is true, but only in settings where the pattern is being
> evaluated eagerly -- the bang in:
>> f3 a = let !(x,y) = a in [1,x,y]
>> f4 a = let (x,y) = a in [1,x,y]
> has an effect.

Cheers Christian

From ramin.honary at gmail.com  Fri Feb 27 07:13:00 2009
From: ramin.honary at gmail.com (Ramin Honary)
Date: Fri Feb 27 07:01:52 2009
Subject: Field labels that do updates
Message-ID: <2a43aa3d0902270413g3eced729x8a9e66d27f89459e@mail.gmail.com>

I have written a couple of small, experimental virtual machines in Haskell,
and I always use the State monad with the virtual machine data type as the
state.
   data VM a = VM { getAlpha :: Int , getBeta :: String , getGamma :: a }
which is all well and good, but I inevitably end up writing code like this
along with it:
    putAlpha a (VM _ b c) = (VM a b c)
    putBeta  b (VM a _ c) = (VM a b c)
    putGamma  c (VM a b _) = (VM a b c)
Its useful because you can just create one monadic function that updates the
state and pass one of the "put" functions as a parameter.
    updateVM :: (x -> VM a -> VM b) -> x -> State (VM b) ()
    updateVM  putFunc value = do { state <- get ; put (putFunc value state)
}

...some algorithm...
    do updateVM putAlpha 12
       updateVM putBeta "Hello"
       return somthing

But writing the "put" functions become tedious for virtual machines with
more fields in their type, especially if you need to add a field to the data
type in the future. Could there be syntactic sugar added to generate a list
of functions that update the fields of a data type?
   data VM a = VM { getAlpha/putAlpha :: Int , getBeta/putBeta :: String ,
getGamma/putGamma :: a }
Where the slash operator is optional, but if included in the code will cause
the compiler to generate functions of the given names that update those
fields.

Pros: one more time-saving feature implemented in syntactic sugar. The
optional nature of the slash operator would give users a choice of whether
or not to use it.
Cons: increases complexity of the syntax

I couldn't find such a suggestion on the mailing list, but something tells
me this idea is too simple to have not been suggested before. Sorry if this
is a redundant feature request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090227/f4d28708/attachment.htm