Personal tools

MaxBolingbroke/Talk:TypesAreCallingConventions

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (final comments from me)
Line 34: Line 34:
   
 
[[User:DuncanCoutts|DuncanCoutts]] 10:22, 11 May 2009 (UTC)
 
[[User:DuncanCoutts|DuncanCoutts]] 10:22, 11 May 2009 (UTC)
  +
  +
--------------------------------
  +
  +
I'm glad you found the paper interesting! Yes, HL is the old name for the source language -- we clearly failed to search-and-replace comprehensively enough.
  +
  +
Your post on the mailing list RE unpack on argument types is very interesting. I hadn't considered the possibility, but it certainly makes sense. I don't think it would be possible to UNPACK non-strict arguments without causing a semantic change (e.g. consider UNPACKing a Int argument to an Int# - unlifted types may not point to a thunk), but certainly UNPACKing strict stuff makes sense.
  +
  +
[[User:Batterseapower|Batterseapower]] 16:08, 11 May 2009 (UTC)

Revision as of 16:08, 11 May 2009

Talk page for "Types Are Calling Conventions"

This is a discussion page for the paper Types Are Calling Conventions.

If you are kind enough to read this paper, you may like to jot down any thoughts it triggers off, and see what others have written. This talk-page lets you do just that.

You can identify your entries by preceding them with four tildes. Doing so adds your name, and the date. Thus:

Batterseapower 08:42, 19 April 2007 (UTC) Note from Max

If you say who you are in this way, we'll be able to acknowledge your help in a revised version of the paper.


OK, I can add the first errata myself: I've just noticed that my section about an alternative translation for type lambdas is total nonsense because it doesn't preserve type variable binding. That's what I get for adding a new section at the last moment... Batterseapower 22:17, 10 May 2009 (UTC)


I'm only half way through but it immediately makes me ask the question of if this helps us to express data types containing functions where we want to specify a particular data representation (ie calling convention of the function). My main example is types for monads eg:

newtype Put a = Put {
        runPut :: (a -> {-# UNPACK #-} !Buffer -> [B.ByteString])
                     -> {-# UNPACK #-} !Buffer -> [B.ByteString]
    }

See this old thread http://www.haskell.org/pipermail/glasgow-haskell-users/2007-March/012188.html

A couple typos: final bit of section 1, final sentence has a spurious '(' before the full stop. Section 6.2 Use-site arity raising, "than than".

Two thirds of the way through now... :-) The basic idea is very appealing. To make it possible (sanely) to express these calling convention optimisations we extend the language to express the before and after picture. It's like the addition of unboxed types/kinds to the intermediate language which enabled the optimiser to express the current worker wrapper transform.

You mention in the introduction "The source language, HL" without it being clear if HL is an acronym we should know or if it's just a name for a language you will be introducing later on. Though the language you introduce later however is featherweight Haskell (FH).

DuncanCoutts 10:22, 11 May 2009 (UTC)


I'm glad you found the paper interesting! Yes, HL is the old name for the source language -- we clearly failed to search-and-replace comprehensively enough.

Your post on the mailing list RE unpack on argument types is very interesting. I hadn't considered the possibility, but it certainly makes sense. I don't think it would be possible to UNPACK non-strict arguments without causing a semantic change (e.g. consider UNPACKing a Int argument to an Int# - unlifted types may not point to a thunk), but certainly UNPACKing strict stuff makes sense.

Batterseapower 16:08, 11 May 2009 (UTC)