On 20 October 2010 13:09, Simon Peyton-Jones wrote:

Yes, you can freely use Foo/unFoo.  There's no runtime penalty.  (In the jargon of GHC's intermediate language, Foo and unFoo translate to *type-safe casts*, which generate no executable code.

That includes the 'newtype deriving' stuff too, and hence your uses of fromInteger etc.

Oh wow, excellent!

No, this isn't optimised.  The trouble is that you write (map Foo xs), but GHC doesn't know about 'map'.  We could add a special case for map, but then you'd soon want (mapTree Foo my_tree).

What you really want is to say is something like this.  Suppose my_tree :: Tree String.  Then you'd like to say        my_tree ::: Tree Foo meaning "please find a way to convert m_tree to type (Tree Foo), using newtype coercions.

The exact syntax is a problem (as usual).  We have the technology now.  The question is how important it is.

I don't know whether it's so important for me at least. I was just interested in how much optimisation it did. On 20 October 2010 17:58, Gregory Crosswhite wrote:

On 10/20/10 4:09 AM, Simon Peyton-Jones wrote:

...

No, this isn't optimised.  The trouble is that you write (map Foo xs), but GHC doesn't know about 'map'.  We could add a special case for map, but then you'd soon want (mapTree Foo my_tree).

How about a special case for fmap?  That seems like it should handle a lot of cases.

Personally I haven't had much use for mapping newtype constructors/unconstructors. My personal use case of newtypes unwrapping/wrapping is in passing them to functions and in record fields, not so much unwarpping them inside data types and trees across the board. -- | Assign a review for a submission to a user. assignReview :: TrackId -> UserId -> SubmissionId -> Model () assignReview tid uid sid = do insert T.review $ F.uid <<- unUserId uid # F.submission <<- unSubmissionId sid # F.trackId <<- unTrackId tid This is the simplest function I could find. However, consider if in my busy hacking I accidentally get the argument order incorrect in the definition, or the call, with newtypes I can't mismatch them. This has stopped me doing bad things a few times in my haste. Another nice thing I've found is combining them with view patterns: -- | Submit a review. submitReview :: UserId -> SubmissionId -> [ReviewField] -> Model () submitReview (unUserId -> uid) (unSubmissionId -> sid) rs = do forM_ rs $ \ReviewField{..} -> ... The next ten lines or so use uid and sid. This makes the submitReview function kind of "guarded" from being given the wrong values. Inside it can do what it wants. You might point out that now that I've unwrapped them I can pass them to some other function willy nilly, but of course if a function needs a submission id, then it needs a SubmissionId. So I find this really nice. And of course I use the deriving extensively: newtype SubmissionId = SubmissionId { unSubmissionId :: Int } deriving (Show,Num,Eq,Ord,Enum,Integral,Real,ShowConstant,JSON) I have a types file with 46 newtypes, zero type aliases, and ah, 47 data types. GHCi gets kind of slow when dealing with it. My solution is to have an Emacs shortcut to build the project with cabal every so often so that GHCi can load the .o files in an instant.

Do we really want to treat every newtype wrappers as a form of 'id'? For example: newtype Nat = Nat Integer -- must always be positive A possible rule (doesn't actually typecheck, but you get the idea): forall (x :: Nat). sqrt (x * x) = x If we ignore newtyping we get an incorrect rewrite rule. It depends on the exact implementation of which 'id's would be recognised. On 20 October 2010 21:08, James Andrew Cook wrote:

On Oct 20, 2010, at 11:58 AM, Gregory Crosswhite wrote:

...

On 10/20/10 4:09 AM, Simon Peyton-Jones wrote:

...

No, this isn't optimised.  The trouble is that you write (map Foo xs), but GHC doesn't know about 'map'.  We could add a special case for map, but then you'd soon want (mapTree Foo my_tree).

How about a special case for fmap?  That seems like it should handle a lot of cases.

Or even better, a special handling of 'id' in rules pragmas that would cause any rule matching id to also match any newtype constructor or projection. Or have the compiler automatically add rules that map all newtype wrappers and unwrappers to unsafeCoerce and make sure that unsafeCoerce has rules for map, fmap, (.), etc.

--James_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Push the envelope. Watch it bend.

On 10/20/10 7:09 AM, Simon Peyton-Jones wrote:

Yes, you can freely use Foo/unFoo. There's no runtime penalty. (In the jargon of GHC's intermediate language, Foo and unFoo translate to *type-safe casts*, which generate no executable code.

When does the conversion to type-safe casts occur relative to other optimizations (namely, rewrite rules)? -- Live well, ~wren

On Thursday 21 October 2010 01:11:25, wren ng thornton wrote:

On 10/20/10 7:07 PM, wren ng thornton wrote:

...

On 10/20/10 7:09 AM, Simon Peyton-Jones wrote:

...

Yes, you can freely use Foo/unFoo. There's no runtime penalty. (In the jargon of GHC's intermediate language, Foo and unFoo translate to *type-safe casts*, which generate no executable code.

When does the conversion to type-safe casts occur relative to other optimizations (namely, rewrite rules)?

That is, I know that rewrite rules operate on the source language not on Core, but to what extent does that mean that type-safe casts inhibit the firing of rules?

Pretty much completely, I'm afraid. There's a rewrite rule for realToFrac :: Double -> Float. Build yourself a benchmark for that transformation that runs some measurable time (say 0.1 seconds or so). Now use a newtype wrapper around Float instead (and don't add a rewrite rule for it). Ouch.

Simon Peyton-Jones wrote:

What you really want is to say is something like this. Suppose my_tree :: Tree String. Then you'd like to say my_tree ::: Tree Foo meaning "please find a way to convert m_tree to type (Tree Foo), using newtype coercions.

The exact syntax is a problem (as usual). We have the technology now. The question is how important it is.

I think extending the syntax for contexts would be sufficient: Write a ~~ b for "a can be converted to b by wrapping / unwrapping newtypes", which is a conservative approximation of "a and b have the same representation". Then we can define safeCoerce :: (a ~~ b) => a -> b safeCoerce = unsafeCoerce and your example would become safeCoerce my_tree :: Tree Foo The feature would add convenience to the language when working with newtypes, and reduce the tension between type safety and performance (where the choice is between using a newtype and unsafeCoerce, and just working with the plain underlying type.) So while the pressure is quite low, I imagine it would become quite a useful feature once we'd have it, but that's of course speculation. As far as I can see, the feature is nontrivial: Care has to be taken to not break abstractions (like "safely"coercing IO to ST), so it's quite possible that the engineering effort outweighs the potential benefits. Best regards, Bertram

| Then we can define | | safeCoerce :: (a ~~ b) => a -> b | safeCoerce = unsafeCoerce

Yes, that's right. When I said "we have the technology" I meant that we (will) have something similar to ~~. See our paper "Generative Type Abstraction and Type-level Computation" http://www.cis.upenn.edu/~sweirich/newtypes.pdf. No unsafeCoerce required.

The idea was to put safeCoerce into a library. The syntax extension would be light-weight because contexts, unlike expressions, still have plenty of room for extensions. The idea is is based on the assumption that to the compiler, 'unsafeCoerce' looks like an artificial safe coercion, so that after inlining safeCoerce, we get exactly the effect of a safe coercion during type checking and further compilation. Perhaps that assumption is wrong. I'll look at the paper. Regards, Bertram