VisibleTypeApplication and AllowAmbiguousTypes

[Andrew Martin]

I'm posting this because Richard said it would be the best place to raise
this issue. I know it's a little bit late in the GHC8 development process,
but I would like to get the idea out there.

To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn
on AllowAmbiguousTypes. I think that a better behavior for most end users
would be to not have this happen.

I need AllowAmbiguousTypes turned on in modules where I want to declare
functions that are presently uncalled. At a call site though, I only need
VisibleTypeApplication, not both extensions. The only reason I bring this
up is because having AllowAmbiguousTypes on is usually bad. It makes it
possible to write functions that don't work, but you don't learn that until
you get to the call site. If I write libraries that require
VisibleTypeAppliaction to call certain functions, I don't want users
accidentally ending up turning on AllowAmbiguousTypes in their own code.

-- 
-Andrew Thaddeus Martin
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Semantics of IORefs in GHC

[Ben Lippmeier]

> On 14 Mar 2016, at 8:06 pm, Simon Peyton Jones  wrote:
> 
> But my rough answer would be: IORefs are really only meant for 
> single-threaded work.  Use STM for concurrent communication.

You can also use atomicModifyIORef for simple things. 


> Why can’t GHC tighten the semantics of IORefs so that the bind operation 
> simply means sequential composition?

Part of the problem is that IO encomposes all sorts of computational effects, 
including ones that don’t have a well defined notion of time. File and network 
effects are also a problem, not just IORefs. The IO instance of bind composes 
two IO computations, but the computations themselves could do anything.

A first step is to split the IO type into more fine grained effects, perhaps 
ones that can be properly sequentialized and those which can’t (or should not 
be). Many people have done work on more expressive effect systems, though no 
system so far has been good enough to want to refactor the GHC base libraries 
using it.

On a more philosophical level, Haskell types are statements in a simple 
predicate logic which does not natively know anything about time. Functions 
don’t know about time either, so it’s a bit odd to ask a functional operator to 
do something sequential (at least relative to the real world). In the “awkward 
squad” paper note that the functional encoding of the bind operator *passes* 
the world from one place to another -- it is not part of the world, and does 
not act upon the world itself.

In recent work on effect systems there are a lot of embeddings of modal logics 
into the ambient Haskell/predicate logic, and the embeddings then suffer an 
encoding overhead. AFAIK the future lies in type systems that natively express 
temporal concepts, rather than needing tricky encodings of them, but we’re not 
there yet.

Ben.


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Semantics of IORefs in GHC

[Ryan Newton]

Hi Madan,

Yes, GHC, like Java, is an "unsafe language" currently ;-).  It does not
protect its abstractions against buggy programs.  Namely both Haskell and
Java do not protect semi-colon/(>>).

Really, we should probably have some additional monad to distinguish
data-race-free (DRF) IO programs from other IO programs that may have data
races.

Or we could just make sequential consistency the law of the land for IO, as
you propose.  One thing I'd really like to work on -- if someone were
interested in collaborating -- is testing the overhead of making sequential
composition the norm in this way.

I had a nice conversation with your SNAPL co-author Satish about this
recently.  It seems like we could survey a broad swath of Haskell code to
see if fine-grained use of "writeIORef" and "readIORef" are at all common.
My hunch is that IORefs used in concurrent apps (web servers, etc), all use
atomicModifyIORef anyway.

Thus like you I think we could fence read/writeIORef with acceptable perf
for most real apps.  You can still have "reallyUnsafeReadIORef" for
specific purposes like implementing concurrent data structures.

Best,
 -Ryan



On Mon, Mar 14, 2016 at 10:06 AM, Simon Peyton Jones 
wrote:

> Maclan
>
>
>
> I’m glad you enjoyed the awkward squad paper.
>
>
>
> I urge you to write to the Haskell Café mailing list and/or ghc-devs.
> Lots of smart people there.  Ryan Newton is working on this kind of stuff;
> I’ve cc’d him.
>
>
>
> But my rough answer would be: IORefs are really only meant for
> single-threaded work.  Use STM for concurrent communication.
>
>
>
> That’s not to say that we are done!  The Haskell community doesn’t have
> many people like you, who care about the detail of the memory model.  So
> please do help us J.   For example, perhaps we could guarantee a simple
> sequential memory model without much additional cost?
>
>
>
> Simon
>
>
>
> *From:* Madan Musuvathi
> *Sent:* 11 March 2016 19:35
> *To:* Simon Peyton Jones 
> *Subject:* Semantics of IORefs in GHC
>
>
>
> Dear Simon,
>
> I really enjoyed reading your awkward squad paper
> .
> Thank you for writing such an accessible paper.
>
>
>
> My current understanding is that the implementation of IORefs in GHC
> breaks the simple semantics you develop in this paper. In particular, by
> not inserting sufficient fences around reads and writes of IORefs, a
> Haskell program is exposed to the weak-memory-consistency effects of the
> underlying hardware and possibly the backend C compiler. As a result, the
> monadic bind operator no longer has the simple semantics of sequential
> composition. Is my understanding correct?
>
>
>
> This is very troublesome as this weaker semantics can lead to unforeseen
> consequences even in pure functional parts of a program. For example, when
> a reference to an object is passed through an IORef to another thread, the
> latter thread is not guaranteed to see the updates of the first thread. So,
> it is quite possible for some (pure functional) code to be processing
> objects with broken invariants or partially-constructed objects. In the
> extreme, this could lead to type-unsafety unless the GHC compiler is taking
> careful precautions to avoid this. (Many of these problems are unlikely to
> show up on x86 machines, but will be common on ARM.)
>
>
>
> I am sure the GHC community is addressing these problems one way or the
> other. But, my question is WHY?  Why can’t GHC tighten the semantics of
> IORefs so that the bind operation simply means sequential composition?
> Given that Haskell has a clean separation between pure functional parts and
> “awkward” parts of the program, the overheads of these fenced IORefs should
> be acceptable.
>
>
>
> My coauthors and I wrote a recent SNAPL article
>  about
> this problem for other (“less-beautiful” J) imperative languages like C#
> and Java. I really believe we should support sequential composition in our
> programming languages.
>
>
>
> madan
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (reprise)

[Thomas Miedema]

On Wed, Mar 9, 2016 at 7:33 PM, Ben Gamari  wrote:
>
> Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
> bytecode interpreter doesn't support unboxed tuples, which various GHC
> modules use.
>

There's a ticket for that: https://ghc.haskell.org/trac/ghc/ticket/1257
("Bytecode generator can't handle unboxed tuples"). Fixing that would make
it much easier to use GHCi to load the compiler, and allow setting
breakpoints, make a change and use `:r` to reload etc. The ticket is closed
as wontfix however.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Fwd: Reducing boilerplate

[Ben Gamari]

Simon Peyton Jones  writes:

> Great.  Is there a clearly-articulated design on a wiki page?
>
The design for the relevant GHC extension is here [1].

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Fwd: Reducing boilerplate

[Simon Peyton Jones]

Great.  Is there a clearly-articulated design on a wiki page?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Sylvain Henry
|  Sent: 11 March 2016 20:59
|  To: Ben Gamari 
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Fwd: Reducing boilerplate
|  
|  Hi Ben,
|  
|  Thanks for your answer. No problem, I can wait.
|  
|  With this proposal, we would have a really nice story about doing FFI
|  with GHC. I've been playing with DataKinds and other type-related
|  extensions for a few days (thanks to everyone involved in implementing
|  them!) and this extension would remove the last glitch:
|  https://github.com/hsyl20/ViperVM/blob/master/WritingBindings.md
|  Btw, the Vector part is inspired from what you did here:
|  https://github.com/expipiplus1/vulkan/pull/1 (thanks!)
|  
|  Cheers,
|  Sylvain
|  
|  
|  2016-03-11 16:51 GMT+01:00 Ben Gamari :
|  > Sylvain Henry  writes:
|  >
|  >> Hi devs,
|  >>
|  >> I would like to add the support for the following automatic
|  >> instance-deriving extension:
|  >>
|  > Hi Sylvain,
|  >
|  > I suspect the person most qualified to answer these questions will be
|  > Simon who is currently in the middle of paper-writing season.
|  > Consequently, it may be a while until he is able to answer. That
|  being
|  > said, I'm quite happy to hear that someone is thinking about these
|  > proposals.
|  >
|  > Cheers,
|  >
|  > - Ben
|  >
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8bc41138302f4cc4
|  696e08d349efffd6%7c72f988bf86f141af91ab2d7cd011db47%7c1=hSoMQAHQ8
|  E5aWPa%2fK8FXsKcKoUUn7Xv6%2ftpaEX0%2b01M%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Semantics of IORefs in GHC

[Simon Peyton Jones]

Maclan

I’m glad you enjoyed the awkward squad paper.

I urge you to write to the Haskell Café mailing list and/or ghc-devs.  Lots of 
smart people there.  Ryan Newton is working on this kind of stuff; I’ve cc’d 
him.

But my rough answer would be: IORefs are really only meant for single-threaded 
work.  Use STM for concurrent communication.

That’s not to say that we are done!  The Haskell community doesn’t have many 
people like you, who care about the detail of the memory model.  So please do 
help us :).   For example, perhaps we could guarantee a simple sequential 
memory model without much additional cost?

Simon

From: Madan Musuvathi
Sent: 11 March 2016 19:35
To: Simon Peyton Jones 
Subject: Semantics of IORefs in GHC

Dear Simon,
I really enjoyed reading your awkward squad 
paper.
 Thank you for writing such an accessible paper.

My current understanding is that the implementation of IORefs in GHC breaks the 
simple semantics you develop in this paper. In particular, by not inserting 
sufficient fences around reads and writes of IORefs, a Haskell program is 
exposed to the weak-memory-consistency effects of the underlying hardware and 
possibly the backend C compiler. As a result, the monadic bind operator no 
longer has the simple semantics of sequential composition. Is my understanding 
correct?

This is very troublesome as this weaker semantics can lead to unforeseen 
consequences even in pure functional parts of a program. For example, when a 
reference to an object is passed through an IORef to another thread, the latter 
thread is not guaranteed to see the updates of the first thread. So, it is 
quite possible for some (pure functional) code to be processing objects with 
broken invariants or partially-constructed objects. In the extreme, this could 
lead to type-unsafety unless the GHC compiler is taking careful precautions to 
avoid this. (Many of these problems are unlikely to show up on x86 machines, 
but will be common on ARM.)

I am sure the GHC community is addressing these problems one way or the other. 
But, my question is WHY?  Why can’t GHC tighten the semantics of IORefs so that 
the bind operation simply means sequential composition? Given that Haskell has 
a clean separation between pure functional parts and “awkward” parts of the 
program, the overheads of these fenced IORefs should be acceptable.

My coauthors and I wrote a recent SNAPL 
article about 
this problem for other (“less-beautiful” :)) imperative languages like C# and 
Java. I really believe we should support sequential composition in our 
programming languages.

madan

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs