RE: Unpacking sum types

| How did you envisage implementing anonymous boxed sums? What is their | heap representation? *Exactly* like tuples; that is, we have a family of data type declarations: data (a|b) = (_|) a | (|_) b data (a|b|c) = (_||) a | (|_|) b | (||_) c ..etc.

Re: Unpacking sum types

On 08/09/2015 09:31, Simon Peyton Jones wrote: | How did you envisage implementing anonymous boxed sums? What is their | heap representation? *Exactly* like tuples; that is, we have a family of data type declarations: data (a|b) = (_|) a | (|_) b data (a|b|c) = (_||) a

Re: Unpacking sum types

On 08/09/2015 09:31, Simon Peyton Jones wrote: | How did you envisage implementing anonymous boxed sums? What is their | heap representation? *Exactly* like tuples; that is, we have a family of data type declarations: data (a|b) = (_|) a | (|_) b data (a|b|c) = (_||) a

Re: Unpacking sum types

On 07/09/2015 15:35, Simon Peyton Jones wrote: Good start. I have updated the page to separate the source-language design (what the programmer sees) from the implementation. And I have included boxed sums as well – it would be deeply strange not to do so. How did you envisage implementing

RE: Unlifted data types

| And to | be honest, I'm not sure we need arbitrary data types in Unlifted; | Force (which would be primitive) might be enough. That's an interesting thought. But presumably you'd have to use 'suspend' (a terrible name) a lot: type StrictList a = Force (StrictList' a) data StrictList' a =

Re: ArrayArrays

On 08/09/2015 09:29, Edward Kmett wrote: Once you start to include all the other primitive types there is a bit more of an explosion. MVar#, TVar#, MutVar#, Small variants, etc. can all be modified to carry unlifted content. Yep, that's a fair point. Cheers Simon Being able to be parametric

Re: ArrayArrays

Once you start to include all the other primitive types there is a bit more of an explosion. MVar#, TVar#, MutVar#, Small variants, etc. can all be modified to carry unlifted content. Being able to be parametric over that choice would permit a number of things in user land to do the same thing

Re: AnonymousSums data con syntax

2015-09-07 21:21 GMT+01:00 Joachim Breitner : > Hi, > > Am Montag, den 07.09.2015, 19:25 + schrieb Simon Peyton Jones: > > > Are we okay with stealing some operator sections for this? E.G. (x > > > > > ). I think the boxed sums larger than 2 choices are all >

Re: ArrayArrays

This would be very cool, however it's questionable whether it's worth it. Without any unlifted kind, we need - ArrayArray# - a set of new/read/write primops for every element type, either built-in or made from unsafeCoerce# With the unlifted kind, we would need - ArrayArray# - one set of

RE: Unlifted data types

| The problem 'Force' is trying to solve is the fact that Haskell | currently has many existing lifted data types, and they all have | ~essentially identical unlifted versions. But for a user to write the | lifted and unlifted version, they have to copy paste their code or use | 'Force'. But

RE: AnonymousSums data con syntax

I can see the force of this discussion about data type constructors for sums, but · We already do this for tuples: () is a type constructor and you have to count commas. We could use a number here but we don’t. · Likewise tuple sections. (,,e,) means (\xyz. (x,y,e,z)) I

Re: Unpacking sum types

Hi, Am Dienstag, den 08.09.2015, 08:53 +0100 schrieb Simon Marlow: > On 07/09/2015 15:35, Simon Peyton Jones wrote: > > Good start. > > > > I have updated the page to separate the source-language design (what the > > programmer sees) from the implementation. > > > > And I have included boxed

RE: Unpacking sum types

| I see, but then you can't have multiple fields, like | | ( (# Int,Bool #) |) | | You'd have to box the inner tuple too. Ok, I suppose. Well of course! It's just a parameterised data type, like a tuple. But, just like unboxed tuples, you could have an unboxed tuple (or sum) inside

Re: Proposal: Automatic derivation of Lift

I don't think there's any fundamental reason why unboxed fields prevent a Generic instance, as long as we're happy that unboxed values will be re-boxed in the generic representation. It simply seems as if nobody has thought of implementing this. As an example, consider the following hand-written

RE: Proposal: Automatic derivation of Lift

| I don't think there's any fundamental reason why unboxed fields | prevent a Generic instance, as long as we're happy that unboxed values | will be re-boxed in the generic representation. It simply seems as if Interesting and quite reasonable idea, as an extension to `deriving(Generic)`.

RE: Shared data type for extension flags

Yes, we’d have to broaden the description of the package. I defer to Edward Yang and Duncan Coutts who have a clearer idea of the architecture in this area. Simon From: Michael Smith [mailto:mich...@diglumi.com] Sent: 02 September 2015 17:27 To: Simon Peyton Jones; Matthew Pickering Cc: GHC

RE: ArrayArrays

| Without any unlifted kind, we need |- ArrayArray# |- a set of new/read/write primops for every element type, | either built-in or made from unsafeCoerce# | | With the unlifted kind, we would need |- ArrayArray# |- one set of new/read/write primops | | With levity

Re: AnonymousSums data con syntax

For what's it worth, I feel like (|True|||) looks better than (2/5|True) or (2 of 5|True). Not sure if the confusion w/r/t (x||) as or section or 3-ary anonymous sum is worth it though. On Tue, Sep 8, 2015 at 10:28 AM, Simon Peyton Jones wrote: > I can see the force of

Re: Unpacking sum types

I just added two design notes to the wiki page: 1. If we're stealing syntax, we're stealing quite a few operators. Things like (#|), and (|#) in terms, along with the otherwise-quite-reasonable (x ||). We're also stealing things like (||) and (#||#|) in types. The fact that we're stealing (||)

Re: Proposal: Automatic derivation of Lift

Sorry, I forgot to reply-all earlier. > I hacked this up quickly just to show that it works in principle. In > practice, I think it's good to not just represent Int# as Int, but as > something like UInt where > > data UInt = UInt Int# > > i.e., is isomorphic to an Int, but distinguishable.

Re: Unlifted data types

I have put up an alternate set of proposals on https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes These sidestep around `Force` and `suspend` but probably have other problems. They make heavy use of levity polymorphism. Back story: this all was developed in a late-evening Haskell

Re: Unlifted data types

> Top-level variables may not have an unlifted type Ah, that makes much more sense now. Thanks. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted data types

On Sep 8, 2015, at 10:15 AM, Jan Stolarek wrote: > But I still can say: > > foo :: UBool > foo = foo > > ... Or am I missing > something here? I'm afraid you are. Top-level variables may not have an unlifted type, for exactly this reason. If you were to do this on a

Re: Haskell Error Messages

Ticket #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809) seems the best spot to look for this. Richard On Sep 8, 2015, at 2:49 PM, "Alan & Kim Zimmerman" wrote: > Is there currently any planned work around making the haskell error messages > able to support something

Re: Unlifted data types

On Tue, Sep 8, 2015 at 3:52 AM, Simon Peyton Jones wrote: > | And to > | be honest, I'm not sure we need arbitrary data types in Unlifted; > | Force (which would be primitive) might be enough. > > That's an interesting thought. But presumably you'd have to use 'suspend'

Re: Unpacking sum types

I don't think any #-based operators are stolen at the term level, because # is required at both ends. `(#| x #)` is not a legal operator section (nor is `(#| x |#)`), and (#|_#) is not an operator name. The boxed version only steals operators because you can shove the entire thing to one side. I

Re: Proposal: accept pull requests on GitHub

> (I'm tempted naively to ask: is there an automated way to go from a GitHub PR to a Phab ticket? Then we could convert the former (if someone wants to submit that way) into the latter.) yes, a github PR is just a branch. Thanks for bringing the discussion back on track to a productive approach.

Re: Unlifted data types

I would say, by the way, that your question still makes some sense. When discussing strict evaluation, one can think of _values_ of a type and _expressions_ of a type. The (denotational) semantics of values would be unlifted, while expressions are lifted. And functions take values to expressions.

Re: ArrayArrays

On 08/09/2015 13:10, Simon Peyton Jones wrote: | Without any unlifted kind, we need |- ArrayArray# |- a set of new/read/write primops for every element type, | either built-in or made from unsafeCoerce# | | With the unlifted kind, we would need |- ArrayArray# |- one set

RE: Unlifted data types

| > data unlifted UBool = UTrue | UFalse | > | > Intuitively, if you have x :: UBool in scope, you are guaranteed to | > have UTrue or UFalse, and not bottom. | | But I still can say: | | foo :: UBool | foo = foo | | and now foo contains bottom. You definitely CANNOT have a

Re: Unlifted data types

I think the wiki page is imprecise when it says: > data unlifted UBool = UTrue | UFalse > > Intuitively, if you have x :: UBool in scope, you are guaranteed to have > UTrue or UFalse, and > not bottom. But I still can say: foo :: UBool foo = foo and now foo contains bottom. I know that any

Re: [haskell-infrastructure] the platform has outgrown Travis-CI

Mark: Is this still an issue? I don't know if phab is the right place -- would have to check with Austin. But if this is a roadblock on the platform, we should certainly do something :-) -g On Sun, Jun 7, 2015 at 12:33 PM, Mark Lentczner wrote: > I finally figured out