Static values language extension proposal

[Mathieu Boespflug]

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