RE: D119: StaticValues language extension

[Simon Peyton Jones]

Thanks Mathieu

Looking at https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan

The spec is much better! Thank you. Still some questions below.

Meanwhile, while we are working on this "half way house" proposal, I'm going to park your emails about the more final version. I can only think about one thing at a time!

Simon

(1) Your point about Bytestring is a good one. But there is vagueness. When you serialise a StaticName, can you just serialise the fingerprint? Presumably not, because to make a new StaticName at the other end you need those Strings. Can you just serialise the Strings? Yes, because you can use mkStaticName to recover the fingerprint.

But:
- why is the fingerprint stuff exposed at all? You could just have
getStaticNameStuffToSerialise :: StaticName -> (String,String,String)
and make the type abstract.

- This bakes in sending three strings, whereas in future,
when we have a proper SPT, just sending a fingerprint will be enough
(just look it up in the SPT; the strings will be in there). Why three
strings?

It would be nice to abstract from these things. The fundamental thing is: how to serialise a StaticName. Could we have something as direct as
encodeSN :: StaticName -> ByteArray#
decodeSN :: ByteArray# -> Maybe StaticName

That API might mean that to serialise a StableName you'd first create a ByteArray# and then copy that ByteArray# into a ByteString. Another API, eliminating the intermediate copy might be:
encodeSN :: (Word8# -> IO ()) -> StaticName -> IO ()
where you pass in an imperative "write next byte" procedure in. Or maybe Word# rather than Word8#? Similarly decodeSN.

But if we did that, we wouldn't need to expose StaticName at all! We could have
encodes :: (Word8# -> IO ()) -> StaticPtr a -> IO ()
Which would be a distinct advantage, wouldn't it?

Maybe the half way house is acceptable exactly as-is, but in that case we should advertise that the entire API, apart from deRefStaticPtr, is subject to change. Perhaps that's still quite acceptable to the DH community.

(2) lookupStaticPtr returns a Dynamic, which contains a value and a TypeRep. Presumably the value is the (StaticPtr t) for some t. And presumably the TypeRep is a type representation for (StaticPtr t). Is that right? So the system must create and store the TypeRep for the StaticPtr, and put it in the SPT? I thought you weren't going to do that?




Simon

| -----Original Message-----
| From: Boespflug, Mathieu [mailto:m...@tweag.io]
| Sent: 25 November 2014 15:19
| To: Simon Peyton Jones
| Cc: Facundo Domínguez; Austin Seipp; Alexander Vershilov; Simon
| Marlow; Mikolaj Konarski; Herbert Valerio Riedel
| Subject: Re: D119: StaticValues language extension
|
| Hi Simon,
|
| I added a few additional remarks to the ImplementationPlan page, which
| I believe should answer all the questions you have in your previous
| email. I argue that serialization/deserialiazation should not be part
| of the StaticPtr API. The standard Binary type class for
| encoders/decoders targets ByteString as the serialization type, which
| is not available in base. Rather of defining serializers that target
| String instead, which strikes me as an unnecessary performance
| pessimization, I think it's better to just expose the definition of
| StaticName. Crucially, keeping StaticName private is *not* necessary
| for correctness or type safety, but making it public *is* necessary to
| allow the user to define her own serializers targeting her own string
| types (String, ByteString, Vector, Array, who knows!). This is akin to
| Data.Typeable's TyCon being public, hence allowing to serialize
| TypeRep's in userland, yet without compromising any safety.
|
| Let us know if there's anything that's still unclear, or whether you
| believe a different API would be preferable.
|
| Best,
|
| Mathieu
| --
| Mathieu Boespflug
| Founder at http://tweag.io.
|
|
| On 24 November 2014 at 18:54, Boespflug, Mathieu <m...@tweag.io> wrote:
| > Hi Simon,
| >
| > many thanks for the update. I'll prepare an email to the DH mailing
| > list, including answers to your questions below.
| >
| > Best,
| >
| > Mathieu
| > --
| > Mathieu Boespflug
| > Founder at http://tweag.io.
| >
| >
| > On 24 November 2014 at 18:49, Simon Peyton Jones
| <sim...@microsoft.com> wrote:
| >> Mathieu
| >>
| >> We talked about this in today's GHC call (unfortunately after you'd
| left, Simon).
| >>
| >> My conclusion: I'm very keen to make GHC support Cloud Haskell
| well.
| >> If you are convinced that some readily implementable half-way house
| >> in 7.10 will have a real impact on the CH community, then yes,
| we'll
| >> work with you to make that happen. (Austin will have some
| >> cross-branch merging to do, but it should not be difficult.)
| >>
| >> Time-wise it would be good to complete the main implementation work
| by the end of next week, which seems feasible since you are suggesting
| end of this week.
| >>
| >> Facundo's is now a committer, so we can work on a GHC branch
| >> wip/static-ptr or something, which will make it easier to work
| >> together. (Still good to push up the draft to Phab for others to
| >> review, though.)
| >>
| >> The first thing is to understand the specification of the half-way
| house, which appears to start at "The proposal is therefore to" on
| https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPla
| n. But I'm afraid I still don't understand the spec.
| >>
| >> * StaticPtr must presumably be an instance of some serialisable or
| >> binary type class, but that does not appear
| >>
| >> * The type class machinery makes it more complicated. Presumably
| there is a monomorphic function to serialise a StaticPtr and one to
| deserialise one. They should be part of the StaticPtr API. What are
| their types?
| >>
| >> * What is this fingerprint thing? Why is it part of the API. (It
| is
| >> not part of the StaticPtr API given here
| >> https://ghc.haskell.org/trac/ghc/wiki/DistributedHaskell.) It
| seems
| >> likely to me that Fingerprint should form part of the
| implementation,
| >> but not part of the client API
| >>
| >> * I don't understand lookup.
| >>
| >> It would be good to share the proposed design with the DH mailing
| list.
| >>
| >> I'm out all tomorrow I'm afraid.
| >>
| >> Simon
| >>
| >>
| >> | -----Original Message-----
| >> | From: Boespflug, Mathieu [mailto:m...@tweag.io]
| >> | Sent: 24 November 2014 16:59
| >> | To: Simon Peyton Jones
| >> | Cc: Facundo Domínguez; Austin Seipp; Alexander Vershilov
| >> | Subject: Re: D119: StaticValues language extension
| >> |
| >> | Hi Simon,
| >> |
| >> | we're fairly new to GHC development, and this means that we're
| >> | discovering a lot of things as we go (both in the codebase and
| >> | process wise!). I'm sorry that none of us noticed the release
| plan
| >> | from October 3rd. I have created a new page with a few remarks
| on
| >> | the implementation plan that I submit to you and Austin:
| >> |
| >> |
| >> |
| https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/Implementation
| >> | Pla
| >> | n
| >> |
| >> | As remarked on that page, I believe that -XStaticPointers
| without
| >> | a revamped Data.Typeable is certainly not the ideal but still
| >> | perfectly viable, especially in the context of
| >> | distributed-process. The size of the TCB becomes quite a bit
| >> | larger without a new Data.Typeable, but that just changes some
| >> | small and localized implementation details internal to both
| >> | distributed-closure and distributed-process. I believe we can
| >> | arrive at a place where we are implementing *exactly* the same
| API
| >> | as we would aim to provide longer term, it's just that short
| term,
| >> | the *implementation* of this API will not perform dynamic checks
| that disributed-process is doing itself anyways.
| >> |
| >> | Crucially, I believe that the intermediate step along the road
| >> | that I have outlined there corresponds to a very small language
| >> | extension with very little impact on the compiler (no change
| >> | required to Data.Typeable required just yet at any rate).
| Building
| >> | the SPT isn't entirely trivial and has had us making very slow
| >> | progress but progress nonetheless in the last few days in the
| >> | absence of Facundo (he is coming back tomorrow). But I suspect
| the
| >> | implementation effort there in terms of KLOC's and with some
| input
| >> | from someone more knowledgeable would be very small indeed.
| >> |
| >> | We already have all the basic infrastructure in place. The
| changes
| >> | to the lexer and parser are already implemented. New tests have
| >> | been added to the test suite. The additional module that must be
| >> | added to base has already been implemented. Static expressions
| are
| >> | defined in the compiler as well as in Template Haskell - all
| these
| >> | things were already part of the D119 phabricator diff we
| submitted
| >> | in August. We have updated all of that to use the new names and
| >> | keep it here for
| >> | now:
| >> |
| >> | https://github.com/tweag/ghc/tree/static-pointers
| >> |
| >> | though we can push that to the GHC repo as soon as one of us
| gets
| >> | access. We have removed any funny business from the desugarer. I
| >> | believe that the typechecker needs to be updated still, but apart
| >> | from that the only major item is actually building the SPT.
| >> |
| >> | I myself and Facundo would be more than happy if this "half way
| house"
| >> | (as you put it) that is outlined above would be included in GHC,
| >> | but it's for you and Austin to decide what plan makes sense of
| course.
| >> | Time wise, I would hope that getting the SPT implemented should
| be
| >> | possible by the end of the week. After that, I expect there to be
| a
| >> | few small revisions following a few more review cycles, but I
| think
| >> | that contrary to our first attempt, we are now a lot better
| >> | synchronized on what it is we are trying to achieve and how we
| >> | ought to go about it.
| >> |
| >> | As we discussed during ICFP, the vision is very much to make
| Cloud
| >> | Haskell as easy to use as Erlang. "Easy" is really key here,
| >> | because if things are not easy then much of the benefits of
| Cloud
| >> | Haskell will be lost. I strongly believe that one of the key
| >> | contributors to confusing complexity in Cloud Haskell today is
| the
| >> | TH that is necessary to use it (it works ok for very simple
| cases,
| >> | but is simply rather difficult to scale up). I met with Peter
| >> | Braam recently who told me that the current TH based solution
| was
| >> | causing him and his team many headaches, in part because e.g.
| the
| >> | fact that the order of declarations is important is very
| unintuitive and "un-Haskell like".
| >> | He told me he spent quite some time wrestling with these issues.
| >> | At Tweag I/O, we have perhaps the largest deployment of Cloud
| >> | Haskell in development and soon to be put in production (Q1
| 2015).
| >> | Wrestling with the TH that is currently in distributed-process
| has
| >> | ended up being a significantly bigger issue than I anticipated
| at
| >> | first. In some of our modules, up to 30% of the code is
| dedicated
| >> | to boilerplate that either repeats or works around bugs in the
| >> | current TH implementation. As mentioned previously, we know that
| >> | FP Complete is currently conducting a very serious feasibility
| >> | study of Cloud Haskell for one of its projects, designed to work
| >> | under the constraint that it must be usable by analysts that are
| >> | not entirely familiar with Haskell. I don't know first hand
| about
| >> | other significant Cloud Haskell projects, but
| >> |
| >> | For the products we develop, we need our client to be able to
| >> | deploy our solution from source code. The DevOps team of our
| >> | client is very unfamiliar with Haskell and avoiding the need for
| >> | them to patch up a GHC source RPM to get things working will be
| a
| >> | great benefit. For all these other current users, and in
| >> | particular for future users, IMHO having first class support
| from
| >> | a stock compiler that ships with their distribution will
| >> | significantly reduce the friction in using Cloud Haskell. If the
| >> | GHC release cycle was shorter, say 6 months instead of a year,
| >> | then I think a very reasonable course of action would be to just
| >> | wait for the next release cycle, but we certainly understand that
| >> | such a biannual major release cadence would put far too much
| strain
| >> | on release management. As it is, waiting for another 18 months
| >> | from now before one sees a stable release of this feature would
| be rather unfortunate I think.
| >> |
| >> | How would you two like to proceed? If you agree that it's
| feasible
| >> | to implement an early version of the extension in GHC 7.10,
| would
| >> | you be up for merging this small feature post feature freeze
| (say
| >> | in the next couple of weeks)? I can't promise to be able to
| >> | dedicate a developer full time to the effort throughout this
| last
| >> | push, but between Facundo and Alexander we should be able to
| work
| >> | out a way to devote an adequate amount of time.
| >> |
| >> | Best,
| >> |
| >> | Mathieu
| >> | --
| >> | Mathieu Boespflug
| >> | Founder at http://tweag.io.
| >> |
| >> |
| >> | On 20 November 2014 at 16:44, Simon Peyton Jones
| >> | <sim...@microsoft.com> wrote:
| >> | > Mathieu
| >> | >
| >> | > Maybe we've failed to communicate well. I apologise for that.
| >> | >
| >> | > | I strongly believe compiler support here will make Cloud
| >> | Haskell > | *much* more usable, based on the experience that
| >> | Facundo and I have > | using it on projects for 2 years, and
| >> | because we're seeing a > | resurgence of interest as of late
| >> | around Cloud Haskell (and to > | mention in passing, FP Complete
| >> | has a large project for which they > | are considering CH) that
| >> | would benefit from this support being part > | of a stable
| >> | compiler release.
| >> | >
| >> | > So do I. Does that mean it has to be in 7.10? I had not
| >> | previously realised that you considered that super-important.
| >> | >
| >> | > If so, what is your plan, time-wise? At the moment we are
| still
| >> | in technical discussion about what and how, and I expect quite a
| >> | bit of iteration. For example, the API for StablePtr builds on
| >> | proposed changes to Typeable (as described here
| >> | https://ghc.haskell.org/trac/ghc/wiki/DistributedHaskell), which
| >> | have not been started, even if everyone agreed.
| >> | >
| >> | > Maybe you have in mind a half-way house? (You mentioned that
| >> | the SPT might not have TypeReps?) If so, it would be good to
| >> | write down a specification of what you propose.
| >> | >
| >> | >
| >> | > These things are not impossible if you want to make a case
| that
| >> | it is mission critical for a significant segment of users; e.g.
| we
| >> | could delay forking the tree altogether, or pay the cost of
| >> | merging patches across.
| >> | >
| >> | > Simon
| >> | >
| >> | > PS We did announce the feature freeze nearly two months ago
| but
| >> | that's > water under the bridge now.
| >> | >
| >> | https://www.haskell.org/pipermail/ghc-devs/2014-
| October/006518.html
| >> | >
| >> | >
| >> | >
| >> | > | -----Original Message-----
| >> | > | From: Boespflug, Mathieu [mailto:m...@tweag.io] > | Sent: 20
| >> | November 2014 09:29 > | To: Simon Peyton Jones > | Cc:
| Facundo
| >> | Domínguez; Austin Seipp; Alexander Vershilov > | Subject: Re:
| >> | D119: StaticValues language extension > | > | Facundo said
| that
| >> | last week ahead of any concertation with me, as I > | was on
| the
| >> | plane coming back from a client meeting in Colorado. I > |
| >> | reallocated resources and shifted Facundo away from a client
| >> | project > | temporarily so that Facundo was able to spend 20 hrs
| >> | this week on > | the patch, before leaving on a holiday that
| was
| >> | planned a while > | ago. I have also arranged for Alexander
| >> | Vershilov (in CC), who has > | been following our work in this
| >> | space internally for a while now > | and is familiar with it,
| to
| >> | work on building an SPT to solve the GC > | issue yesterday,
| >> | today and tomorrow.
| >> | > |
| >> | > | It's the best I can do to reallocate resources on a 2 week
| >> | notice > | for a feature freeze. I strongly believe compiler
| >> | support here will > | make Cloud Haskell *much* more usable,
| >> | based on the experience that > | Facundo and I have using it
| on
| >> | projects for 2 years, and because > | we're seeing a resurgence
| >> | of interest as of late around Cloud > | Haskell (and to mention
| >> | in passing, FP Complete has a large project > | for which they
| >> | are considering CH) that would benefit from this > | support
| >> | being part of a stable compiler release.
| >> | > | --
| >> | > | Mathieu Boespflug
| >> | > | Founder at http://tweag.io.

[Boespflug, Mathieu]

Hi Simon,

On 26 November 2014 at 16:15, Simon Peyton Jones <sim...@microsoft.com> wrote:

> (1) Your point about Bytestring is a good one. But there is vagueness. When you serialise a StaticName, can you just serialise the fingerprint? Presumably not, because to make a new StaticName at the other end you need those Strings. Can you just serialise the Strings? Yes, because you can use mkStaticName to recover the fingerprint.

Right. So this is why in the previous spec the types were as follows:

fingerprint :: StaticPtr a -> Fingerprint
lookupStaticPtr :: Fingerprint -> Maybe DynStaticPtr

i.e. the Fingerprint is the key, not the StaticName. A StaticName as
currently defined is only really useful for debugging, but it's only
the fingerprint that one really needs to serialize down the wire. A
fingerprint is much shorter than a StaticName, and much faster to
serialize. I believe we ought to consider Fingerprints as the unique
identifier for "values that one can get a StaticPtr to". But that's
evidently a more contentious tack.

> But:
> - why is the fingerprint stuff exposed at all? You could just have
> getStaticNameStuffToSerialise :: StaticName -> (String,String,String)
> and make the type abstract.
>
> - This bakes in sending three strings, whereas in future,
> when we have a proper SPT, just sending a fingerprint will be enough
> (just look it up in the SPT; the strings will be in there). Why three
> strings?

Indeed. As it happens, we'll have an SPT for 7.10 anyways, and it's
easy enough to store this kind of "metadata" (the 3 strings) in the
SPT. So how about something like this? (see below for my remarks about
encodeSN/decodeSN)

data StaticName = StaticName
{ staticNameHash :: !Fingerprint
, staticNamePackage :: String
, staticNameModule :: String
, staticNameIdentifier :: String
}

staticName :: StaticPtr a -> StaticName
lookupStaticPtr :: Fingerprint -> Maybe DynStaticPtr

From a StaticName, a library like distributed-process can get a
Fingerprint, which it can send down the wire (and only that, no
strings) however the library likes. Since on the other end, only a
fingerprint is required to lookup a StaticPtr, that's fine. And given
a StaticPtr, for debugging purposes one can always ask for a "name"
for that StaticPtr, i.e. a StaticName, obtainable using the
'staticName' function.

As for whether StaticName should be abstract - well, we went with
whatever TyCon does (the two types are isomorphic). In my mind
exposing a record with name fields is clearer than a tuple of unnamed
things, and fingerprint should be exposed anyways to allow the user to
serialize only that rather than a full StaticName.

Compared to your proposal below, I think it comes down to a
philosophical choice: keep as much as possible under wraps from the
user (more abstraction) and commit to a serialization strategy in the
base library (less freedom), or let the user serialize as she wishes
(more freedom) but expose more concrete data types (less abstraction).

> It would be nice to abstract from these things. The fundamental thing is: how to serialise a StaticName. Could we have something as direct as
> encodeSN :: StaticName -> ByteArray#
> decodeSN :: ByteArray# -> Maybe StaticName
>
> That API might mean that to serialise a StableName you'd first create a ByteArray# and then copy that ByteArray# into a ByteString. Another API, eliminating the intermediate copy might be:
> encodeSN :: (Word8# -> IO ()) -> StaticName -> IO ()
> where you pass in an imperative "write next byte" procedure in. Or maybe Word# rather than Word8#? Similarly decodeSN.

Well, the ByteArray# could be embedded in the StaticName, I guess, in
which there would be no copying (the ByteArray# would be created once
and for all at StaticName creation time).

> But if we did that, we wouldn't need to expose StaticName at all! We could have
> encodes :: (Word8# -> IO ()) -> StaticPtr a -> IO ()
> Which would be a distinct advantage, wouldn't it?

I'm not sure. StaticName disappears from the API, but at the cost of
moving everything into IO, and also stripping the user away from the
freedom to encode names as she wishes. At the end of the day, I don't
think StaticName is an "internal" matter - it's precisely isomorphic
to TyCon in Data.Typeable, which is itself a public type. It provides
the user with a means to identify incoming static pointers in a human
readable form, and let's the user send down the wire anything she
likes. Besides, I suspect that calling the (Word8# -> IO ()) callback
for each byte is slower still than doing a copy from ByteArray# to
ByteString.

BTW, does anyone on this list know why the bytestring authors didn't just take

data ByteString = ByteString { offset :: Int, payload :: ByteArray# }

?

> Maybe the half way house is acceptable exactly as-is, but in that case we should advertise that the entire API, apart from deRefStaticPtr, is subject to change. Perhaps that's still quite acceptable to the DH community.

It would be nice to reserve the right to change this API in 7.12 no
matter what, even if I think it's possible to have something today
that could very well be just fine tomorrow.

> (2) lookupStaticPtr returns a Dynamic, which contains a value and a TypeRep. Presumably the value is the (StaticPtr t) for some t. And presumably the TypeRep is a type representation for (StaticPtr t). Is that right? So the system must create and store the TypeRep for the StaticPtr, and put it in the SPT? I thought you weren't going to do that?

Well, the intention originally was to have the same API as down the
line, and have the TypeRep in the Dynamic be something bogus (since
we're not storing a real TypeRep in the SPT currently). Should make a
note of that explicitly in the implementation plan. Another approach
is to take

data DynStaticPtr = forall a. DynStaticPtr (StaticPtr a)

and in the future redefine that to

type DynStaticPtr = Dynamic

Best,

[Simon Peyton Jones]

Let's try this:

===================
deRefStaticPtr :: StaticPtr a -> a
staticName :: StaticPtr a -> (String, String, String)
-- Or use some data type, I don't care, but with no fingerprint

encodeStaticPtr :: StaticPtr a -> EncodedStaticPtr
decodeStaticPtr :: EncodedStaticPtr -> Maybe DynStaticPtr

-- THIS ONE WILL CHANGE!
data DynStaticPtr where
DSP :: StaticPtr a -> DynStaticPtr

type EncodedStaticPtr = Fingerprint
or
type EncodedStaticPtr = ByteArray
===============

* You can call EncodedStaticPtr StaticName, if you like. The point is that it is full concrete, and trivial to serialise. It does not carry strings. Moreover Fingerprint and ByetArray are already part of 'base'. (I think Fingerprint is probably neatest.)

* You can get the package/module/name info from a StaticPtr with staticName. If you want a data type to make the triple easier to make sense of, that's fine with me. Do we already have such a data type in 'base'?

* I'm not persuaded by analogy with TyCon, which I think is too concrete!

* DynStaticPtr will change later, by adding a Typeable a, or TTypeRep a, to the constructor. Meanwhile you have to use unsafeCoerce.


Does that work?

Simon



| -----Original Message-----
| From: Boespflug, Mathieu [mailto:m...@tweag.io]
| Sent: 26 November 2014 17:01
| To: Simon Peyton Jones
| Cc: Facundo Domínguez; Austin Seipp; Alexander Vershilov; Simon
| Marlow; Mikolaj Konarski; Herbert Valerio Riedel; distributed-ha.
| Subject: Re: D119: StaticValues language extension
|

[Boespflug, Mathieu]

If you take

type EncodedStaticPtr = Fingerprint

then that API is precisely the same as the one in my previous email
(except for the names of encodeStaticPtr/decodeStaticPtr), so I think
we're in agreement here.

> * You can get the package/module/name info from a StaticPtr with staticName. If you want a data type to make the triple easier to make sense of, that's fine with me. Do we already have such a data type in 'base'?

Not that I'm aware of. I think we should - and as noted earlier,
replace both (part of) TyCon and the return type of staticName with
it. Perhaps a refactoring for GHC 7.12?

[Simon Peyton Jones]

| If you take
|
| type EncodedStaticPtr = Fingerprint
|
| then that API is precisely the same as the one in my previous email
| (except for the names of encodeStaticPtr/decodeStaticPtr), so I think
| we're in agreement here.

Fine -- but now we can better articulate the reasoning. (Or at least I can :-).)

Might you update the wiki page, including the reasoning?

Maybe 'EncodedStaticPtr' is not a terribly good name. StaticKey, perhaps?

| Not that I'm aware of. I think we should - and as noted earlier,
| replace both (part of) TyCon and the return type of staticName with
| it. Perhaps a refactoring for GHC 7.12?

That's fine with me. So maybe we want to define

data EntityName
= EntityName { entityPkg, entityMod, entityOcc :: String }

and we can use it more widely in 7.12.

I'm not stressed out about the exact naming.

Simon