Doug McIlroy | 2 Mar 00:22 2015

definition of List.transpose

Not having participated in haskell' before, I'm not sure how
to put these perfecting amendments--mot langauge changes--into
the pot.

Doug McIlroy

The specification of List.transpose does not tell what a "column"
of a ragged-right list of rows is, either directly or by example.
Here is a fuller spec, plus some properties.


A generalization of the customary matrix operation, transpose returns
a list of columns extracted from a list of rows.  The jth column
of x::[[a]] comprises all extant elements x!!i!!j ordered by i.

In the subdomain of list structures that have positive nonincreasing
row lengths, e.g. matrices and Young tableaux,
	transpose . transpose === id
	(transpose x) !! i !! j === x !! j !! i
In general
	transpose . transpose . transpose === transpose
	sum . map length . transpose === sum . map length

Example: transpose [[10,11],[20],[],[30,31,32]] === [[10,20,30],[11,31],[32]]


The reference definition can be simplified:

(Continue reading)

Edward Kmett | 12 Aug 19:20 2014

Proposal: Treat OtherLetter as lower case in the grammar

Back in 2008 or so, GHC changed the behavior of unicode characters in the parser that parse as OtherLetter to make them parse as lower case so that languages like Japanese that lack case could be used in identifier names:

In a recent thread on reddit Lennart Augustsson pointed out that this change 
was never backported to Haskell'.

Would it make sense to adopt this change in the language standard?

Marlow when he made the change to GHC noted he was considering bringing it up to Haskell' but here we are 6 years later.

-Edward Kmett

Haskell-prime mailing list
Björn Peemöller | 7 Aug 15:16 2014

Infix declaration: digit or integer?

Hello Haskell-Prime,

I just discovered that the Haskell 2010 report allows the precedence of
infix declarations to be an integer instead of just a digit. Therefore,
also the following declarations are allowed:

    -- compiles
    infix 0x7 <$>
    infix 0o7 <$>

    -- does not compile because of precedence out of range
    infix 0xa <$>
    infix 0oa <$>
    infix 123 <$>

Interestingly, the in section 4.4.2 (Fixity Declarations) the report says:

> The *integer* in a fixity declaration must be in the range 0 to 9.

as well as

> If the *digit* is omitted, level 9 is assumed.

This is of course no problem, I'm just curious if there is some
motivation for integer I'm not aware of.

Kind Regards,

Haskell-prime mailing list
Haskell-prime <at>
Merijn Verstraaten | 17 Apr 16:19 2014

Proposal - Foreign enum support

Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification.

Proposal - Foreign enum support

At the moment the FFI does not have a convenient way with interacting enums
(whether proper enums or CPP defines) in C (like languages). Both enums and CPP
defined enums are major parts of large C APIs and they are thus crucial to
writing foreign bindings. A few examples:

SDL_image defines the following enum:

    typedef enum {
        IMG_INIT_JPG = 0x00000001,
        IMG_INIT_PNG = 0x00000002,
        IMG_INIT_TIF = 0x00000004,
        IMG_INIT_WEBP = 0x00000008
    } IMG_InitFlags;

OpenCL specifies the following typedefs + CPP defined enum:

    typedef uint32_t  cl_uint     __attribute__((aligned(4)));
    typedef cl_uint   cl_platform_info;

    /* cl_platform_info */
    #define CL_PLATFORM_PROFILE                         0x0900
    #define CL_PLATFORM_VERSION                         0x0901
    #define CL_PLATFORM_NAME                            0x0902
    #define CL_PLATFORM_VENDOR                          0x0903
    #define CL_PLATFORM_EXTENSIONS                      0x0904

OpenCL functions will return the above CPP defines as return values of type

Current Solutions

In many cases someone wrapping such a C library would like to expose these
enums as a simple sum type as this has several benefits: type safety, the
ability to use haskell constructors for pattern matching, exhaustiveness

Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set
of foreign types and newtypes with exposed constructors of these types. As such
there seem two approaches to wrap these enums:

 1. Implement an ADT representing the enum and write a manual conversion
    function between the ADT and the corresponding C type (e.g. CInt -> Foo and
    Foo -> CInt).

 2. Use a tool like c2hs to automatically generate the ADT and conversion

In both cases the foreign functions are imported using the corresponding C type
in their signature (reducing type safety) and the user is forced write trivial
wrappers for every imported function to convert the ADT to the relevant C type
and back.

This is both tedious to write and costly in terms of code produced, in case of
c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every
argument/result even though this could trivially be a no-op.

Worse, since c2hs uses the Enum class for it's conversion to/from C types it
generates Enum instances like:

    instance Enum Foo where
        fromEnum Bar = 1
        fromEnum Baz = 1337

        toEnum 1 = Bar
        toEnum 1337 = Baz
        toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched)

Since succ/pred and enumFromTo's default implementations assume enums convert
to continuous sequence of Int this means the default generated enum instances
crash. This problem could be overcome by making c2hs' code generation smarter,
but this does not eliminate the tediousness of wrapping all foreign imported
functions with marshalling wrappers, NOR does it eliminate the overhead of all
this useless marshalling.


Add a new foreign construct for enums, the syntax I propose below is rather
ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining
based on a concrete example.

    foreign enum CInt as Foo where
        Bar = 1
        Quux = 1337
        Xyzzy = _

This would introduce a new type 'Foo' with semantics approximately equivalent
too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1;
pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _".

Explicit listing of the value corresponding to a constructor should be
optional, missing values should just increment by one from the previous (like
C), if the initial value is missing, it should assume to start from 0. Values
do not need to be contiguous.

Users should be able to use these constructors as normal in pattern match
(really, this mostly follows to semantics of the above pattern synonyms).

The foreign import/export functionality should invisibly marshall Foo to the
underlying foreign type (as is done for newtypes).

I'm unsure about the support for a wildcard constructor like Xyzzy. If there is
support for a wildcard, it should be optional. On the upside a wildcard means
the marshalling is no longer a partial function. The downside is that it makes
desugaring the use of enums in patterns harder. It seems clear that

    f Xyzzy = {- ... -}
    f Bar = {- ... -}
    f Baz = {- ... -}
    f Quux = {- ... -}

Should not have the same semantics as:

    f (Foo _) = {- ... -}
    f (Foo 1) = {- ... -}
    f (Foo 2) = {- ... -}
    f (Foo 1337) = {- ... -}

So in the presence of wildcards, the Foo enum can't trivially be desugared into
pattern synonyms after checking exhaustiveness.

 1. Foreign imports are slightly more type safe, as one can now write:

        foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO ()

    Preventing users from passing an arbitrary CInt to an argument expecting a
    specific enum.

 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness
    checks and pattern matching

 3. Cheaper as marshalling Foo to CInt is a no-op

 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int
    mapping is no longer used for marshalling

 1. Non-standard extension of the FFI

 2. Someone has to implement it

 3. Wildcards constructors would present difficulties desugaring pattern
    matches to a simple newtype.

 4. ??

What Would Need to be Done?

1. Parser needs to be extended to deal with parsing of enum declarations.
2. Pattern matches of an enum type need to be checked for exhaustiveness and
   desugared to the underlying type's representation.
3. Extend foreign imports/exports to marshall enums properly.

If there's no objections I'm willing to take a stab at implementing this,
although I'd probably need some help with GHC's internals (although I could bug
#ghc for that).

Haskell-prime mailing list
Henk-Jan van Tuyl | 3 Feb 13:58 2014

Trac detected an internal error


I am trying to register as a user in the Haskell prime trac, but I get the  
error message:
Trac detected an internal error:
IOError: [Errno 2] No such file or directory: ''

There was an internal error in Trac. It is recommended that you notify  
your local Trac administrator with the information needed to reproduce the  

To that end, you could   a ticket.

The action that triggered the error was:
POST: /register

TracGuide — The Trac User and Administration Guide

I tried to register with the browsers Opera, FireFox and Internet  
Explorer; each gave the same message.

Henk-Jan van Tuyl


Folding <at> home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
Haskell programming
Haskell-prime mailing list
Haskell-prime <at>
Herbert Valerio Riedel | 29 Jan 12:09 2014

Over/underflow semantics for 'Int' et al.

Hello *,

I'd like to point your attention to

which brings up the issue what the results operations such as

 * `div minBound (-1)`
 * `quot minBound (-1)`
 * `abs minBound`

shall result in for the standard H2010 fixed-width signed types such as
`Int`, that is whether ⊥ (arithmetic overflow-exception) or
`minBound` is the more appropriate result.

Relevant sections from the Haskell 2010 report:


| 6.4. Numbers
| [...] The results of exceptional conditions (such as overflow or
| underflow) on the fixed-precision numeric types are undefined; an
| implementation may choose error (⊥, semantically), a truncated value,
| or a special value such as infinity, indefinite, etc.

...which seems contradictory to...


| * 18.1. Signed integer types
|  This module provides signed integer types of unspecified width (Int)
|  and fixed widths (Int8, Int16, Int32 and Int64). All arithmetic is
|  performed modulo 2^n, where n is the number of bits in the type.
|  [...]

Would a Haskell 2010 implementation which turns *every* integer
over/underflow (even those for addition or multiplication of 'Int'
values whose result would lie outside of [minBound..maxBound]) into a
arithmetic exception be a valid H2010 implementation?

-- hvr
Haskell-prime mailing list
Haskell-prime <at>
Ramin Honary | 9 Jan 08:46 2014

Hiding top level declaration with tilde


I did some Googling, and read a bit through the Haskell 2010 report, Chapter 5 "Modules," and searched through the Haskell-prime Trac tickets and can't really find anything on this. I don't know if it has ever been suggested before, or the reasoning for how export lists work the way they do.

So as we all know, when there is no exports list in a module declaration, everything in the top level is exported by default. If you provide an exports list, everything is hidden except what you declare in the exports list.

I think a good way to hide things without an exports list might be to simply prefix the type signature with a tilde character. For example:

    module M where

    ~type A = ()
    ~newtype B = B ()
    ~data C = MkB1 () | MkB2 ()
    ~abc :: ()
    abc = ()
    increment :: Int -> Int
    increment = (+1)

So in this example, the module M would only export the "increment" function, everything else would be hidden.

Right now, this would produce a compile-time error like:
    Invalid type signature: ~abc :: ()

I propose making this kind of expression legal and effecting whether or not the symbol is exported.

The only disadvantage I can think of is that tilde is generally reserved for making things more lazy, and using tilde in a way that has nothing to do with lazyness, it could make the language a bit more confusing. Otherwise I think it is very practical.

Haskell-prime mailing list
Benjamin Franksen | 4 Dec 14:38 2013


Module System.Posix.Directory of the unix package defines

  getWorkingDirectory :: IO FilePath
  changeWorkingDirectory :: FilePath -> IO ()

I believe the functionality is quite portable and not limited to unix-like 
systems. I know that e.g. Windows has chdir and getcwd. Module Filesystem of 
the system-fileio package has

  getWorkingDirectory :: IO FilePath
  setWorkingDirectory :: FilePath -> IO ()

I propose to add these functions to System.Environmant or maybe 


(1) This is standard functionality that should at least be in the Haskell 
Platform, if not in the standard libraries.

(2) I would like to avoid depending on an extra package just to have these 
two very basic functions available in a OS independent way.

(3) "system-fileio".Filesystem does not seem to be the right place for this. 

The last point may be arguable, but the first two are plain common sense 


"Make it so they have to reboot after every typo." ? Scott Adams
Ed Soares | 24 Nov 04:41 2013

Lista de emails trabalho com mala direta mala direta como fazer

Lista de emails trabalho com mala direta mala direta como fazer lista de mail também lista de emails,
cadastro email lista email:    Nós sabemos que list mail, é muito
legal para a maioria das pessoas. endereco de email listas email  e acima de tudo lista de emails, email de
empresas o que e mailing, o objetivo de nosso website. se você busca emails de pessoas, email marketing e
também email mailing: 

é excelente listas de emails tais como lista email, endereco de email lista com emails. é fantástico
emails de pessoas e, além disso lista email. envio de emails email cadastro, marketing email. 

atualmente lista de email compreendendo Enviar email, newsletter pode ser bastante bom. é realmente a
função do nosso website: cadastro email, Enviar email, e bem como listas de emails. Oferecemos o melhor
em lista de email listas de emails, envio de emails. 
Nikita Volkov | 14 Oct 18:13 2013

Anonymous records. A solution to the problems of record-system.

Anonymous records. A solution to the problems of record-system.

The current record system is notorious for three major flaws:

  1. It does not solve the namespacing problem. I.e., you cannot have two records sharing field names in a single module. E.g., the following won't compile:

    data A = A { field :: String } data B = B { field :: String }
  2. It's partial. The following code will result in a runtime error:

    data A = A1 { field1 :: String } | A2 { field2 :: String } main = print $ field1 $ A2 "abc"
  3. It does not allow you to use the same field name for different types across constructors:

    data A = A1 { field :: String } | A2 { field :: Int }

This proposal approaches all the problems above and also a fourth one, which is unrelated to the current record system: it allows one to avoid declaration of intermediate types (see details below).

Gentlemen, I want you to meet,

Anonymous Records

When a record-syntax is used in Haskell it's almost always a single-constructor ADT. A question rises then: why use ADT when you don't need its main feature (i.e., the multiple constructors)? This main feature is actually the root of the second and the third problem of record-syntax from the list above. In such situations one doesn't actually need ADT, but something more like a tuple with ability to access its items by name. E.g.:

f :: (a :: Int, b :: String) -> String f rec = rec.b ++ show rec.a


f (a = 123, b = "abc")

So now you think "Okay, but how about naming it?". Well, not a problem at all - use the existingtype-construct:

type TheRecord = (a :: Int, b :: String)

Now, about the avoidance of intermediate types:

type Person = (name :: String, phone :: (country :: Int, area :: Int, number :: Int))

See? No need to declare separate types for inner values. But, of course, if you need, you still can:

type Phone = (country :: Int, area :: Int, number :: Int) type Person = (name :: String, phone :: Phone)

We can nicely access the deeply nested fields, e.g.:

personCountryCode :: Person -> Int personCountryCode person =

Okay. What about the type ambiguity? E.g., in the following the Person is actually the same type asCompany:

type Person = (name :: String, phone :: Phone) type Company = (name :: String, phone :: Phone)

Easily solvable with a help of newtype:

newtype Person = Person (name :: String, phone :: Phone) newtype Company = Company (name :: String, phone :: Phone)

What about ADTs? Again, easy:

data Product = Tea (brand :: Company) | Milk (brand :: Company, fatness :: Float)

Now, the beautiful fact:

This solution does not conflict with any existing feature of Haskell! As the examples show, it easily fits into the language as an extension. It can peacefully coexist with the existing record system of ADTs. Hence a complete backwards compatibility with old codebase. There's also a potential for many other additional features.


Haskell-prime mailing list
Andreas Abel | 10 Jul 09:08 2013

Proposal: Non-recursive let

Proposal: add a non-recursive let to the Haskell language.  In

   let' p = e in e'
   do { ... let' p = e ... }

the variables of pattern p are then *not* in scope in e.

Reasons for adding a non-recursive let:

1. recursive-let is the source for many non-termination bugs.

An instance of such a bug is in the state monad of mtl-2.1 (forgive me, 
Edward, for quoting this again): 

     state :: (s -> (a, s)) -> m a
     state f = do
       s <- get
       let ~(a, s) = f s
       put s
       return a

here, a non-recursive let was meant, the s bound by the let was supposed 
to be a new state, shadowing the old state.  However, since let is 
recursive, this actually causes a loop.

Another instance (cut-down) are let-guards like

   let Just x | x > 0 = e in x

The "x > 0" is understood as an assertion here, documenting an 
invariant.  However, Haskell reads this as

   let Just x = case () of { () | x > 0 -> e } in x

leading to non-termination.  A non-recursive version

   let' Just x | x > 0 = e in x

could be interpreted as

   case e of { Just x | x > 0 -> x }

instead, which is meaningful (in contrast to the current interpretation).

2.  Connected to 1., a non-recursive let allows for painless shadowing.

For instance, the hack

   do ...
      x <- return $ f x

exploiting non-recursiveness of the <- binding, would be unnecessary, 
instead we could write

   do ...
      let' x = f x

NB: In a do-Block, we could drop the keyword let' and simply write

   do ...
      x = f x

for a non-monadic binding, in accordance to x <- mf x,

See also

PS.:  I can work out the details of grammar and semantics if this 
proposal finds followers.



Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY