Personal tools

MaxBolingbroke/Talk:TypesAreCallingConventions

From HaskellWiki

Jump to: navigation, search

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)


Another minor errata for when I get around to fixing it: probably need more kind restrictions in the type rule to prevent things of kinds other than * from entering the value environment. In particular, consider data constructors.

Batterseapower 08:21, 16 May 2009 (UTC)


First I have some minor comments on section 3.5 and 3.6

  • Typo: "delcaration" -> "declaration"
  • Typo: "the a" -> "a"
  • You claim that case expressions in Haskell perform evaluation. But it is not necessarily so.
  • You claim that it doesn't matter which order arguments are evaluated in a pure strict language. While this holds if we only consider termination and side effects evaluation order does matter if we want to reliably reason about space usage.

In the related work I miss a comparison to the work of Karl-Filip Faxén. It's probably the work most closely related to what you're doing.

Josef 15:27, 27 May 2009 (UTC)


Josef, thanks for your comments - I've corrected those typos and added a comparison to FLEET -- the new version is on the webpage. However, I don't understand your point about order of argument evaluation. If I have:

{{{ let x = e1 in let y = e2 in ... }}}

Then reordering the x and y assignments won't change the peak memory requirements, will it?

Batterseapower 21:49, 28 May 2009 (UTC)