From jwlato at gmail.com  Wed Jan  1 19:38:00 2014
From: jwlato at gmail.com (John Lato)
Date: Wed, 1 Jan 2014 11:38:00 -0800
Subject: memory ordering
In-Reply-To: <1388496939-sup-1821@sabre>
References: <CAJ727GgSbO4zON2ruenB4zKuB8kfjq6WqJ4pCE5zkBJfEzHaMA@mail.gmail.com>
 <1388409528-sup-9632@sabre>
 <CAJ727GhzqGrFqZSTCfzGapjDRv65C-5vgKfdBmxZPTE7NdRobg@mail.gmail.com>
 <1388496939-sup-1821@sabre>
Message-ID: <CAJ727Gj2L25AzkE3P4b0LO=tF-2brAf_5QtS4WpL16YQG68Arg@mail.gmail.com>

One point I'm getting from this discussion is that perhaps not much time
has been spent considering these issues in ghc backends. If so, it's
probably a good thing to work through it now.

For myself, I guess the only option I have now is to measure using
loadLoadBarrier and see if it's better or worse than calling
atomicModifyIORef.
On Dec 31, 2013 6:42 AM, "Edward Z. Yang" <ezyang at mit.edu> wrote:

> I was thinking about my response, and realized there was one major
> misleading thing in my description.  The load reordering I described
> applies to load instructions in C-- proper, i.e. things that show up
> in the C-- dup as:
>
>     W_ x = I64[...addr...]
>
> Reads to IORefs and reads to vectors get compiled inline (as they
> eventually translate into inline primops), so my admonitions are
> applicable.
>
> However, the story with *foreign primops* (which is how loadLoadBarrier
> in atomic-primops is defined, how you might imagine defining a custom
> read function as a primop) is a little different.  First, what does a
> call to an foreign primop compile into? It is *not* inlined, so it will
> eventually get compiled into a jump (this could be a problem if you're
> really trying to squeeze out performance!)  Second, the optimizer is a
> bit more conservative when it comes to primop calls (internally referred
> to as "unsafe foreign calls"); at the moment, the optimizer assumes
> these foreign calls clobber heap memory, so we *automatically* will not
> push loads/stores beyond this boundary. (NB: We reserve the right to
> change this in the future!)
>
> This is probably why atomic-primops, as it is written today, seems to
> work OK, even in the presence of the optimizer.  But I also have a hard
> time believing it gives the speedups you want, due to the current
> design. (CC'd Ryan Newton, because I would love to be wrong here, and
> maybe he can correct me on this note.)
>
> Cheers,
> Edward
>
> P.S. loadLoadBarrier compiles to a no-op on x86 architectures, but
> because it's not inlined I think you will still end up with a jump (LLVM
> might be able to eliminate it).
>
> Excerpts from John Lato's message of 2013-12-31 03:01:58 +0800:
> > Hi Edward,
> >
> > Thanks very much for this reply, it answers a lot of questions I'd had.
> >  I'd hoped that ordering would be preserved through C--, but c'est la
> vie.
> >  Optimizing compilers are ever the bane of concurrent algorithms!
> >
> > stg/SMP.h does define a loadLoadBarrier, which is exposed in Ryan
> Newton's
> > atomic-primops package.  From the docs, I think that's a general read
> > barrier, and should do what I want.  Assuming it works properly, of
> course.
> >  If I'm lucky it might even be optimized out.
> >
> > Thanks,
> > John
> >
> > On Mon, Dec 30, 2013 at 6:04 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> > > Hello John,
> > >
> > > Here are some prior discussions (which I will attempt to summarize
> > > below):
> > >
> > >     http://www.haskell.org/pipermail/haskell-cafe/2011-May/091878.html
> > >
> http://www.haskell.org/pipermail/haskell-prime/2006-April/001237.html
> > >
> http://www.haskell.org/pipermail/haskell-prime/2006-March/001079.html
> > >
> > > The guarantees that Haskell and GHC give in this area are hand-wavy at
> > > best; at the moment, I don't think Haskell or GHC have a formal memory
> > > model?this seems to be an open research problem. (Unfortunately, AFAICT
> > > all the researchers working on relaxed memory models have their hands
> > > full with things like C++ :-)
> > >
> > > If you want to go ahead and build something that /just/ works for a
> > > /specific version/ of GHC, you will need to answer this question
> > > separately for every phase of the compiler.  For Core and STG, monads
> > > will preserve ordering, so there is no trouble.  However, for C--, we
> > > will almost certainly apply optimizations which reorder reads (look at
> > > CmmSink.hs).  To properly support your algorithm, you will have to add
> > > some new read barrier mach-ops, and teach the optimizer to respect
> them.
> > > (This could be fiendishly subtle; it might be better to give C-- a
> > > memory model first.)  These mach-ops would then translate into
> > > appropriate arch-specific assembly or LLVM instructions, preserving
> > > the guarantees further.
> > >
> > > This is not related to your original question, but the situation is a
> > > bit better with regards to reordering stores: we have a WriteBarrier
> > > MachOp, which in principle, prevents store reordering.  In practice, we
> > > don't seem to actually have any C-- optimizations that reorder stores.
> > > So, at least you can assume these will work OK!
> > >
> > > Hope this helps (and is not too inaccurate),
> > > Edward
> > >
> > > Excerpts from John Lato's message of 2013-12-20 09:36:11 +0800:
> > > > Hello,
> > > >
> > > > I'm working on a lock-free algorithm that's meant to be used in a
> > > > concurrent setting, and I've run into a possible issue.
> > > >
> > > > The crux of the matter is that a particular function needs to
> perform the
> > > > following:
> > > >
> > > > > x <- MVector.read vec ix
> > > > > position <- readIORef posRef
> > > >
> > > > and the algorithm is only safe if these two reads are not reordered
> (both
> > > > the vector and IORef are written to by other threads).
> > > >
> > > > My concern is, according to standard Haskell semantics this should be
> > > safe,
> > > > as IO sequencing should guarantee that the reads happen in-order.  Of
> > > > course this also relies upon the architecture's memory model, but x86
> > > also
> > > > guarantees that reads happen in order.  However doubts remain; I do
> not
> > > > have confidence that the code generator will handle this properly.
>  In
> > > > particular, LLVM may freely re-order loads of NotAtomic and Unordered
> > > > values.
> > > >
> > > > The one hope I have is that ghc will preserve IO semantics through
> the
> > > > entire pipeline.  This seems like it would be necessary for proper
> > > handling
> > > > of exceptions, for example.  So, can anyone tell me if my worries are
> > > > unfounded, or if there's any way to ensure the behavior I want?  I
> could
> > > > change the readIORef to an atomicModifyIORef, which should issue an
> > > mfence,
> > > > but that seems a bit heavy-handed as just a read fence would be
> > > sufficient
> > > > (although even that seems more than necessary).
> > > >
> > > > Thanks,
> > > > John L.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140101/85c1cae6/attachment.html>

From carter.schonwald at gmail.com  Sat Jan  4 23:23:18 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 4 Jan 2014 18:23:18 -0500
Subject: Mips64el Linux Build
In-Reply-To: <CAFZ-Tg=MRYXR4xsAKqDnHMTFR1eTba63P8X7O8rDrT1s6jXkFQ@mail.gmail.com>
References: <CAFZ-Tg=MRYXR4xsAKqDnHMTFR1eTba63P8X7O8rDrT1s6jXkFQ@mail.gmail.com>
Message-ID: <CAHYVw0yj2PFODCPrvovRK67y1w4k8ZB5X4wMgzxCra117_A=AQ@mail.gmail.com>

hey Cherry, thanks for noting this.

could you file a ticket on trac? (though adding it to the cross compiling
notes on the wiki is great too)

cheers
-Carter


On Sun, Dec 15, 2013 at 10:32 PM, cherry <cherry.mui9 at gmail.com> wrote:

> Hello,
>
> I am new to the list, though I have been using GHC for a long time. Just
> say Hello.
>
> I would like to share my experience about building GHC (7.7.20131112)
> on/for mips64el linux, just in case anybody is interested, as it seems not
> documented (on Wiki pages of Platforms, CrossCompiling, or Porting). Ignore
> this email if it is not interesting or too trivial.
>
> It bootstrapped by cross compiling on x86_64 linux, with some tweaking on
> mk/build.mk and the build process. In particular, I needed to specify
>
> export CPP="mips64el-unknown-linux-gnu-gcc -E"
>
> otherwise the configure script just found to use the native "gcc -E" and
> it failed in preprocessing rts C files. Also in mk/build.mk I forced
>
> GhcThreaded = NO
> GhcWithInterpreter = YES  # so, it can use TH and build happy
>
> The make process failed when trying to use ghc-stage2, but at that point
> the stage 2 compiler is already built, that's enough.
>
> With this cross-compiled ghc-stage2, the native build on mips64el machine
> was done without much interleaving. inplace/lib/unlit was x86_64 binary,
> and needed to be rebuild. Also manually built alex and happy (and their
> dependencies). Then it just went through. So, the new way of porting seems
> just cross compiling followed by native compiling? Somewhat surprisingly,
> GHCi is also working (forced it to be built), with system's dynamic linker.
>
> Is there need to write/update a wiki page for this?
>
> Thanks,
> cherry
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140104/e249d0df/attachment.html>

From sami.liedes at iki.fi  Sun Jan  5 21:47:24 2014
From: sami.liedes at iki.fi (Sami Liedes)
Date: Sun, 5 Jan 2014 23:47:24 +0200
Subject: Parallel building multiple targets
Message-ID: <20140105214723.GC12676@sli.dy.fi>

Hi,

I have a Haskell project where a number of executables are produced
from mostly the same modules. I'm using a Makefile to enable parallel
builds. I received advice[1] that ghc -M is broken, but that there
is parallel ghc --make in HEAD.

As far as I can tell, ghc --make does not allow building several
binaries in one run, so I think it may not still be a full replacement
for Makefiles.

However I have a question about ghc --make that is also relevant
without parallel ghc --make:

If I have two main modules, prog1.hs and prog2.hs, which have mutual
dependencies (for example, both import A from A.hs), is it safe to run
"ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there
some kind of locking to prevent both from building module A at the
same time and interfering with each other?

Is there a good way (either in current releases or HEAD) to build
multiple binaries partially from the same sources in parallel?

	Sami


[1] http://stackoverflow.com/questions/20938894/generating-correct-link-dependencies-for-ghc-and-makefile-style-builds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140105/ca4d6c97/attachment.sig>

From jwlato at gmail.com  Sun Jan  5 23:48:37 2014
From: jwlato at gmail.com (John Lato)
Date: Sun, 5 Jan 2014 15:48:37 -0800
Subject: Parallel building multiple targets
In-Reply-To: <20140105214723.GC12676@sli.dy.fi>
References: <20140105214723.GC12676@sli.dy.fi>
Message-ID: <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>

(FYI, I expect I'm the source of the suggestion that ghc -M is broken)

First, just to clarify, I don't think ghc -M is obviously broken.  Rather,
I think it's broken in subtle, unobvious ways, such that trying to develop
a make-based project with ghc -M will fail at various times in a
non-obvious fashion, at least without substantial additional rules.  For an
example of some of the extra steps necessary to make something like this
work, see e.g. https://github.com/nh2/multishake (which is admittedly for a
more complicated setup, and also has some issues).  The especially
frustrating part is, just when you think you have everything working,
someone wants to add some other tool to a workflow (hsc2hs, .cmm files,
etc), and your build system doesn't support it.

ghc --make doesn't allow building several binaries in one run, however if
you use cabal all the separate runs will use a shared build directory, so
subsequent builds will be able to take advantage of the intermediate output
of the first build.  Of course you could do the same without cabal, but
it's a convenient way to create a common build directory and manage
multiple targets.  This is the approach I would take to building multiple
executables from the same source files.

ghc doesn't do any locking of build files AFAIK.  Running parallel ghc
commands for two main modules that have the same import, using the same
working directory, is not safe.  In pathological cases the two different
main modules may even generate different code *for the imported module*.
 This sort of situation can arise with the IncoherentInstances extension,
for example.

The obvious approach is of course to make a library out of your common
files.  This has the downsides of requiring a bit more work on the
developer's part, but if the common files are relatively stable it'll
probably lead to the fastest builds of your executables.  Also in this case
you could run multiple `ghc --make`s in parallel, using different build
directories, since they won't be rebuilding any common code.

John L.

On Sun, Jan 5, 2014 at 1:47 PM, Sami Liedes <sami.liedes at iki.fi> wrote:

> Hi,
>
> I have a Haskell project where a number of executables are produced
> from mostly the same modules. I'm using a Makefile to enable parallel
> builds. I received advice[1] that ghc -M is broken, but that there
> is parallel ghc --make in HEAD.
>
> As far as I can tell, ghc --make does not allow building several
> binaries in one run, so I think it may not still be a full replacement
> for Makefiles.
>
> However I have a question about ghc --make that is also relevant
> without parallel ghc --make:
>
> If I have two main modules, prog1.hs and prog2.hs, which have mutual
> dependencies (for example, both import A from A.hs), is it safe to run
> "ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there
> some kind of locking to prevent both from building module A at the
> same time and interfering with each other?
>
> Is there a good way (either in current releases or HEAD) to build
> multiple binaries partially from the same sources in parallel?
>
>         Sami
>
>
> [1]
> http://stackoverflow.com/questions/20938894/generating-correct-link-dependencies-for-ghc-and-makefile-style-builds
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140105/28e8e5f3/attachment.html>

From mle+hs at mega-nerd.com  Sun Jan  5 23:54:03 2014
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Mon, 6 Jan 2014 10:54:03 +1100
Subject: Parallel building multiple targets
In-Reply-To: <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
References: <20140105214723.GC12676@sli.dy.fi>
 <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
Message-ID: <20140106105403.9915eb64deb23175dcd67085@mega-nerd.com>

John Lato wrote:

> ghc --make doesn't allow building several binaries in one run, however if
> you use cabal all the separate runs will use a shared build directory, so
> subsequent builds will be able to take advantage of the intermediate output
> of the first build.

As long as the ghc-options flags are the same for all the different component
sections (I've been bitten by this).

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From jwlato at gmail.com  Sun Jan  5 23:55:31 2014
From: jwlato at gmail.com (John Lato)
Date: Sun, 5 Jan 2014 15:55:31 -0800
Subject: Parallel building multiple targets
In-Reply-To: <20140106105403.9915eb64deb23175dcd67085@mega-nerd.com>
References: <20140105214723.GC12676@sli.dy.fi>
 <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
 <20140106105403.9915eb64deb23175dcd67085@mega-nerd.com>
Message-ID: <CAJ727GhtKtYweOER33eraPdMDiXfvZNv9cUtmfb_VTe790mzQA@mail.gmail.com>

On Sun, Jan 5, 2014 at 3:54 PM, Erik de Castro Lopo <mle+hs at mega-nerd.com>wrote:

> John Lato wrote:
>
> > ghc --make doesn't allow building several binaries in one run, however if
> > you use cabal all the separate runs will use a shared build directory, so
> > subsequent builds will be able to take advantage of the intermediate
> output
> > of the first build.
>
> As long as the ghc-options flags are the same for all the different
> component
> sections (I've been bitten by this).
>

Yes, good point.  This is one case where putting the common code in a
library will help a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140105/160de98d/attachment.html>

From cbrolin at gmail.com  Sun Jan 12 14:07:52 2014
From: cbrolin at gmail.com (Christian Brolin)
Date: Sun, 12 Jan 2014 15:07:52 +0100
Subject: Problem with the object file name of the Main module.
Message-ID: <52D2A1B8.50103@gmail.com>

H.

The documentation (version 7.6.3) section 7.7.2 Output files says that 
the source file name of the Main module does not have to be Main.hs 
making it "possible to have several Main modules in separate source 
files in the same directory". While this is true and promising it is 
seems to be unusable since GHC always compiles the main source file into 
an object file called Main.o.


From carter.schonwald at gmail.com  Sun Jan 12 16:23:12 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 12 Jan 2014 11:23:12 -0500
Subject: Problem with the object file name of the Main module.
In-Reply-To: <52D2A1B8.50103@gmail.com>
References: <52D2A1B8.50103@gmail.com>
Message-ID: <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>

Christian, have you tried using cabal? People write cabal files with
multiple executables being generated all the time.

On Sunday, January 12, 2014, Christian Brolin wrote:

> H.
>
> The documentation (version 7.6.3) section 7.7.2 Output files says that the
> source file name of the Main module does not have to be Main.hs making it
> "possible to have several Main modules in separate source files in the same
> directory". While this is true and promising it is seems to be unusable
> since GHC always compiles the main source file into an object file called
> Main.o.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140112/5b299e70/attachment.html>

From cbrolin at gmail.com  Mon Jan 13 18:22:19 2014
From: cbrolin at gmail.com (Christian Brolin)
Date: Mon, 13 Jan 2014 19:22:19 +0100
Subject: Problem with the object file name of the Main module.
In-Reply-To: <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
Message-ID: <52D42EDB.6050508@gmail.com>

No. As a workaround I remove the Main.o file after the executable has 
been linked. It works, but it has its drawbacks.

On 2014-01-12 17:23, Carter Schonwald wrote:
> Christian, have you tried using cabal? People write cabal files with 
> multiple executables being generated all the time.
>
> On Sunday, January 12, 2014, Christian Brolin wrote:
>
>     H.
>
>     The documentation (version 7.6.3) section 7.7.2 Output files says
>     that the source file name of the Main module does not have to be
>     Main.hs making it "possible to have several Main modules in
>     separate source files in the same directory". While this is true
>     and promising it is seems to be unusable since GHC always compiles
>     the main source file into an object file called Main.o.
>
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.org
>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/0e5242e3/attachment.html>

From carter.schonwald at gmail.com  Mon Jan 13 18:28:34 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 13 Jan 2014 13:28:34 -0500
Subject: Problem with the object file name of the Main module.
In-Reply-To: <52D42EDB.6050508@gmail.com>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
 <52D42EDB.6050508@gmail.com>
Message-ID: <CAHYVw0yORYjgcG3S+qt5PUVgOsY_cU9PwLPCrdz3xuAq4N6zUQ@mail.gmail.com>

i warmly recommend you use cabal for any complicated build processes. if
you're stuck, holler and we or haskell-cafe are happy to help


On Mon, Jan 13, 2014 at 1:22 PM, Christian Brolin <cbrolin at gmail.com> wrote:

>  No. As a workaround I remove the Main.o file after the executable has
> been linked. It works, but it has its drawbacks.
>
>
> On 2014-01-12 17:23, Carter Schonwald wrote:
>
> Christian, have you tried using cabal? People write cabal files with
> multiple executables being generated all the time.
>
> On Sunday, January 12, 2014, Christian Brolin wrote:
>
>> H.
>>
>> The documentation (version 7.6.3) section 7.7.2 Output files says that
>> the source file name of the Main module does not have to be Main.hs making
>> it "possible to have several Main modules in separate source files in the
>> same directory". While this is true and promising it is seems to be
>> unusable since GHC always compiles the main source file into an object file
>> called Main.o.
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/bb9850d6/attachment.html>

From krz.gogolewski at gmail.com  Mon Jan 13 18:42:35 2014
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Mon, 13 Jan 2014 19:42:35 +0100
Subject: Enabling TypeHoles by default
Message-ID: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>

Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check
type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile
stays the same - Haskell 2010. The only exception is that if you use
-fdefer-type-errors, then a program with a hole compiles, but this seems
fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is
7.8, two people (John and Richard) suggested 7.10.

-KG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/3d6de6aa/attachment.html>

From ekmett at gmail.com  Mon Jan 13 18:54:25 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 13 Jan 2014 13:54:25 -0500
Subject: Enabling TypeHoles by default
In-Reply-To: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
Message-ID: <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>

I have to admit, I rather like this suggestion.

-Edward


On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski <
krz.gogolewski at gmail.com> wrote:

> Hello,
>
> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
> default. Rationale:
>
> (1) This way holes are far easier to use; just entering "_" allows to
> check type of a subexpression, no need of adding "-XTypeHoles".
>
> (2) This affects error messages only; i.e. the set of programs that
> compile stays the same - Haskell 2010. The only exception is that if you
> use -fdefer-type-errors, then a program with a hole compiles, but this
> seems fine with philosophy of -fdefer-type-errors.
>
> If so: would you like it to be in 7.8 or wait a cycle? My preference is
> 7.8, two people (John and Richard) suggested 7.10.
>
> -KG
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/62f2e3bf/attachment.html>

From migmit at gmail.com  Mon Jan 13 19:03:24 2014
From: migmit at gmail.com (migmit)
Date: Mon, 13 Jan 2014 23:03:24 +0400
Subject: Enabling TypeHoles by default
In-Reply-To: <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>
Message-ID: <44D991B1-67A9-4291-9D9B-C32173266EA6@gmail.com>

Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can break anything.

?????????? ? iPad

> 13 ???. 2014 ?., ? 22:54, Edward Kmett <ekmett at gmail.com> ???????(?):
> 
> I have to admit, I rather like this suggestion.
> 
> -Edward
> 
> 
>> On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski <krz.gogolewski at gmail.com> wrote:
>> Hello,
>> 
>> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:
>> 
>> (1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".
>> 
>> (2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.
>> 
>> If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.
>> 
>> -KG
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/8f9952e9/attachment.html>

From hesselink at gmail.com  Mon Jan 13 19:07:53 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 13 Jan 2014 20:07:53 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <44D991B1-67A9-4291-9D9B-C32173266EA6@gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>
 <44D991B1-67A9-4291-9D9B-C32173266EA6@gmail.com>
Message-ID: <CAPeieQH6+x-5bGrSVceXst=J-7f1UzZ_jrnSn+4Q=aOWRdL1uw@mail.gmail.com>

I think that's a good idea. It was also suggested in a reddit thread
[0] a year ago, and it doesn't seem like that thread has any arguments
against it.

Erik

[0] http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/c6gvy0r

On Mon, Jan 13, 2014 at 8:03 PM, migmit <migmit at gmail.com> wrote:
> Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can
> break anything.
>
> ?????????? ? iPad
>
> 13 ???. 2014 ?., ? 22:54, Edward Kmett <ekmett at gmail.com> ???????(?):
>
> I have to admit, I rather like this suggestion.
>
> -Edward
>
>
> On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski
> <krz.gogolewski at gmail.com> wrote:
>>
>> Hello,
>>
>> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
>> default. Rationale:
>>
>> (1) This way holes are far easier to use; just entering "_" allows to
>> check type of a subexpression, no need of adding "-XTypeHoles".
>>
>> (2) This affects error messages only; i.e. the set of programs that
>> compile stays the same - Haskell 2010. The only exception is that if you use
>> -fdefer-type-errors, then a program with a hole compiles, but this seems
>> fine with philosophy of -fdefer-type-errors.
>>
>> If so: would you like it to be in 7.8 or wait a cycle? My preference is
>> 7.8, two people (John and Richard) suggested 7.10.
>>
>> -KG
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From carter.schonwald at gmail.com  Mon Jan 13 19:11:23 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 13 Jan 2014 14:11:23 -0500
Subject: Enabling TypeHoles by default
In-Reply-To: <CAPeieQH6+x-5bGrSVceXst=J-7f1UzZ_jrnSn+4Q=aOWRdL1uw@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>
 <44D991B1-67A9-4291-9D9B-C32173266EA6@gmail.com>
 <CAPeieQH6+x-5bGrSVceXst=J-7f1UzZ_jrnSn+4Q=aOWRdL1uw@mail.gmail.com>
Message-ID: <CAHYVw0zhbQ5Sw=cYB0VqsKgGWxLyUbCmeFs21jYPmiPVYVsTOA@mail.gmail.com>

+1. Will any freevariable be considered a type hole? Or just _blah and _ ?


On Mon, Jan 13, 2014 at 2:07 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> I think that's a good idea. It was also suggested in a reddit thread
> [0] a year ago, and it doesn't seem like that thread has any arguments
> against it.
>
> Erik
>
> [0]
> http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/c6gvy0r
>
> On Mon, Jan 13, 2014 at 8:03 PM, migmit <migmit at gmail.com> wrote:
> > Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it
> can
> > break anything.
> >
> > ?????????? ? iPad
> >
> > 13 ???. 2014 ?., ? 22:54, Edward Kmett <ekmett at gmail.com> ???????(?):
> >
> > I have to admit, I rather like this suggestion.
> >
> > -Edward
> >
> >
> > On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski
> > <krz.gogolewski at gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
> >> default. Rationale:
> >>
> >> (1) This way holes are far easier to use; just entering "_" allows to
> >> check type of a subexpression, no need of adding "-XTypeHoles".
> >>
> >> (2) This affects error messages only; i.e. the set of programs that
> >> compile stays the same - Haskell 2010. The only exception is that if
> you use
> >> -fdefer-type-errors, then a program with a hole compiles, but this seems
> >> fine with philosophy of -fdefer-type-errors.
> >>
> >> If so: would you like it to be in 7.8 or wait a cycle? My preference is
> >> 7.8, two people (John and Richard) suggested 7.10.
> >>
> >> -KG
> >>
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users at haskell.org
> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/ccba5366/attachment.html>

From krz.gogolewski at gmail.com  Mon Jan 13 19:18:04 2014
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Mon, 13 Jan 2014 20:18:04 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <CAHYVw0zhbQ5Sw=cYB0VqsKgGWxLyUbCmeFs21jYPmiPVYVsTOA@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <CAJumaK9YHBe4+3WjJDCJ0F4OQvefjXtgvDtos1Fdtw2KepGcMw@mail.gmail.com>
 <44D991B1-67A9-4291-9D9B-C32173266EA6@gmail.com>
 <CAPeieQH6+x-5bGrSVceXst=J-7f1UzZ_jrnSn+4Q=aOWRdL1uw@mail.gmail.com>
 <CAHYVw0zhbQ5Sw=cYB0VqsKgGWxLyUbCmeFs21jYPmiPVYVsTOA@mail.gmail.com>
Message-ID: <CA+h2LzknOcmYUGwNDbjJf72SRw974qz_SiVzRzwWd4ZzgsDJ0w@mail.gmail.com>

> Will any freevariable be considered a type hole? Or just _blah and _ ?
-XTypeHoles makes holes only out of _blah (where _blah is not in scope) and
_.


On Mon, Jan 13, 2014 at 8:11 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> +1. Will any freevariable be considered a type hole? Or just _blah and _ ?
>
>
> On Mon, Jan 13, 2014 at 2:07 PM, Erik Hesselink <hesselink at gmail.com>wrote:
>
>> I think that's a good idea. It was also suggested in a reddit thread
>> [0] a year ago, and it doesn't seem like that thread has any arguments
>> against it.
>>
>> Erik
>>
>> [0]
>> http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/c6gvy0r
>>
>> On Mon, Jan 13, 2014 at 8:03 PM, migmit <migmit at gmail.com> wrote:
>> > Agreed. Having it in 7.8 would be very nice, and yes, I don't see how
>> it can
>> > break anything.
>> >
>> > ?????????? ? iPad
>> >
>> > 13 ???. 2014 ?., ? 22:54, Edward Kmett <ekmett at gmail.com> ???????(?):
>> >
>> > I have to admit, I rather like this suggestion.
>> >
>> > -Edward
>> >
>> >
>> > On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski
>> > <krz.gogolewski at gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
>> >> default. Rationale:
>> >>
>> >> (1) This way holes are far easier to use; just entering "_" allows to
>> >> check type of a subexpression, no need of adding "-XTypeHoles".
>> >>
>> >> (2) This affects error messages only; i.e. the set of programs that
>> >> compile stays the same - Haskell 2010. The only exception is that if
>> you use
>> >> -fdefer-type-errors, then a program with a hole compiles, but this
>> seems
>> >> fine with philosophy of -fdefer-type-errors.
>> >>
>> >> If so: would you like it to be in 7.8 or wait a cycle? My preference is
>> >> 7.8, two people (John and Richard) suggested 7.10.
>> >>
>> >> -KG
>> >>
>> >> _______________________________________________
>> >> Glasgow-haskell-users mailing list
>> >> Glasgow-haskell-users at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> >>
>> >
>> > _______________________________________________
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users at haskell.org
>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> >
>> >
>> > _______________________________________________
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users at haskell.org
>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> >
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/e8694ef0/attachment.html>

From hallgren at chalmers.se  Mon Jan 13 20:18:14 2014
From: hallgren at chalmers.se (Thomas Hallgren)
Date: Mon, 13 Jan 2014 21:18:14 +0100
Subject: Problem with the object file name of the Main module.
In-Reply-To: <52D42EDB.6050508@gmail.com>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
 <52D42EDB.6050508@gmail.com>
Message-ID: <lb1hlq$8rp$1@ger.gmane.org>

The main module doesn't have to be called Main. You can specify a different name
with the -main-is option. That seems like the easiest way to avoid the object
file name clash.

By the way, this problem only seems to arise when the -odir flag is used. If my
Main module is in A.hs and I compile it with "ghc --make A.hs", I get "A.o",
"A.hi" and an executable file "A". (Tested with GHC 7.6.3.)

Thomas H

On 2014-01-13 19:22, Christian Brolin wrote:
> No. As a workaround I remove the Main.o file after the executable has been
> linked. It works, but it has its drawbacks.
> 
> On 2014-01-12 17:23, Carter Schonwald wrote:
>> Christian, have you tried using cabal? People write cabal files with multiple
>> executables being generated all the time.  
>>
>> On Sunday, January 12, 2014, Christian Brolin wrote:
>>
>>     H.
>>
>>     The documentation (version 7.6.3) section 7.7.2 Output files says that the
>>     source file name of the Main module does not have to be Main.hs making it
>>     "possible to have several Main modules in separate source files in the
>>     same directory". While this is true and promising it is seems to be
>>     unusable since GHC always compiles the main source file into an object
>>     file called Main.o.
>>
>>     _______________________________________________
>>     Glasgow-haskell-users mailing list
>>     Glasgow-haskell-users at haskell.org
>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> 
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 



From fuuzetsu at fuuzetsu.co.uk  Mon Jan 13 20:54:44 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 13 Jan 2014 20:54:44 +0000
Subject: Enabling TypeHoles by default
In-Reply-To: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
Message-ID: <52D45294.7070402@fuuzetsu.co.uk>

On 13/01/14 18:42, Krzysztof Gogolewski wrote:
> Hello,
> 
> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
> default. Rationale:
> 
> (1) This way holes are far easier to use; just entering "_" allows to check
> type of a subexpression, no need of adding "-XTypeHoles".
> 
> (2) This affects error messages only; i.e. the set of programs that compile
> stays the same - Haskell 2010. The only exception is that if you use
> -fdefer-type-errors, then a program with a hole compiles, but this seems
> fine with philosophy of -fdefer-type-errors.
> 
> If so: would you like it to be in 7.8 or wait a cycle? My preference is
> 7.8, two people (John and Richard) suggested 7.10.
> 
> -KG
> 

Sounds good. Are there plans to allow TypeHoles to actually sit in place
of types? In the past I did

```
data Hole

hole :: Hole
hole = undefined

foo :: Integer -> Integer
foo x = hole

bar :: Integer -> Hole
bar x y = x + y
```

to cause type errors that could guide me. I now don't have to resort to
the first use in ?foo? but I still have to define my own Hole type in ?bar?.


-- 
Mateusz K.

From difrumin at gmail.com  Mon Jan 13 21:30:05 2014
From: difrumin at gmail.com (Daniil Frumin)
Date: Tue, 14 Jan 2014 01:30:05 +0400
Subject: Enabling TypeHoles by default
In-Reply-To: <52D45294.7070402@fuuzetsu.co.uk>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
Message-ID: <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>

On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
to TypedHoles or to something similar, because "TypeHoles" sounds like
you can have holes in types, just like in your example.

But what error message do you want to get if you have a hole in your
type? GHC won't be able to tell you much

On Tue, Jan 14, 2014 at 12:54 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 13/01/14 18:42, Krzysztof Gogolewski wrote:
>> Hello,
>>
>> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
>> default. Rationale:
>>
>> (1) This way holes are far easier to use; just entering "_" allows to check
>> type of a subexpression, no need of adding "-XTypeHoles".
>>
>> (2) This affects error messages only; i.e. the set of programs that compile
>> stays the same - Haskell 2010. The only exception is that if you use
>> -fdefer-type-errors, then a program with a hole compiles, but this seems
>> fine with philosophy of -fdefer-type-errors.
>>
>> If so: would you like it to be in 7.8 or wait a cycle? My preference is
>> 7.8, two people (John and Richard) suggested 7.10.
>>
>> -KG
>>
>
> Sounds good. Are there plans to allow TypeHoles to actually sit in place
> of types? In the past I did
>
> ```
> data Hole
>
> hole :: Hole
> hole = undefined
>
> foo :: Integer -> Integer
> foo x = hole
>
> bar :: Integer -> Hole
> bar x y = x + y
> ```
>
> to cause type errors that could guide me. I now don't have to resort to
> the first use in ?foo? but I still have to define my own Hole type in ?bar?.
>
>
> --
> Mateusz K.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
Sincerely yours,
-- Daniil

From ekmett at gmail.com  Mon Jan 13 21:32:40 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 13 Jan 2014 16:32:40 -0500
Subject: Enabling TypeHoles by default
In-Reply-To: <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
Message-ID: <CAJumaK8i_87rTFXkr2mFT4R08=85tZEu1rS=T8bsmycuOC6_Gw@mail.gmail.com>

Heck if we wanted to bikeshed the name, even 'Holes' would do. ;)


On Mon, Jan 13, 2014 at 4:30 PM, Daniil Frumin <difrumin at gmail.com> wrote:

> On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
> to TypedHoles or to something similar, because "TypeHoles" sounds like
> you can have holes in types, just like in your example.
>
> But what error message do you want to get if you have a hole in your
> type? GHC won't be able to tell you much
>
> On Tue, Jan 14, 2014 at 12:54 AM, Mateusz Kowalczyk
> <fuuzetsu at fuuzetsu.co.uk> wrote:
> > On 13/01/14 18:42, Krzysztof Gogolewski wrote:
> >> Hello,
> >>
> >> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
> >> default. Rationale:
> >>
> >> (1) This way holes are far easier to use; just entering "_" allows to
> check
> >> type of a subexpression, no need of adding "-XTypeHoles".
> >>
> >> (2) This affects error messages only; i.e. the set of programs that
> compile
> >> stays the same - Haskell 2010. The only exception is that if you use
> >> -fdefer-type-errors, then a program with a hole compiles, but this seems
> >> fine with philosophy of -fdefer-type-errors.
> >>
> >> If so: would you like it to be in 7.8 or wait a cycle? My preference is
> >> 7.8, two people (John and Richard) suggested 7.10.
> >>
> >> -KG
> >>
> >
> > Sounds good. Are there plans to allow TypeHoles to actually sit in place
> > of types? In the past I did
> >
> > ```
> > data Hole
> >
> > hole :: Hole
> > hole = undefined
> >
> > foo :: Integer -> Integer
> > foo x = hole
> >
> > bar :: Integer -> Hole
> > bar x y = x + y
> > ```
> >
> > to cause type errors that could guide me. I now don't have to resort to
> > the first use in ?foo? but I still have to define my own Hole type in
> ?bar?.
> >
> >
> > --
> > Mateusz K.
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
> --
> Sincerely yours,
> -- Daniil
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/2c78b15f/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Mon Jan 13 21:45:07 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 13 Jan 2014 21:45:07 +0000
Subject: Enabling TypeHoles by default
In-Reply-To: <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>	<52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
Message-ID: <52D45E63.3080708@fuuzetsu.co.uk>

On 13/01/14 21:30, Daniil Frumin wrote:
> On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
> to TypedHoles or to something similar, because "TypeHoles" sounds like
> you can have holes in types, just like in your example.
> 
> But what error message do you want to get if you have a hole in your
> type? GHC won't be able to tell you much
> 

Indeed I have seen the ghc-devs post. Using Hole instead of stating a
type is useful for me to me for two things:

* Causing type errors for type of the expression, for example to
specialise part of the signature and see what GHC infers for the rest of it

* Easily checking types of the expressions I'm working on inside of the
function. Sometimes one might lose track of types inside a larger
expression and it is useful to cause a type error with a hole on one of
the sub-expressions to see where we're at. GHCi doesn't provide a way to
check type of subexpressions, only top-level definitions so this is
particularly useful.

While the second problem can be mitigated in simple situations where we
have a single symbol expression such as

foo :: Integer -> Integer
foo x y = x + _y

the ?_? does not work for larger expressions. For example, the following

foo :: Integer -> Integer
foo x y = x + _(y + 3)

does not work as it actually gets translated to

foo :: Integer -. Integer
foo x y = x + _ (y + 3)

and rather than get the type of (y + 3), we get the type of the function
which takes that expression. Close but not quite. With _ for types I
could do

x + (y + 3 :: _)

as opposed to

data Hole
x + (y + 3 :: Hole)

It'd be great if I could spare myself defining Hole *and* get all the
information about bindings that _ provides.

-- 
Mateusz K.

From cbrolin at gmail.com  Mon Jan 13 22:10:23 2014
From: cbrolin at gmail.com (Christian Brolin)
Date: Mon, 13 Jan 2014 23:10:23 +0100
Subject: Problem with the object file name of the Main module.
In-Reply-To: <CAHYVw0yORYjgcG3S+qt5PUVgOsY_cU9PwLPCrdz3xuAq4N6zUQ@mail.gmail.com>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
 <52D42EDB.6050508@gmail.com>
 <CAHYVw0yORYjgcG3S+qt5PUVgOsY_cU9PwLPCrdz3xuAq4N6zUQ@mail.gmail.com>
Message-ID: <52D4644F.20808@gmail.com>

Thanks, but it is not a complicated build process. Just a few simple 
programs that share some modules. I like to keep it simple.

On 2014-01-13 19:28, Carter Schonwald wrote:
> i warmly recommend you use cabal for any complicated build processes. 
> if you're stuck, holler and we or haskell-cafe are happy to help
>
>
> On Mon, Jan 13, 2014 at 1:22 PM, Christian Brolin <cbrolin at gmail.com 
> <mailto:cbrolin at gmail.com>> wrote:
>
>     No. As a workaround I remove the Main.o file after the executable
>     has been linked. It works, but it has its drawbacks.
>
>
>     On 2014-01-12 17:23, Carter Schonwald wrote:
>>     Christian, have you tried using cabal? People write cabal files
>>     with multiple executables being generated all the time.
>>
>>     On Sunday, January 12, 2014, Christian Brolin wrote:
>>
>>         H.
>>
>>         The documentation (version 7.6.3) section 7.7.2 Output files
>>         says that the source file name of the Main module does not
>>         have to be Main.hs making it "possible to have several Main
>>         modules in separate source files in the same directory".
>>         While this is true and promising it is seems to be unusable
>>         since GHC always compiles the main source file into an object
>>         file called Main.o.
>>
>>         _______________________________________________
>>         Glasgow-haskell-users mailing list
>>         Glasgow-haskell-users at haskell.org
>>         http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140113/a96d2839/attachment.html>

From cbrolin at gmail.com  Mon Jan 13 22:36:41 2014
From: cbrolin at gmail.com (Christian Brolin)
Date: Mon, 13 Jan 2014 23:36:41 +0100
Subject: Problem with the object file name of the Main module.
In-Reply-To: <lb1hlq$8rp$1@ger.gmane.org>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
 <52D42EDB.6050508@gmail.com> <lb1hlq$8rp$1@ger.gmane.org>
Message-ID: <52D46A79.7080309@gmail.com>

Thanks.

Strange feature!

Yes, I'm using -outputdir. It seems the -main-is MyProg is the best work 
around for me. But for it to work I also have to declare that MyProg is 
the name of the main module in the source (of course) which I otherwise 
don't have to. I also like to name my main modules with initial 
lowercase (myProg.hs) to get Unix sounded executables so my makefile has 
to adjust for this too.


On 2014-01-13 21:18, Thomas Hallgren wrote:
> The main module doesn't have to be called Main. You can specify a different name
> with the -main-is option. That seems like the easiest way to avoid the object
> file name clash.
>
> By the way, this problem only seems to arise when the -odir flag is used. If my
> Main module is in A.hs and I compile it with "ghc --make A.hs", I get "A.o",
> "A.hi" and an executable file "A". (Tested with GHC 7.6.3.)
>
> Thomas H
>
> On 2014-01-13 19:22, Christian Brolin wrote:
>> No. As a workaround I remove the Main.o file after the executable has been
>> linked. It works, but it has its drawbacks.
>>
>> On 2014-01-12 17:23, Carter Schonwald wrote:
>>> Christian, have you tried using cabal? People write cabal files with multiple
>>> executables being generated all the time.
>>>
>>> On Sunday, January 12, 2014, Christian Brolin wrote:
>>>
>>>      H.
>>>
>>>      The documentation (version 7.6.3) section 7.7.2 Output files says that the
>>>      source file name of the Main module does not have to be Main.hs making it
>>>      "possible to have several Main modules in separate source files in the
>>>      same directory". While this is true and promising it is seems to be
>>>      unusable since GHC always compiles the main source file into an object
>>>      file called Main.o.
>>>
>>>      _______________________________________________
>>>      Glasgow-haskell-users mailing list
>>>      Glasgow-haskell-users at haskell.org
>>>      http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From hesselink at gmail.com  Tue Jan 14 09:25:44 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 14 Jan 2014 10:25:44 +0100
Subject: Problem with the object file name of the Main module.
In-Reply-To: <52D4644F.20808@gmail.com>
References: <52D2A1B8.50103@gmail.com>
 <CAHYVw0yCFUeHOwyT0927H5OORu-0xYx0TTTSadMFo_3wiRNPPQ@mail.gmail.com>
 <52D42EDB.6050508@gmail.com>
 <CAHYVw0yORYjgcG3S+qt5PUVgOsY_cU9PwLPCrdz3xuAq4N6zUQ@mail.gmail.com>
 <52D4644F.20808@gmail.com>
Message-ID: <CAPeieQFPkqQ+0UmT=uqC8ZG4AA0KiWAH=KY-fJkCugGFAQ5_qw@mail.gmail.com>

I'd like to repeat the suggestion to use cabal. It's very well suited
for simple programs. In addition, you get the ability to specify
dependencies, you can upload to hackage, etc.

Erik

On Mon, Jan 13, 2014 at 11:10 PM, Christian Brolin <cbrolin at gmail.com> wrote:
> Thanks, but it is not a complicated build process. Just a few simple
> programs that share some modules. I like to keep it simple.
>
>
> On 2014-01-13 19:28, Carter Schonwald wrote:
>
> i warmly recommend you use cabal for any complicated build processes. if
> you're stuck, holler and we or haskell-cafe are happy to help
>
>
> On Mon, Jan 13, 2014 at 1:22 PM, Christian Brolin <cbrolin at gmail.com> wrote:
>>
>> No. As a workaround I remove the Main.o file after the executable has been
>> linked. It works, but it has its drawbacks.
>>
>>
>> On 2014-01-12 17:23, Carter Schonwald wrote:
>>
>> Christian, have you tried using cabal? People write cabal files with
>> multiple executables being generated all the time.
>>
>> On Sunday, January 12, 2014, Christian Brolin wrote:
>>>
>>> H.
>>>
>>> The documentation (version 7.6.3) section 7.7.2 Output files says that
>>> the source file name of the Main module does not have to be Main.hs making
>>> it "possible to have several Main modules in separate source files in the
>>> same directory". While this is true and promising it is seems to be unusable
>>> since GHC always compiles the main source file into an object file called
>>> Main.o.
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From merijn at inconsistent.nl  Tue Jan 14 13:56:24 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Tue, 14 Jan 2014 14:56:24 +0100
Subject: Feature request: Vacuous/error constraint (related to 7.7 closed type
 families regression)
Message-ID: <50F879EA-C3D6-48AB-8B26-74953A829F8F@inconsistent.nl>

I was trying to fix one of my closed type families examples for the new syntax, and run into an unfortunate issue. Due to a kind error in my code one of my constraints was being silently discarded (see ticket: https://ghc.haskell.org/trac/ghc/ticket/8669)

The main reason I resorted to this (in hindsight) ill-kinded hack is the lack of a vacuous (i.e. never holding) constraint to produce type errors. I would love to be able to explicitly force GHC into realising "this constraint can never hold", if I had the ability to pass along a String/Symbol to be reported to the user, that would be even better.

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140114/e19711e9/attachment.sig>

From hesselink at gmail.com  Tue Jan 14 14:13:34 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 14 Jan 2014 15:13:34 +0100
Subject: Feature request: Vacuous/error constraint (related to 7.7 closed
 type families regression)
In-Reply-To: <50F879EA-C3D6-48AB-8B26-74953A829F8F@inconsistent.nl>
References: <50F879EA-C3D6-48AB-8B26-74953A829F8F@inconsistent.nl>
Message-ID: <CAPeieQEu2xQ4c6_Bdrwqrzt31K-9HO7p7DcJpc0H2ibs8bp1Xw@mail.gmail.com>

You can of course produce an infinite set of vacuous constraints using
the Symbol type (or any two non-equal types). For example, here you
could use:

    Restrict a (a ': as) = ("Error" ~ "Oops! Tried to apply a restricted type!")

Erik

On Tue, Jan 14, 2014 at 2:56 PM, Merijn Verstraaten
<merijn at inconsistent.nl> wrote:
> I was trying to fix one of my closed type families examples for the new syntax, and run into an unfortunate issue. Due to a kind error in my code one of my constraints was being silently discarded (see ticket: https://ghc.haskell.org/trac/ghc/ticket/8669)
>
> The main reason I resorted to this (in hindsight) ill-kinded hack is the lack of a vacuous (i.e. never holding) constraint to produce type errors. I would love to be able to explicitly force GHC into realising "this constraint can never hold", if I had the ability to pass along a String/Symbol to be reported to the user, that would be even better.
>
> Cheers,
> Merijn
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From vogt.adam at gmail.com  Tue Jan 14 15:36:37 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Tue, 14 Jan 2014 10:36:37 -0500
Subject: Feature request: Vacuous/error constraint (related to 7.7 closed
 type families regression)
In-Reply-To: <50F879EA-C3D6-48AB-8B26-74953A829F8F@inconsistent.nl>
References: <50F879EA-C3D6-48AB-8B26-74953A829F8F@inconsistent.nl>
Message-ID: <CAHfjoWkxJKibm_ZceDLhs=O+uuKO9xpB9o32KEgGpqSX2WEuSQ@mail.gmail.com>

Hi Merijn,

Let me suggest the Fail type family in
http://www.haskell.org/pipermail/haskell-cafe/2013-November/111549.html

--
Adam

On Tue, Jan 14, 2014 at 8:56 AM, Merijn Verstraaten
<merijn at inconsistent.nl> wrote:
> I was trying to fix one of my closed type families examples for the new syntax, and run into an unfortunate issue. Due to a kind error in my code one of my constraints was being silently discarded (see ticket: https://ghc.haskell.org/trac/ghc/ticket/8669)
>
> The main reason I resorted to this (in hindsight) ill-kinded hack is the lack of a vacuous (i.e. never holding) constraint to produce type errors. I would love to be able to explicitly force GHC into realising "this constraint can never hold", if I had the ability to pass along a String/Symbol to be reported to the user, that would be even better.
>
> Cheers,
> Merijn
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From austin at well-typed.com  Tue Jan 14 16:07:35 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 10:07:35 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <52D45E63.3080708@fuuzetsu.co.uk>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
Message-ID: <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>

Hi all,

As a follow up to these, Simon and I discussed it in a call today, and
we're actually both in favor of enabling TypeHoles by default. The
reasoning is as stated: it provides more useful error messages and
doesn't cause any programs to fail to work. It's strictly a
development aide when you have errors.

We probably won't change the name right now however. It's already been
put into Cabal (as a recognized extension,) so the name has propagated
a slight bit. We can however give it a new name and deprecate the old
-XTypeHoles in the future. Or, we could change it, but I'm afraid it's
probably a bit too late in the cycle for other devs to change.

Unless anyone has any major objections, I'll probably implement this
(as Krzysztof suggested in ghc-devs@) later today/tomorrow for the 7.8
branch.

On Mon, Jan 13, 2014 at 3:45 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 13/01/14 21:30, Daniil Frumin wrote:
>> On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
>> to TypedHoles or to something similar, because "TypeHoles" sounds like
>> you can have holes in types, just like in your example.
>>
>> But what error message do you want to get if you have a hole in your
>> type? GHC won't be able to tell you much
>>
>
> Indeed I have seen the ghc-devs post. Using Hole instead of stating a
> type is useful for me to me for two things:
>
> * Causing type errors for type of the expression, for example to
> specialise part of the signature and see what GHC infers for the rest of it
>
> * Easily checking types of the expressions I'm working on inside of the
> function. Sometimes one might lose track of types inside a larger
> expression and it is useful to cause a type error with a hole on one of
> the sub-expressions to see where we're at. GHCi doesn't provide a way to
> check type of subexpressions, only top-level definitions so this is
> particularly useful.
>
> While the second problem can be mitigated in simple situations where we
> have a single symbol expression such as
>
> foo :: Integer -> Integer
> foo x y = x + _y
>
> the ?_? does not work for larger expressions. For example, the following
>
> foo :: Integer -> Integer
> foo x y = x + _(y + 3)
>
> does not work as it actually gets translated to
>
> foo :: Integer -. Integer
> foo x y = x + _ (y + 3)
>
> and rather than get the type of (y + 3), we get the type of the function
> which takes that expression. Close but not quite. With _ for types I
> could do
>
> x + (y + 3 :: _)
>
> as opposed to
>
> data Hole
> x + (y + 3 :: Hole)
>
> It'd be great if I could spare myself defining Hole *and* get all the
> information about bindings that _ provides.
>
> --
> Mateusz K.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From dluposchainsky at googlemail.com  Tue Jan 14 16:14:51 2014
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 14 Jan 2014 17:14:51 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
Message-ID: <52D5627B.4080706@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.01.2014 17:07, Austin Seipp wrote:
> We probably won't change the name right now however. It's already
> been put into Cabal (as a recognized extension,) so the name has
> propagated a slight bit. We can however give it a new name and
> deprecate the old -XTypeHoles in the future. Or, we could change
> it, but I'm afraid it's probably a bit too late in the cycle for
> other devs to change.

Removing a name later on is more time-consuming, with or without
deprecation. People get used to the "wrong" name and stop caring, but
I can already picture the "type holes are really typed holes"
discussions on IRC. I'm strongly in favour of introducing the new name
(and the deprecation for the synonym) as early as possible. This
change should not be very extensive anyway, so why not slip it in?

Greetings,
David/quchen

PS: +1 in general of course
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS1WJ7AAoJELrQsaT5WQUsoeQH/0vSEnyYLcAPk36sBaxf9EMb
CNZM84lfnP1cgx9r0joM07iW6eA71kOnuAo0JzEOfJWJygkpoARpIJsmD0cvZdHX
jibIXoiP2i50IYyMlHIoxsfQ5E4WgIsQuGQ200L5DgZuWWcgP7dk0f/AqnBeY8Mw
RWd60Y5vpAOqNy2l5pw869KfVMOECKi+N2eD2UyUhbBrvs93QnCpeVrSpPNRjaoG
Z7Z+rRyEGNDqoX88goOzBoxtmG/Ua6wuE6wq/bkmubCI5JE/kT+0upKeB3BfKOd1
kN72gbtAVJ+MumxAkncCk582QmcirlrbqS1ewL4xxRIEgdIqBlmTNyy6NGxB2vM=
=16TU
-----END PGP SIGNATURE-----

From hvr at gnu.org  Tue Jan 14 16:27:35 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 14 Jan 2014 17:27:35 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <52D5627B.4080706@gmail.com> (David Luposchainsky's message of
 "Tue, 14 Jan 2014 17:14:51 +0100")
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com>
Message-ID: <87eh4a1qbs.fsf@gnu.org>

Hi,

On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> On 14.01.2014 17:07, Austin Seipp wrote:
>> We probably won't change the name right now however. It's already
>> been put into Cabal (as a recognized extension,) so the name has
>> propagated a slight bit. We can however give it a new name and
>> deprecate the old -XTypeHoles in the future. Or, we could change
>> it, but I'm afraid it's probably a bit too late in the cycle for
>> other devs to change.
>
> Removing a name later on is more time-consuming, with or without
> deprecation. People get used to the "wrong" name and stop caring, but
> I can already picture the "type holes are really typed holes"
> discussions on IRC. I'm strongly in favour of introducing the new name
> (and the deprecation for the synonym) as early as possible. This
> change should not be very extensive anyway, so why not slip it in?

Well, as Austin hinted at, this would also require a Cabal-1.18.x
release in time for the final 7.8, and a recompile of Hackage to pick it
up so that people can start using the new 'TypedHoles' token in their
.cabal files... so there's a bit of coordination required to make this
happen in a timely manner... Or put differently, somebody has to care
enough to invest some time and pull this through :-)

Cheers,
  hvr

From austin at well-typed.com  Tue Jan 14 16:33:48 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 10:33:48 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <87eh4a1qbs.fsf@gnu.org>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
Message-ID: <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>

At the very least, Type(d)Holes would never appear explicitly since it
would be enabled by default. But it might be turned off (but I don't
know who would do that for the most part.) Cabal at least might still
need an update.

In any case, Herbert basically summed it up: the time window is kind
of close, and we would need to re-release/redeploy a few things most
likely. I really think it mostly depends on the Cabal team and what
their priorities are. I've CC'd Duncan and Johan for their opinions.

On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> Hi,
>
> On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>> On 14.01.2014 17:07, Austin Seipp wrote:
>>> We probably won't change the name right now however. It's already
>>> been put into Cabal (as a recognized extension,) so the name has
>>> propagated a slight bit. We can however give it a new name and
>>> deprecate the old -XTypeHoles in the future. Or, we could change
>>> it, but I'm afraid it's probably a bit too late in the cycle for
>>> other devs to change.
>>
>> Removing a name later on is more time-consuming, with or without
>> deprecation. People get used to the "wrong" name and stop caring, but
>> I can already picture the "type holes are really typed holes"
>> discussions on IRC. I'm strongly in favour of introducing the new name
>> (and the deprecation for the synonym) as early as possible. This
>> change should not be very extensive anyway, so why not slip it in?
>
> Well, as Austin hinted at, this would also require a Cabal-1.18.x
> release in time for the final 7.8, and a recompile of Hackage to pick it
> up so that people can start using the new 'TypedHoles' token in their
> .cabal files... so there's a bit of coordination required to make this
> happen in a timely manner... Or put differently, somebody has to care
> enough to invest some time and pull this through :-)
>
> Cheers,
>   hvr
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eir at cis.upenn.edu  Tue Jan 14 16:40:27 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 14 Jan 2014 11:40:27 -0500
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
Message-ID: <888AC9BD-3135-401D-9FCC-5BB858E104B6@cis.upenn.edu>

Perhaps I'm being silly, but if the extended errors are enabled by default, and they seem to cause no problems, does the feature even need a name? The release notes could say something like "extended type information is produced for out-of-scope variables beginning with an underscore" or similar. Is it very important that users can specify -XNoTypeHoles?

Richard

On Jan 14, 2014, at 11:33 AM, Austin Seipp <austin at well-typed.com> wrote:

> At the very least, Type(d)Holes would never appear explicitly since it
> would be enabled by default. But it might be turned off (but I don't
> know who would do that for the most part.) Cabal at least might still
> need an update.
> 
> In any case, Herbert basically summed it up: the time window is kind
> of close, and we would need to re-release/redeploy a few things most
> likely. I really think it mostly depends on the Cabal team and what
> their priorities are. I've CC'd Duncan and Johan for their opinions.
> 
> On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>> Hi,
>> 
>> On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>>> On 14.01.2014 17:07, Austin Seipp wrote:
>>>> We probably won't change the name right now however. It's already
>>>> been put into Cabal (as a recognized extension,) so the name has
>>>> propagated a slight bit. We can however give it a new name and
>>>> deprecate the old -XTypeHoles in the future. Or, we could change
>>>> it, but I'm afraid it's probably a bit too late in the cycle for
>>>> other devs to change.
>>> 
>>> Removing a name later on is more time-consuming, with or without
>>> deprecation. People get used to the "wrong" name and stop caring, but
>>> I can already picture the "type holes are really typed holes"
>>> discussions on IRC. I'm strongly in favour of introducing the new name
>>> (and the deprecation for the synonym) as early as possible. This
>>> change should not be very extensive anyway, so why not slip it in?
>> 
>> Well, as Austin hinted at, this would also require a Cabal-1.18.x
>> release in time for the final 7.8, and a recompile of Hackage to pick it
>> up so that people can start using the new 'TypedHoles' token in their
>> .cabal files... so there's a bit of coordination required to make this
>> happen in a timely manner... Or put differently, somebody has to care
>> enough to invest some time and pull this through :-)
>> 
>> Cheers,
>>  hvr
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From johan.tibell at gmail.com  Tue Jan 14 16:44:35 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 14 Jan 2014 17:44:35 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
Message-ID: <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>

I can make another cabal release if needed, if someone submits a pull
request with the right fix (i.e. add TypedHoles with TypeHoles as a
synonym.)


On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com> wrote:

> At the very least, Type(d)Holes would never appear explicitly since it
> would be enabled by default. But it might be turned off (but I don't
> know who would do that for the most part.) Cabal at least might still
> need an update.
>
> In any case, Herbert basically summed it up: the time window is kind
> of close, and we would need to re-release/redeploy a few things most
> likely. I really think it mostly depends on the Cabal team and what
> their priorities are. I've CC'd Duncan and Johan for their opinions.
>
> On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
> > Hi,
> >
> > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> >> On 14.01.2014 17:07, Austin Seipp wrote:
> >>> We probably won't change the name right now however. It's already
> >>> been put into Cabal (as a recognized extension,) so the name has
> >>> propagated a slight bit. We can however give it a new name and
> >>> deprecate the old -XTypeHoles in the future. Or, we could change
> >>> it, but I'm afraid it's probably a bit too late in the cycle for
> >>> other devs to change.
> >>
> >> Removing a name later on is more time-consuming, with or without
> >> deprecation. People get used to the "wrong" name and stop caring, but
> >> I can already picture the "type holes are really typed holes"
> >> discussions on IRC. I'm strongly in favour of introducing the new name
> >> (and the deprecation for the synonym) as early as possible. This
> >> change should not be very extensive anyway, so why not slip it in?
> >
> > Well, as Austin hinted at, this would also require a Cabal-1.18.x
> > release in time for the final 7.8, and a recompile of Hackage to pick it
> > up so that people can start using the new 'TypedHoles' token in their
> > .cabal files... so there's a bit of coordination required to make this
> > happen in a timely manner... Or put differently, somebody has to care
> > enough to invest some time and pull this through :-)
> >
> > Cheers,
> >   hvr
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140114/3cdeffa0/attachment.html>

From duncan at well-typed.com  Tue Jan 14 16:54:49 2014
From: duncan at well-typed.com (Duncan Coutts)
Date: Tue, 14 Jan 2014 16:54:49 +0000
Subject: Enabling TypeHoles by default
In-Reply-To: <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
Message-ID: <1389718489.16190.100.camel@dunky.localdomain>

On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
> I can make another cabal release if needed, if someone submits a pull
> request with the right fix (i.e. add TypedHoles with TypeHoles as a
> synonym.)

Thanks Johan, or I'm happy to do it.

Duncan

> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com> wrote:
> 
> > At the very least, Type(d)Holes would never appear explicitly since it
> > would be enabled by default. But it might be turned off (but I don't
> > know who would do that for the most part.) Cabal at least might still
> > need an update.
> >
> > In any case, Herbert basically summed it up: the time window is kind
> > of close, and we would need to re-release/redeploy a few things most
> > likely. I really think it mostly depends on the Cabal team and what
> > their priorities are. I've CC'd Duncan and Johan for their opinions.
> >
> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org>
> > wrote:
> > > Hi,
> > >
> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> > >> On 14.01.2014 17:07, Austin Seipp wrote:
> > >>> We probably won't change the name right now however. It's already
> > >>> been put into Cabal (as a recognized extension,) so the name has
> > >>> propagated a slight bit. We can however give it a new name and
> > >>> deprecate the old -XTypeHoles in the future. Or, we could change
> > >>> it, but I'm afraid it's probably a bit too late in the cycle for
> > >>> other devs to change.
> > >>
> > >> Removing a name later on is more time-consuming, with or without
> > >> deprecation. People get used to the "wrong" name and stop caring, but
> > >> I can already picture the "type holes are really typed holes"
> > >> discussions on IRC. I'm strongly in favour of introducing the new name
> > >> (and the deprecation for the synonym) as early as possible. This
> > >> change should not be very extensive anyway, so why not slip it in?
> > >
> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
> > > release in time for the final 7.8, and a recompile of Hackage to pick it
> > > up so that people can start using the new 'TypedHoles' token in their
> > > .cabal files... so there's a bit of coordination required to make this
> > > happen in a timely manner... Or put differently, somebody has to care
> > > enough to invest some time and pull this through :-)
> > >
> > > Cheers,
> > >   hvr
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> >


-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


From austin at well-typed.com  Tue Jan 14 17:12:53 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 11:12:53 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <1389718489.16190.100.camel@dunky.localdomain>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
Message-ID: <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>

I'm actually more in favor of Richard's proposal of just removing the
flag to be honest, now that he mentioned it. And it's not like it's
much more code.

In any case, as Duncan informed me we'll have a Cabal release anyway,
so I'll work on sorting this out and enabling it.

On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com> wrote:
> On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
>> I can make another cabal release if needed, if someone submits a pull
>> request with the right fix (i.e. add TypedHoles with TypeHoles as a
>> synonym.)
>
> Thanks Johan, or I'm happy to do it.
>
> Duncan
>
>> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com> wrote:
>>
>> > At the very least, Type(d)Holes would never appear explicitly since it
>> > would be enabled by default. But it might be turned off (but I don't
>> > know who would do that for the most part.) Cabal at least might still
>> > need an update.
>> >
>> > In any case, Herbert basically summed it up: the time window is kind
>> > of close, and we would need to re-release/redeploy a few things most
>> > likely. I really think it mostly depends on the Cabal team and what
>> > their priorities are. I've CC'd Duncan and Johan for their opinions.
>> >
>> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org>
>> > wrote:
>> > > Hi,
>> > >
>> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>> > >> On 14.01.2014 17:07, Austin Seipp wrote:
>> > >>> We probably won't change the name right now however. It's already
>> > >>> been put into Cabal (as a recognized extension,) so the name has
>> > >>> propagated a slight bit. We can however give it a new name and
>> > >>> deprecate the old -XTypeHoles in the future. Or, we could change
>> > >>> it, but I'm afraid it's probably a bit too late in the cycle for
>> > >>> other devs to change.
>> > >>
>> > >> Removing a name later on is more time-consuming, with or without
>> > >> deprecation. People get used to the "wrong" name and stop caring, but
>> > >> I can already picture the "type holes are really typed holes"
>> > >> discussions on IRC. I'm strongly in favour of introducing the new name
>> > >> (and the deprecation for the synonym) as early as possible. This
>> > >> change should not be very extensive anyway, so why not slip it in?
>> > >
>> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
>> > > release in time for the final 7.8, and a recompile of Hackage to pick it
>> > > up so that people can start using the new 'TypedHoles' token in their
>> > > .cabal files... so there's a bit of coordination required to make this
>> > > happen in a timely manner... Or put differently, somebody has to care
>> > > enough to invest some time and pull this through :-)
>> > >
>> > > Cheers,
>> > >   hvr
>> > >
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Austin Seipp, Haskell Consultant
>> > Well-Typed LLP, http://www.well-typed.com/
>> >
>
>
> --
> Duncan Coutts, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Tue Jan 14 17:23:34 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Jan 2014 17:23:34 +0000
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
Message-ID: <1389720214.2465.26.camel@kirk>

Hi,

heh, I wanted to throw in the same argument: If its just more elaborate
error messages, why do we need a flag for it? So count that as +1 from
me.

Greetings,
Joachim


Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
> I'm actually more in favor of Richard's proposal of just removing the
> flag to be honest, now that he mentioned it. And it's not like it's
> much more code.
> 
> In any case, as Duncan informed me we'll have a Cabal release anyway,
> so I'll work on sorting this out and enabling it.
> 
> On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com> wrote:
> > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
> >> I can make another cabal release if needed, if someone submits a pull
> >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
> >> synonym.)
> >
> > Thanks Johan, or I'm happy to do it.
> >
> > Duncan
> >
> >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com> wrote:
> >>
> >> > At the very least, Type(d)Holes would never appear explicitly since it
> >> > would be enabled by default. But it might be turned off (but I don't
> >> > know who would do that for the most part.) Cabal at least might still
> >> > need an update.
> >> >
> >> > In any case, Herbert basically summed it up: the time window is kind
> >> > of close, and we would need to re-release/redeploy a few things most
> >> > likely. I really think it mostly depends on the Cabal team and what
> >> > their priorities are. I've CC'd Duncan and Johan for their opinions.
> >> >
> >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <hvr at gnu.org>
> >> > wrote:
> >> > > Hi,
> >> > >
> >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
> >> > >>> We probably won't change the name right now however. It's already
> >> > >>> been put into Cabal (as a recognized extension,) so the name has
> >> > >>> propagated a slight bit. We can however give it a new name and
> >> > >>> deprecate the old -XTypeHoles in the future. Or, we could change
> >> > >>> it, but I'm afraid it's probably a bit too late in the cycle for
> >> > >>> other devs to change.
> >> > >>
> >> > >> Removing a name later on is more time-consuming, with or without
> >> > >> deprecation. People get used to the "wrong" name and stop caring, but
> >> > >> I can already picture the "type holes are really typed holes"
> >> > >> discussions on IRC. I'm strongly in favour of introducing the new name
> >> > >> (and the deprecation for the synonym) as early as possible. This
> >> > >> change should not be very extensive anyway, so why not slip it in?
> >> > >
> >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
> >> > > release in time for the final 7.8, and a recompile of Hackage to pick it
> >> > > up so that people can start using the new 'TypedHoles' token in their
> >> > > .cabal files... so there's a bit of coordination required to make this
> >> > > happen in a timely manner... Or put differently, somebody has to care
> >> > > enough to invest some time and pull this through :-)
> >> > >
> >> > > Cheers,
> >> > >   hvr
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> >
> >> > Austin Seipp, Haskell Consultant
> >> > Well-Typed LLP, http://www.well-typed.com/
> >> >
> >
> >
> > --
> > Duncan Coutts, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> >
> >
> 
> 
> 

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140114/3b0789f3/attachment.sig>

From johan.tibell at gmail.com  Tue Jan 14 18:04:49 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 14 Jan 2014 19:04:49 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <1389720214.2465.26.camel@kirk>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
Message-ID: <CAK-tuPbZ+KgExMLweJoaMw=DWjVMhETp1V_WoTZgo+FOrgxsbw@mail.gmail.com>

Stupid question: is it really only better error messages? What about being
allowed to use _ on the RHS?


On Tue, Jan 14, 2014 at 6:23 PM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Hi,
>
> heh, I wanted to throw in the same argument: If its just more elaborate
> error messages, why do we need a flag for it? So count that as +1 from
> me.
>
> Greetings,
> Joachim
>
>
> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
> > I'm actually more in favor of Richard's proposal of just removing the
> > flag to be honest, now that he mentioned it. And it's not like it's
> > much more code.
> >
> > In any case, as Duncan informed me we'll have a Cabal release anyway,
> > so I'll work on sorting this out and enabling it.
> >
> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com>
> wrote:
> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
> > >> I can make another cabal release if needed, if someone submits a pull
> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
> > >> synonym.)
> > >
> > > Thanks Johan, or I'm happy to do it.
> > >
> > > Duncan
> > >
> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com>
> wrote:
> > >>
> > >> > At the very least, Type(d)Holes would never appear explicitly since
> it
> > >> > would be enabled by default. But it might be turned off (but I don't
> > >> > know who would do that for the most part.) Cabal at least might
> still
> > >> > need an update.
> > >> >
> > >> > In any case, Herbert basically summed it up: the time window is kind
> > >> > of close, and we would need to re-release/redeploy a few things most
> > >> > likely. I really think it mostly depends on the Cabal team and what
> > >> > their priorities are. I've CC'd Duncan and Johan for their opinions.
> > >> >
> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <
> hvr at gnu.org>
> > >> > wrote:
> > >> > > Hi,
> > >> > >
> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
> > >> > >>> We probably won't change the name right now however. It's
> already
> > >> > >>> been put into Cabal (as a recognized extension,) so the name has
> > >> > >>> propagated a slight bit. We can however give it a new name and
> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could change
> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle for
> > >> > >>> other devs to change.
> > >> > >>
> > >> > >> Removing a name later on is more time-consuming, with or without
> > >> > >> deprecation. People get used to the "wrong" name and stop
> caring, but
> > >> > >> I can already picture the "type holes are really typed holes"
> > >> > >> discussions on IRC. I'm strongly in favour of introducing the
> new name
> > >> > >> (and the deprecation for the synonym) as early as possible. This
> > >> > >> change should not be very extensive anyway, so why not slip it
> in?
> > >> > >
> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
> > >> > > release in time for the final 7.8, and a recompile of Hackage to
> pick it
> > >> > > up so that people can start using the new 'TypedHoles' token in
> their
> > >> > > .cabal files... so there's a bit of coordination required to make
> this
> > >> > > happen in a timely manner... Or put differently, somebody has to
> care
> > >> > > enough to invest some time and pull this through :-)
> > >> > >
> > >> > > Cheers,
> > >> > >   hvr
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Regards,
> > >> >
> > >> > Austin Seipp, Haskell Consultant
> > >> > Well-Typed LLP, http://www.well-typed.com/
> > >> >
> > >
> > >
> > > --
> > > Duncan Coutts, Haskell Consultant
> > > Well-Typed LLP, http://www.well-typed.com/
> > >
> > >
> >
> >
> >
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140114/6d4d4df7/attachment-0001.html>

From austin at well-typed.com  Tue Jan 14 18:14:26 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 12:14:26 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <CAK-tuPbZ+KgExMLweJoaMw=DWjVMhETp1V_WoTZgo+FOrgxsbw@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
 <CAK-tuPbZ+KgExMLweJoaMw=DWjVMhETp1V_WoTZgo+FOrgxsbw@mail.gmail.com>
Message-ID: <CAEs96n35ReKVkds=5unoFm7azK+r7tqjMhK3dMGr-bjiqgLjcw@mail.gmail.com>

The program is still rejected with an error if _ occurs on the RHS,
it's just a matter of what the compiler says in this specific case.

$ cat test.hs
module Main (main) where

test :: a -> a
test a = _

main = print $ test (10 :: Int)

$ ./inplace/bin/ghc-stage2 test.hs
[1 of 1] Compiling Main             ( test.hs, test.o )

test.hs:4:10: Pattern syntax in expression context: _
$ ./inplace/bin/ghc-stage2 test.hs -XTypeHoles
[1 of 1] Compiling Main             ( test.hs, test.o )

test.hs:4:10:
    Found hole ?_? with type: a
    Where: ?a? is a rigid type variable bound by
               the type signature for test :: a -> a at test.hs:3:9
    Relevant bindings include
      a :: a (bound at test.hs:4:6)
      test :: a -> a (bound at test.hs:4:1)
    In the expression: _
    In an equation for ?test?: test a = _

Named holes only occur when the name on the RHS is unbound and
prefixed with _, as opposed to giving an undeclared identifier error.

As Krzysztof mentioned originally, I find the first case to be pretty
unlikely to occur regularly, even for newbies since wildcard patterns
are 'de facto' on the LHS. Although perhaps it's an odd exception.

If it's turned into a 'warning', my idea was just to turn -XTypeHoles
to -Wtype-holes and turn it on by default, so this can be switched
off.

On Tue, Jan 14, 2014 at 12:04 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Stupid question: is it really only better error messages? What about being
> allowed to use _ on the RHS?
>
>
> On Tue, Jan 14, 2014 at 6:23 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>>
>> Hi,
>>
>> heh, I wanted to throw in the same argument: If its just more elaborate
>> error messages, why do we need a flag for it? So count that as +1 from
>> me.
>>
>> Greetings,
>> Joachim
>>
>>
>> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
>> > I'm actually more in favor of Richard's proposal of just removing the
>> > flag to be honest, now that he mentioned it. And it's not like it's
>> > much more code.
>> >
>> > In any case, as Duncan informed me we'll have a Cabal release anyway,
>> > so I'll work on sorting this out and enabling it.
>> >
>> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com>
>> > wrote:
>> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
>> > >> I can make another cabal release if needed, if someone submits a pull
>> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
>> > >> synonym.)
>> > >
>> > > Thanks Johan, or I'm happy to do it.
>> > >
>> > > Duncan
>> > >
>> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com>
>> > >> wrote:
>> > >>
>> > >> > At the very least, Type(d)Holes would never appear explicitly since
>> > >> > it
>> > >> > would be enabled by default. But it might be turned off (but I
>> > >> > don't
>> > >> > know who would do that for the most part.) Cabal at least might
>> > >> > still
>> > >> > need an update.
>> > >> >
>> > >> > In any case, Herbert basically summed it up: the time window is
>> > >> > kind
>> > >> > of close, and we would need to re-release/redeploy a few things
>> > >> > most
>> > >> > likely. I really think it mostly depends on the Cabal team and what
>> > >> > their priorities are. I've CC'd Duncan and Johan for their
>> > >> > opinions.
>> > >> >
>> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel
>> > >> > <hvr at gnu.org>
>> > >> > wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
>> > >> > >>> We probably won't change the name right now however. It's
>> > >> > >>> already
>> > >> > >>> been put into Cabal (as a recognized extension,) so the name
>> > >> > >>> has
>> > >> > >>> propagated a slight bit. We can however give it a new name and
>> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could
>> > >> > >>> change
>> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle
>> > >> > >>> for
>> > >> > >>> other devs to change.
>> > >> > >>
>> > >> > >> Removing a name later on is more time-consuming, with or without
>> > >> > >> deprecation. People get used to the "wrong" name and stop
>> > >> > >> caring, but
>> > >> > >> I can already picture the "type holes are really typed holes"
>> > >> > >> discussions on IRC. I'm strongly in favour of introducing the
>> > >> > >> new name
>> > >> > >> (and the deprecation for the synonym) as early as possible. This
>> > >> > >> change should not be very extensive anyway, so why not slip it
>> > >> > >> in?
>> > >> > >
>> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
>> > >> > > release in time for the final 7.8, and a recompile of Hackage to
>> > >> > > pick it
>> > >> > > up so that people can start using the new 'TypedHoles' token in
>> > >> > > their
>> > >> > > .cabal files... so there's a bit of coordination required to make
>> > >> > > this
>> > >> > > happen in a timely manner... Or put differently, somebody has to
>> > >> > > care
>> > >> > > enough to invest some time and pull this through :-)
>> > >> > >
>> > >> > > Cheers,
>> > >> > >   hvr
>> > >> > >
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Regards,
>> > >> >
>> > >> > Austin Seipp, Haskell Consultant
>> > >> > Well-Typed LLP, http://www.well-typed.com/
>> > >> >
>> > >
>> > >
>> > > --
>> > > Duncan Coutts, Haskell Consultant
>> > > Well-Typed LLP, http://www.well-typed.com/
>> > >
>> > >
>> >
>> >
>> >
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Tue Jan 14 18:17:15 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 12:17:15 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n35ReKVkds=5unoFm7azK+r7tqjMhK3dMGr-bjiqgLjcw@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
 <CAK-tuPbZ+KgExMLweJoaMw=DWjVMhETp1V_WoTZgo+FOrgxsbw@mail.gmail.com>
 <CAEs96n35ReKVkds=5unoFm7azK+r7tqjMhK3dMGr-bjiqgLjcw@mail.gmail.com>
Message-ID: <CAEs96n23YoCtb-cRuNxZMRxYnd7JiWqCCODu46bJmx1UOXAeUw@mail.gmail.com>

On Tue, Jan 14, 2014 at 12:14 PM, Austin Seipp <austin at well-typed.com> wrote:
> If it's turned into a 'warning', my idea was just to turn -XTypeHoles
> to -Wtype-holes and turn it on by default, so this can be switched
> off.

... which, I might add, is rather the same for *all* warnings, so it's
really more of a bikeshed of a slightly different color than anything.
:)

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From ekmett at gmail.com  Tue Jan 14 19:00:41 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 14 Jan 2014 14:00:41 -0500
Subject: Enabling TypeHoles by default
In-Reply-To: <1389720214.2465.26.camel@kirk>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
Message-ID: <CAJumaK_BrHcaKr1rSPZKOgPRrfa4CUXqwNUvcXDtdYtQnedrww@mail.gmail.com>

It actually can affect what code compiles with -fdefer-type-errors, but I
don't feel terribly strongly about that.

-Edward




On Tue, Jan 14, 2014 at 12:23 PM, Joachim Breitner <mail at joachim-breitner.de
> wrote:

> Hi,
>
> heh, I wanted to throw in the same argument: If its just more elaborate
> error messages, why do we need a flag for it? So count that as +1 from
> me.
>
> Greetings,
> Joachim
>
>
> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
> > I'm actually more in favor of Richard's proposal of just removing the
> > flag to be honest, now that he mentioned it. And it's not like it's
> > much more code.
> >
> > In any case, as Duncan informed me we'll have a Cabal release anyway,
> > so I'll work on sorting this out and enabling it.
> >
> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com>
> wrote:
> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
> > >> I can make another cabal release if needed, if someone submits a pull
> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
> > >> synonym.)
> > >
> > > Thanks Johan, or I'm happy to do it.
> > >
> > > Duncan
> > >
> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com>
> wrote:
> > >>
> > >> > At the very least, Type(d)Holes would never appear explicitly since
> it
> > >> > would be enabled by default. But it might be turned off (but I don't
> > >> > know who would do that for the most part.) Cabal at least might
> still
> > >> > need an update.
> > >> >
> > >> > In any case, Herbert basically summed it up: the time window is kind
> > >> > of close, and we would need to re-release/redeploy a few things most
> > >> > likely. I really think it mostly depends on the Cabal team and what
> > >> > their priorities are. I've CC'd Duncan and Johan for their opinions.
> > >> >
> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel <
> hvr at gnu.org>
> > >> > wrote:
> > >> > > Hi,
> > >> > >
> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
> > >> > >>> We probably won't change the name right now however. It's
> already
> > >> > >>> been put into Cabal (as a recognized extension,) so the name has
> > >> > >>> propagated a slight bit. We can however give it a new name and
> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could change
> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle for
> > >> > >>> other devs to change.
> > >> > >>
> > >> > >> Removing a name later on is more time-consuming, with or without
> > >> > >> deprecation. People get used to the "wrong" name and stop
> caring, but
> > >> > >> I can already picture the "type holes are really typed holes"
> > >> > >> discussions on IRC. I'm strongly in favour of introducing the
> new name
> > >> > >> (and the deprecation for the synonym) as early as possible. This
> > >> > >> change should not be very extensive anyway, so why not slip it
> in?
> > >> > >
> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
> > >> > > release in time for the final 7.8, and a recompile of Hackage to
> pick it
> > >> > > up so that people can start using the new 'TypedHoles' token in
> their
> > >> > > .cabal files... so there's a bit of coordination required to make
> this
> > >> > > happen in a timely manner... Or put differently, somebody has to
> care
> > >> > > enough to invest some time and pull this through :-)
> > >> > >
> > >> > > Cheers,
> > >> > >   hvr
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Regards,
> > >> >
> > >> > Austin Seipp, Haskell Consultant
> > >> > Well-Typed LLP, http://www.well-typed.com/
> > >> >
> > >
> > >
> > > --
> > > Duncan Coutts, Haskell Consultant
> > > Well-Typed LLP, http://www.well-typed.com/
> > >
> > >
> >
> >
> >
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140114/4022b5ed/attachment.html>

From austin at well-typed.com  Wed Jan 15 02:24:29 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Jan 2014 20:24:29 -0600
Subject: Enabling TypeHoles by default
In-Reply-To: <CAJumaK_BrHcaKr1rSPZKOgPRrfa4CUXqwNUvcXDtdYtQnedrww@mail.gmail.com>
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
 <CAJumaK_BrHcaKr1rSPZKOgPRrfa4CUXqwNUvcXDtdYtQnedrww@mail.gmail.com>
Message-ID: <CAEs96n1dNrUg3d882f8uf7isv4dLKNRR9nR5=t5sJFFN7sPJRw@mail.gmail.com>

Oops. Resending to list:
-----------------------------------

Right, same goes for every type error in that case though. (We also
ban -fdefer-type-errors in the hackage server, FYI, so it's not like
it can affect released code very much anyway.)

In light of this discussion I've made this change in 235fd88a9:

https://github.com/ghc/ghc/commit/235fd88a9a35a6ca1aed70ff71291d7b433e45e4

I'll submit a change to Cabal to remove its awareness of TypeHoles as
an extension.

P.S. As I wrote this, I realize I should probably change it to
-fwarn-typed-holes, as everyone seemed to have wanted...

On Tue, Jan 14, 2014 at 1:00 PM, Edward Kmett <ekmett at gmail.com> wrote:
> It actually can affect what code compiles with -fdefer-type-errors, but I
> don't feel terribly strongly about that.
>
> -Edward
>
>
>
>
> On Tue, Jan 14, 2014 at 12:23 PM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>>
>> Hi,
>>
>> heh, I wanted to throw in the same argument: If its just more elaborate
>> error messages, why do we need a flag for it? So count that as +1 from
>> me.
>>
>> Greetings,
>> Joachim
>>
>>
>> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
>> > I'm actually more in favor of Richard's proposal of just removing the
>> > flag to be honest, now that he mentioned it. And it's not like it's
>> > much more code.
>> >
>> > In any case, as Duncan informed me we'll have a Cabal release anyway,
>> > so I'll work on sorting this out and enabling it.
>> >
>> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com>
>> > wrote:
>> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
>> > >> I can make another cabal release if needed, if someone submits a pull
>> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
>> > >> synonym.)
>> > >
>> > > Thanks Johan, or I'm happy to do it.
>> > >
>> > > Duncan
>> > >
>> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com>
>> > >> wrote:
>> > >>
>> > >> > At the very least, Type(d)Holes would never appear explicitly since
>> > >> > it
>> > >> > would be enabled by default. But it might be turned off (but I
>> > >> > don't
>> > >> > know who would do that for the most part.) Cabal at least might
>> > >> > still
>> > >> > need an update.
>> > >> >
>> > >> > In any case, Herbert basically summed it up: the time window is
>> > >> > kind
>> > >> > of close, and we would need to re-release/redeploy a few things
>> > >> > most
>> > >> > likely. I really think it mostly depends on the Cabal team and what
>> > >> > their priorities are. I've CC'd Duncan and Johan for their
>> > >> > opinions.
>> > >> >
>> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel
>> > >> > <hvr at gnu.org>
>> > >> > wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
>> > >> > >>> We probably won't change the name right now however. It's
>> > >> > >>> already
>> > >> > >>> been put into Cabal (as a recognized extension,) so the name
>> > >> > >>> has
>> > >> > >>> propagated a slight bit. We can however give it a new name and
>> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could
>> > >> > >>> change
>> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle
>> > >> > >>> for
>> > >> > >>> other devs to change.
>> > >> > >>
>> > >> > >> Removing a name later on is more time-consuming, with or without
>> > >> > >> deprecation. People get used to the "wrong" name and stop
>> > >> > >> caring, but
>> > >> > >> I can already picture the "type holes are really typed holes"
>> > >> > >> discussions on IRC. I'm strongly in favour of introducing the
>> > >> > >> new name
>> > >> > >> (and the deprecation for the synonym) as early as possible. This
>> > >> > >> change should not be very extensive anyway, so why not slip it
>> > >> > >> in?
>> > >> > >
>> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
>> > >> > > release in time for the final 7.8, and a recompile of Hackage to
>> > >> > > pick it
>> > >> > > up so that people can start using the new 'TypedHoles' token in
>> > >> > > their
>> > >> > > .cabal files... so there's a bit of coordination required to make
>> > >> > > this
>> > >> > > happen in a timely manner... Or put differently, somebody has to
>> > >> > > care
>> > >> > > enough to invest some time and pull this through :-)
>> > >> > >
>> > >> > > Cheers,
>> > >> > >   hvr
>> > >> > >
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Regards,
>> > >> >
>> > >> > Austin Seipp, Haskell Consultant
>> > >> > Well-Typed LLP, http://www.well-typed.com/
>> > >> >
>> > >
>> > >
>> > > --
>> > > Duncan Coutts, Haskell Consultant
>> > > Well-Typed LLP, http://www.well-typed.com/
>> > >
>> > >
>> >
>> >
>> >
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From hvr at gnu.org  Wed Jan 15 10:46:23 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 15 Jan 2014 11:46:23 +0100
Subject: Enabling TypeHoles by default
In-Reply-To: <CAEs96n1dNrUg3d882f8uf7isv4dLKNRR9nR5=t5sJFFN7sPJRw@mail.gmail.com>
 (Austin Seipp's message of "Tue, 14 Jan 2014 20:24:29 -0600")
References: <CA+h2LznY_j7ev_2Dn870k7239Qos_Pr7uOe0C5Zc_ZGc9vjmag@mail.gmail.com>
 <52D45294.7070402@fuuzetsu.co.uk>
 <CACxkR4DoTYp2a=SM2BnwmjDotsAPeV-8Q1p4GwwbvtPP78J1GA@mail.gmail.com>
 <52D45E63.3080708@fuuzetsu.co.uk>
 <CAEs96n2BLD8_hy1J_4bOogAsLGtULJH42rMvqzb32YJRxbn41A@mail.gmail.com>
 <52D5627B.4080706@gmail.com> <87eh4a1qbs.fsf@gnu.org>
 <CAEs96n1+yfwyZ71vkjPVqnh1BAnxMZ26bxDK2cvi3szBEc-e1Q@mail.gmail.com>
 <CAK-tuPY8V51V9OBXD0T-MCpafkd6eNV+VKpaMQNF-+47aF22WQ@mail.gmail.com>
 <1389718489.16190.100.camel@dunky.localdomain>
 <CAEs96n1m0oQK8s8Bs8rGFUyNLAMgFiLhxurBtsrzb4Wasic_Bw@mail.gmail.com>
 <1389720214.2465.26.camel@kirk>
 <CAJumaK_BrHcaKr1rSPZKOgPRrfa4CUXqwNUvcXDtdYtQnedrww@mail.gmail.com>
 <CAEs96n1dNrUg3d882f8uf7isv4dLKNRR9nR5=t5sJFFN7sPJRw@mail.gmail.com>
Message-ID: <877ga11q0w.fsf@gnu.org>

On 2014-01-15 at 03:24:29 +0100, Austin Seipp wrote:
> I'll submit a change to Cabal to remove its awareness of TypeHoles as
> an extension.

...actually, I forgot that 'TypeHoles' actually never made into Cabal
when we added missing language-extensions tokens, as Duncan noticed in
[1], that

| We didn't add TypeHoles on the theory that it would not be used in
| released packages. However on reflection it would be better to add it
| as a registered extension but to have an explicit check for it not
| being used in distributed packages (e.g. like we complain about
| -Werror).


Luckily, this turns my comments regarding updating Cabal & Hackage into
a non-issue :-)


 [1]: https://ghc.haskell.org/trac/ghc/ticket/8176#comment:6

Cheers,
  hvr

From p.k.f.holzenspies at utwente.nl  Fri Jan 17 06:51:26 2014
From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?=22Philip_K=2EF=2E_H=F6lzenspies=22?=)
Date: Fri, 17 Jan 2014 07:51:26 +0100
Subject: GADT records revisited
Message-ID: <52D8D2EE.5090300@utwente.nl>

Dear all,

I was playing around with GADT-records again and ran into behaviour that 
I'm not sure is intentional. Given this program:



{-#LANGUAGE GADTs #-}

data FooBar x a where
   Foo :: { fooBar :: a } -> FooBar Char a
   Bar :: { fooBar :: a } -> FooBar Bool a


GHC tells me this:


foo.hs:3:1:
     Constructors Foo and Bar have a common field `fooBar',
       but have different result types
     In the data declaration for `FooBar'
Failed, modules loaded: none.


The user guide does say (section 7.4.7): "However, for GADTs there is 
the following additional constraint: every constructor that has a field 
f must have the same result type (modulo alpha conversion)." So this 
behaviour is documented in the user guide. However, it seems reasonable 
that in the case above, where all the relevant variables are exposed in 
the result type of both constructors, this should be perfectly typeable. 
In other words, shouldn't GHC be able to derive a type that is simply:

fooBar :: FooBar x a -> a

?

Is this something that was simply never implemented, but could be, or is 
this not decidable or prohibitively computationally complex?

Regards,
Philip



From roma at ro-che.info  Fri Jan 17 07:18:21 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 17 Jan 2014 09:18:21 +0200
Subject: GADT records revisited
In-Reply-To: <52D8D2EE.5090300@utwente.nl>
References: <52D8D2EE.5090300@utwente.nl>
Message-ID: <20140117071821.GA5796@sniper>

I think this is intentional and conforms to the documentation. Your
constructors clearly have *different* result types, even though they
both can be instantiated from a single type scheme `FooBar x a`.

I'll leave it to others to comment on whether the generalization you
propose is reasonable and feasible.

Roman

* "Philip K.F. H?lzenspies" <p.k.f.holzenspies at utwente.nl> [2014-01-17 07:51:26+0100]
> Dear all,
> 
> I was playing around with GADT-records again and ran into behaviour
> that I'm not sure is intentional. Given this program:
> 
> 
> 
> {-#LANGUAGE GADTs #-}
> 
> data FooBar x a where
>   Foo :: { fooBar :: a } -> FooBar Char a
>   Bar :: { fooBar :: a } -> FooBar Bool a
> 
> 
> GHC tells me this:
> 
> 
> foo.hs:3:1:
>     Constructors Foo and Bar have a common field `fooBar',
>       but have different result types
>     In the data declaration for `FooBar'
> Failed, modules loaded: none.
> 
> 
> The user guide does say (section 7.4.7): "However, for GADTs there is
> the following additional constraint: every constructor that has a
> field f must have the same result type (modulo alpha conversion)." So
> this behaviour is documented in the user guide. However, it seems
> reasonable that in the case above, where all the relevant variables
> are exposed in the result type of both constructors, this should be
> perfectly typeable. In other words, shouldn't GHC be able to derive a
> type that is simply:
> 
> fooBar :: FooBar x a -> a
> 
> ?
> 
> Is this something that was simply never implemented, but could be, or
> is this not decidable or prohibitively computationally complex?
> 
> Regards,
> Philip
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140117/ea17e904/attachment.sig>

From simonpj at microsoft.com  Fri Jan 17 08:07:47 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Jan 2014 08:07:47 +0000
Subject: GADT records revisited
In-Reply-To: <52D8D2EE.5090300@utwente.nl>
References: <52D8D2EE.5090300@utwente.nl>
Message-ID: <59543203684B2244980D7E4057D5FBC1487191C2@DB3EX14MBXC306.europe.corp.microsoft.com>

It's a choice.  Consider

data Bar a where
  B1 :: { x :: b } -> Bar [b]
  B2 :: { x :: b } -> Bar [b]
  B3 :: Bar a

Now we can define a perfectly good selector
  x :: Bar [b] -> b
  x (B1 v) = v
  x (B2 v) = v

But this wouldn't work if the result types were different

data BadBar a where
  B1 :: { x :: b } -> Bar [b]
  B2 :: { x :: b } -> Bar b
  B3 :: Bar a


Now it's true that in your example the field mentions only *polymorphic* components, so there is a perfectly well-defined selector with the type you give.  Indeed, it could be a bit more complicated:

data FooBar x a where
  Foo :: { fooBar :: a } -> FooBar Char [a]
  Bar :: { fooBar :: a } -> FooBar Bool [a]

Then there is a reasonable selector with type

  fooBar :: FooBar b [a] -> a

So what is the general rule? When exactly is there a well-defined selector type, and what is that type?  Notice that in the type of fooBar we had to generalise over the Char/Bool difference, but maintain the [a] part.  Indeed it might all be part of one type:

data FooBar2 x where
  Foo2 :: { fooBar2 :: a } -> FooBar2 (Char, [a])
  Bar2 :: { fooBar2 :: a } -> FooBar2 (Bool, [a])

So now

  fooBar2 :: FooBar2 (x, [a]) -> a

where we generalise part of the type. 

So, on reflection, there must be a more permissive rule than the one GHC currently implements.  If someone wants to figure out the general rule, express it formally, say what the user manual would say, we could discuss whether the cost benefit ratio is good enough to be worth implementing.  

This seems interesting enough to make into a ticket.
https://ghc.haskell.org/trac/ghc/ticket/8673

Simon



| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of "Philip K.F. H?lzenspies"
| Sent: 17 January 2014 06:51
| To: glasgow-haskell-users at haskell.org
| Subject: GADT records revisited
| 
| Dear all,
| 
| I was playing around with GADT-records again and ran into behaviour that
| I'm not sure is intentional. Given this program:
| 
| 
| 
| {-#LANGUAGE GADTs #-}
| 
| data FooBar x a where
|    Foo :: { fooBar :: a } -> FooBar Char a
|    Bar :: { fooBar :: a } -> FooBar Bool a
| 
| 
| GHC tells me this:
| 
| 
| foo.hs:3:1:
|      Constructors Foo and Bar have a common field `fooBar',
|        but have different result types
|      In the data declaration for `FooBar'
| Failed, modules loaded: none.
| 
| 
| The user guide does say (section 7.4.7): "However, for GADTs there is
| the following additional constraint: every constructor that has a field
| f must have the same result type (modulo alpha conversion)." So this
| behaviour is documented in the user guide. However, it seems reasonable
| that in the case above, where all the relevant variables are exposed in
| the result type of both constructors, this should be perfectly typeable.
| In other words, shouldn't GHC be able to derive a type that is simply:
| 
| fooBar :: FooBar x a -> a
| 
| ?
| 
| Is this something that was simply never implemented, but could be, or is
| this not decidable or prohibitively computationally complex?
| 
| Regards,
| Philip
| 
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From carter.schonwald at gmail.com  Mon Jan 20 00:02:27 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Jan 2014 19:02:27 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
Message-ID: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>

Hey everyone,

I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install
(aka cabal) executable, but not include the library deps of cabal-install
that aren't already distributed with ghc.(unless ghc should have those deps
baked in, which theres very very good reasons not to do.).

currently if someone wants just a basic haskell install of the freshest ghc
 they have to install a ghc bindist, then do a boostrap build of
cabal-install by hand (if they want to actually get anything done :) ).

This is not a human friendly situation for folks who are new to haskell
tooling, but want to try out haskell dev on a server style vm or the like!

point being: It'd be great for haskell usability (and egads amounts of
config time, even by seasoned users) the ghc bindists / installers included
a cabal-install binary

thoughts?
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140119/21ce7f17/attachment.html>

From the.dead.shall.rise at gmail.com  Mon Jan 20 00:11:36 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 20 Jan 2014 01:11:36 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>

Hi,

On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
>
> point being: It'd be great for haskell usability (and egads amounts of
> config time, even by seasoned users) the ghc bindists / installers included
> a cabal-install binary

For Windows, we provide a stand-alone cabal.exe on the Cabal site [1].
I guess we could do the same for Linux and OS X.

[1] http://www.haskell.org/cabal/download.html

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From carter.schonwald at gmail.com  Mon Jan 20 00:14:57 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Jan 2014 19:14:57 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>
Message-ID: <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>

that still requires some discovery though! The idea (i'd hope) would be to
make the "my first ghc install on a vm" (for experts and new folks both)

go from

#install ghc via whatever mechanism, eg wget, guntar, cd blah ; make
install PREFIX=yah
#figure out how to install cabal, eg discover wget and then ./bootstrap
# cabal install thingsIwannaTry

to
# install ghc via some wget and make
#cabal install nice things


On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi,
>
> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > point being: It'd be great for haskell usability (and egads amounts of
> > config time, even by seasoned users) the ghc bindists / installers
> included
> > a cabal-install binary
>
> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1].
> I guess we could do the same for Linux and OS X.
>
> [1] http://www.haskell.org/cabal/download.html
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140119/b4f0f81f/attachment.html>

From mle+hs at mega-nerd.com  Mon Jan 20 00:33:55 2014
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Mon, 20 Jan 2014 11:33:55 +1100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>
 <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>
Message-ID: <20140120113355.b7955edea7075a1dff3317e4@mega-nerd.com>

Carter Schonwald wrote:

> that still requires some discovery though! The idea (i'd hope) would be to
> make the "my first ghc install on a vm" (for experts and new folks both)
> 
> go from
> 
> #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make
> install PREFIX=yah
> #figure out how to install cabal, eg discover wget and then ./bootstrap
> # cabal install thingsIwannaTry
> 
> to
> # install ghc via some wget and make
> #cabal install nice things

Thats basically how I work on Debian based Linux systems:

    # apt-get install ghc alex happy cabal-install
    $ cabal install nice-things

Where '#' is the root prompt and '$' is the user prompt.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From the.dead.shall.rise at gmail.com  Mon Jan 20 02:37:21 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 20 Jan 2014 03:37:21 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>
 <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>
Message-ID: <CA+tcxkCFukFuR3PhXrpVtLZDm+JgGRA_COtxn2rmQmZ=E50j-w@mail.gmail.com>

Hi,

On Mon, Jan 20, 2014 at 1:14 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> that still requires some discovery though! The idea (i'd hope) would be to
> make the "my first ghc install on a vm" (for experts and new folks both)

Regardless, I think it should be the Cabal developers' job to provide
pre-built cabal-install binaries. The choice of whether or not to ship
them with the GHC binary tarballs falls to GHC HQ.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From carter.schonwald at gmail.com  Mon Jan 20 05:38:58 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 20 Jan 2014 00:38:58 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CADJiDhs9pzb4b_oYxdQxm4ZhJWkAMoh-f-4a-duga19hBbtFdA@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CA+tcxkBTnuF9ofMMW45ai9j9P-RxkLFLAN737UVueWBLCOznZw@mail.gmail.com>
 <CAHYVw0zXLCEsU8f16_THjiuitSwJQZf_-6A1yZsgoMh9LtTAkg@mail.gmail.com>
 <CADJiDhs9pzb4b_oYxdQxm4ZhJWkAMoh-f-4a-duga19hBbtFdA@mail.gmail.com>
Message-ID: <CAHYVw0wy6PjOwLdFpuPBetXEkByzJXdw9R1bkCAn+PJuM=-dew@mail.gmail.com>

indeed, after thinking a wee bit more, yes, it'd be AMAZING if cabal devs
made binaries visibly available to the community!

(also, it does seem like cabal / cabal-install docs aren't super
discoverable for some people)


On Mon, Jan 20, 2014 at 12:24 AM, Oren Ben-Kiki
<haskell-oren at ben-kiki.org>wrote:

> Hear hear! This would be most welcome.
>
>
> On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> that still requires some discovery though! The idea (i'd hope) would be
>> to make the "my first ghc install on a vm" (for experts and new folks both)
>>
>> go from
>>
>> #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make
>> install PREFIX=yah
>> #figure out how to install cabal, eg discover wget and then ./bootstrap
>> # cabal install thingsIwannaTry
>>
>> to
>> # install ghc via some wget and make
>> #cabal install nice things
>>
>>
>> On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov <
>> the.dead.shall.rise at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald
>>> <carter.schonwald at gmail.com> wrote:
>>> >
>>> > point being: It'd be great for haskell usability (and egads amounts of
>>> > config time, even by seasoned users) the ghc bindists / installers
>>> included
>>> > a cabal-install binary
>>>
>>> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1].
>>> I guess we could do the same for Linux and OS X.
>>>
>>> [1] http://www.haskell.org/cabal/download.html
>>>
>>> --
>>> ()  ascii ribbon campaign - against html e-mail
>>> /\  www.asciiribbon.org   - against proprietary attachments
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140120/405f5582/attachment.html>

From roma at ro-che.info  Mon Jan 20 07:53:56 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 20 Jan 2014 09:53:56 +0200
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <20140120075356.GA14101@sniper>

Agreed, this would improve usability of binary GHC releases a lot, and I
don't see any downsides.

+1

Roman

* Carter Schonwald <carter.schonwald at gmail.com> [2014-01-19 19:02:27-0500]
> Hey everyone,
> 
> I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install
> (aka cabal) executable, but not include the library deps of cabal-install
> that aren't already distributed with ghc.(unless ghc should have those deps
> baked in, which theres very very good reasons not to do.).
> 
> currently if someone wants just a basic haskell install of the freshest ghc
>  they have to install a ghc bindist, then do a boostrap build of
> cabal-install by hand (if they want to actually get anything done :) ).
> 
> This is not a human friendly situation for folks who are new to haskell
> tooling, but want to try out haskell dev on a server style vm or the like!
> 
> point being: It'd be great for haskell usability (and egads amounts of
> config time, even by seasoned users) the ghc bindists / installers included
> a cabal-install binary
> 
> thoughts?
> -Carter

> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140120/0cd3a344/attachment-0001.sig>

From hvr at gnu.org  Mon Jan 20 09:00:51 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 20 Jan 2014 10:00:51 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 (Carter Schonwald's message of "Sun, 19 Jan 2014 19:02:27 -0500")
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <87ha8zc9j0.fsf@gnu.org>

On 2014-01-20 at 01:02:27 +0100, Carter Schonwald wrote:
> I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install
> (aka cabal) executable, but not include the library deps of cabal-install
> that aren't already distributed with ghc.(unless ghc should have those deps
> baked in, which theres very very good reasons not to do.).

+1


PS: ...would this affect the source-dist tarball as well?

From marlowsd at gmail.com  Mon Jan 20 10:50:06 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 20 Jan 2014 10:50:06 +0000
Subject: --split-objs
In-Reply-To: <CA+tcxkBL5d5p9xwYAMmzR5yu1H8=bt6Oyy1xnMG-_p-_zz3Dmw@mail.gmail.com>
References: <1387357681954-5741209.post@n5.nabble.com>
 <CAKFCL4Uhp8XXdVXkyoadLDfTyzB2tqmPa5Ssjn6HXPXyVo-b9g@mail.gmail.com>
 <1387380464300-5741215.post@n5.nabble.com>
 <CAKFCL4U8A4qqCg9fKnthHu8kBf+-=k=i3MQJK32=7+ofg1N0tQ@mail.gmail.com>
 <CA+tcxkBL5d5p9xwYAMmzR5yu1H8=bt6Oyy1xnMG-_p-_zz3Dmw@mail.gmail.com>
Message-ID: <52DCFF5E.40007@gmail.com>

On 19/12/2013 03:00, Mikhail Glushenkov wrote:
> The problem in https://github.com/haskell/cabal/issues/1611 is with
> that we have a module (say, A) from which we're only importing a
> single value, and this module is a part of the cabal-install source
> tree. It would be nice if the whole contents of A weren't linked with
> the final executable. So I tried to compile cabal-install with
> --split-objs, but apparently this doesn't work because in this case
> the linker's input is A.o instead of A_split_0.o A_split_1.o ...
> A_split_N.o. And apparently that's why the documentation says that
> "--split-objs doesn't make sense for executables".
>
> Note that if cabal-install was split into an executable and a library,
> then this would work.
>
> So the question is why --split-objs only works for libraries and
> whether this behaviour can be fixed.

There is nothing fundamental about -split-objs that prevents it from 
working with executables.  I expect that GHC doesn't take it into 
account during its link step when linking an executable with 
-split-objs, though.  That would be a reasonable enhancement - open a 
ticket?

Cheers,
	Simon


From the.dead.shall.rise at gmail.com  Mon Jan 20 14:00:18 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 20 Jan 2014 15:00:18 +0100
Subject: --split-objs
In-Reply-To: <52DCFF5E.40007@gmail.com>
References: <1387357681954-5741209.post@n5.nabble.com>
 <CAKFCL4Uhp8XXdVXkyoadLDfTyzB2tqmPa5Ssjn6HXPXyVo-b9g@mail.gmail.com>
 <1387380464300-5741215.post@n5.nabble.com>
 <CAKFCL4U8A4qqCg9fKnthHu8kBf+-=k=i3MQJK32=7+ofg1N0tQ@mail.gmail.com>
 <CA+tcxkBL5d5p9xwYAMmzR5yu1H8=bt6Oyy1xnMG-_p-_zz3Dmw@mail.gmail.com>
 <52DCFF5E.40007@gmail.com>
Message-ID: <CA+tcxkDBdYz7cesCZuAy6PX4xfGQvqpqHF+eoU3Pcc-4GwSCKQ@mail.gmail.com>

Hi,

On Mon, Jan 20, 2014 at 11:50 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> There is nothing fundamental about -split-objs that prevents it from working
> with executables.  I expect that GHC doesn't take it into account during its
> link step when linking an executable with -split-objs, though.  That would
> be a reasonable enhancement - open a ticket?

Thanks. Ticket created: https://ghc.haskell.org/trac/ghc/ticket/8685



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From ganesh at earth.li  Tue Jan 21 19:22:48 2014
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Tue, 21 Jan 2014 19:22:48 +0000
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <52DEC908.70806@earth.li>

I feel this blurs the roles of GHC and the Platform.

Can't the cabal-install that comes with the Platform can be used with a
later GHC installation? If that's correct, then the only use case that
this proposal covers is someone who wants to use a bleeding edge GHC and
no other version on a new machine. A separate binary distribution of
cabal-install should be more than adequate for that and it avoids
coupling GHC to other things.

So a weak -1.


On 20/01/2014 00:02, Carter Schonwald wrote:
> Hey everyone,
> 
> I'd like to propose that GHC releases 7.8.1 onwards include a
> cabal-install (aka cabal) executable, but not include the library deps
> of cabal-install that aren't already distributed with ghc.(unless ghc
> should have those deps baked in, which theres very very good reasons not
> to do.). 
> 
> currently if someone wants just a basic haskell install of the freshest
> ghc  they have to install a ghc bindist, then do a boostrap build of
> cabal-install by hand (if they want to actually get anything done :) ). 
> 
> This is not a human friendly situation for folks who are new to haskell
> tooling, but want to try out haskell dev on a server style vm or the like! 
> 
> point being: It'd be great for haskell usability (and egads amounts of
> config time, even by seasoned users) the ghc bindists / installers
> included a cabal-install binary
> 
> thoughts?
> -Carter
> 
> 
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 


From johan.tibell at gmail.com  Tue Jan 21 19:32:19 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 21 Jan 2014 11:32:19 -0800
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <52DEC908.70806@earth.li>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li>
Message-ID: <CAK-tuPZCp_ePhX88p=fscka-HEwC5z=OR_5Sq6u5Y9Xx8nWZUg@mail.gmail.com>

We could offer OS X and Linux binaries in addition to the Windows binaries
already downloaded on the cabal home page (http://www.haskell.org/cabal/)
if someone could commit to building them.

Aside: Right now building the Windows binaries is a very ad-hoc process (I
email Mikhail who has a Windows machine and ask him to build one). I'm not
very keen to make the process even slower, given that that will mean I will
make fewer cabal releases. Ideally the binaries could be produced on a
build bot. The very least we should have the Makefile in the cabal repo
being able to create the binary in a reproducible manner.

-- Johan



On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam <ganesh at earth.li>wrote:

> I feel this blurs the roles of GHC and the Platform.
>
> Can't the cabal-install that comes with the Platform can be used with a
> later GHC installation? If that's correct, then the only use case that
> this proposal covers is someone who wants to use a bleeding edge GHC and
> no other version on a new machine. A separate binary distribution of
> cabal-install should be more than adequate for that and it avoids
> coupling GHC to other things.
>
> So a weak -1.
>
>
> On 20/01/2014 00:02, Carter Schonwald wrote:
> > Hey everyone,
> >
> > I'd like to propose that GHC releases 7.8.1 onwards include a
> > cabal-install (aka cabal) executable, but not include the library deps
> > of cabal-install that aren't already distributed with ghc.(unless ghc
> > should have those deps baked in, which theres very very good reasons not
> > to do.).
> >
> > currently if someone wants just a basic haskell install of the freshest
> > ghc  they have to install a ghc bindist, then do a boostrap build of
> > cabal-install by hand (if they want to actually get anything done :) ).
> >
> > This is not a human friendly situation for folks who are new to haskell
> > tooling, but want to try out haskell dev on a server style vm or the
> like!
> >
> > point being: It'd be great for haskell usability (and egads amounts of
> > config time, even by seasoned users) the ghc bindists / installers
> > included a cabal-install binary
> >
> > thoughts?
> > -Carter
> >
> >
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140121/9d5e73c6/attachment.html>

From migmit at gmail.com  Tue Jan 21 20:12:49 2014
From: migmit at gmail.com (migmit)
Date: Wed, 22 Jan 2014 00:12:49 +0400
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <52DEC908.70806@earth.li>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li>
Message-ID: <DEA3513B-711E-4347-B119-DE0E598CB533@gmail.com>

Agreed. That's exactly what we have Platform for: to give the user an integrated set of tools. My vote is to have only the things that are really necessary being included in the ghc distribution.

?????????? ? iPad

> 21 ???. 2014 ?., ? 23:22, Ganesh Sittampalam <ganesh at earth.li> ???????(?):
> 
> I feel this blurs the roles of GHC and the Platform.
> 
> Can't the cabal-install that comes with the Platform can be used with a
> later GHC installation? If that's correct, then the only use case that
> this proposal covers is someone who wants to use a bleeding edge GHC and
> no other version on a new machine. A separate binary distribution of
> cabal-install should be more than adequate for that and it avoids
> coupling GHC to other things.
> 
> So a weak -1.
> 
> 
>> On 20/01/2014 00:02, Carter Schonwald wrote:
>> Hey everyone,
>> 
>> I'd like to propose that GHC releases 7.8.1 onwards include a
>> cabal-install (aka cabal) executable, but not include the library deps
>> of cabal-install that aren't already distributed with ghc.(unless ghc
>> should have those deps baked in, which theres very very good reasons not
>> to do.). 
>> 
>> currently if someone wants just a basic haskell install of the freshest
>> ghc  they have to install a ghc bindist, then do a boostrap build of
>> cabal-install by hand (if they want to actually get anything done :) ). 
>> 
>> This is not a human friendly situation for folks who are new to haskell
>> tooling, but want to try out haskell dev on a server style vm or the like! 
>> 
>> point being: It'd be great for haskell usability (and egads amounts of
>> config time, even by seasoned users) the ghc bindists / installers
>> included a cabal-install binary
>> 
>> thoughts?
>> -Carter
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From ganesh at earth.li  Tue Jan 21 20:44:52 2014
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Tue, 21 Jan 2014 20:44:52 +0000
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAK-tuPZCp_ePhX88p=fscka-HEwC5z=OR_5Sq6u5Y9Xx8nWZUg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li>
 <CAK-tuPZCp_ePhX88p=fscka-HEwC5z=OR_5Sq6u5Y9Xx8nWZUg@mail.gmail.com>
Message-ID: <52DEDC44.70209@earth.li>

If you can't find any better options, I can try to run a buildbot on a
laptop that's probably mostly online.


On 21/01/2014 19:32, Johan Tibell wrote:
> We could offer OS X and Linux binaries in addition to the Windows
> binaries already downloaded on the cabal home page
> (http://www.haskell.org/cabal/) if someone could commit to building them.
> 
> Aside: Right now building the Windows binaries is a very ad-hoc process
> (I email Mikhail who has a Windows machine and ask him to build one).
> I'm not very keen to make the process even slower, given that that will
> mean I will make fewer cabal releases. Ideally the binaries could be
> produced on a build bot. The very least we should have the Makefile in
> the cabal repo being able to create the binary in a reproducible manner.
> 
> -- Johan
> 
> 
> 
> On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam <ganesh at earth.li
> <mailto:ganesh at earth.li>> wrote:
> 
>     I feel this blurs the roles of GHC and the Platform.
> 
>     Can't the cabal-install that comes with the Platform can be used with a
>     later GHC installation? If that's correct, then the only use case that
>     this proposal covers is someone who wants to use a bleeding edge GHC and
>     no other version on a new machine. A separate binary distribution of
>     cabal-install should be more than adequate for that and it avoids
>     coupling GHC to other things.
> 
>     So a weak -1.
> 
> 
>     On 20/01/2014 00:02, Carter Schonwald wrote:
>     > Hey everyone,
>     >
>     > I'd like to propose that GHC releases 7.8.1 onwards include a
>     > cabal-install (aka cabal) executable, but not include the library deps
>     > of cabal-install that aren't already distributed with ghc.(unless ghc
>     > should have those deps baked in, which theres very very good
>     reasons not
>     > to do.).
>     >
>     > currently if someone wants just a basic haskell install of the
>     freshest
>     > ghc  they have to install a ghc bindist, then do a boostrap build of
>     > cabal-install by hand (if they want to actually get anything done
>     :) ).
>     >
>     > This is not a human friendly situation for folks who are new to
>     haskell
>     > tooling, but want to try out haskell dev on a server style vm or
>     the like!
>     >
>     > point being: It'd be great for haskell usability (and egads amounts of
>     > config time, even by seasoned users) the ghc bindists / installers
>     > included a cabal-install binary
>     >
>     > thoughts?
>     > -Carter
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Libraries mailing list
>     > Libraries at haskell.org <mailto:Libraries at haskell.org>
>     > http://www.haskell.org/mailman/listinfo/libraries
>     >
> 
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
> 
> 


From carter.schonwald at gmail.com  Tue Jan 21 21:47:44 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 21 Jan 2014 16:47:44 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <52DEDC44.70209@earth.li>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li>
 <CAK-tuPZCp_ePhX88p=fscka-HEwC5z=OR_5Sq6u5Y9Xx8nWZUg@mail.gmail.com>
 <52DEDC44.70209@earth.li>
Message-ID: <CAHYVw0wTVZZmzvK0mrsXqhtFZMif=4AULpaUboRAdbAwR-XVgA@mail.gmail.com>

Ok,

so either

a) provide a ghc + cabal-install binary included (heck, its easy to update
to a cabal install anyways, and the ~/.cabal/bin path will be before
wherever the ghc pkgs are installed anyways. The same argument could be
made for packaging happy and alex with ghc too! ). After all, i already
have a happy / alex from cabal-installing them from earlier, why should ghc
install it again? :p



b) either way, perhaps the cabal-install devs/maintainers should
standardize making some binaries available




On Tue, Jan 21, 2014 at 3:44 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:

> If you can't find any better options, I can try to run a buildbot on a
> laptop that's probably mostly online.
>
>
> On 21/01/2014 19:32, Johan Tibell wrote:
> > We could offer OS X and Linux binaries in addition to the Windows
> > binaries already downloaded on the cabal home page
> > (http://www.haskell.org/cabal/) if someone could commit to building
> them.
> >
> > Aside: Right now building the Windows binaries is a very ad-hoc process
> > (I email Mikhail who has a Windows machine and ask him to build one).
> > I'm not very keen to make the process even slower, given that that will
> > mean I will make fewer cabal releases. Ideally the binaries could be
> > produced on a build bot. The very least we should have the Makefile in
> > the cabal repo being able to create the binary in a reproducible manner.
> >
> > -- Johan
> >
> >
> >
> > On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam <ganesh at earth.li
> > <mailto:ganesh at earth.li>> wrote:
> >
> >     I feel this blurs the roles of GHC and the Platform.
> >
> >     Can't the cabal-install that comes with the Platform can be used
> with a
> >     later GHC installation? If that's correct, then the only use case
> that
> >     this proposal covers is someone who wants to use a bleeding edge GHC
> and
> >     no other version on a new machine. A separate binary distribution of
> >     cabal-install should be more than adequate for that and it avoids
> >     coupling GHC to other things.
> >
> >     So a weak -1.
> >
> >
> >     On 20/01/2014 00:02, Carter Schonwald wrote:
> >     > Hey everyone,
> >     >
> >     > I'd like to propose that GHC releases 7.8.1 onwards include a
> >     > cabal-install (aka cabal) executable, but not include the library
> deps
> >     > of cabal-install that aren't already distributed with ghc.(unless
> ghc
> >     > should have those deps baked in, which theres very very good
> >     reasons not
> >     > to do.).
> >     >
> >     > currently if someone wants just a basic haskell install of the
> >     freshest
> >     > ghc  they have to install a ghc bindist, then do a boostrap build
> of
> >     > cabal-install by hand (if they want to actually get anything done
> >     :) ).
> >     >
> >     > This is not a human friendly situation for folks who are new to
> >     haskell
> >     > tooling, but want to try out haskell dev on a server style vm or
> >     the like!
> >     >
> >     > point being: It'd be great for haskell usability (and egads
> amounts of
> >     > config time, even by seasoned users) the ghc bindists / installers
> >     > included a cabal-install binary
> >     >
> >     > thoughts?
> >     > -Carter
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Libraries mailing list
> >     > Libraries at haskell.org <mailto:Libraries at haskell.org>
> >     > http://www.haskell.org/mailman/listinfo/libraries
> >     >
> >
> >     _______________________________________________
> >     Libraries mailing list
> >     Libraries at haskell.org <mailto:Libraries at haskell.org>
> >     http://www.haskell.org/mailman/listinfo/libraries
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140121/feb32a36/attachment-0001.html>

From marlowsd at gmail.com  Wed Jan 22 08:25:41 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 22 Jan 2014 08:25:41 +0000
Subject: Parallel building multiple targets
In-Reply-To: <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
References: <20140105214723.GC12676@sli.dy.fi>
 <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
Message-ID: <52DF8085.8080108@gmail.com>

On 05/01/2014 23:48, John Lato wrote:
> (FYI, I expect I'm the source of the suggestion that ghc -M is broken)
>
> First, just to clarify, I don't think ghc -M is obviously broken.
>   Rather, I think it's broken in subtle, unobvious ways, such that
> trying to develop a make-based project with ghc -M will fail at various
> times in a non-obvious fashion, at least without substantial additional
> rules.

If I understand you correctly, you're not saying that ghc -M is broken, 
but that it would be easier to use if it did more.  Right?  Maybe you 
could make specific suggestions?  Saying it is "broken" is a bit 
FUD-ish.  We use it in GHC's build system, so by an existence proof it 
is certainly not broken.

Cheers,
Simon


   For an example of some of the extra steps necessary to make
> something like this work, see e.g.
> https://github.com/nh2/multishake (which is admittedly for a more
> complicated setup, and also has some issues).  The especially
> frustrating part is, just when you think you have everything working,
> someone wants to add some other tool to a workflow (hsc2hs, .cmm files,
> etc), and your build system doesn't support it.
>
> ghc --make doesn't allow building several binaries in one run, however
> if you use cabal all the separate runs will use a shared build
> directory, so subsequent builds will be able to take advantage of the
> intermediate output of the first build.  Of course you could do the same
> without cabal, but it's a convenient way to create a common build
> directory and manage multiple targets.  This is the approach I would
> take to building multiple executables from the same source files.
>
> ghc doesn't do any locking of build files AFAIK.  Running parallel ghc
> commands for two main modules that have the same import, using the same
> working directory, is not safe.  In pathological cases the two different
> main modules may even generate different code *for the imported module*.
>   This sort of situation can arise with the IncoherentInstances
> extension, for example.
>
> The obvious approach is of course to make a library out of your common
> files.  This has the downsides of requiring a bit more work on the
> developer's part, but if the common files are relatively stable it'll
> probably lead to the fastest builds of your executables.  Also in this
> case you could run multiple `ghc --make`s in parallel, using different
> build directories, since they won't be rebuilding any common code.
>
> John L.
>
> On Sun, Jan 5, 2014 at 1:47 PM, Sami Liedes <sami.liedes at iki.fi
> <mailto:sami.liedes at iki.fi>> wrote:
>
>     Hi,
>
>     I have a Haskell project where a number of executables are produced
>     from mostly the same modules. I'm using a Makefile to enable parallel
>     builds. I received advice[1] that ghc -M is broken, but that there
>     is parallel ghc --make in HEAD.
>
>     As far as I can tell, ghc --make does not allow building several
>     binaries in one run, so I think it may not still be a full replacement
>     for Makefiles.
>
>     However I have a question about ghc --make that is also relevant
>     without parallel ghc --make:
>
>     If I have two main modules, prog1.hs and prog2.hs, which have mutual
>     dependencies (for example, both import A from A.hs), is it safe to run
>     "ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there
>     some kind of locking to prevent both from building module A at the
>     same time and interfering with each other?
>
>     Is there a good way (either in current releases or HEAD) to build
>     multiple binaries partially from the same sources in parallel?
>
>              Sami
>
>
>     [1]
>     http://stackoverflow.com/questions/20938894/generating-correct-link-dependencies-for-ghc-and-makefile-style-builds
>
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.org
>     <mailto:Glasgow-haskell-users at haskell.org>
>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From hvr at gnu.org  Wed Jan 22 08:57:45 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 22 Jan 2014 09:57:45 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <52DEC908.70806@earth.li> (Ganesh Sittampalam's message of "Tue, 
 21 Jan 2014 19:22:48 +0000")
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li>
Message-ID: <874n4w2y2e.fsf@gnu.org>

On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
> I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
provided by the HP instead. Moreover, GHC ships with a set of base
libraries (which, and thus effectively GHC forces 20 or so packages
(fixed to specific package versions) into the HP and takes away
authority from the HP release process. But now the difficult to explain
thing is that GHC also bundles the library part of CABAL but
deliberately leaves out CABAL's frontend tool `cabal-install` only to
justify the existence of the HP a bit more? :-)

Cheers,
  hvr

From hvr at gnu.org  Wed Jan 22 11:55:53 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 22 Jan 2014 12:55:53 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <52DF8A72.1000003@henning-thielemann.de> (Henning Thielemann's
 message of "Wed, 22 Jan 2014 10:08:02 +0100")
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org>
 <52DF8A72.1000003@henning-thielemann.de>
Message-ID: <87ppnk1b92.fsf@gnu.org>

On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote:
> Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel:
>> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
>>> I feel this blurs the roles of GHC and the Platform.
>>
>> IMO, that's a weak argument, as the roles are already blurred:
>
>> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
>> provided by the HP instead.
>
> At least haddock is bound to the specific GHC version.

When I look at http://hackage.haskell.org/package/haddock, there are
multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all
declared to work with ghc == 7.6.*, that is, 5 haddock versions
compatible with 3 released versions of GHC 7.6. So while it may be bound
to a major version of the GHC API, haddock can obviously have more
releases than GHC has releases (otherwise it could just carry GHC's
version), and can therefore be updated.

From roma at ro-che.info  Wed Jan 22 12:22:41 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 22 Jan 2014 14:22:41 +0200
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <87ppnk1b92.fsf@gnu.org>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org>
 <52DF8A72.1000003@henning-thielemann.de> <87ppnk1b92.fsf@gnu.org>
Message-ID: <20140122122241.GA25668@sniper>

* Herbert Valerio Riedel <hvr at gnu.org> [2014-01-22 12:55:53+0100]
> On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote:
> > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel:
> >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
> >>> I feel this blurs the roles of GHC and the Platform.
> >>
> >> IMO, that's a weak argument, as the roles are already blurred:
> >
> >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
> >> provided by the HP instead.
> >
> > At least haddock is bound to the specific GHC version.
> 
> When I look at http://hackage.haskell.org/package/haddock, there are
> multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all
> declared to work with ghc == 7.6.*, that is, 5 haddock versions
> compatible with 3 released versions of GHC 7.6. So while it may be bound
> to a major version of the GHC API, haddock can obviously have more
> releases than GHC has releases (otherwise it could just carry GHC's
> version), and can therefore be updated.

Henning could be more specific in his claim that "haddock is bound to
the specific GHC version".

I guess he's referring to the binary rather than source distribution's
compatibility. Assuming static linking w.r.t. the ghc package, the
incompatibility with a different GHC version could still arise from the
fact that haddock (as any other GHC API using application, I suppose)
makes use of the GHC's lib directory, although I don't know the details.

If we are talking about installing haddock from source (using
cabal-install), then it should be no different from installing, say,
ghc-mod.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140122/45aaed3c/attachment.sig>

From johan.tibell at gmail.com  Wed Jan 22 15:45:21 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 22 Jan 2014 07:45:21 -0800
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <874n4w2y2e.fsf@gnu.org>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org>
Message-ID: <CAK-tuPb5sAJs3iF07u3tH5pBAh_zM9uCuZFKF_H0SDzGqFExsg@mail.gmail.com>

On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:

> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
> > I feel this blurs the roles of GHC and the Platform.
>
> IMO, that's a weak argument, as the roles are already blurred:
>
> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
> provided by the HP instead. Moreover, GHC ships with a set of base
> libraries (which, and thus effectively GHC forces 20 or so packages
> (fixed to specific package versions) into the HP and takes away
> authority from the HP release process. But now the difficult to explain
> thing is that GHC also bundles the library part of CABAL but
> deliberately leaves out CABAL's frontend tool `cabal-install` only to
> justify the existence of the HP a bit more? :-)
>

Cabal is part of GHC's build process and GHC uses data types from Cabal.
That's why it's there. It's not because we want Cabal to be included (just
like we don't want to ship those libs.) These are technical limitations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140122/80eb6a10/attachment.html>

From carter.schonwald at gmail.com  Wed Jan 22 16:18:08 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 22 Jan 2014 11:18:08 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAK-tuPb5sAJs3iF07u3tH5pBAh_zM9uCuZFKF_H0SDzGqFExsg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org>
 <CAK-tuPb5sAJs3iF07u3tH5pBAh_zM9uCuZFKF_H0SDzGqFExsg@mail.gmail.com>
Message-ID: <CAHYVw0y1eJWbDFXvpWkOREUMRywdS0EkxzNoEBL0bjD-BK1HFw@mail.gmail.com>

ANYWAYS :)

the point is: there is a nonzero population of haskell folks who want to
use ghc + cabal-install on a machine where they may not have admin /
package manager powers, AND it requires some amount of cabal-install
familiarity (or asking around) to find out about the ./boot-strap script
that cabal comes with.  (I've definitely had 1-2 incidents where on a new
server i did the bootstrap process by hand before i found out about that
script)

at the very very least, the directions for boostrap cabal-install should be
more discoverable


On Wed, Jan 22, 2014 at 10:45 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:
>
>> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
>> > I feel this blurs the roles of GHC and the Platform.
>>
>> IMO, that's a weak argument, as the roles are already blurred:
>>
>> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
>> provided by the HP instead. Moreover, GHC ships with a set of base
>> libraries (which, and thus effectively GHC forces 20 or so packages
>> (fixed to specific package versions) into the HP and takes away
>> authority from the HP release process. But now the difficult to explain
>> thing is that GHC also bundles the library part of CABAL but
>> deliberately leaves out CABAL's frontend tool `cabal-install` only to
>> justify the existence of the HP a bit more? :-)
>>
>
> Cabal is part of GHC's build process and GHC uses data types from Cabal.
> That's why it's there. It's not because we want Cabal to be included (just
> like we don't want to ship those libs.) These are technical limitations.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140122/5986a942/attachment.html>

From jwlato at gmail.com  Thu Jan 23 03:52:14 2014
From: jwlato at gmail.com (John Lato)
Date: Wed, 22 Jan 2014 19:52:14 -0800
Subject: Parallel building multiple targets
In-Reply-To: <52DF8085.8080108@gmail.com>
References: <20140105214723.GC12676@sli.dy.fi>
 <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
 <52DF8085.8080108@gmail.com>
Message-ID: <CAJ727GjvikpWeWEK1RUR1p0YcoZMo85bCB2hD_vwo6UVe-HBRQ@mail.gmail.com>

On Wed, Jan 22, 2014 at 12:25 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 05/01/2014 23:48, John Lato wrote:
>
>> (FYI, I expect I'm the source of the suggestion that ghc -M is broken)
>>
>> First, just to clarify, I don't think ghc -M is obviously broken.
>>   Rather, I think it's broken in subtle, unobvious ways, such that
>> trying to develop a make-based project with ghc -M will fail at various
>> times in a non-obvious fashion, at least without substantial additional
>> rules.
>>
>
> If I understand you correctly, you're not saying that ghc -M is broken,
> but that it would be easier to use if it did more.  Right?  Maybe you could
> make specific suggestions?  Saying it is "broken" is a bit FUD-ish.  We use
> it in GHC's build system, so by an existence proof it is certainly not
> broken.
>

This is more-or-less true.  To be a bit more precise, I'm saying that the
raw output from ghc -M is insufficient in several interesting/useful cases.
 I'm also not convinced that it's worth anyone's time to add the necessary
features to ghc -M to cover these cases, or indeed that it's even
necessarily the correct place to fix it.

Some specific shortcomings of ghc -M are:

1.  no support for .cmm file dependencies (though in fairness, --make
doesn't track these either)
2.  no support for Language.Haskell.TH.Syntax.addDependentFile
3.  no support for preprocessing, such as .hsc or #include'd files.  (I
think it would work to write a .hs file that uses -pgmF to call hsc2hs, but
that seems rather non-obvious and I'm not sure it's a good idea).

However, these are all rather obviously fixable as part of the build
system.  For me, the worst problems have to do with cleaning.  If you're
using a Makefile, typically you want to leave intermediate object files
around and only rebuild them when the sources have changed.  However, there
are various issues with ghc batch-mode that make this difficult (e.g.
https://ghc.haskell.org/trac/ghc/ticket/8029 ).  The workarounds to deal
with this are not as straightforward.  The alternative is to live with the
occasional build error that can only be fixed by blowing away the entire
build dir (a remedy that I often need with ghc's source tree, as even make
maintainer-clean doesn't always cut it.  Hopefully my experience here is
unique, but I do not believe it is).

Also, the most common use case seems to be for parallel building of
modules.  As ghc-7.8 provides this with --make, I'd expect the demand for
ghc -M will be greatly reduced.  That's why I'm not certain it's worth the
time it would take to resolve these issues.

Cheers,
John


> Cheers,
> Simon
>
>
>
>   For an example of some of the extra steps necessary to make
>
>> something like this work, see e.g.
>> https://github.com/nh2/multishake (which is admittedly for a more
>> complicated setup, and also has some issues).  The especially
>> frustrating part is, just when you think you have everything working,
>> someone wants to add some other tool to a workflow (hsc2hs, .cmm files,
>> etc), and your build system doesn't support it.
>>
>> ghc --make doesn't allow building several binaries in one run, however
>> if you use cabal all the separate runs will use a shared build
>> directory, so subsequent builds will be able to take advantage of the
>> intermediate output of the first build.  Of course you could do the same
>> without cabal, but it's a convenient way to create a common build
>> directory and manage multiple targets.  This is the approach I would
>> take to building multiple executables from the same source files.
>>
>> ghc doesn't do any locking of build files AFAIK.  Running parallel ghc
>> commands for two main modules that have the same import, using the same
>> working directory, is not safe.  In pathological cases the two different
>> main modules may even generate different code *for the imported module*.
>>   This sort of situation can arise with the IncoherentInstances
>> extension, for example.
>>
>> The obvious approach is of course to make a library out of your common
>> files.  This has the downsides of requiring a bit more work on the
>> developer's part, but if the common files are relatively stable it'll
>> probably lead to the fastest builds of your executables.  Also in this
>> case you could run multiple `ghc --make`s in parallel, using different
>> build directories, since they won't be rebuilding any common code.
>>
>> John L.
>>
>> On Sun, Jan 5, 2014 at 1:47 PM, Sami Liedes <sami.liedes at iki.fi
>> <mailto:sami.liedes at iki.fi>> wrote:
>>
>>     Hi,
>>
>>     I have a Haskell project where a number of executables are produced
>>     from mostly the same modules. I'm using a Makefile to enable parallel
>>     builds. I received advice[1] that ghc -M is broken, but that there
>>     is parallel ghc --make in HEAD.
>>
>>     As far as I can tell, ghc --make does not allow building several
>>     binaries in one run, so I think it may not still be a full replacement
>>     for Makefiles.
>>
>>     However I have a question about ghc --make that is also relevant
>>     without parallel ghc --make:
>>
>>     If I have two main modules, prog1.hs and prog2.hs, which have mutual
>>     dependencies (for example, both import A from A.hs), is it safe to run
>>     "ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there
>>     some kind of locking to prevent both from building module A at the
>>     same time and interfering with each other?
>>
>>     Is there a good way (either in current releases or HEAD) to build
>>     multiple binaries partially from the same sources in parallel?
>>
>>              Sami
>>
>>
>>     [1]
>>     http://stackoverflow.com/questions/20938894/generating-
>> correct-link-dependencies-for-ghc-and-makefile-style-builds
>>
>>     _______________________________________________
>>     Glasgow-haskell-users mailing list
>>     Glasgow-haskell-users at haskell.org
>>     <mailto:Glasgow-haskell-users at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140122/13f6c098/attachment-0001.html>

From marlowsd at gmail.com  Thu Jan 23 09:28:36 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 23 Jan 2014 09:28:36 +0000
Subject: Parallel building multiple targets
In-Reply-To: <CAJ727GjvikpWeWEK1RUR1p0YcoZMo85bCB2hD_vwo6UVe-HBRQ@mail.gmail.com>
References: <20140105214723.GC12676@sli.dy.fi>	<CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>	<52DF8085.8080108@gmail.com>
 <CAJ727GjvikpWeWEK1RUR1p0YcoZMo85bCB2hD_vwo6UVe-HBRQ@mail.gmail.com>
Message-ID: <52E0E0C4.7080403@gmail.com>

On 23/01/14 03:52, John Lato wrote:

> However, these are all rather obviously fixable as part of the build
> system.  For me, the worst problems have to do with cleaning.  If you're
> using a Makefile, typically you want to leave intermediate object files
> around and only rebuild them when the sources have changed.  However,
> there are various issues with ghc batch-mode that make this difficult
> (e.g. https://ghc.haskell.org/trac/ghc/ticket/8029 ).  The workarounds
> to deal with this are not as straightforward.  The alternative is to
> live with the occasional build error that can only be fixed by blowing
> away the entire build dir (a remedy that I often need with ghc's source
> tree, as even make maintainer-clean doesn't always cut it.  Hopefully my
> experience here is unique, but I do not believe it is).

You said "various issues", but you've only mentioned *one* specific 
issue so far: #8029, and we concluded that was not a bug, although I do 
see how it could require manually deleting a .hi file if you have a 
module that shadows a package module and then remove it.  This seems a 
rare occurrence to me, but perhaps it is something you do often.  If it 
really hurts, then you could have a way to tell your build system about 
a file when it is removed from the project, so that it can delete the 
build artifacts that go with it.

Anyway, are there other problems you'd like to bring to our attention?

Cheers,
Simon





> Also, the most common use case seems to be for parallel building of
> modules.  As ghc-7.8 provides this with --make, I'd expect the demand
> for ghc -M will be greatly reduced.  That's why I'm not certain it's
> worth the time it would take to resolve these issues.
>
> Cheers,
> John
>
>
>     Cheers,
>     Simon
>
>
>
>        For an example of some of the extra steps necessary to make
>
>         something like this work, see e.g.
>         https://github.com/nh2/__multishake
>         <https://github.com/nh2/multishake> (which is admittedly for a more
>         complicated setup, and also has some issues).  The especially
>         frustrating part is, just when you think you have everything
>         working,
>         someone wants to add some other tool to a workflow (hsc2hs, .cmm
>         files,
>         etc), and your build system doesn't support it.
>
>         ghc --make doesn't allow building several binaries in one run,
>         however
>         if you use cabal all the separate runs will use a shared build
>         directory, so subsequent builds will be able to take advantage
>         of the
>         intermediate output of the first build.  Of course you could do
>         the same
>         without cabal, but it's a convenient way to create a common build
>         directory and manage multiple targets.  This is the approach I would
>         take to building multiple executables from the same source files.
>
>         ghc doesn't do any locking of build files AFAIK.  Running
>         parallel ghc
>         commands for two main modules that have the same import, using
>         the same
>         working directory, is not safe.  In pathological cases the two
>         different
>         main modules may even generate different code *for the imported
>         module*.
>            This sort of situation can arise with the IncoherentInstances
>         extension, for example.
>
>         The obvious approach is of course to make a library out of your
>         common
>         files.  This has the downsides of requiring a bit more work on the
>         developer's part, but if the common files are relatively stable
>         it'll
>         probably lead to the fastest builds of your executables.  Also
>         in this
>         case you could run multiple `ghc --make`s in parallel, using
>         different
>         build directories, since they won't be rebuilding any common code.
>
>         John L.
>
>         On Sun, Jan 5, 2014 at 1:47 PM, Sami Liedes <sami.liedes at iki.fi
>         <mailto:sami.liedes at iki.fi>
>         <mailto:sami.liedes at iki.fi <mailto:sami.liedes at iki.fi>>> wrote:
>
>              Hi,
>
>              I have a Haskell project where a number of executables are
>         produced
>              from mostly the same modules. I'm using a Makefile to
>         enable parallel
>              builds. I received advice[1] that ghc -M is broken, but
>         that there
>              is parallel ghc --make in HEAD.
>
>              As far as I can tell, ghc --make does not allow building
>         several
>              binaries in one run, so I think it may not still be a full
>         replacement
>              for Makefiles.
>
>              However I have a question about ghc --make that is also
>         relevant
>              without parallel ghc --make:
>
>              If I have two main modules, prog1.hs and prog2.hs, which
>         have mutual
>              dependencies (for example, both import A from A.hs), is it
>         safe to run
>              "ghc --make prog1" in parallel with "ghc --make prog2"?
>         IOW, is there
>              some kind of locking to prevent both from building module A
>         at the
>              same time and interfering with each other?
>
>              Is there a good way (either in current releases or HEAD) to
>         build
>              multiple binaries partially from the same sources in parallel?
>
>                       Sami
>
>
>              [1]
>         http://stackoverflow.com/__questions/20938894/generating-__correct-link-dependencies-for-__ghc-and-makefile-style-builds
>         <http://stackoverflow.com/questions/20938894/generating-correct-link-dependencies-for-ghc-and-makefile-style-builds>
>
>              _________________________________________________
>              Glasgow-haskell-users mailing list
>         Glasgow-haskell-users at haskell.__org
>         <mailto:Glasgow-haskell-users at haskell.org>
>              <mailto:Glasgow-haskell-users at __haskell.org
>         <mailto:Glasgow-haskell-users at haskell.org>>
>         http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
>
>
>
>
>         _________________________________________________
>         Glasgow-haskell-users mailing list
>         Glasgow-haskell-users at haskell.__org
>         <mailto:Glasgow-haskell-users at haskell.org>
>         http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
>


From jwlato at gmail.com  Thu Jan 23 18:22:47 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 23 Jan 2014 10:22:47 -0800
Subject: Parallel building multiple targets
In-Reply-To: <52E0E0C4.7080403@gmail.com>
References: <20140105214723.GC12676@sli.dy.fi>
 <CAJ727GiD17sBY50r_k_YW-9bu8Ec8sei8h8cFZEa_vSAZTWerg@mail.gmail.com>
 <52DF8085.8080108@gmail.com>
 <CAJ727GjvikpWeWEK1RUR1p0YcoZMo85bCB2hD_vwo6UVe-HBRQ@mail.gmail.com>
 <52E0E0C4.7080403@gmail.com>
Message-ID: <CAJ727GimWj8iMCnBKZuTgGWa5USNcoOcR1j-pBZP57BJVmzf-Q@mail.gmail.com>

On Jan 23, 2014 1:28 AM, "Simon Marlow" <marlowsd at gmail.com> wrote:
>
> On 23/01/14 03:52, John Lato wrote:
>
>> However, these are all rather obviously fixable as part of the build
>> system.  For me, the worst problems have to do with cleaning.  If you're
>> using a Makefile, typically you want to leave intermediate object files
>> around and only rebuild them when the sources have changed.  However,
>> there are various issues with ghc batch-mode that make this difficult
>> (e.g. https://ghc.haskell.org/trac/ghc/ticket/8029 ).  The workarounds
>> to deal with this are not as straightforward.  The alternative is to
>> live with the occasional build error that can only be fixed by blowing
>> away the entire build dir (a remedy that I often need with ghc's source
>> tree, as even make maintainer-clean doesn't always cut it.  Hopefully my
>> experience here is unique, but I do not believe it is).
>
>
> You said "various issues", but you've only mentioned *one* specific issue
so far: #8029, and we concluded that was not a bug, although I do see how
it could require manually deleting a .hi file if you have a module that
shadows a package module and then remove it.  This seems a rare occurrence
to me, but perhaps it is something you do often.  If it really hurts, then
you could have a way to tell your build system about a file when it is
removed from the project, so that it can delete the build artifacts that go
with it.

It seems uncommon until you're developing in a branch that does so, and try
to go back and forth between that branch and another.

>
> Anyway, are there other problems you'd like to bring to our attention?

If the one bug I linked to earlier is to be closed as "not a bug" (seems
correct to me), there doesn't seem much point to raising other issues
relating to out-of-date intermediate files.  The general solution is
exactly as you suggested, leading to an increasingly baroque build system.

I don't think any of this detracts from my original thrust, which is that
something that looks like an afternoon's work is much more complicated.
Plus, you'll end up fighting with/hacking on a build system instead of what
you meant to work on.

>
> Cheers,
> Simon
>
>
>
>
>
>> Also, the most common use case seems to be for parallel building of
>> modules.  As ghc-7.8 provides this with --make, I'd expect the demand
>> for ghc -M will be greatly reduced.  That's why I'm not certain it's
>> worth the time it would take to resolve these issues.
>>
>> Cheers,
>> John
>>
>>
>>     Cheers,
>>     Simon
>>
>>
>>
>>        For an example of some of the extra steps necessary to make
>>
>>         something like this work, see e.g.
>>         https://github.com/nh2/__multishake
>>
>>         <https://github.com/nh2/multishake> (which is admittedly for a
more
>>         complicated setup, and also has some issues).  The especially
>>         frustrating part is, just when you think you have everything
>>         working,
>>         someone wants to add some other tool to a workflow (hsc2hs, .cmm
>>         files,
>>         etc), and your build system doesn't support it.
>>
>>         ghc --make doesn't allow building several binaries in one run,
>>         however
>>         if you use cabal all the separate runs will use a shared build
>>         directory, so subsequent builds will be able to take advantage
>>         of the
>>         intermediate output of the first build.  Of course you could do
>>         the same
>>         without cabal, but it's a convenient way to create a common build
>>         directory and manage multiple targets.  This is the approach I
would
>>         take to building multiple executables from the same source files.
>>
>>         ghc doesn't do any locking of build files AFAIK.  Running
>>         parallel ghc
>>         commands for two main modules that have the same import, using
>>         the same
>>         working directory, is not safe.  In pathological cases the two
>>         different
>>         main modules may even generate different code *for the imported
>>         module*.
>>            This sort of situation can arise with the IncoherentInstances
>>         extension, for example.
>>
>>         The obvious approach is of course to make a library out of your
>>         common
>>         files.  This has the downsides of requiring a bit more work on
the
>>         developer's part, but if the common files are relatively stable
>>         it'll
>>         probably lead to the fastest builds of your executables.  Also
>>         in this
>>         case you could run multiple `ghc --make`s in parallel, using
>>         different
>>         build directories, since they won't be rebuilding any common
code.
>>
>>         John L.
>>
>>         On Sun, Jan 5, 2014 at 1:47 PM, Sami Liedes <sami.liedes at iki.fi
>>         <mailto:sami.liedes at iki.fi>
>>         <mailto:sami.liedes at iki.fi <mailto:sami.liedes at iki.fi>>> wrote:
>>
>>              Hi,
>>
>>              I have a Haskell project where a number of executables are
>>         produced
>>              from mostly the same modules. I'm using a Makefile to
>>         enable parallel
>>              builds. I received advice[1] that ghc -M is broken, but
>>         that there
>>              is parallel ghc --make in HEAD.
>>
>>              As far as I can tell, ghc --make does not allow building
>>         several
>>              binaries in one run, so I think it may not still be a full
>>         replacement
>>              for Makefiles.
>>
>>              However I have a question about ghc --make that is also
>>         relevant
>>              without parallel ghc --make:
>>
>>              If I have two main modules, prog1.hs and prog2.hs, which
>>         have mutual
>>              dependencies (for example, both import A from A.hs), is it
>>         safe to run
>>              "ghc --make prog1" in parallel with "ghc --make prog2"?
>>         IOW, is there
>>              some kind of locking to prevent both from building module A
>>         at the
>>              same time and interfering with each other?
>>
>>              Is there a good way (either in current releases or HEAD) to
>>         build
>>              multiple binaries partially from the same sources in
parallel?
>>
>>                       Sami
>>
>>
>>              [1]
>>
http://stackoverflow.com/__questions/20938894/generating-__correct-link-dependencies-for-__ghc-and-makefile-style-builds
>>         <
http://stackoverflow.com/questions/20938894/generating-correct-link-dependencies-for-ghc-and-makefile-style-builds
>
>>
>>              _________________________________________________
>>              Glasgow-haskell-users mailing list
>>         Glasgow-haskell-users at haskell.__org
>>         <mailto:Glasgow-haskell-users at haskell.org>
>>              <mailto:Glasgow-haskell-users at __haskell.org
>>         <mailto:Glasgow-haskell-users at haskell.org>>
>>         http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users<
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>>
>>
>>
>>
>>
>>         _________________________________________________
>>         Glasgow-haskell-users mailing list
>>         Glasgow-haskell-users at haskell.__org
>>         <mailto:Glasgow-haskell-users at haskell.org>
>>         http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users<
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140123/cae6db93/attachment.html>

From facundo.dominguez at tweag.io  Fri Jan 24 17:19:42 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Fri, 24 Jan 2014 15:19:42 -0200
Subject: Static values language extension proposal
Message-ID: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>

Hello,
    With the support of Tweag I/O, Mathieu and I have been assembling
a design proposal for the language extension for Static values that
will take Cloud Haskell a big step forward in usability. Please, find
the proposal inlined below.

    We are looking forward to discuss its feasibility and features
with the community.

Best,
Facundo

--

In these notes we discuss a design of the language extension proposed
in [1] for Cloud Haskell. That is, support from the compiler to
produce labels that can be used to identify Haskell top-level bindings
across processes in a network.

Static values
=========

Following [1], the extension consists of a new syntactic form `static
e`, along with a type constructor `StaticRef` and a function

unstatic :: StaticRef a -> a

The idea is that values of type `StaticRef a` uniquely identify a
value that can be referred to by a global name rather than serialized
over the network between processes that are instances of a single
binary, because all such processes share the same top-level bindings.

Generating static references
====================

We start by introducing global names. A `GlobalName` is a symbol bound
in the top-level environment. It is much like global names in Template
Haskell, but `GlobalNames` always refer to terms, and they include a
package version.

data GlobalName = GlobalName PkgName PkgVersion ModName OccName

`GlobalNames` can be used as references to static values.

newtype StaticRef a = StaticRef GlobalName

`StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper
with a phantom type parameter that keeps track of the type of the
value that is referenced.

The special form

static e

is an expression of type `StaticRef a` where `e :: a` is a closed
expression (meaning any free variables in `e` are bound in the
top-level environment).

If `e` is an identifier, `static e` just refers to it. Otherwise, the
compiler needs to introduce a new top-level binding with a fresh name
and the expression used as right-hand side, and the static reference
would point to this top-level binding instead.

Looking up static references
====================

`unstatic` is implemented as a function which finds a top-level value
from the `GlobalName`, otherwise it raises an exception. It crucially
relies on leveraging the system?s dynamic linker, so out-of-the-box
only works with dynamically linked binaries (but see below).
`unstatic` proceeds as follows:

  * Determines the name of the shared library from the package name
and the package version.

  * Determines the symbol of the value by Z-Encoding the package name,
the module name and the value name.

  * Uses the system?s dynamic linker interface to obtain the address
of the symbol.

  * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#`

In principle, only symbols in shared libraries can be found. However,
the dynamic linker is able to find symbols in modules that are linked
statically if GHC is fed with the option -optl-Wl,--export-dynamic. A
future enhancement could be to have GHC warn the user when modules
using the extension are linked statically and this option is not used
during linking.

GHC only defines symbols for exported definitions in modules. So
unstatic won?t be able to find the private bindings of a module. For
this sake, the implementation of static should in addition ensure that
the bindings it gets will appear in the symbol table when they are not
exported by their defining modules.

Template Haskell support
==================

The static keyword needs to be made available in Template Haskell so
the distributed-static package can benefit from this language
extension.

Rationale
=======

We want the language extension to meet the following requirements:

  1. It must be a practical alternative to the remoteTable functions
in the distributed-static package.

  2. It must not change the build scheme used for Haskell programs. A
collection of .o files produced from Haskell source code should still
be possible to link with the system linking tools.

  3. It must not restrict all communicating processes using the
extension to be launched from the same binary.

  4. It must not significantly increase the binary size.

(1) is addressed by replacing remote tables with the symbol tables
produced by the compiler. Additionally, Template Haskell support is
included so that the existing distributed-static package can be
adapted and extended to include this extension.

(2) is addressed by choosing a scheme which does not require the
linker to perform any extension-specific procedure to collect the
static values in various modules. There?s a trade off here though,
since symbols in statically linked modules cannot be accessed unless
-optl-Wl,--export-dynamic is supplied during linking.

(3) is addressed by allowing programs to exchange static values for
any bindings found in the modules they share.

(4) is addressed by reusing the symbol tables produced by the compiler
in object files rather than creating separate remote tables.

About the need for using different binaries
==============================

While using distributed-process we found some use cases for supporting
communicating closures between multiple binaries.

One of these use cases involved a distributed application and a
monitoring tool. The monitoring tool would need to link in some
graphics libraries to display information on the screen, none of which
were required by the monitored application. Conversely, the monitored
application would link in some modules that the monitoring application
didn?t need. Crucially, both applications are fairly loosely coupled,
even if they both need to exchange static values about bindings in
some modules they shared.

An analogous use case involved the distributed application and a
control application that would be used to change dynamic settings of
the former.

Further Work
==========

As the application depends on shared libraries, now a tool to collect
these libraries would be required so they can be distributed together
with the executable binary when deploying a Cloud Haskell application
in a cluster. We won?t delve further into this problem.

Another possible line of work is extending this approach so a process
can pull shared objects from a remote peer, when this remote peer
sends a static value that is defined in a shared object not available
to the process.

Integration with distributed-static
=======================

The package distributed-static could either adopt this extension as
the only implementation of static values, or it could support many
notions of static references, say by using a type class to overload
`unstatic`.

class Static st s | s -> st where
   unstatic :: st -> s a -> Either String a

where the class parameter `st` is provided for backwards compatibility
with the existing scheme to provide context-dependent information. The
extension we present here does not depend on this parameter, so `()`
could be used for the `StaticRef` instance.

instance Static () StaticRef where ...

References
========

[1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards
Haskell in the cloud. SIGPLAN Not., 46(12):118?129, September 2011.
ISSN 0362-1340.

From carter.schonwald at gmail.com  Fri Jan 24 17:59:05 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 24 Jan 2014 12:59:05 -0500
Subject: Static values language extension proposal
In-Reply-To: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
Message-ID: <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>

Hey Facundo,

thanks for sharing this proposal.

several questions:

0) I think you could actually implement this proposal as a userland
library, at least as you've described it. Have you tried doing so?

1) what does this accomplish that can not be accomplished by having various
nodes agree on a DSL, and sending ASTs to each other?
     1a) in fact, I'd argue (and some others agree, and i'll admit my
opinions have been shaped by those more expert than me) that the sending a
wee AST you can interpret on the other side is much SAFER than "sending a
function symbol thats hard coded hopefully into both programs in a way that
it means the same thing".  I've had many educational conversations with

2) how does it provide more type safety than the current TH based approach?
(I've seen Tim and others hit very very gnarly bugs in cloud haskell based
upon the "magic static values" approach).

3) this proposal requires changes to linking etc that would really make it
useful only on systems and deployments that only have Template Haskell AND
Dynamic linking.  (and also rules out any context where it'd be nice to
deploy a static app or say, use CH in ios! )


to repeat: have you considered defining an AST type + interpreter for the
computations you want to send around, and doing that? I think its a much
simpler, safer, easier, flexible and PORTABLE approach, though one current
CH doesn't do (though the folks working on CH seem to be receptive to
switching to such a strategy if someone validates it)

cheers
-Carter



On Fri, Jan 24, 2014 at 12:19 PM, Facundo Dom?nguez <
facundo.dominguez at tweag.io> wrote:

> Hello,
>     With the support of Tweag I/O, Mathieu and I have been assembling
> a design proposal for the language extension for Static values that
> will take Cloud Haskell a big step forward in usability. Please, find
> the proposal inlined below.
>
>     We are looking forward to discuss its feasibility and features
> with the community.
>
> Best,
> Facundo
>
> --
>
> In these notes we discuss a design of the language extension proposed
> in [1] for Cloud Haskell. That is, support from the compiler to
> produce labels that can be used to identify Haskell top-level bindings
> across processes in a network.
>
> Static values
> =========
>
> Following [1], the extension consists of a new syntactic form `static
> e`, along with a type constructor `StaticRef` and a function
>
> unstatic :: StaticRef a -> a
>
> The idea is that values of type `StaticRef a` uniquely identify a
> value that can be referred to by a global name rather than serialized
> over the network between processes that are instances of a single
> binary, because all such processes share the same top-level bindings.
>
> Generating static references
> ====================
>
> We start by introducing global names. A `GlobalName` is a symbol bound
> in the top-level environment. It is much like global names in Template
> Haskell, but `GlobalNames` always refer to terms, and they include a
> package version.
>
> data GlobalName = GlobalName PkgName PkgVersion ModName OccName
>
> `GlobalNames` can be used as references to static values.
>
> newtype StaticRef a = StaticRef GlobalName
>
> `StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper
> with a phantom type parameter that keeps track of the type of the
> value that is referenced.
>
> The special form
>
> static e
>
> is an expression of type `StaticRef a` where `e :: a` is a closed
> expression (meaning any free variables in `e` are bound in the
> top-level environment).
>
> If `e` is an identifier, `static e` just refers to it. Otherwise, the
> compiler needs to introduce a new top-level binding with a fresh name
> and the expression used as right-hand side, and the static reference
> would point to this top-level binding instead.
>
> Looking up static references
> ====================
>
> `unstatic` is implemented as a function which finds a top-level value
> from the `GlobalName`, otherwise it raises an exception. It crucially
> relies on leveraging the system?s dynamic linker, so out-of-the-box
> only works with dynamically linked binaries (but see below).
> `unstatic` proceeds as follows:
>
>   * Determines the name of the shared library from the package name
> and the package version.
>
>   * Determines the symbol of the value by Z-Encoding the package name,
> the module name and the value name.
>
>   * Uses the system?s dynamic linker interface to obtain the address
> of the symbol.
>
>   * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#`
>
> In principle, only symbols in shared libraries can be found. However,
> the dynamic linker is able to find symbols in modules that are linked
> statically if GHC is fed with the option -optl-Wl,--export-dynamic. A
> future enhancement could be to have GHC warn the user when modules
> using the extension are linked statically and this option is not used
> during linking.
>
> GHC only defines symbols for exported definitions in modules. So
> unstatic won?t be able to find the private bindings of a module. For
> this sake, the implementation of static should in addition ensure that
> the bindings it gets will appear in the symbol table when they are not
> exported by their defining modules.
>
> Template Haskell support
> ==================
>
> The static keyword needs to be made available in Template Haskell so
> the distributed-static package can benefit from this language
> extension.
>
> Rationale
> =======
>
> We want the language extension to meet the following requirements:
>
>   1. It must be a practical alternative to the remoteTable functions
> in the distributed-static package.
>
>   2. It must not change the build scheme used for Haskell programs. A
> collection of .o files produced from Haskell source code should still
> be possible to link with the system linking tools.
>
>   3. It must not restrict all communicating processes using the
> extension to be launched from the same binary.
>
>   4. It must not significantly increase the binary size.
>
> (1) is addressed by replacing remote tables with the symbol tables
> produced by the compiler. Additionally, Template Haskell support is
> included so that the existing distributed-static package can be
> adapted and extended to include this extension.
>
> (2) is addressed by choosing a scheme which does not require the
> linker to perform any extension-specific procedure to collect the
> static values in various modules. There?s a trade off here though,
> since symbols in statically linked modules cannot be accessed unless
> -optl-Wl,--export-dynamic is supplied during linking.
>
> (3) is addressed by allowing programs to exchange static values for
> any bindings found in the modules they share.
>
> (4) is addressed by reusing the symbol tables produced by the compiler
> in object files rather than creating separate remote tables.
>
> About the need for using different binaries
> ==============================
>
> While using distributed-process we found some use cases for supporting
> communicating closures between multiple binaries.
>
> One of these use cases involved a distributed application and a
> monitoring tool. The monitoring tool would need to link in some
> graphics libraries to display information on the screen, none of which
> were required by the monitored application. Conversely, the monitored
> application would link in some modules that the monitoring application
> didn?t need. Crucially, both applications are fairly loosely coupled,
> even if they both need to exchange static values about bindings in
> some modules they shared.
>
> An analogous use case involved the distributed application and a
> control application that would be used to change dynamic settings of
> the former.
>
> Further Work
> ==========
>
> As the application depends on shared libraries, now a tool to collect
> these libraries would be required so they can be distributed together
> with the executable binary when deploying a Cloud Haskell application
> in a cluster. We won?t delve further into this problem.
>
> Another possible line of work is extending this approach so a process
> can pull shared objects from a remote peer, when this remote peer
> sends a static value that is defined in a shared object not available
> to the process.
>
> Integration with distributed-static
> =======================
>
> The package distributed-static could either adopt this extension as
> the only implementation of static values, or it could support many
> notions of static references, say by using a type class to overload
> `unstatic`.
>
> class Static st s | s -> st where
>    unstatic :: st -> s a -> Either String a
>
> where the class parameter `st` is provided for backwards compatibility
> with the existing scheme to provide context-dependent information. The
> extension we present here does not depend on this parameter, so `()`
> could be used for the `StaticRef` instance.
>
> instance Static () StaticRef where ...
>
> References
> ========
>
> [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards
> Haskell in the cloud. SIGPLAN Not., 46(12):118?129, September 2011.
> ISSN 0362-1340.
>
> --
> You received this message because you are subscribed to the Google Groups
> "parallel-haskell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to parallel-haskell+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140124/b59aeedd/attachment-0001.html>

From watson.timothy at gmail.com  Fri Jan 24 18:06:58 2014
From: watson.timothy at gmail.com (Tim Watson)
Date: Fri, 24 Jan 2014 18:06:58 +0000
Subject: Static values language extension proposal
In-Reply-To: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
Message-ID: <D548FA98-4E47-4E8E-A5DB-52944F44443F@gmail.com>

I don't have time to weigh in on this proposal right now, but I have several comments...

On 24 Jan 2014, at 17:19, Facundo Dom?nguez wrote:
> Rationale
> =======
> 
> We want the language extension to meet the following requirements:
> 
>  1. It must be a practical alternative to the remoteTable functions
> in the distributed-static package.
> 

Agreed - this is vital!

>  2. It must not change the build scheme used for Haskell programs. A
> collection of .o files produced from Haskell source code should still
> be possible to link with the system linking tools.
> 

Also vital.

>  3. It must not restrict all communicating processes using the
> extension to be launched from the same binary.
> 

I personally think this is very valuable.

> About the need for using different binaries
> ==============================
> 
> While using distributed-process we found some use cases for supporting
> communicating closures between multiple binaries.
> 
> One of these use cases involved a distributed application and a
> monitoring tool. The monitoring tool would need to link in some
> graphics libraries to display information on the screen, none of which
> were required by the monitored application. Conversely, the monitored
> application would link in some modules that the monitoring application
> didn?t need. Crucially, both applications are fairly loosely coupled,
> even if they both need to exchange static values about bindings in
> some modules they shared.

Indeed - this is an almost canonical use-case, as are administrative (e.g., remote management) tools.

> As the application depends on shared libraries, now a tool to collect
> these libraries would be required so they can be distributed together
> with the executable binary when deploying a Cloud Haskell application
> in a cluster. We won?t delve further into this problem.

Great idea.

> 
> Another possible line of work is extending this approach so a process
> can pull shared objects from a remote peer, when this remote peer
> sends a static value that is defined in a shared object not available
> to the process.

This would go a long way towards answering our questions about 'hot code upgrade' and be useful in many other areas too.


From watson.timothy at gmail.com  Fri Jan 24 18:20:05 2014
From: watson.timothy at gmail.com (Tim Watson)
Date: Fri, 24 Jan 2014 18:20:05 +0000
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
Message-ID: <B1122717-A3BB-4BD2-9624-092D84444466@gmail.com>

On 24 Jan 2014, at 17:59, Carter Schonwald wrote:
> 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? 
> 

I didn't pick up on that at all - how would we be able to do that?

> 1) what does this accomplish that can not be accomplished by having various nodes agree on a DSL, and sending ASTs to each other?
>      1a) in fact, I'd argue (and some others agree, and i'll admit my opinions have been shaped by those more expert than me) that the sending a wee AST you can interpret on the other side is much SAFER than "sending a function symbol thats hard coded hopefully into both programs in a way that it means the same thing".  I've had many educational conversations with 
> 

I've still not seen a convincing example of how to do this though. It would help if someone explained what this would look like, running over two (or more) separate binaries and still shipping code. It's just that, afaict, that AST wouldn't be so "wee" once it had to represent any arbitrary expression. One could, of course, just ship source (or some intermediate representation), but that would also require compiler infrastructure to be installed on the target.

> 2) how does it provide more type safety than the current TH based approach? (I've seen Tim and others hit very very gnarly bugs in cloud haskell based upon the "magic static values" approach). 
> 

This is definitely true, but I see it as a problem related to our use of TH rather than our current use of closures and 'Static' per se. Having said that, it can be toe-curlingly difficult to work with closure/static sometimes, so *anything* that makes this easier sounds good to me.

> 
> to repeat: have you considered defining an AST type + interpreter for the computations you want to send around, and doing that? I think its a much simpler, safer, easier, flexible and PORTABLE approach, though one current CH doesn't do (though the folks working on CH seem to be receptive to switching to such a strategy if someone validates it)
> 

I/we are, I think, amenable to doing whatever makes the most sense. This could include doing more than one thing, when it comes to dealing with 'statics'. Personally I think the proposal sounds interesting, though as I mentioned in my previously mail, I haven't had time to sit down and look at it in detail yet.

Cheers,
Tim

From allbery.b at gmail.com  Fri Jan 24 18:53:23 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 24 Jan 2014 13:53:23 -0500
Subject: Static values language extension proposal
In-Reply-To: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
Message-ID: <CAKFCL4XzpL_p7+9zU-yHNsGf1fganLoSXyom7-1G7s9HSxHM5g@mail.gmail.com>

On Fri, Jan 24, 2014 at 12:19 PM, Facundo Dom?nguez <
facundo.dominguez at tweag.io> wrote:

> In principle, only symbols in shared libraries can be found. However,
> the dynamic linker is able to find symbols in modules that are linked
> statically if GHC is fed with the option -optl-Wl,--export-dynamic. A
>

This strikes me as highly platform specific to the Linux and possibly
FreeBSD implementations of ELF; it likely will not work with Solaris ELF,
which handles dynamic symbols differently (or at least used to), and will
not work with non-ELF platforms (OS X, Windows) and probably won't work
with a non-GNU ld such as is used on Solaris and OS X.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140124/f8bbe5eb/attachment.html>

From 0xbadcode at gmail.com  Fri Jan 24 20:19:04 2014
From: 0xbadcode at gmail.com (Mathieu Boespflug)
Date: Fri, 24 Jan 2014 21:19:04 +0100
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
Message-ID: <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>

[Sorry for the multiple reposts - couldn't quite figure out which
email address doesn't get refused by the list..]


Hi Carter,

thank you for the good points you raise. I'll try and address each of
them as best I can below.

> 0) I think you could actually implement this proposal as a userland library,
> at least as you've described it. Have you tried doing so?

Indeed, this could be done without touching the compiler at all. We
thought long and hard about a path that would ultimately make an
extension either unnecessary, or at any rate very small. At this
point, the only thing that we are proposing to add to the compiler is
the syntactic form "static e". Contrary to the presentation in the
paper, the 'unstatic' function can be implemented entirely as library
code and does not need to be a primop. Moreover, we do not need to
piece together any kind of global remote table at compile time or link
time, because we're piggy backing on that already constructed by the
system linker.

The `static e` form could as well be a piece of Template Haskell, but
making it a proper extension means that the compiler can enforce more
invariants and be a bit more helpful to the user. In particular,
detecting situations where symbolic references cannot be generated
because e.g. the imported packages were not compiled as dynamic linked
libraries. Or seamlessly supporting calling `static f` on an idenfier
`f` that is not exported by the module.

> 1) what does this accomplish that can not be accomplished by having various
> nodes agree on a DSL, and sending ASTs to each other?
>      1a) in fact, I'd argue (and some others agree, and i'll admit my
> opinions have been shaped by those more expert than me) that the sending a
> wee AST you can interpret on the other side is much SAFER than "sending a
> function symbol thats hard coded hopefully into both programs in a way that
> it means the same thing".

I very much subscribe to the idea of defining small DSL's for
exchanging code between nodes. And this proposal is compatible with
that idea.

One thing that might not have been so clear in the original email is
that we are proposing here to introduce just *one such DSL*. It's just
that it's a trivial one whose grammar only contains linker symbol
names.

As it happens, distributed-static today already supports two such
DSL's: a DSL of labels, which are arbitrary string names for
functions, and a small language for composing Static values together.
There is a patch lying around by Edsko proposing to add a third "DSL":
one that allows nodes to trade arbitrary Haskell strings that are then
eval'ed on the other end by the 'plugins' package.

As Facundo explains at the end of his email, the notion of a "static"
value ought to be a more general one than was first envisioned in the
paper: a static value is any closed denotation, denoted in any of a
choice of multiple small languages, some of which ship standard with
distributed-static. The user can define his own DSL for shipping code
around.

This is why we propose to make Static into a class. Each DSL is
generated by one datatype. Each such datatype has a Static instance.
If you would like to ship an AST around the cluster, you can make the
datatype for that AST an instance of Static, with 'unstatic' being
defined as an interpreter for your AST.

Concretely:

data HsExpr = ...

instance Static HsExpr where
  unstatic e = Hs.interpret e

> I've had many educational conversations with

... ?

> 2) how does it provide more type safety than the current TH based approach?
> (I've seen Tim and others hit very very gnarly bugs in cloud haskell based
> upon the "magic static values" approach).

The type safety of the current TH approach is reasonable I think. One
potential problem comes from managing dynamically typed values in the
remote table, which must be coerced to the right type and use the
right decoders if you don't use TH. With the approach we propose,
there is no remote table, so I guess this should help eliminate a
source of bugs.

> 3) this proposal requires changes to linking etc that would really make it
> useful only on systems and deployments that only have Template Haskell AND
> Dynamic linking.  (and also rules out any context where it'd be nice to
> deploy a static app or say, use CH in ios! )

I don't know about iOS. And it's very likely that there are contexts
in which this extension doesn't work. But as I said above, you are
always free to define your own DSL's that cover the particular use
case that you have in mind. The nice thing with this particular DSL is
that it requires little to no TH to generate label names, which can
always be a source of bugs, especially when you forget to include them
in the global remote table (which is something that TH doesn't and
can't help you with).

Furthermore, it was my understanding that GHC is heading towards a
world of "dynamic linkable by default", and it is by now something
that is supported on most platforms by GHC. See e.g.

https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms

There are fairly good solutions to deploy self contained dynamically
linked apps these days, e.g. Docker. And in any case, with a few extra
flags we can still do away with the dynamic linking requirement on
some (all?) platforms.

> to repeat: have you considered defining an AST type + interpreter for the
> computations you want to send around, and doing that? I think its a much
> simpler, safer, easier, flexible and PORTABLE approach, though one current
> CH doesn't do (though the folks working on CH seem to be receptive to
> switching to such a strategy if someone validates it)

We have, and it's an option with different tradeoffs. Both solutions
could gainfully live side by side and are in fact complementary. I
contend that the solution described by Facundo has the advantage of
eliminating much of the syntactic overhead associated with sending
references to (higher-order) values across the cluster. We have more
ideas specific to distributed-process which we can discuss in a
separate thread to reduce the syntactic overhead even further, to
practically nothing.

Best,

Mathieu

From carter.schonwald at gmail.com  Sat Jan 25 18:12:01 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 25 Jan 2014 13:12:01 -0500
Subject: Static values language extension proposal
In-Reply-To: <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
Message-ID: <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>

anyways

1) you should (once 7.8 is out) evaluate how far you can push your ideas
wrt dynamic loading as a user land library.
 If you can't make it work as a library and can demonstrate why (or how
even though it works its not quite satisfactory), thats signals something!

But I really think insisting that the linker symbol names denote the "datum
agreement" in a distributed system is punting on what should be handled at
the application level. Simon Marlow put some improvements into GHC to help
improve doing dynamic code (un)loading, stress test that!

 Theres quite a few industrial haskell shops that provide products /
services where internally they do runtime dynamic loading of user provided
object files, so i'm sure that the core GHC support is there if you
actually dig into the apis! And they do this in a distributed systems
context, sans CH.

2) I've a work in progress on specing out a proper (and sound :) ) static
values type extension for ghc, that will be usable perhaps in your your
case (though by dint of being sound, will preclude some of the things you
think you want). BUT, any type system changes need to actually provide
safety. My motivation for having a notion of static values comes from a
desire to add compiler support for certain numerical computing operations
that require compiler support to be usable in haskell. BUT, much of the
same work

@tim: what on earth does "sending arbitrary code" mean? I feel like the
more precise thing everyone here wants is "for a given application /
infrastructure deployment, I would to be able to send my application
specific computations over the network, using cloud haskell, and be sure
that both sides think its the same code".

As for *how* to send an AST fragment, edward kmett and other have some
pretty nice typed AST models that are easy to adapt and extend for an
application specific use case. Bound
http://hackage.haskell.org/package/bound is one nice one.

heres a really really good school of haskell exposition
https://www.fpcomplete.com/user/edwardk/bound

And theres a generalization that supports strong typing that i've copied
from an hpaste https://gist.github.com/cartazio/5727196, where its notable
that the AST data type is called "Remote" :),
I think thats a hint its meant to be a haskell manipulable way of
constructing a typed DSL you can serialize using a finally tagless style
api approach (ie have a set of type class instances / operations that you
use to run the computation and/or construct the AST you can send over the
wire)




On Fri, Jan 24, 2014 at 3:19 PM, Mathieu Boespflug <0xbadcode at gmail.com>wrote:

> [Sorry for the multiple reposts - couldn't quite figure out which
> email address doesn't get refused by the list..]
>
>
> Hi Carter,
>
> thank you for the good points you raise. I'll try and address each of
> them as best I can below.
>
> > 0) I think you could actually implement this proposal as a userland
> library,
> > at least as you've described it. Have you tried doing so?
>
> Indeed, this could be done without touching the compiler at all. We
> thought long and hard about a path that would ultimately make an
> extension either unnecessary, or at any rate very small. At this
> point, the only thing that we are proposing to add to the compiler is
> the syntactic form "static e". Contrary to the presentation in the
> paper, the 'unstatic' function can be implemented entirely as library
> code and does not need to be a primop. Moreover, we do not need to
> piece together any kind of global remote table at compile time or link
> time, because we're piggy backing on that already constructed by the
> system linker.
>
> The `static e` form could as well be a piece of Template Haskell, but
> making it a proper extension means that the compiler can enforce more
> invariants and be a bit more helpful to the user. In particular,
> detecting situations where symbolic references cannot be generated
> because e.g. the imported packages were not compiled as dynamic linked
> libraries. Or seamlessly supporting calling `static f` on an idenfier
> `f` that is not exported by the module.
>
> > 1) what does this accomplish that can not be accomplished by having
> various
> > nodes agree on a DSL, and sending ASTs to each other?
> >      1a) in fact, I'd argue (and some others agree, and i'll admit my
> > opinions have been shaped by those more expert than me) that the sending
> a
> > wee AST you can interpret on the other side is much SAFER than "sending a
> > function symbol thats hard coded hopefully into both programs in a way
> that
> > it means the same thing".
>
> I very much subscribe to the idea of defining small DSL's for
> exchanging code between nodes. And this proposal is compatible with
> that idea.
>
> One thing that might not have been so clear in the original email is
> that we are proposing here to introduce just *one such DSL*. It's just
> that it's a trivial one whose grammar only contains linker symbol
> names.
>
> As it happens, distributed-static today already supports two such
> DSL's: a DSL of labels, which are arbitrary string names for
> functions, and a small language for composing Static values together.
> There is a patch lying around by Edsko proposing to add a third "DSL":
> one that allows nodes to trade arbitrary Haskell strings that are then
> eval'ed on the other end by the 'plugins' package.
>
> As Facundo explains at the end of his email, the notion of a "static"
> value ought to be a more general one than was first envisioned in the
> paper: a static value is any closed denotation, denoted in any of a
> choice of multiple small languages, some of which ship standard with
> distributed-static. The user can define his own DSL for shipping code
> around.
>
> This is why we propose to make Static into a class. Each DSL is
> generated by one datatype. Each such datatype has a Static instance.
> If you would like to ship an AST around the cluster, you can make the
> datatype for that AST an instance of Static, with 'unstatic' being
> defined as an interpreter for your AST.
>
> Concretely:
>
> data HsExpr = ...
>
> instance Static HsExpr where
>   unstatic e = Hs.interpret e
>
> > I've had many educational conversations with
>
> ... ?
>
> > 2) how does it provide more type safety than the current TH based
> approach?
> > (I've seen Tim and others hit very very gnarly bugs in cloud haskell
> based
> > upon the "magic static values" approach).
>
> The type safety of the current TH approach is reasonable I think. One
> potential problem comes from managing dynamically typed values in the
> remote table, which must be coerced to the right type and use the
> right decoders if you don't use TH. With the approach we propose,
> there is no remote table, so I guess this should help eliminate a
> source of bugs.
>
> > 3) this proposal requires changes to linking etc that would really make
> it
> > useful only on systems and deployments that only have Template Haskell
> AND
> > Dynamic linking.  (and also rules out any context where it'd be nice to
> > deploy a static app or say, use CH in ios! )
>
> I don't know about iOS. And it's very likely that there are contexts
> in which this extension doesn't work. But as I said above, you are
> always free to define your own DSL's that cover the particular use
> case that you have in mind. The nice thing with this particular DSL is
> that it requires little to no TH to generate label names, which can
> always be a source of bugs, especially when you forget to include them
> in the global remote table (which is something that TH doesn't and
> can't help you with).
>
> Furthermore, it was my understanding that GHC is heading towards a
> world of "dynamic linkable by default", and it is by now something
> that is supported on most platforms by GHC. See e.g.
>
> https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms
>
> There are fairly good solutions to deploy self contained dynamically
> linked apps these days, e.g. Docker. And in any case, with a few extra
> flags we can still do away with the dynamic linking requirement on
> some (all?) platforms.
>
> > to repeat: have you considered defining an AST type + interpreter for the
> > computations you want to send around, and doing that? I think its a much
> > simpler, safer, easier, flexible and PORTABLE approach, though one
> current
> > CH doesn't do (though the folks working on CH seem to be receptive to
> > switching to such a strategy if someone validates it)
>
> We have, and it's an option with different tradeoffs. Both solutions
> could gainfully live side by side and are in fact complementary. I
> contend that the solution described by Facundo has the advantage of
> eliminating much of the syntactic overhead associated with sending
> references to (higher-order) values across the cluster. We have more
> ideas specific to distributed-process which we can discuss in a
> separate thread to reduce the syntactic overhead even further, to
> practically nothing.
>
> Best,
>
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140125/0d581f03/attachment.html>

From glaebhoerl at gmail.com  Sat Jan 25 18:48:05 2014
From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=)
Date: Sat, 25 Jan 2014 19:48:05 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>

+1 to this proposal. The benefits are obvious and practical: when
installing a new GHC, it will save users the tedium of having to figure out
how to build a cabal-install and then do so before they can install the
packages they actually want. The drawbacks are indefinite and amorphous:
the download is a little bit larger. So what? It further blurs the line
between GHC and the Platform. Who does this harm? People who already have a
cabal-install will now have a second one. What discomfort will this cause
them?


On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey everyone,
>
> I'd like to propose that GHC releases 7.8.1 onwards include a
> cabal-install (aka cabal) executable, but not include the library deps of
> cabal-install that aren't already distributed with ghc.(unless ghc should
> have those deps baked in, which theres very very good reasons not to do.).
>
> currently if someone wants just a basic haskell install of the freshest
> ghc  they have to install a ghc bindist, then do a boostrap build of
> cabal-install by hand (if they want to actually get anything done :) ).
>
> This is not a human friendly situation for folks who are new to haskell
> tooling, but want to try out haskell dev on a server style vm or the like!
>
> point being: It'd be great for haskell usability (and egads amounts of
> config time, even by seasoned users) the ghc bindists / installers included
> a cabal-install binary
>
> thoughts?
> -Carter
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140125/8561a18f/attachment.html>

From lukexipd at gmail.com  Sun Jan 26 10:23:10 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Sun, 26 Jan 2014 02:23:10 -0800
Subject: GHC iOS ARMv7/ARMv7s fat support completed
Message-ID: <CAGo83Ci8EZ_wnjzRVtoB1biXE2G8uxTsXioq3SeA4nFYjmY5wQ@mail.gmail.com>

Hi folks,

Happy to report that I've finished an approach to armv7/armv7s fat
compilation, just in time for 7.8's imminent release.

You'll find the necessary scripts here:
https://github.com/ghc-ios/ghc-ios-scripts

and the latest instructions for building GHC for iOS usage here:
https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

I've also added support for a perf-cross BuildFlavour, which will give a
higher-performance and profiling-ready build that matches what we'll be
putting together as the official 7.8 GHC iOS binaries:
https://ghc.haskell.org/trac/ghc/ticket/8700

Cheers
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140126/19076d07/attachment-0001.html>

From difrumin at gmail.com  Sun Jan 26 13:08:31 2014
From: difrumin at gmail.com (Daniil Frumin)
Date: Sun, 26 Jan 2014 17:08:31 +0400
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
Message-ID: <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>

cabal-install doesn't even have to be distributed in one tar.gz with
GHC, just merely mentioning cabal-install binaries on
http://www.haskell.org/ghc/download will surely help (assuming we get
to actually have the cabal-install binaries :)

On Sat, Jan 25, 2014 at 10:48 PM, G?bor Lehel <glaebhoerl at gmail.com> wrote:
> +1 to this proposal. The benefits are obvious and practical: when installing
> a new GHC, it will save users the tedium of having to figure out how to
> build a cabal-install and then do so before they can install the packages
> they actually want. The drawbacks are indefinite and amorphous: the download
> is a little bit larger. So what? It further blurs the line between GHC and
> the Platform. Who does this harm? People who already have a cabal-install
> will now have a second one. What discomfort will this cause them?
>
>
> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> Hey everyone,
>>
>> I'd like to propose that GHC releases 7.8.1 onwards include a
>> cabal-install (aka cabal) executable, but not include the library deps of
>> cabal-install that aren't already distributed with ghc.(unless ghc should
>> have those deps baked in, which theres very very good reasons not to do.).
>>
>> currently if someone wants just a basic haskell install of the freshest
>> ghc  they have to install a ghc bindist, then do a boostrap build of
>> cabal-install by hand (if they want to actually get anything done :) ).
>>
>> This is not a human friendly situation for folks who are new to haskell
>> tooling, but want to try out haskell dev on a server style vm or the like!
>>
>> point being: It'd be great for haskell usability (and egads amounts of
>> config time, even by seasoned users) the ghc bindists / installers included
>> a cabal-install binary
>>
>> thoughts?
>> -Carter
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Sincerely yours,
-- Daniil

From efsubenovex at gmail.com  Sun Jan 26 18:33:02 2014
From: efsubenovex at gmail.com (Schell Scivally)
Date: Sun, 26 Jan 2014 10:33:02 -0800
Subject: [Haskell-iPhone] GHC iOS ARMv7/ARMv7s fat support completed
In-Reply-To: <CAGo83Ci8EZ_wnjzRVtoB1biXE2G8uxTsXioq3SeA4nFYjmY5wQ@mail.gmail.com>
References: <CAGo83Ci8EZ_wnjzRVtoB1biXE2G8uxTsXioq3SeA4nFYjmY5wQ@mail.gmail.com>
Message-ID: <CA+11MeBkNrPydjR7PO2_jTYA0t212jgbjSkXX1YUxf8_PDbq+Q@mail.gmail.com>

Awesome! I'll be spinning this up soon.

On Sun, Jan 26, 2014 at 2:23 AM, Luke Iannini <lukexipd at gmail.com> wrote:

> Hi folks,
>
> Happy to report that I've finished an approach to armv7/armv7s fat
> compilation, just in time for 7.8's imminent release.
>
> You'll find the necessary scripts here:
> https://github.com/ghc-ios/ghc-ios-scripts
>
> and the latest instructions for building GHC for iOS usage here:
> https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS
>
> I've also added support for a perf-cross BuildFlavour, which will give a
> higher-performance and profiling-ready build that matches what we'll be
> putting together as the official 7.8 GHC iOS binaries:
> https://ghc.haskell.org/trac/ghc/ticket/8700
>
> Cheers
> Luke
>
> _______________________________________________
> iPhone mailing list
> iPhone at haskell.org
> http://www.haskell.org/mailman/listinfo/iphone
>
>


-- 
Schell Scivally
http://blog.efnx.com
http://github.com/schell
http://twitter.com/schellsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140126/048190ca/attachment.html>

From watson.timothy at gmail.com  Sun Jan 26 18:43:41 2014
From: watson.timothy at gmail.com (Tim Watson)
Date: Sun, 26 Jan 2014 18:43:41 +0000
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
Message-ID: <6BA9AA09-CE74-4E4B-AF43-F571DAA80D22@gmail.com>

On 25 Jan 2014, at 18:12, Carter Schonwald wrote:

> 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library.
>  If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something!  
> 

Is that something you'll consider looking at Matthieu?

>  Theres quite a few industrial haskell shops that provide products / services where internally they do runtime dynamic loading of user provided object files, so i'm sure that the core GHC support is there if you actually dig into the apis! And they do this in a distributed systems context, sans CH.
> 

We have a pull request from Edsko that melds hs-plugins support with static, as per the original proposal's notes, so this seems like a corollary issue to me. 

> 2) I've a work in progress on specing out a proper (and sound :) ) static values type extension for ghc, that will be usable perhaps in your your case (though by dint of being sound, will preclude some of the things you think you want). BUT, any type system changes need to actually provide safety. My motivation for having a notion of static values comes from a desire to add compiler support for certain numerical computing operations that require compiler support to be usable in haskell. BUT, much of the same work 
> 

Timescales? There are commercial users of Cloud Haskell clamouring for improvements to the way we handle this situation, and I'm keen to combine getting broader community agreements about "the right thing to do" with facilitating our users real needs. If there are other options pertaining to "static" support, I'd like to know more!

> @tim: what on earth does "sending arbitrary code" mean? I feel like the more precise thing everyone here wants is "for a given application / infrastructure deployment, I would to be able to send my application specific computations over the network, using cloud haskell, and be sure that both sides think its the same code".
> 

With Cloud Haskell in its current guise, I can "Closure up" pretty any thunk I like and spawn it on a remote node. If the node's are both running the same executable, we're fine. If they're not, we're potentially in trouble.

In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making.

> As for *how* to send an AST fragment, edward kmett and other have some pretty nice typed AST models that are easy to adapt and extend for an application specific use case. Bound http://hackage.haskell.org/package/bound is one nice one. 
> 
> heres a really really good school of haskell exposition https://www.fpcomplete.com/user/edwardk/bound
> 
> And theres a generalization that supports strong typing that i've copied from an hpaste https://gist.github.com/cartazio/5727196, where its notable that the AST data type is called "Remote" :),
> I think thats a hint its meant to be a haskell manipulable way of constructing a typed DSL you can serialize using a finally tagless style api approach (ie have a set of type class instances / operations that you use to run the computation and/or construct the AST you can send over the wire)
> 

These are all lovely, but aren't we talking about either (a) putting together an AST to represent whatever valid Haskell program someone wants to send, or (b) forcing every application developer to write an AST to cover all their remote computations. Both of those sound like a lot more work than the proposal below. They may be the right approach from some domains, but there is a fair bit of "developer overhead" involved from what I can see.

> On Fri, Jan 24, 2014 at 3:19 PM, Mathieu Boespflug <0xbadcode at gmail.com> wrote:
> The `static e` form could as well be a piece of Template Haskell, but
> making it a proper extension means that the compiler can enforce more
> invariants and be a bit more helpful to the user. In particular,
> detecting situations where symbolic references cannot be generated
> because e.g. the imported packages were not compiled as dynamic linked
> libraries. Or seamlessly supporting calling `static f` on an idenfier
> `f` that is not exported by the module.
> 

All of which sound like a usability improvement to me.

> I very much subscribe to the idea of defining small DSL's for
> exchanging code between nodes. And this proposal is compatible with
> that idea.
> 
> One thing that might not have been so clear in the original email is
> that we are proposing here to introduce just *one such DSL*. It's just
> that it's a trivial one whose grammar only contains linker symbol
> names.
> 

That triviality is a rather important point as well, because...

> As it happens, distributed-static today already supports two such
> DSL's: a DSL of labels, which are arbitrary string names for
> functions, and a small language for composing Static values together.

And whilst those two DSL's are rather simple, it can still be tricky to get things right. 

> As Facundo explains at the end of his email, the notion of a "static"
> value ought to be a more general one than was first envisioned in the
> paper: a static value is any closed denotation, denoted in any of a
> choice of multiple small languages, some of which ship standard with
> distributed-static. The user can define his own DSL for shipping code
> around.

Indeed - there's never been anything preventing users from doing thus. Indeed, sending messages that are "interpreted" by a remote processes in order to apply some specific processing is pretty much the MO of all Cloud Haskell code. The "plugins" based support will add to the options there.

> > 2) how does it provide more type safety than the current TH based approach?
> > (I've seen Tim and others hit very very gnarly bugs in cloud haskell based
> > upon the "magic static values" approach).
> 
> The type safety of the current TH approach is reasonable I think. One
> potential problem comes from managing dynamically typed values in the
> remote table, which must be coerced to the right type and use the
> right decoders if you don't use TH. With the approach we propose,
> there is no remote table, so I guess this should help eliminate a
> source of bugs.

And remove a slightly awkward programming model. 

> 
> > to repeat: have you considered defining an AST type + interpreter for the
> > computations you want to send around, and doing that? I think its a much
> > simpler, safer, easier, flexible and PORTABLE approach, though one current
> > CH doesn't do (though the folks working on CH seem to be receptive to
> > switching to such a strategy if someone validates it)
> 
> We have, and it's an option with different tradeoffs. Both solutions
> could gainfully live side by side and are in fact complementary. I
> contend that the solution described by Facundo has the advantage of
> eliminating much of the syntactic overhead associated with sending
> references to (higher-order) values across the cluster. We have more
> ideas specific to distributed-process which we can discuss in a
> separate thread to reduce the syntactic overhead even further, to
> practically nothing.
> 

I agree that the proposal sounds beneficial. It's a good thing that both approaches can live side by side. 

I'd like to hear more about these other ideas too. I'd also like to hear more from the rest of the community - especially Cloud Haskell users. I know a few others besides Parallel Scientific are using Cloud Haskell in commercial applications - I'd very much like to hear from you all on this proposal too.

Cheers,
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140126/c752800b/attachment-0001.html>

From allbery.b at gmail.com  Sun Jan 26 19:01:38 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 26 Jan 2014 14:01:38 -0500
Subject: Static values language extension proposal
In-Reply-To: <6BA9AA09-CE74-4E4B-AF43-F571DAA80D22@gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <6BA9AA09-CE74-4E4B-AF43-F571DAA80D22@gmail.com>
Message-ID: <CAKFCL4WXV9KCCZRJHPPxK6fit9-Kei_i+DLv-B+tZ7zhuRw8fQ@mail.gmail.com>

On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson <watson.timothy at gmail.com>wrote:

> In Erlang, I can rpc/send *any* term and evaluate it on another node. That
> includes functions of course. Whether or not we want to be quite that
> general is another matter, but that is the comparison I've been making.
>

Note that Erlang gets away with this through being a virtual machine
architecture; BEAM is about as write-once-run-anywhere as it gets, and the
platform specifics are abstracted by the BEAM VM interpreter. You just
aren't going to accomplish this with a native compiled language, without
encoding as a virtual machine yourself (that is, the AST-based mechanisms).

Perhaps you should consider fleshing out ghc's current bytecode support to
be a full VM? Or perhaps an interesting alternative would be a BEAM backend
for ghc.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140126/4b79b57a/attachment.html>

From austin at well-typed.com  Mon Jan 27 00:39:32 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 26 Jan 2014 18:39:32 -0600
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
Message-ID: <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>

Hello,

My input is this: I think a lot of confusion stems from some
documentation that just needs to be cleared up.

I think that just cleaning up the pages so that:

 * http://www.haskell.org/cabal has binaries for Tier 1 platforms: OS
X, Windows, FreeBSD i386/amd64, Linux i386/amd64. IMO, there should be
a clear 'Download pre-built binaries' on the immediate front page that
cannot be missed.

 * http://www.haskell.org/ghc/download still points to the platform
for most users (i.e. the platform is more long-term stable/supported,)
but also mentions cabal install binaries. They can be linked to
directly from the subsection for each platform: "Download GHC 7.8.1
Mac OS X x86-64 - also download <latest cabal-install OS X build> from
here"

I personally think this would go a significant way to making it easier
for people to bootstrap environments. (IMO, both the GHC and Cabal
homepage could both do with a visual makeover as well, to make this
all the more apparent and easily accessible.)

As for cabal install binaries: I can easily provide dedicated hardware
(thanks to Rackspace) for Windows, FreeBSD or Linux build machines. I
also have a dedicated OS X machine in Oxford (thanks to Duncan) that
can be used to build binaries for OS X as well. So I can absolutely
provide resources for Cabal developers to build them if they'd like.
At least for T1 platforms.

As for shipping with GHC itself: this is technically possible, but
slightly annoying to implement, and it also makes the build processes
for a release slightly more annoying (which is mostly my problem.) But
it is all doable. However, keep in mind I *do not* maintain the binary
distributions for everything, nor do Cabal devs have access to all
hardware - so all people making upstream releases for their platforms
(i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal
themselves. But perhaps that's not a huge deal.

I guess my vote on this is ultimately neutral. I think it can be fixed
by simply making the downloads more clear. Alternatively we can
package cabal-install. I'll leave the decision up to users at large
and their votes.

On Sun, Jan 26, 2014 at 7:08 AM, Daniil Frumin <difrumin at gmail.com> wrote:
> cabal-install doesn't even have to be distributed in one tar.gz with
> GHC, just merely mentioning cabal-install binaries on
> http://www.haskell.org/ghc/download will surely help (assuming we get
> to actually have the cabal-install binaries :)
>
> On Sat, Jan 25, 2014 at 10:48 PM, G?bor Lehel <glaebhoerl at gmail.com> wrote:
>> +1 to this proposal. The benefits are obvious and practical: when installing
>> a new GHC, it will save users the tedium of having to figure out how to
>> build a cabal-install and then do so before they can install the packages
>> they actually want. The drawbacks are indefinite and amorphous: the download
>> is a little bit larger. So what? It further blurs the line between GHC and
>> the Platform. Who does this harm? People who already have a cabal-install
>> will now have a second one. What discomfort will this cause them?
>>
>>
>> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>>>
>>> Hey everyone,
>>>
>>> I'd like to propose that GHC releases 7.8.1 onwards include a
>>> cabal-install (aka cabal) executable, but not include the library deps of
>>> cabal-install that aren't already distributed with ghc.(unless ghc should
>>> have those deps baked in, which theres very very good reasons not to do.).
>>>
>>> currently if someone wants just a basic haskell install of the freshest
>>> ghc  they have to install a ghc bindist, then do a boostrap build of
>>> cabal-install by hand (if they want to actually get anything done :) ).
>>>
>>> This is not a human friendly situation for folks who are new to haskell
>>> tooling, but want to try out haskell dev on a server style vm or the like!
>>>
>>> point being: It'd be great for haskell usability (and egads amounts of
>>> config time, even by seasoned users) the ghc bindists / installers included
>>> a cabal-install binary
>>>
>>> thoughts?
>>> -Carter
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> Sincerely yours,
> -- Daniil
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From watson.timothy at gmail.com  Mon Jan 27 16:20:03 2014
From: watson.timothy at gmail.com (Tim Watson)
Date: Mon, 27 Jan 2014 16:20:03 +0000
Subject: Static values language extension proposal
In-Reply-To: <CAKFCL4WXV9KCCZRJHPPxK6fit9-Kei_i+DLv-B+tZ7zhuRw8fQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <6BA9AA09-CE74-4E4B-AF43-F571DAA80D22@gmail.com>
 <CAKFCL4WXV9KCCZRJHPPxK6fit9-Kei_i+DLv-B+tZ7zhuRw8fQ@mail.gmail.com>
Message-ID: <F6105069-815C-4A7B-B5BD-25B8C1B7CCFB@gmail.com>

Hi Brandon,

On 26 Jan 2014, at 19:01, Brandon Allbery wrote:

> On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson <watson.timothy at gmail.com> wrote:
> In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making.
> 
> Note that Erlang gets away with this through being a virtual machine architecture; BEAM is about as write-once-run-anywhere as it gets, and the platform specifics are abstracted by the BEAM VM interpreter. You just aren't going to accomplish this with a native compiled language, without encoding as a virtual machine yourself (that is, the AST-based mechanisms).

Yeah, I do realise this. Of course we're not trying to reproduce the BEAM really, but what we /do/ want is to be able to do is exchange messages between nodes that are not running the same executable. The proposal does appear to address this requirement, at least to some extent. There may be complementary (or better) approaches. I believe Carter is going to provide some additional details viz his work in this area at some point.

Anything that reduces the amount of Template Haskell required to work with Cloud Haskell is a "good thing (tm)" IMO. Not that I mind using TH, but the programming model is currently quite awkward from the caller's perspective, since you've got to (a) create a Static/Closure out of potentially complex chunks of code, which often involves creating numerous top level wrapper APIs and (b) fiddle around with the remote-table (both in the code that defines remote-able thunks *and* in the code that starts a node wishing to operate on them.

Also note that this problem isn't limited to sending code around the network. Just sending arbitrary *data* between nodes is currently discouraged (though not disallowed) because the receiving program *might* not understand the types you're sending it. This is very restrictive and the proposal does, at the very least, allow us to safely serialise, send and receive types that both programs "know about" by virtue of having been linked to the same library/libraries. 

But yes - there are certainly constraints and edge cases aplenty here. I'm not entirely sure whether or not we'd need to potentially change the (binary) encoding of raw messages in distributed-process, for example, in response to this change. Currently we serialise a pointer (i.e., the pointer to the fingerprint for the type that's being sent), and I can imagine that not working properly across different nodes running on different architectures etc.

> Perhaps you should consider fleshing out ghc's current bytecode support to be a full VM?

After discussing this with Simon M, we concluded there was little point in doing so. The GHC RTS is practically a VM anyway, and there's probably not that much value to be gained by shipping bytecode around. Besides, as you put it, the AST-based mechanisms allow for this anyway (albeit with some coding required on the part of the application developer) and Carter (and others) assure me that the mechanisms required to do this kind of thing already exist. We just need to find the right way to take advantage of them.

> Or perhaps an interesting alternative would be a BEAM backend for ghc.
> 

I've talked to a couple of people that want to try this. I'm intrigued, but have other things to focus on. :)

Cheers,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140127/50c8ebe4/attachment.html>

From facundo.dominguez at tweag.io  Tue Jan 28 12:33:40 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Tue, 28 Jan 2014 10:33:40 -0200
Subject: Static values language extension proposal
In-Reply-To: <F6105069-815C-4A7B-B5BD-25B8C1B7CCFB@gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <6BA9AA09-CE74-4E4B-AF43-F571DAA80D22@gmail.com>
 <CAKFCL4WXV9KCCZRJHPPxK6fit9-Kei_i+DLv-B+tZ7zhuRw8fQ@mail.gmail.com>
 <F6105069-815C-4A7B-B5BD-25B8C1B7CCFB@gmail.com>
Message-ID: <CA+Q==SAzkZ_aROijn+k9nYtchQAe+_BWryWL7TQt8YwnNZ0=uA@mail.gmail.com>

To address the concerns about static linking and portability, there is
also the alternative of of using the RTS linker in those platforms
that need it.

In many aspects, neither linker makes a big difference to us. We are
going with the system's dynamic linker mainly because GHC team has
expressed the desire to get rid of the RTS linker.

Using the RTS linker would require addressing some additional
technical issues, none of which appear to be show-stoppers. It would
be just more work.

Best,
Facundo


On Mon, Jan 27, 2014 at 2:20 PM, Tim Watson <watson.timothy at gmail.com> wrote:
> Hi Brandon,
>
> On 26 Jan 2014, at 19:01, Brandon Allbery wrote:
>
> On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson <watson.timothy at gmail.com>
> wrote:
>>
>> In Erlang, I can rpc/send *any* term and evaluate it on another node. That
>> includes functions of course. Whether or not we want to be quite that
>> general is another matter, but that is the comparison I've been making.
>
>
> Note that Erlang gets away with this through being a virtual machine
> architecture; BEAM is about as write-once-run-anywhere as it gets, and the
> platform specifics are abstracted by the BEAM VM interpreter. You just
> aren't going to accomplish this with a native compiled language, without
> encoding as a virtual machine yourself (that is, the AST-based mechanisms).
>
>
> Yeah, I do realise this. Of course we're not trying to reproduce the BEAM
> really, but what we /do/ want is to be able to do is exchange messages
> between nodes that are not running the same executable. The proposal does
> appear to address this requirement, at least to some extent. There may be
> complementary (or better) approaches. I believe Carter is going to provide
> some additional details viz his work in this area at some point.
>
> Anything that reduces the amount of Template Haskell required to work with
> Cloud Haskell is a "good thing (tm)" IMO. Not that I mind using TH, but the
> programming model is currently quite awkward from the caller's perspective,
> since you've got to (a) create a Static/Closure out of potentially complex
> chunks of code, which often involves creating numerous top level wrapper
> APIs and (b) fiddle around with the remote-table (both in the code that
> defines remote-able thunks *and* in the code that starts a node wishing to
> operate on them.
>
> Also note that this problem isn't limited to sending code around the
> network. Just sending arbitrary *data* between nodes is currently
> discouraged (though not disallowed) because the receiving program *might*
> not understand the types you're sending it. This is very restrictive and the
> proposal does, at the very least, allow us to safely serialise, send and
> receive types that both programs "know about" by virtue of having been
> linked to the same library/libraries.
>
> But yes - there are certainly constraints and edge cases aplenty here. I'm
> not entirely sure whether or not we'd need to potentially change the
> (binary) encoding of raw messages in distributed-process, for example, in
> response to this change. Currently we serialise a pointer (i.e., the pointer
> to the fingerprint for the type that's being sent), and I can imagine that
> not working properly across different nodes running on different
> architectures etc.
>
> Perhaps you should consider fleshing out ghc's current bytecode support to
> be a full VM?
>
>
> After discussing this with Simon M, we concluded there was little point in
> doing so. The GHC RTS is practically a VM anyway, and there's probably not
> that much value to be gained by shipping bytecode around. Besides, as you
> put it, the AST-based mechanisms allow for this anyway (albeit with some
> coding required on the part of the application developer) and Carter (and
> others) assure me that the mechanisms required to do this kind of thing
> already exist. We just need to find the right way to take advantage of them.
>
> Or perhaps an interesting alternative would be a BEAM backend for ghc.
>
>
> I've talked to a couple of people that want to try this. I'm intrigued, but
> have other things to focus on. :)
>
> Cheers,
> Tim
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From m at tweag.io  Tue Jan 28 12:53:33 2014
From: m at tweag.io (Mathieu Boespflug)
Date: Tue, 28 Jan 2014 13:53:33 +0100
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
Message-ID: <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>

Hi Carter, Tim,

On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> anyways
>
> 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt
> dynamic loading as a user land library.
>  If you can't make it work as a library and can demonstrate why (or how even
> though it works its not quite satisfactory), thats signals something!

Signals what?

On Sun, Jan 26, 2014 at 7:43 PM, Tim Watson <watson.timothy at gmail.com> wrote:
> Is that something you'll consider looking at Matthieu?

We would prefer to do it that way, to be honest. As explained in my
previous email, we identified two problems with this approach:

1) User friendliness. It's important for us that Cloud Haskell be
pretty much as user friendly and easy to use as Erlang is.

    a) I don't know that it's possible from Template Haskell to detect
and warn the user when dependent modules have not been compiled into
dynamic object code or into static code with the right flags.

    b)  It's very convenient in practice to be able to send not just
`f` if `f` is a global identifier, but in general `e` where `e` is any
closed expression mentioning only global names. That can easily be
done by having the compiler float the expression `e` to the top-level
and give it a global name. I don't see how to do that in TH in a user
friendly way.

2) A technical issue: you ought to be able to send unexported
functions across the wire, just as you can pass unexported functions
as arguments to higher-order functions. Yet GHC does not create linker
symbols for unexported identifiers, so our approach would break down.
Worse, I don't think that it's even possible to detect in TH whether
an identifier is exported or not, in order to warn the user. One could
imagine a compiler flag to force the creation of linker symbols for
all toplevel bindings, exported or unexported. But that seems
wasteful, and potentially not very user friendly.

If the above can be solved, all the better!

If not: we don't always want to touch the compiler, but when we do,
ideally it should be in an unintrusive way. I contend our proposal
fits that criterion. And our cursory implementation efforts seem to
confirm that so far.

> But I really think insisting that the linker symbol names denote the "datum
> agreement" in a distributed system is punting on what should be handled at
> the application level. Simon Marlow put some improvements into GHC to help
> improve doing dynamic code (un)loading, stress test that!

We could use either the system linker or rts linker. Not sure that it
makes any difference at the application level.

> 2) I've a work in progress on specing out a proper (and sound :) ) static
> values type extension for ghc, that will be usable perhaps in your your case
> (though by dint of being sound, will preclude some of the things you think
> you want).

I look forward to hearing more about that. How is the existing
proposal not (type?) sound?

> BUT, any type system changes need to actually provide safety.

To be clear, this proposal doesn't touch the type checker in any way.

> As for *how* to send an AST fragment, edward kmett and other have some
> pretty nice typed AST models that are easy to adapt and extend for an
> application specific use case. Bound
> http://hackage.haskell.org/package/bound is one nice one.
>
> heres a really really good school of haskell exposition
> https://www.fpcomplete.com/user/edwardk/bound

These are nice encodings for AST's. But they don't address how to
minimize the amount of code to ship around the cluster. If you have no
agreement about what functions are commonly available, then the AST
needs to include the code for the function you are sending, + any
functions it depends, + any of their dependencies, and so on
transitively.

Tim, perhaps the following also answers some of your questions. This
is where the current proposal comes in: if you choose to ship around
AST's, you can minimize their size by having them mention shared
linker symbol names. Mind, that's already possible today, by means of
the global RemoteTable, but it's building that remote table safely,
conveniently, in a modular way, and with static checking that no
symbols from any of the modules that were linked at build time were
missed, that is difficult.

By avoiding a RemoteTable entirely, we avoid having to solve that
difficult problem. :)

Best,

-- 
Mathieu Boespflug
Founder at http://tweag.io.

From allbery.b at gmail.com  Tue Jan 28 15:21:47 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 28 Jan 2014 10:21:47 -0500
Subject: Static values language extension proposal
In-Reply-To: <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
Message-ID: <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>

On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m at tweag.io> wrote:

> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> > 1) you should (once 7.8 is out) evaluate how far you can push your ideas
> wrt
> > dynamic loading as a user land library.
> >  If you can't make it work as a library and can demonstrate why (or how
> even
> > though it works its not quite satisfactory), thats signals something!
>
> Signals what?
>

That there is a shortcoming in ghc and/or the rts that needs to be
addressed.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140128/0b8a6692/attachment.html>

From watson.timothy at gmail.com  Tue Jan 28 17:02:15 2014
From: watson.timothy at gmail.com (Tim Watson)
Date: Tue, 28 Jan 2014 17:02:15 +0000
Subject: Static values language extension proposal
In-Reply-To: <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
Message-ID: <DB845B52-0525-426B-AAF1-58CB556C23BB@gmail.com>

Hi Mathieu,

On 28 Jan 2014, at 12:53, Mathieu Boespflug wrote:
> We would prefer to do it that way, to be honest. As explained in my
> previous email, we identified two problems with this approach:
> 
> 1) User friendliness. It's important for us that Cloud Haskell be
> pretty much as user friendly and easy to use as Erlang is.
> 

Exactly!

>    a) I don't know that it's possible from Template Haskell to detect
> and warn the user when dependent modules have not been compiled into
> dynamic object code or into static code with the right flags.
> 

I don't think that it is, from what I've seen, though I'm by no means an expert.

>    b)  It's very convenient in practice to be able to send not just
> `f` if `f` is a global identifier, but in general `e` where `e` is any
> closed expression mentioning only global names. That can easily be
> done by having the compiler float the expression `e` to the top-level
> and give it a global name. I don't see how to do that in TH in a user
> friendly way.

Agreed.

> 
> 2) A technical issue: you ought to be able to send unexported
> functions across the wire, just as you can pass unexported functions
> as arguments to higher-order functions. Yet GHC does not create linker
> symbols for unexported identifiers, so our approach would break down.
> Worse, I don't think that it's even possible to detect in TH whether
> an identifier is exported or not, in order to warn the user. One could
> imagine a compiler flag to force the creation of linker symbols for
> all toplevel bindings, exported or unexported. But that seems
> wasteful, and potentially not very user friendly.

Interesting.

> 
> If the above can be solved, all the better!
> 
> If not: we don't always want to touch the compiler, but when we do,
> ideally it should be in an unintrusive way. I contend our proposal
> fits that criterion. And our cursory implementation efforts seem to
> confirm that so far.

Good!

> 
>> But I really think insisting that the linker symbol names denote the "datum
>> agreement" in a distributed system is punting on what should be handled at
>> the application level. Simon Marlow put some improvements into GHC to help
>> improve doing dynamic code (un)loading, stress test that!
> 
> We could use either the system linker or rts linker. Not sure that it
> makes any difference at the application level.

No indeed.

> 
>> 2) I've a work in progress on specing out a proper (and sound :) ) static
>> values type extension for ghc, that will be usable perhaps in your your case
>> (though by dint of being sound, will preclude some of the things you think
>> you want).
> 
> I look forward to hearing more about that.

+1

> How is the existing proposal not (type?) sound?
> 

I'd like to hear more about the concerns too.

>> As for *how* to send an AST fragment, edward kmett and other have some
>> pretty nice typed AST models that are easy to adapt and extend for an
>> application specific use case. Bound
>> http://hackage.haskell.org/package/bound is one nice one.
>> 
>> heres a really really good school of haskell exposition
>> https://www.fpcomplete.com/user/edwardk/bound
> 
> These are nice encodings for AST's. But they don't address how to
> minimize the amount of code to ship around the cluster. If you have no
> agreement about what functions are commonly available, then the AST
> needs to include the code for the function you are sending, + any
> functions it depends, + any of their dependencies, and so on
> transitively.

That was precisely my concern with the idea of shipping *something* AST-like around. It's a lot of overhead for every application you want to develop, or a *massive* overhead to cover all bases.

> 
> Tim, perhaps the following also answers some of your questions. This
> is where the current proposal comes in: if you choose to ship around
> AST's, you can minimize their size by having them mention shared
> linker symbol names.

Indeed, that does seem to simplify things.

> Mind, that's already possible today, by means of
> the global RemoteTable, but it's building that remote table safely,
> conveniently, in a modular way, and with static checking that no
> symbols from any of the modules that were linked at build time were
> missed, that is difficult.
> 

Yep. It's awkward and when you get it wrong, you're either fighting with TH-obscured compiler errors or worse, the damn thing just doesn't work (because you can't decode properly on the remote node and things just crash, or worse still, just hang on waiting for the *correct* input types, which never arrive because they're not "known" to the RTS).

> By avoiding a RemoteTable entirely, we avoid having to solve that
> difficult problem. :)

Not having a RemoteTable sounds like a plus to me.

Cheers,
Tim



From carter.schonwald at gmail.com  Tue Jan 28 17:03:20 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 28 Jan 2014 12:03:20 -0500
Subject: Static values language extension proposal
In-Reply-To: <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
 <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
Message-ID: <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>

Theres actually a missing piece of information in this thread: what are the
example computations that are being sent?
My understanding is that erlang has not way to send file handles, shared
variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
pointers , and other fun unportable things between nodes, and I don't
really expect / see how we can hope to sanely do that in haskell!

point in fact, even when restricted to "exactly the same binary, running on
a cluster of homogeneous machines with the exact same hardware, with a
modern linux distro " you hit some gnarly problems doing this for arbitrary
closures!  Its for a very simple (and fun) reason: address randomization!

Nathan Howell was actually doing some experimentation with one strategy for
this special case here https://github.com/alphaHeavy/vacuum-tube  as a
deeply rts twiddling bit of hackery so you could in fact "serialize
arbitrary closures" between homogeneous machines running the exact same
code (and with address randomization disabled too i think)

on the GHC API front,
http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.htmlalong
with (and more appropriately
http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html)
should actually give enough basic tooling to make this possible as a
userland library, mind you unload was recently fixed up in HEAD by Simon
Marlow to support the dynamic code loading / unloading use case he has in
facebook.  Point being the GHC 7.8 version of the ObjLink api should
actually give enough support tooling to prototype this idea in user land,
and that plus better support for writing "direct haskell code" and getting
out both a local computation and an AST we can serialize would probably be
a good set of primitives for making this feasible in user land.  I

The meat of my point is 1) "yes I want this too" but also 2) one thing I
really have come to appreciate about how GHC is engineered is a lot of work
is done to provide the "right" primitives so that really really great tools
can be built in user land.  I think That the goal of this proposal can be
accomplished quite nicely with the  ObjLink module, unless i'm not
understanding something.  In Fact, because in general not every computation
will be properly serializable, you need not even bother with tracking an
explicit symbol table on each side, just try to load it at a given type and
if it fails it wasn't there!

The point being, linkers are a thing, ghc exposes an API for linking, have
you tried that api?
http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html






On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery <allbery.b at gmail.com>wrote:

> On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m at tweag.io> wrote:
>
>> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>> > 1) you should (once 7.8 is out) evaluate how far you can push your
>> ideas wrt
>> > dynamic loading as a user land library.
>> >  If you can't make it work as a library and can demonstrate why (or how
>> even
>> > though it works its not quite satisfactory), thats signals something!
>>
>> Signals what?
>>
>
> That there is a shortcoming in ghc and/or the rts that needs to be
> addressed.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140128/763dfca6/attachment-0001.html>

From facundo.dominguez at tweag.io  Tue Jan 28 19:13:59 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Tue, 28 Jan 2014 17:13:59 -0200
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
 <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
 <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
Message-ID: <CA+Q==SCEN8t+JnMNPnniqcJ-C4C046S50RpTeR6N69rqA50FpA@mail.gmail.com>

Hello Carter,
  Thanks for the links. IIUC the ObjLink module contains an interface
to the RTS linker. The points raised by Mathieu in his last email as
(1a), (1b) and (2) still hold.

Here's a use case for (2):

module Communicate(run)

import Control.Distributed.Process

f :: Int -> Int
f = id

runSend :: Process ()
runSend = send someone (static f)

runExpect :: Int -> Process Int
runExpect n = fmap (($ n) . unstatic) expect

If any program tries to use runExpect, it would fail at runtime
because it would fail to find `f`, because `f` is not exported and
therefore a symbol for it would not appear in object files.

The solution that modifies the compiler is superior to all workarounds
we could think of to workaround this problem with a library. Any
suggestions?

Best,
Facundo

On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Theres actually a missing piece of information in this thread: what are the
> example computations that are being sent?
> My understanding is that erlang has not way to send file handles, shared
> variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
> pointers , and other fun unportable things between nodes, and I don't really
> expect / see how we can hope to sanely do that in haskell!
>
> point in fact, even when restricted to "exactly the same binary, running on
> a cluster of homogeneous machines with the exact same hardware, with a
> modern linux distro " you hit some gnarly problems doing this for arbitrary
> closures!  Its for a very simple (and fun) reason: address randomization!
>
> Nathan Howell was actually doing some experimentation with one strategy for
> this special case here https://github.com/alphaHeavy/vacuum-tube  as a
> deeply rts twiddling bit of hackery so you could in fact "serialize
> arbitrary closures" between homogeneous machines running the exact same code
> (and with address randomization disabled too i think)
>
> on the GHC API front,
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html
> along with (and more appropriately
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
> ) should actually give enough basic tooling to make this possible as a
> userland library, mind you unload was recently fixed up in HEAD by Simon
> Marlow to support the dynamic code loading / unloading use case he has in
> facebook.  Point being the GHC 7.8 version of the ObjLink api should
> actually give enough support tooling to prototype this idea in user land,
> and that plus better support for writing "direct haskell code" and getting
> out both a local computation and an AST we can serialize would probably be a
> good set of primitives for making this feasible in user land.  I
>
> The meat of my point is 1) "yes I want this too" but also 2) one thing I
> really have come to appreciate about how GHC is engineered is a lot of work
> is done to provide the "right" primitives so that really really great tools
> can be built in user land.  I think That the goal of this proposal can be
> accomplished quite nicely with the  ObjLink module, unless i'm not
> understanding something.  In Fact, because in general not every computation
> will be properly serializable, you need not even bother with tracking an
> explicit symbol table on each side, just try to load it at a given type and
> if it fails it wasn't there!
>
> The point being, linkers are a thing, ghc exposes an API for linking, have
> you tried that api?
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
>
>
>
>
>
>
> On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>>
>> On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m at tweag.io> wrote:
>>>
>>> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
>>> <carter.schonwald at gmail.com> wrote:
>>> > 1) you should (once 7.8 is out) evaluate how far you can push your
>>> > ideas wrt
>>> > dynamic loading as a user land library.
>>> >  If you can't make it work as a library and can demonstrate why (or how
>>> > even
>>> > though it works its not quite satisfactory), thats signals something!
>>>
>>> Signals what?
>>
>>
>> That there is a shortcoming in ghc and/or the rts that needs to be
>> addressed.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From facundo.dominguez at tweag.io  Tue Jan 28 19:20:32 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Tue, 28 Jan 2014 17:20:32 -0200
Subject: Static values language extension proposal
In-Reply-To: <CA+Q==SCEN8t+JnMNPnniqcJ-C4C046S50RpTeR6N69rqA50FpA@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
 <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
 <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
 <CA+Q==SCEN8t+JnMNPnniqcJ-C4C046S50RpTeR6N69rqA50FpA@mail.gmail.com>
Message-ID: <CA+Q==SCAPe6hjHzECtE7TjqmsVFOCvQaE=Z2NTNLzy7FBjZ-xQ@mail.gmail.com>

Escuse me, the module export list was meant to be

> module Communicate(runExpect, runSend) where

Facundo

On Tue, Jan 28, 2014 at 5:13 PM, Facundo Dom?nguez
<facundo.dominguez at tweag.io> wrote:
> Hello Carter,
>   Thanks for the links. IIUC the ObjLink module contains an interface
> to the RTS linker. The points raised by Mathieu in his last email as
> (1a), (1b) and (2) still hold.
>
> Here's a use case for (2):
>
> module Communicate(run)
>
> import Control.Distributed.Process
>
> f :: Int -> Int
> f = id
>
> runSend :: Process ()
> runSend = send someone (static f)
>
> runExpect :: Int -> Process Int
> runExpect n = fmap (($ n) . unstatic) expect
>
> If any program tries to use runExpect, it would fail at runtime
> because it would fail to find `f`, because `f` is not exported and
> therefore a symbol for it would not appear in object files.
>
> The solution that modifies the compiler is superior to all workarounds
> we could think of to workaround this problem with a library. Any
> suggestions?
>
> Best,
> Facundo
>
> On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>> Theres actually a missing piece of information in this thread: what are the
>> example computations that are being sent?
>> My understanding is that erlang has not way to send file handles, shared
>> variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
>> pointers , and other fun unportable things between nodes, and I don't really
>> expect / see how we can hope to sanely do that in haskell!
>>
>> point in fact, even when restricted to "exactly the same binary, running on
>> a cluster of homogeneous machines with the exact same hardware, with a
>> modern linux distro " you hit some gnarly problems doing this for arbitrary
>> closures!  Its for a very simple (and fun) reason: address randomization!
>>
>> Nathan Howell was actually doing some experimentation with one strategy for
>> this special case here https://github.com/alphaHeavy/vacuum-tube  as a
>> deeply rts twiddling bit of hackery so you could in fact "serialize
>> arbitrary closures" between homogeneous machines running the exact same code
>> (and with address randomization disabled too i think)
>>
>> on the GHC API front,
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html
>> along with (and more appropriately
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
>> ) should actually give enough basic tooling to make this possible as a
>> userland library, mind you unload was recently fixed up in HEAD by Simon
>> Marlow to support the dynamic code loading / unloading use case he has in
>> facebook.  Point being the GHC 7.8 version of the ObjLink api should
>> actually give enough support tooling to prototype this idea in user land,
>> and that plus better support for writing "direct haskell code" and getting
>> out both a local computation and an AST we can serialize would probably be a
>> good set of primitives for making this feasible in user land.  I
>>
>> The meat of my point is 1) "yes I want this too" but also 2) one thing I
>> really have come to appreciate about how GHC is engineered is a lot of work
>> is done to provide the "right" primitives so that really really great tools
>> can be built in user land.  I think That the goal of this proposal can be
>> accomplished quite nicely with the  ObjLink module, unless i'm not
>> understanding something.  In Fact, because in general not every computation
>> will be properly serializable, you need not even bother with tracking an
>> explicit symbol table on each side, just try to load it at a given type and
>> if it fails it wasn't there!
>>
>> The point being, linkers are a thing, ghc exposes an API for linking, have
>> you tried that api?
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>>
>>> On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m at tweag.io> wrote:
>>>>
>>>> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
>>>> <carter.schonwald at gmail.com> wrote:
>>>> > 1) you should (once 7.8 is out) evaluate how far you can push your
>>>> > ideas wrt
>>>> > dynamic loading as a user land library.
>>>> >  If you can't make it work as a library and can demonstrate why (or how
>>>> > even
>>>> > though it works its not quite satisfactory), thats signals something!
>>>>
>>>> Signals what?
>>>
>>>
>>> That there is a shortcoming in ghc and/or the rts that needs to be
>>> addressed.
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>

From mle+hs at mega-nerd.com  Wed Jan 29 02:20:25 2014
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 29 Jan 2014 13:20:25 +1100
Subject: Static values language extension proposal
In-Reply-To: <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
Message-ID: <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>

Mathieu Boespflug wrote:

> [Sorry for the multiple reposts - couldn't quite figure out which
> email address doesn't get refused by the list..]
> 
> 
> Hi Carter,
> 
> thank you for the good points you raise. I'll try and address each of
> them as best I can below.
> 
> > 0) I think you could actually implement this proposal as a userland library,
> > at least as you've described it. Have you tried doing so?
> 
> Indeed, this could be done without touching the compiler at all.

We had this response really early on in this discussion. 

Quite honestly I think that should have been the end of the discussion.

The existing GHC release already have a huge workload getting releases
out the door and adding to that workload without adding manpower and
resources would be a bad idea.

You really should try doing this as a library outside of GHC and if GHC
needs a few small additional features, they can be added.

> The `static e` form could as well be a piece of Template Haskell, but
> making it a proper extension means that the compiler can enforce more
> invariants and be a bit more helpful to the user. 

Once it works outside GHC and has proven useful, then it might be worthwhile
add small specific, easily testable/maintainable features to GHC to support
what goes on on your library.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From berthold at Mathematik.Uni-Marburg.de  Wed Jan 29 09:38:05 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Wed, 29 Jan 2014 10:38:05 +0100
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
 <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
 <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
Message-ID: <52E8CBFD.3050106@mathematik.uni-marburg.de>

On 01/28/2014 06:03 PM, Carter Schonwald wrote:
> Theres actually a missing piece of information in this thread: what
> are the example computations that are being sent? My understanding is
> that erlang has not way to send file handles, shared variables,
> Tvars, Mvars, memory mapped binary files, GPU code / memory pointers
> , and other fun unportable things between nodes, and I don't really
> expect / see how we can hope to sanely do that in haskell!
>
> [...]"exactly the same binary, running on a cluster of homogeneous
> machines with the exact same hardware, with a modern linux distro "
> [...]
>
> Nathan Howell was actually doing some experimentation with one
> strategy for this special case here
> https://github.com/alphaHeavy/vacuum-tube  as a deeply rts twiddling
> bit of hackery so you could in fact "serialize arbitrary closures"
> between homogeneous machines running the exact same code (and with
> address randomization disabled too i think)

When mentioning Nathan's approach (based on foreign primops), let me
point to a more complete, RTS-backed implementation; work done by myself
and itself based on a long-standing runtime support for a parallel 
Haskell on distributed memory systems.
The latest instance of this rts-based serialisation was reported in the 
Haskell-implementors' workshop 2013 ( 
www.haskell.org/wikiupload/2/28/HIW2013PackingAPI.pdf ); code is on 
github (https://github.com/jberthold/rts-serialisation)

Some technical remarks:
-Nathan's prim.op approach is awesome, but it is not easy to get its 
interplay with garbage collection right. It is on my list to take a look 
at this code again and see how far we can push the envelope.

-About address randomisation: The RTS-based serialisation uses relative 
locations from a known offset to handle it. A more concerning detail is 
that CAFs must be reverted rather than discarded during GC (currently 
they are just retained, not satisfactory for long-running code).

-About sending arbitrary closures: indeed it does not make any sense to 
transfer MVars and IORefs (file handles, StablePtrs, etc). My approach 
is to solve this dynamically by exception handling. I can imagine that 
there is a sensible combination of RTS support with a suitable type 
class framework (Static, for one), but lazy evaluation, especially lazy 
I/O, complicates matters.

/ Jost Berthold

From m at tweag.io  Wed Jan 29 11:02:04 2014
From: m at tweag.io (Mathieu Boespflug)
Date: Wed, 29 Jan 2014 12:02:04 +0100
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <CAHYVw0wXZ1GZwD8uGiRLAj_N0okhMDSMA79TGGr78-R2mQ0jsA@mail.gmail.com>
 <CAJ0eudpgwTMqsL+zb4SaZ+5K-R6K9=0mdiKRcN5vH-_GXAm0Jw@mail.gmail.com>
 <CAKFCL4UXSc=JrpQ3YC02VLXu6Jxex=Whxu1Gj6kjj5YL988cAg@mail.gmail.com>
 <CAHYVw0yPKsYvWOHTBWdCzcFPYJJEV5Hd9TfgJb=QVAyKuix6aQ@mail.gmail.com>
Message-ID: <CAJ0eudpMX5oYkhq7UvFyGtbfWmSjgQjMZqkLundw2g9O0n9WmQ@mail.gmail.com>

Hi Carter,

On Tue, Jan 28, 2014 at 6:03 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Theres actually a missing piece of information in this thread: what are the
> example computations that are being sent?

Quite simply, the same as those considered in the original Cloud
Haskell paper, that already advocates the extension that Facundo's
first email merely fleshed out a tiny bit. Here's the link once again:

"Towards Haskell in the Cloud", Jeff Epstein, Andrew P. Black, and
Simon Peyton-Jones (2011).
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf

We are emphatically not considering "arbitrary closures" as you say
below, anymore than the original paper does. As such...

> My understanding is that erlang has not way to send file handles, shared
> variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
> pointers , and other fun unportable things between nodes, and I don't really
> expect / see how we can hope to sanely do that in haskell!

... the above is completely impossible. The original paper explains
why this is so (see Sections 2.3 and 5.1). Here's the gist:

1. you can only send remotely serializable values, i.e. that have an
instance of class Serializable.
2. none of the above have a Serializable instance, and are hence not
"send"-able.

When it comes to sending closures capturing any of the above types of
values, the reasoning goes like this:

3. a closure in the sense of CH is a pair of a static value and an environment,
4. a closure can only be sent if it is serializable,
5. a closure is serializable only if its its environment can be serialized,
5. its environment can be serialized only if all free variables of the
closure can,
6. none of the above have a Serializable instance,
7. hence any closure capturing file handles, MVars, memory pointers,
etc cannot be sent.

> point in fact, even when restricted to "exactly the same binary, running on
> a cluster of homogeneous machines with the exact same hardware, with a
> modern linux distro " you hit some gnarly problems doing this for arbitrary
> closures!  Its for a very simple (and fun) reason: address randomization!

Which is why neither we nor the original paper considered using
addresses as labels for static values. We use linker labels, which are
stable.

> on the GHC API front,
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html
> along with (and more appropriately
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
> ) should actually give enough basic tooling to make this possible as a
> userland library, mind you unload was recently fixed up in HEAD by Simon
> Marlow to support the dynamic code loading / unloading use case he has in
> facebook.  Point being the GHC 7.8 version of the ObjLink api should
> actually give enough support tooling to prototype this idea in user land,
> and that plus better support for writing "direct haskell code" and getting
> out both a local computation and an AST we can serialize would probably be a
> good set of primitives for making this feasible in user land.  I

For the third time: we can of course use any linker API that the
system or the compiler happens to provide, so long as it allows
resolving linker symbols to Haskell values. The (small) extension
under consideration does not replace or add to any existing linker
API. It just transparently floats closed expressions to the top-level,
makes sure linker symbols will exist at runtime (they currently don't
always do),  and does some basic sanity checks so the user doesn't
lose his.

I listed problems labeled 1a), 1b) and 2) in my previous email. You
still haven't showed us how to address those in pure TH userland.

> In Fact, because in general not every computation
> will be properly serializable, you need not even bother with tracking an
> explicit symbol table on each side, just try to load it at a given type and
> if it fails it wasn't there!
>
> The point being, linkers are a thing, ghc exposes an API for linking, have
> you tried that api?
> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html

Yes we have. But I don't see how using it or not using it makes any
difference to the user interface of the proposed compiler extension.
It's an implementation detail with tradeoffs that Facundo could
explain in detail in GHC ticket #8711 if you hadn't rudely closed it
as a "duplicate" of some future and unspecified work of yours.

Best,

Mathieu

From m at tweag.io  Wed Jan 29 11:03:01 2014
From: m at tweag.io (Mathieu Boespflug)
Date: Wed, 29 Jan 2014 12:03:01 +0100
Subject: Static values language extension proposal
In-Reply-To: <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>
Message-ID: <CAJ0eudrO1x9YAFF4OKiu8C6X_6=ZTVhC1FpKjestTejAJQzQnQ@mail.gmail.com>

Hi Eric,

On Wed, Jan 29, 2014 at 3:20 AM, Erik de Castro Lopo
<mle+hs at mega-nerd.com> wrote:
> Mathieu Boespflug wrote:
>
>> thank you for the good points you raise. I'll try and address each of
>> them as best I can below.
>>
>> > 0) I think you could actually implement this proposal as a userland library,
>> > at least as you've described it. Have you tried doing so?
>>
>> Indeed, this could be done without touching the compiler at all.
>
> We had this response really early on in this discussion.
>
> Quite honestly I think that should have been the end of the discussion.

The response you quote above comes in context, which includes the
sentence you also quote below. In another email, the problems we face
with a pure TH implementation are labeled as 1a), 1b), 2). We'd be
very happy if you could show us how to solve those problems using TH
alone in a way that does not impact user friendliness and static
checking of invariants in any way.

> The existing GHC release already have a huge workload getting releases
> out the door and adding to that workload without adding manpower and
> resources would be a bad idea.
>
> You really should try doing this as a library outside of GHC and if GHC
> needs a few small additional features, they can be added.
>
>> The `static e` form could as well be a piece of Template Haskell, but
>> making it a proper extension means that the compiler can enforce more
>> invariants and be a bit more helpful to the user.
>
> Once it works outside GHC and has proven useful, then it might be worthwhile
> add small specific, easily testable/maintainable features to GHC to support
> what goes on on your library.

I for one very much agree with all the principles state above. But the
wider context of the discussion is that we already have such a TH
userland solution today, implemented in packages distributed-static
and distributed-process. We already have several users, including in
the industry (to my knowledge Parallel Scientific for over a year,
Tweag I/O for a couple of months, probably others...). The proposal to
go ahead and implement an idea that was first presented in the
original Cloud Haskell paper was borne out of frustration with the
existing approach based on remote tables, which are very error prone
in practice, and the operational experience that I, Facundo, Tim and
others have had showing that making the semantics of distributed
computation depend on *all* modules across several packages being
compiled with the right incantation of compiler flags without any kind
of static checking is a problem, especially for beginners.

Is there something in the proposed extension that leads you to believe
that is neither small nor specific, or that it would not be easily
testable, or maintainable? If so, we could amend it accordingly.

Best,

Mathieu

From austin at well-typed.com  Wed Jan 29 11:11:34 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 29 Jan 2014 05:11:34 -0600
Subject: Static values language extension proposal
In-Reply-To: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
Message-ID: <CAEs96n1c8LVo55sD4Hb2z5isoe416p2zwH=HbJ9pgzM5f3bCeg@mail.gmail.com>

Hello,

I'd just like to say I haven't gone over every discussion in this
thread and had time to digest it all - I thought I would just
highlight a minor technicality.

On Fri, Jan 24, 2014 at 11:19 AM, Facundo Dom?nguez
<facundo.dominguez at tweag.io> wrote:
> Looking up static references
> ====================
>
> `unstatic` is implemented as a function which finds a top-level value
> from the `GlobalName`, otherwise it raises an exception. It crucially
> relies on leveraging the system?s dynamic linker, so out-of-the-box
> only works with dynamically linked binaries (but see below).
> `unstatic` proceeds as follows:
>
>   * Determines the name of the shared library from the package name
> and the package version.
>
>   * Determines the symbol of the value by Z-Encoding the package name,
> the module name and the value name.
>
>   * Uses the system?s dynamic linker interface to obtain the address
> of the symbol.
>
>   * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#`
>
> In principle, only symbols in shared libraries can be found. However,
> the dynamic linker is able to find symbols in modules that are linked
> statically if GHC is fed with the option -optl-Wl,--export-dynamic. A
> future enhancement could be to have GHC warn the user when modules
> using the extension are linked statically and this option is not used
> during linking.
>
> GHC only defines symbols for exported definitions in modules. So
> unstatic won?t be able to find the private bindings of a module. For
> this sake, the implementation of static should in addition ensure that
> the bindings it gets will appear in the symbol table when they are not
> exported by their defining modules.

Regarding -optl-Wl,--export-dynamic for static builds, and all that
jazz - if I am understanding you right, note that Windows is a bit
particular here, because there is a hard limit on the number of
symbols allowed in a DLL. That means forcefully exporting *everything*
could quickly get you to the symbol limit with the dynamic linker with
large-ish applications (one exported function or data type may result
in a handful of exported symbols created.) If you want to see the pain
this has caused GHC itself, please see GHC bug #5987[1], which makes
dynamic support on windows difficult - it's currently disabled now
anyway.

Furthermore, dynamic DLLs on Windows are a bit tricky anyway as the
loader is fundamentally different from your typical ld.so (which there
are ways around[2], but a bit nasty as you have to hack the COFF
file.) Windows unfortunately isn't in an easy position here, but it's
improving and it would be unfortunate to neglect it.

This restriction does not exist with the static linker inside the RTS,
so my suggestion, I guess, is that I'm inclined to want this to work
for *both* static/dynamic configurations out of the box without
hackery, if at all possible, which would be great for Windows users
especially until the dynamic story is back up to scratch.

[1] https://ghc.haskell.org/trac/ghc/ticket/5987
[2] http://blog.omega-prime.co.uk/?p=138

> As the application depends on shared libraries, now a tool to collect
> these libraries would be required so they can be distributed together
> with the executable binary when deploying a Cloud Haskell application
> in a cluster. We won?t delve further into this problem.

And for any people interested in this - on Linux, a tool like
patchelf[3] would help immensely for moving executables+their
dependencies around in a 'bundle' style way.

[3] http://nixos.org/patchelf.html

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From m at tweag.io  Wed Jan 29 12:11:46 2014
From: m at tweag.io (Mathieu Boespflug)
Date: Wed, 29 Jan 2014 13:11:46 +0100
Subject: Static values language extension proposal
In-Reply-To: <CAEs96n1c8LVo55sD4Hb2z5isoe416p2zwH=HbJ9pgzM5f3bCeg@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAEs96n1c8LVo55sD4Hb2z5isoe416p2zwH=HbJ9pgzM5f3bCeg@mail.gmail.com>
Message-ID: <CAJ0eudooPwQScx4Tuc3ao4-jz3oH_-4Bf48ekMk7y87BWTJ6dQ@mail.gmail.com>

Hi Austin,

this is very useful information, thanks. So it seems that the rts
linker is here to stay for a while longer still, at least because
there is no good alternative on Windows as of yet.

If I understand you correctly, on Windows dynamic linking is not an
option in part because of the number-of-exported-symbols limit, and
when linking statically one hits the same limit if stuff like
-optl-Wl,--export-dynamic is used. So at least on Windows, the only
way out is the rts linker. Supporting both linkers is certainly an
option. If I remember correctly, the issue Facundo found with the rts
linker is that to use it for looking up symbol addresses, you
apparently need to have an object file loaded twice, effectively (once
statically linked at build time, the second time through the rts
linker at runtime for doing the lookups). Maybe there's a way around
that, or that could be added? In any case for platforms with no
alternative, like Windows, I guess double loading is a tolerable price
to pay.

Best,

Mathieu

On Wed, Jan 29, 2014 at 12:11 PM, Austin Seipp <austin at well-typed.com> wrote:
> Hello,
>
> I'd just like to say I haven't gone over every discussion in this
> thread and had time to digest it all - I thought I would just
> highlight a minor technicality.
>
> On Fri, Jan 24, 2014 at 11:19 AM, Facundo Dom?nguez
> <facundo.dominguez at tweag.io> wrote:
>> Looking up static references
>> ====================
>>
>> `unstatic` is implemented as a function which finds a top-level value
>> from the `GlobalName`, otherwise it raises an exception. It crucially
>> relies on leveraging the system's dynamic linker, so out-of-the-box
>> only works with dynamically linked binaries (but see below).
>> `unstatic` proceeds as follows:
>>
>>   * Determines the name of the shared library from the package name
>> and the package version.
>>
>>   * Determines the symbol of the value by Z-Encoding the package name,
>> the module name and the value name.
>>
>>   * Uses the system's dynamic linker interface to obtain the address
>> of the symbol.
>>
>>   * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#`
>>
>> In principle, only symbols in shared libraries can be found. However,
>> the dynamic linker is able to find symbols in modules that are linked
>> statically if GHC is fed with the option -optl-Wl,--export-dynamic. A
>> future enhancement could be to have GHC warn the user when modules
>> using the extension are linked statically and this option is not used
>> during linking.
>>
>> GHC only defines symbols for exported definitions in modules. So
>> unstatic won't be able to find the private bindings of a module. For
>> this sake, the implementation of static should in addition ensure that
>> the bindings it gets will appear in the symbol table when they are not
>> exported by their defining modules.
>
> Regarding -optl-Wl,--export-dynamic for static builds, and all that
> jazz - if I am understanding you right, note that Windows is a bit
> particular here, because there is a hard limit on the number of
> symbols allowed in a DLL. That means forcefully exporting *everything*
> could quickly get you to the symbol limit with the dynamic linker with
> large-ish applications (one exported function or data type may result
> in a handful of exported symbols created.) If you want to see the pain
> this has caused GHC itself, please see GHC bug #5987[1], which makes
> dynamic support on windows difficult - it's currently disabled now
> anyway.
>
> Furthermore, dynamic DLLs on Windows are a bit tricky anyway as the
> loader is fundamentally different from your typical ld.so (which there
> are ways around[2], but a bit nasty as you have to hack the COFF
> file.) Windows unfortunately isn't in an easy position here, but it's
> improving and it would be unfortunate to neglect it.
>
> This restriction does not exist with the static linker inside the RTS,
> so my suggestion, I guess, is that I'm inclined to want this to work
> for *both* static/dynamic configurations out of the box without
> hackery, if at all possible, which would be great for Windows users
> especially until the dynamic story is back up to scratch.
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/5987
> [2] http://blog.omega-prime.co.uk/?p=138
>
>> As the application depends on shared libraries, now a tool to collect
>> these libraries would be required so they can be distributed together
>> with the executable binary when deploying a Cloud Haskell application
>> in a cluster. We won't delve further into this problem.
>
> And for any people interested in this - on Linux, a tool like
> patchelf[3] would help immensely for moving executables+their
> dependencies around in a 'bundle' style way.
>
> [3] http://nixos.org/patchelf.html
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Mathieu Boespflug
Founder at http://tweag.io.

From carter.schonwald at gmail.com  Thu Jan 30 18:47:32 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 30 Jan 2014 13:47:32 -0500
Subject: Static values language extension proposal
In-Reply-To: <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>
Message-ID: <CAHYVw0zQZX1cr-KPiGG_Gw0NEwgrgpVRuMoqaUJ+_wuqXeR_1Q@mail.gmail.com>

indeed! Thanks erik!

On the paralllel list, edkso shares with us a single commit that adds all
the requested features as a user land lib

https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7

@tweag folks, please do not write personal attacks on the issue tracker, if
you find yourself frustrated, I probably am too! please keep a positive
constructive tone in all future communications.





On Tue, Jan 28, 2014 at 9:20 PM, Erik de Castro Lopo
<mle+hs at mega-nerd.com>wrote:

> Mathieu Boespflug wrote:
>
> > [Sorry for the multiple reposts - couldn't quite figure out which
> > email address doesn't get refused by the list..]
> >
> >
> > Hi Carter,
> >
> > thank you for the good points you raise. I'll try and address each of
> > them as best I can below.
> >
> > > 0) I think you could actually implement this proposal as a userland
> library,
> > > at least as you've described it. Have you tried doing so?
> >
> > Indeed, this could be done without touching the compiler at all.
>
> We had this response really early on in this discussion.
>
> Quite honestly I think that should have been the end of the discussion.
>
> The existing GHC release already have a huge workload getting releases
> out the door and adding to that workload without adding manpower and
> resources would be a bad idea.
>
> You really should try doing this as a library outside of GHC and if GHC
> needs a few small additional features, they can be added.
>
> > The `static e` form could as well be a piece of Template Haskell, but
> > making it a proper extension means that the compiler can enforce more
> > invariants and be a bit more helpful to the user.
>
> Once it works outside GHC and has proven useful, then it might be
> worthwhile
> add small specific, easily testable/maintainable features to GHC to support
> what goes on on your library.
>
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140130/7ee38ee7/attachment.html>

From facundo.dominguez at tweag.io  Thu Jan 30 21:48:38 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Thu, 30 Jan 2014 19:48:38 -0200
Subject: Static values language extension proposal
In-Reply-To: <CAHYVw0zQZX1cr-KPiGG_Gw0NEwgrgpVRuMoqaUJ+_wuqXeR_1Q@mail.gmail.com>
References: <CA+Q==SA-jeZBWPDaPUS6G7UTD1y1gjz=3fHeLNN_oPrFrBi05w@mail.gmail.com>
 <CAHYVw0wNnMJfJytKkp30WT=gMAt9JbOMBfnX4g3rouEfrKX6TQ@mail.gmail.com>
 <CAC0LnftcPGtd3NS9wN3JzeKtUc5Pk8nKPKGUOD10RZcLVco0Gg@mail.gmail.com>
 <20140129132025.01d3f80cee8b789c11cf5d10@mega-nerd.com>
 <CAHYVw0zQZX1cr-KPiGG_Gw0NEwgrgpVRuMoqaUJ+_wuqXeR_1Q@mail.gmail.com>
Message-ID: <CA+Q==SBrUhj8=dsQwqy6n-tJCg7vhPnGjop0O9sFnjHnZAonfQ@mail.gmail.com>

For interested fellows, discussion also continues in [1] and [2].

Best,
Facundo

[1] https://ghc.haskell.org/trac/ghc/ticket/7015
[2] https://groups.google.com/d/topic/parallel-haskell/b-x7VmjlEOw/discussion

On Thu, Jan 30, 2014 at 4:47 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> indeed! Thanks erik!
>
> On the paralllel list, edkso shares with us a single commit that adds all
> the requested features as a user land lib
>
> https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7
>
> @tweag folks, please do not write personal attacks on the issue tracker, if
> you find yourself frustrated, I probably am too! please keep a positive
> constructive tone in all future communications.
>
>
>
>
>
> On Tue, Jan 28, 2014 at 9:20 PM, Erik de Castro Lopo <mle+hs at mega-nerd.com>
> wrote:
>>
>> Mathieu Boespflug wrote:
>>
>> > [Sorry for the multiple reposts - couldn't quite figure out which
>> > email address doesn't get refused by the list..]
>> >
>> >
>> > Hi Carter,
>> >
>> > thank you for the good points you raise. I'll try and address each of
>> > them as best I can below.
>> >
>> > > 0) I think you could actually implement this proposal as a userland
>> > > library,
>> > > at least as you've described it. Have you tried doing so?
>> >
>> > Indeed, this could be done without touching the compiler at all.
>>
>> We had this response really early on in this discussion.
>>
>> Quite honestly I think that should have been the end of the discussion.
>>
>> The existing GHC release already have a huge workload getting releases
>> out the door and adding to that workload without adding manpower and
>> resources would be a bad idea.
>>
>> You really should try doing this as a library outside of GHC and if GHC
>> needs a few small additional features, they can be added.
>>
>> > The `static e` form could as well be a piece of Template Haskell, but
>> > making it a proper extension means that the compiler can enforce more
>> > invariants and be a bit more helpful to the user.
>>
>> Once it works outside GHC and has proven useful, then it might be
>> worthwhile
>> add small specific, easily testable/maintainable features to GHC to
>> support
>> what goes on on your library.
>>
>> Erik
>> --
>> ----------------------------------------------------------------------
>> Erik de Castro Lopo
>> http://www.mega-nerd.com/
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>