Proposal to simplify (static e) slightly: call for comments

Announcements
1

Do you use the StaticPointers extension at all (manual entry)? Or Cloud Haskell?

I’m proposing to simplify the specification of (static e) expressions very slightly, which might affect you.

Here is the GHC proposal.

I would love to hear if you have any thoughts about this. Thanks!

10 Likes
2

Looking around for users of static pointers, I found that Cabal’s new setup hooks use static pointers under the hood!

3 Likes
3

Interesting! Is there any way you could

  • Look at the code and assess whether this proposal would impact it?
  • Find out who wrote that code and invite them to comment on the proposal?

Thanks!

Simon

2 Likes
4

I’m not a user of CloudHaskell, so can’t “weigh in” on the proposal.

But I found it very interesting. Going back to the original manual entry, a superficial reading by a user may lead one to think it’s sufficient to have a Typeable instance, and to not consider that actually this seems more to be about a lexical/syntactic restriction not reflected in the types.

It’s hard not to have Template Haskell come to mind, as splices and Lift have related restrictions. And with Lift you can derive a serialisation to a file with Haskell syntax and then load that syntax in again in GHCi (almost Lisp-like). I’ve been exploring this in my Hell scripting language for the purpose of easily dumping and loading a data structure where the storage format is simply Hell/Haskell code, and thought Lift (without Q in the type) would be one angle.

Obviously, static itself is of interest to me, too, because I could in theory change (this) Lit :: a → Exp g a to contain a StaticPtr a after type checking is done, and write that to disk, or send over network, as “bytecode.” Similar use case to CloudHaskell, but much more modest.

Feels like there’s a broader formalisation that would handle both the dynamic Lift case and the static pointer case, in terms of recognizing a complete closed term, avoiding the warts, but remains to be seen.

4 Likes
5

I am looking at static pointers as a mechanism to compare functions.

From looking at the proposal, it seems to me that expressive power remains the same and only some convenience is lost. If we disregard sharing of y, one can always move the let variable inside the static scope manually:

let y = "Hello" in static (reverse y)

becomes

static (let y = "Hello" in reverse y)

Is that right?

If no expressive power is lost and this proposal frees up GHC developer time to work on other things, then I am all for it.

2 Likes
6

Correct. Indeed that exact example is (now) given in Section 6. All good.

1 Like
7

Indeed Matthew Pickering has been thinking about exactly this, as Section 5 now mentions. But this proposal is about a very narrow point, leaving open the possiblity of a more thorough-going update if someone makes proposal for that.

6 Likes
8

@chrisdone

I think that a TH quotation is analogous to the static keyword, since they both are about lexical/syntactic properties of expressions.

Lift is useful for converting dynamic values into a TH AST. The analogous class for Static would be something like Binary.

It is an interesting idea you propose whether you could implement static by sending bytecode over the network rather than creating a shared static pointer table. If you did this you would still need an interpreter in your binary to evaluate the bytecode, but you would be able to handle executing “unknown” programs.

1 Like
9

I think this proposal is about ready to submit to the committee.

Does anyone have anything else they’d like to add.

(NB: I have changed it quite a bit since originally posting it, so you might want to take another look.)

One open question is about deprecation cycles. I think that:

  • No one has said that their code even uses the current ability to deal with nested defintions
  • The currently impelementation has genuine bugs that cannot readily be fixed withotu this change

So I’m inclined to propose that we just implement this change without a deprecation cycle; that is, without preserving the bugs for a year while deprecating any nested definitions.

Any views?

1 Like
10

I’m also inclined to eschew a deprecation cycle for this. As mentioned in the proposal, I’m happy to help any affected user of Cloud Haskell. I’ll just need to make sure that everything is buildable during the appropriate GHC release process, before the final release.

The proposal refers to this bug report; will the change you propose make distributed-closure unbuildable?

11

On the contrary, it’ll fix it the bug!

The code in the bug report is

class C a where
  f :: a -> StaticPtr ()
  f _ = static ()

That obeys all the rules – there are no free varialbes of the static. It’s terrible that it’s rejected today.

1 Like