__color__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter
1,2,Check class instances against their definitions.,Type Inferencer,0.1.2,0.1.3,defect,benl,assigned,2009-05-12T11:58:37Z+0100,2010-10-04T03:12:49Z+0100,"We don't currently check whether a type class instance is valid wrt its definition. Unsafe program sometimes make it through the core type checker and sometimes not.

{{{T2-CheckInstance}}} contains an area function that has a larger closure than the definition, but it is silently accepted. I've seen other programs like this be caught by the core type checker.
",benl
1,7,Merge projection dictionaries from different modules.,Source Desugarer,0.1.2,0.1.3,defect,erikd,assigned,2009-05-12T12:15:45Z+0100,2010-03-06T02:17:55Z+0000,"Projection dictionaries are open, so we should be able to give instance functions in multiple modules. ",benl
1,73,Bad core generated for recursive function with projections,Source to Core Translation,0.1.2,0.1.3,defect,,new,2009-05-14T04:47:22Z+0100,2010-01-12T09:45:56Z+0000,"Added by Jared

This function
{{{
example = []
  where xs = example
        y  = xs.head
}}}

Causes
{{{
        applyTypeT: Kind error in type application.
            caller = Just Core.Bind.bindXDo
            in application:
                (\/ (y :: *) -> ...) (Const %rTS1)
        
                type: Const %rTS1
            has kind: Just Const %rTS1
        
            expected: *
}}}

Test is {{{T73-BadCoreProj}}}",benl
1,81,Bug in core type checker,Build System,0.1.2,0.1.3,defect,,new,2009-05-14T05:14:33Z+0100,2009-05-14T05:14:47Z+0100,"With this program
{{{
class Copy2 a where
  copy2 :: forall b. a -(!e1)> b
	:- !e1 = !ReadT a
	,  Shape2 a b

instance Copy2 Int where
  copy2 x = x

main ()
 = do	i :: Int %r1 :- Const %r1
	i	= 5
	i'	= copy2 i
        i' := 27
	()
}}}

Have this in dump-core-dict
{{{
i' = /\ (+xC9             :: Mutable %rTS21) ->
     [** (Base.Int32 %rTS21) ]
     do {
        instance_Copy2_Int32_copy2 %r1 (i +wCB4);
     };
}}}

return type of copy2 is {{{(Int32 %r1)}}}, not {{{(Int %rTS21)}}}

This problem originally originally arises because the instance for copy2
didn't copy the int like it should have. 

Is really 2 bugs: core type checker, and and not checking instances against class defs

",benl
1,155,"PANIC ""mergeClasses: classes have differing kinds"" in my Hashtable first cut",Core Type Checker,0.1.2,0.1.3,defect,benl,assigned,2010-02-01T21:15:10Z+0000,2010-02-15T01:24:46Z+0000,"{{{
[1 of 1] Compiling Hashtable
ddc: PANIC in Type.Squid.Class
        mergeClasses: classes have differing kinds
            cids = [720, 721]
            ks   = [*, * -> *]
        
        Please report this bug to the maintainers at:
            http://trac.haskell.org/ddc
            or by emailing disciple-cafe@googlegroups.com
}}}
",blackh
1,160,Runtime crash with recursive bindings,Runtime System,0.1.2,0.1.3,defect,,new,2010-02-21T09:49:02Z+0000,2010-02-21T10:01:32Z+0000,"The following Haskell code to solve the 2nd Euler problem causes a runtime crash.

{{{
maxN	= 10000
main ()
 = do	println $ show solution1

even x = x `mod` 2 == 0

solution1 
  = sum [ x 	| x <- takeWhile ((<=) maxN) fibs
              		, even x]
  where	fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
}}}",benl
1,163,Elaboration of class constructors isn't respecting their kinds,Source Desugarer,0.1.2,0.1.3,defect,,new,2010-02-22T11:47:14Z+0000,2010-02-22T11:47:14Z+0000,"This program should work
{{{
class Bag (bag :: % -> * -> *) where
	size 	:: forall a %r1 %r2 
		.  bag %r1 a -(!e1)> Int %r2
		:- !e1 = !Read %r1

instance Bag List where
	size = length

main ()	= println $ show $ size [1, 2, 3];
}}}

In the class instance, `List` has the correct kind, but it's being elaborated to:

{{{
instance Bag (List %r1) where
	size = length
}}}

which is now an error because `(List %r1)` has kind `* -> *` and not `% -> * -> *`.

The elaborator shouldn't have added the %r1 because that type expression already had the correct kind.
",benl
1,167,Missing constraints in interface files.,Core Type Checker,,0.1.3,defect,,new,2010-02-25T05:16:25Z+0000,2010-02-25T05:16:25Z+0000,"Various constraints are missing from interface files, eg. Data.Bool.otherwise should have a !Const constraint.",bens
1,168,Module exporter re-exports projections it has  imported,Unknown,0.1.2,0.1.3,defect,,new,2010-02-26T10:17:39Z+0000,2010-04-18T06:18:50Z+0100,"With a simple module that defines a new projection on Data.List like this:

{{{
module Foo

project List where
	count = length
}}}

the exporter (src/Module/Exporter.hs) for this exports the following proections for Foo:

{{{
project Data.List.List %rDK125 where
{
        x = project_List_x;
        xs = project_List_xs;
        ref_x = project_List_ref_x;
        ref_xs = project_List_ref_xs;
        count = project_List_count;
}
}}}

where the first 4 are the projections already defined in Data.List. Only the last projection (count) should actually be exported from this module.
",erikd
1,172,Lexer generates incorrect token sequence,Source Parser,,0.1.3,defect,erikd,assigned,2010-03-05T10:03:08Z+0000,2010-03-07T10:48:03Z+0000,"For the function:

{{{
trick2 xs = [ (x, y)
		| x <- xs
		, let y = x `mod` 3 ]
}}}

the lexer generates a token sequence (ignoring other tokens) of ""[ { ] }"" where the brackets don't match up properly. Changing the code to:

{{{
trick2 xs = [ (x, y)
		| x <- xs
		, let y = x `mod` 3
		]
}}}

generates the correct sqeuence of ""[ { } ]"".

",erikd
1,173,Faliure to parse type annotations within list defintion,Source Parser,,0.1.3,defect,erikd,assigned,2010-03-06T05:36:12Z+0000,2010-03-06T05:36:24Z+0000,"The following parses correctly under GHC bug fails with DDC

{{{
main = println $ show [ (1::Int) .. 10 ]
}}}
",erikd
1,181,Fix display of node effects in type error messages,Source Type Inferencer,,0.1.3,defect,,new,2010-05-24T11:33:04Z+0100,2010-05-24T11:33:04Z+0100,"PurifyReadWrite2 reports:

{{{
   Conflicting region constraints.
               constraint: Base.Const %75
        which purifies
              the use of: (*)
                 of type: (224 225)
                      at: ./test/15-Typing/Purity/PurifyReadWrite2/Test.ds:5:25
}}}

The application (224 225) isn't getting expanded to the real effect.
",benl
1,188,"Bad quantifier in type for ""undefined""",Source Type Inferencer,0.1.2,0.1.3,defect,,new,2010-09-07T14:53:38Z+0100,2010-09-07T14:53:38Z+0100,"
Type inference for this code
{{{
undefined :: a
undefined = primThrow_silent @ (Exception ""undefined"")
}}}

gives
{{{
foreign import undefined
        :: forall t0
        .  t0
        :- LazyH (forall t0. t0 :- LazyH t0)
        ,  LazyH t0
}}}

But that first LazyH constraint is dodgy.


",benl
1,16,Add type bindings,Source Parser,,0.1.3,enhancement,erikd,new,2009-05-12T13:52:38Z+0100,2010-02-05T03:19:38Z+0000,"{{{type Thing = ...}}}

We need this to handle a stack of simple GHC regression tests.

",benl
1,67,Compiler panic applying polymorphic functions to unboxed values,Core Type Checker,0.1.2,0.1.4,defect,,new,2009-05-14T04:20:14Z+0100,2010-09-23T08:01:14Z+0100,"Added by Jared

{{{
example () = do
    ub3 = primInt32U_neg $ 3#
    ()
}}}

Gives
{{{
cc1: warnings being treated as errors
./Foo.ddc.c: In function ‘Panic1_main’:
./Foo.ddc.c:39: error: passing argument 2 of ‘Data_Function__symDl’ makes
pointer from integer without a cast
./Foo.ddc.c:39: error: assignment makes integer from pointer without a cast
ddc: PANIC in Main.Invoke
        invokeSeaCompiler: compilation of C file failed.
            pathC = ./Panic1.ddc.c
}}}

Should detect this in core and give a nicer error message.",benl
1,68,Do kind checking during constraint generation.,Source Type Inferencer,0.1.2,0.1.4,defect,,new,2009-05-14T04:22:15Z+0100,2009-05-14T04:35:26Z+0100,"Added by Jared

Compiling the following function
{{{
data Foo %r0 = Foo (Int32# %r0)
}}}

Gives
{{{
ddc: PANIC in Type.Util.Elaborate
        elabRs2: no match for ([%r0], *)
            topType = Base.Int32# %r0
}}}

Applying %r0 to Int32# is a kind error. We should detect this and give a nicer messages.",benl
1,79,Kind inference checking problem for mutable tuples,Source Type Inferencer,0.1.2,0.1.4,defect,None,new,2009-05-14T05:06:58Z+0100,2010-02-07T23:42:31Z+0000,"Added by Jared

The following function fails to compile.

{{{
example :: (Int, Int) %r0
        :- Mutable %r0
example = (0,0)
}}}

The error message is
{{{
ddc: src/Source/Desugar.hs:(647,4)-(670,28): Non-exhaustive patterns in case
}}}
The same error occurs if the region is placed before the type.

",benl
1,34,Check inferred type against signatures.,Source Type Inferencer,,0.1.4,enhancement,,new,2009-05-13T03:48:29Z+0100,2010-01-31T08:53:57Z+0000,"
As we add sig types to the graph, we'll get a type error if part of it can't be unified with the inferred type. However, we don't currently check that the inferred types effect, closure and constraints is <: the signature. Want sigs to be instantiatable from the inferred type.

Also want to have partial sigs. Maybe we need a different syntax compared with :: sigs. eg:

{{{
fun <: a -(!Console)> b 
}}}",benl
1,83,Look in data definition when checking dangerous vars,Source Type Inferencer,,0.1.5,enhancement,,new,2009-05-14T05:18:58Z+0100,2010-02-10T04:00:09Z+0000,"{{{
data TwoThings r1 r2 r3 a 
      = ThingOne (Int r2)
      | ThingTwo (Maybe r3 b)
}}}

wrt the mutability / backtracking problem.

The rule should be at generalisation time, If a region var makes other variables dangerous, then hold  it constant unless it already has a mutability constraint.  If the user wants it to be mutable, then require them to supply a type signature. Otherwise leave it constant.

For example, if we are to generalise:
{{{
 foo :: TwoThings r1 r2 r3
}}}
then make r1 and r3 constant, but leave r2 unconstrained.
",benl
1,86,Use Haskell/GHC style pragma instead of a pragma keyword,Build System,0.1.2,0.1.5,newbie,,new,2009-06-24T08:11:36Z+0100,2010-08-25T08:10:49Z+0100,"If in doubt, follow GHC.",benl
4,37,Fix closure trimming of data types containing functions.,Source Type Inferencer,,,defect,,new,2009-05-13T03:57:36Z+0100,2009-05-13T03:57:36Z+0100,"When trimming a closure term containing:

{{{
 x : Thing a0 a1 %r2
}}}

We don't know whether or not to keep %r2, without looking at the definition. Don't know if (Thing a0 a1 %r2) actually contains a region %r2

{{{
data Thing a a1 %r2
  = C1 (Int %r2 -> Int %r2)   -- nope
  | C2 (Int %r2)              -- yep
}}}

We should attach definitions to type constructors so we have this information at trimming time.

",benl
4,24,Allow resumption of tests in bin/war test driver,Build System,,,enhancement,,new,2009-05-13T03:08:11Z+0100,2010-02-07T22:58:39Z+0000,"If a test dies due to some problem we don't always want to start from scratch again.  Maybe drop a file saying where we were up to, then do a  bin/war -resume ",benl
4,17,Check profiling and ticky counters in runtime system and add tests,Runtime System,,,newbie,,new,2009-05-12T13:56:26Z+0100,2010-08-25T08:04:03Z+0100,"I haven't checked this for a while, not sure if it's still working.
Need to add tests to make sure support for ticky counters doesn't rot.",benl
4,186,Source.Defix.hs: Non-exhaustive patterns in lambda,Source Semantics,,,newbie,,new,2010-08-24T09:30:44Z+0100,2010-08-25T08:03:10Z+0100,"Simple program:

{{{
main ()
 = do	list = [1, 2, 3]
	println $ ""list "" % list % "" : "" $ show list
}}}

currently fails with the error message:

{{{
ddc: src/Source/Defix.hs:94:16-31: Non-exhaustive patterns in lambda
}}}

The program is wrong but should display a better error message.
",erikd
4,187,"Write tests for Data,ArrayU module.",Runtime System,,,newbie,,new,2010-08-26T11:50:19Z+0100,2010-08-26T11:50:19Z+0100,"I just found and fixed a bug in this module. Unfortunately the module has no tests.
",erikd
4,47,"Package DDC into Cabal, and streamline install process.",Build System,,,task,,new,2009-05-13T04:51:30Z+0100,2009-05-13T04:51:30Z+0100,,benl
4,189,Check for missing quantifiers in type class definitions.,Source Desugarer,0.1.2,0.1.3,defect,,new,2010-09-19T09:37:00Z+0100,2010-09-19T09:39:20Z+0100,"Check for missing quantifiers in type class definitions. The type variable ""c"" here isn't quantified, and will be defaulted to Unit by the inferencer.

{{{
class Floating a where
	fpow	:: forall b
		.  a -> b -(!e1 $c1)> c
		:- !e1 = !{ !ReadT a; !ReadT b }
		,  $c1 = x : a
		,  Shape3 a b c
}}}",benl
4,190,Bad parser error message,Source Parser,0.1.2,0.1.3,defect,,new,2010-10-20T06:57:27Z+0100,2010-10-20T06:57:27Z+0100,"{{{
dude	:: Int %r5
dude	= 5

thing 	:> Int -> Int -($c1)> Int
	:- $c1 = x : %r5
	
thing x y = x
}}}",benl
4,161,Implement let qualifiers for list comprehensions,Source Parser,0.1.2,0.1.3,enhancement,erikd,assigned,2010-02-21T10:56:57Z+0000,2010-03-07T10:45:48Z+0000,"Eg for a solution to the 4th Euler problem.

{{{
solution1
 = maximum 	
	[ x 	| y <- [100..999]
		, z <- [y..999]
		, let x = y * z
		, let s = show x
		, s == reverse s ]
}}}",benl
4,15,Ensure we're sharing constant values of enumeration type.,Core Transforms,,0.1.3,newbie,,new,2009-05-12T13:48:17Z+0100,2010-08-25T08:11:51Z+0100,"Make sure we're not reallocating True, False and Unit values.",benl
4,40,Check for overlapping projection dictionaries during type inference,Source Parser,0.1.2,0.1.4,defect,,new,2009-05-13T04:07:48Z+0100,2010-09-19T09:40:01Z+0100,"
Projections should be associated with data constructors, not general types, otherwise we get overlapping name problems.

{{{
project Maybe a where
 ... 

project Maybe Int where
 ... 
}}}

This will also allow a better syntax for & projections, eg {{{List&reverse}}}.

",benl
4,19,Erase calls to prim.force on objects in direct regions during Core.Simplify,Core Transforms,,0.1.4,enhancement,,new,2009-05-12T14:00:46Z+0100,2009-05-12T14:00:46Z+0100,Matching against literals generates explicit forcing in core. We want to remove these if we're forcing data in direct regions.,benl
4,41,Refactor occurance checker to improve speed.,Source Type Inferencer,,0.1.4,refactor,,new,2009-05-13T04:09:11Z+0100,2009-11-18T07:06:52Z+0000,Doing occurance checking in Type.Util.Substitute made test/Typing/Complexity/Complex1 3x slower. Probably recover from this by writing custom var detection boilerplate for types instead of relying on collectTClassVars,benl
4,50,Emit error for dangerous vars at top level.,Source Type Inferencer,0.1.2,0.1.5,defect,,new,2009-05-13T05:03:23Z+0100,2010-09-19T09:42:12Z+0100,"Exporting mutable data containing monomorphic type vars is not sound because two different modules might update it at different types. 

At the moment we seem to silently default such types to Unit.
{{{
thing 	:: forall a. Ref %r1 (a -> a)
	:- Mutable %r1

thing	= Ref id
}}}

In the .di file we get
{{{
foreign import thing
        :: Base.Ref %r1 (Base.Unit -> Base.Unit)
        :- Base.Mutable %r1
        ,  Base.Direct %r1
        :$ Base.Data;
}}}

",benl
4,11,Resurrect Core.Inline,Core Transforms,,0.1.5,enhancement,,new,2009-05-12T12:39:16Z+0100,2010-09-19T09:40:55Z+0100,We should at least inline simple projection functions into their use sites. This would likely produce much faster code.,benl
4,20,Implement the rest of the primitive types.,Libraries,,0.1.5,enhancement,,new,2009-05-12T14:02:12Z+0100,2009-05-13T04:03:57Z+0100,"We're only supporting Char, String, Int32 and Float32 at the moment - but most of the code is there for the rest. We'll need to push these into core and add conversion operators to the base library.",benl
4,52,Auto export class instance functions,Source Desugarer,,0.1.5,enhancement,,new,2009-05-13T05:07:08Z+0100,2009-05-13T05:07:38Z+0100,"From Data.Array

{{{
export	index
	indexR
	array_map_
	array_foldl

instance Functor Array where
	map_		= array_map_

instance Foldable Array where
	foldl		= array_foldl
}}}

We must manually export array_map_ and array_foldl_ because they are used in the type class instance. 

Probably want to add proper module namespaces for this.


",benl
4,87,Support type constraints on constructor,Source Parser,0.1.2,0.1.5,enhancement,,new,2009-06-24T08:42:22Z+0100,2010-09-19T09:43:30Z+0100,"
Allow type constraint on constructors so we can explicitly state effect and closure constraints.

{{{
data Fun a b
     = forall !e1 $c1. SomeFun (a -(!e1 $c1)> b) :- Pure !e1, Empty $c1
}}}",benl
4,88,Allow data fields to be listed with the offside rule,Source Parser,0.1.2,0.1.5,enhancement,,new,2009-06-24T08:46:28Z+0100,2009-06-24T08:46:28Z+0100,"Want to support:

{{{
data Thing a
       = SomeCtor 
              someField1 :: Type1
              someField2 :: Type2

       | SomeOtherCtor
              someField3 :: Type3
              ...
}}}

Instead of needing braces around the fields as in:
       
{{{
data Thing a
       = SomeCtor {
              someField1 :: Type1;
              someField2 :: Type2;
       }
       | SomeOtherCtor {
              someField3 :: Type3;
              ...
       }
}}}
",benl
4,90,Support default instances in type class declarations.,Source Parser,0.1.2,0.1.5,enhancement,,new,2009-06-24T09:40:04Z+0100,2009-06-24T09:40:04Z+0100,,benl
4,157,Do a more fine-grained dangerous variables check,Source Type Inferencer,0.1.2,0.1.5,enhancement,,new,2010-02-10T04:05:35Z+0000,2010-09-19T09:40:25Z+0100,"At the moment, if we have a data type like

{{{
data Thing r1 (C r2 (Int r3)) (Int r4)
 ...

}}}

If `r1` is mutable then all of `r2, r3, r4` are marked as dangerous. However, If these variables are non-material in the type, then we don't actually have to mark them as dangerous.

NB: If we do this we'll also want to test for and reject nested data types, as the current algorithm for determining which variables are dangerous doesn't support them.


",benl
4,89,Test out effect constructors with interesting kinds,Source Type Inferencer,0.1.2,0.1.5,task,,new,2009-06-24T09:08:23Z+0100,2009-06-24T09:08:23Z+0100,"Effect constructors with kinds other than ! and % -> ! haven't been well tested.

Suppose we do:

{{{
effect  Exception :: ! -> * -> ! 
}}}

This effect carries another effect and a type. Is the inferencer going to manage that?

",benl
5,6,Check format of source pragmas.,Source Parser,0.1.2,,defect,,new,2009-05-12T12:14:13Z+0100,2009-05-12T12:26:45Z+0100,Malformed pragmas in the source code are probably being silently discarded. Check they're being handled properly.,benl
5,3,Check Shape witnesses in core,Core Type Checker,,,enhancement,,new,2009-05-12T12:05:48Z+0100,2009-05-12T13:54:06Z+0100,"We don't currently check the validity of shape witnesses. Problems should be caught by the source type inferencer, but we should check them in the core language as well.",benl
5,4,Check for unsound erasure of type lambdas in core to sea translation,Core to Sea Translation,,,enhancement,,new,2009-05-12T12:09:48Z+0100,2009-05-12T13:54:20Z+0100,"Erasing type lambdas from mutable objects is unsound due to the problem with polymorphic update. 

The Source type inferencer does a dangerous variables check to avoid introducing said type lambdas, but we should check that we don't erase them as well. (a double check).
",benl
5,29,Check well-formedness of bound witnesses in letregion,Build System,,,enhancement,,new,2009-05-13T03:22:02Z+0100,2009-05-13T03:22:02Z+0100,"The source to core translation shouldn't create malformed witnesses, but we should check them in core anyway.",benl
5,32,Don't panic if user Control-C's GCC,Compilation Driver,,,enhancement,,new,2009-05-13T03:30:53Z+0100,2010-04-15T19:28:36Z+0100,"Is there a way to detect that gcc has died this way vs by a compile error?
",benl
5,46,Compile base libraries into .so,Compilation Driver,,,enhancement,,new,2009-05-13T04:50:36Z+0100,2009-05-13T04:50:36Z+0100,"Don't want to statically link the whole lot into each executable.
",benl
5,85,Create large pinned memory blocks automatically,Runtime System,,,enhancement,,new,2009-05-14T05:21:47Z+0100,2009-05-14T05:21:47Z+0100,"If the allocator is asked for a chunk over a certain size, then it could just pin it automatically. This'd be better for large objects like window buffers.

",benl
5,145,Add a point free case expression,Source Parser,,,enhancement,,new,2009-11-05T19:28:16Z+0000,2009-11-18T07:07:16Z+0000,"Straight from the haskell cafe mailing list:

    http://www.haskell.org/pipermail/haskell-cafe/2009-November/068673.html

Instead of this:

{{{
myFunc = anotherFunc $ \x -> case x of
                               Left err -> print err
                               Right msg -> putStrLn msg
}}}

allow this:

{{{
myFunc = anotherFunc $ case of
                         Left err -> print err
                         Right msg -> putStrLn msg
}}}

",erikd
5,18,Refactor Core.Exp to push XPrim calls into new data type,Core Transforms,,,refactor,,new,2009-05-12T13:58:12Z+0100,2009-05-12T13:58:12Z+0100,"Want to share data type that represents primitive functions with Sea.Exp.

",benl
5,38,Refactor Util.Pretty to use Data.Seq instead of Data.List,Compilation Driver,,,refactor,,new,2009-05-13T04:00:10Z+0100,2009-05-13T04:00:30Z+0100,I think uses O(n) list operations might be making trace file generation very slow.,benl
5,185,Refactor function ddcCompile to use ddcMake,Build System,,,refactor,,new,2010-07-17T05:23:43Z+0100,2010-07-17T05:25:04Z+0100,"There are separate functions ddcCompile (-c cmdline option, just compile that single file) and ddcMake (recursive compile) that basically do the same thing.

These should be merged.

",erikd
5,1,Check for partial application of functions to unboxed args.,Core to Sea Translation,0.1.2,0.1.3,defect,,new,2009-05-12T10:06:46Z+0100,2009-11-18T07:06:19Z+0000,"Runtime system cannot handle partial application of functions to unboxed args. It'd be easy to check for this problem in the core language, and panic.

Test is {{{T1-CurryUnboxed}}}.",benl
5,9,Disallow unboxed data being present in function closures.,Core Type Checker,0.1.2,0.1.4,defect,,new,2009-05-12T12:33:06Z+0100,2009-05-12T12:35:45Z+0100,"The runtime system doesn't support unboxed data being present in closures. We should check this in core and give a suitable error message.

This program
{{{
main () 
 = putStr $ show $ fun () ()

fun ()
 = do	dude	= 100#
	(\t -> dude + 100#)
}}}

Causes:
{{{
./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c: In function ‘Main_main’:
./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c:43: warning: assignment makes integer from pointer without a cast
./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c:44: warning: passing argument 2 of ‘Data_Function__symDl’ makes pointer from integer without a cast
./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c: In function ‘Main_fun’:
./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c:79: warning: assignment makes pointer from integer without a cast
ddc: PANIC in Main.Invoke
        invokeSeaCompiler: compilation of C file failed.
            pathC = ./test/Broken-skip/T9-UnboxedDataInClosures/Main.ddc.c
}}}",benl
6,30,Emit a better error message when reading an empty interface file.,Compilation Driver,,,defect,,new,2009-05-13T03:24:59Z+0100,2009-11-18T07:07:38Z+0000,"If a .di file is empty for some reason, we just get DDC: reading EOF, which isn't helpful.",benl
7,44,Fix elaboration of recursive data types.,Source Type Inferencer,,,defect,,new,2009-05-13T04:17:47Z+0100,2010-02-22T11:43:14Z+0000,"At the moment, data type definitions to be elaborated must be in-order and not recursive. For example:

{{{
data Foo a 
  = FooInt Int

data Bar a 
  = BarFoo Foo
}}}

The definition for Bar must come after def for Foo, otherwise Source.Desugar won't have the correct kind for it. Should probably tie this elaboration to kind inference.

",benl
7,8,Add a full set of unboxed casting operators.,Libraries,,,enhancement,,new,2009-05-12T12:26:30Z+0100,2009-05-13T03:22:41Z+0100,We want unsafeFloat32ToInt32 etc etc. Also unsafe ones like castVoid. We need these for FFI stubs.,benl
7,13,Share GC stack slots in Sea code,Core to Sea Translation,,,enhancement,,new,2009-05-12T12:46:14Z+0100,2009-05-12T12:46:14Z+0100,"We don't currently share slots on the GC shadow stack between Sea level values, so we use much more stack space than we really need to.

Ideally, we would import the graph coloring code from GHC and use that to do the allocation.
",benl
7,14,Implement full laziness transform,Core Transforms,,,enhancement,,new,2009-05-12T13:45:47Z+0100,2009-05-12T13:45:47Z+0100,This was working before but rotted in a previous refactoring of the core transforms.,benl
7,22,Mask mutability constraints on fresh data,Source Type Inferencer,,,enhancement,,new,2009-05-12T14:06:55Z+0100,2009-05-12T14:06:55Z+0100,"In a type like

{{{
 fun :: forall %r1 %r2
     .  Int %r1 -> Int %r2
     :- Mutable %r2
}}}

The returned Int is fresh, that its region does not appear on the lhs of an arrow or in a closure. In this case it does not matter that the data is Mutable, and this fetter can be masked. 

We'll want to use the closure information the core language for this, so make sure the core type checker works.

",benl
7,23,Mask effects on fresh data,Source Type Inferencer,,,enhancement,,new,2009-05-13T03:00:09Z+0100,2009-05-13T03:02:09Z+0100,"In a type like

{{{
 fun :: forall %r1 %r2
     .  Int %r1 -(!e1)> Int %r2
     :- !e1 = Read %r2
}}}

The effect Read %r2 isn't being masked by Type.Scheme because %r2 is
visible in the shape of the type. However, as the data is fresh the fact
that there was a read when constructing it does matter, so it can be masked.

Core.Reconstruct will need to use the closure annotations on XLam nodes to
show that this is ok.",anonymous
7,28,"When defining projections, auto-open the other fns in the projection",Source Parser,,,enhancement,,new,2009-05-13T03:19:21Z+0100,2009-05-13T03:19:58Z+0100,"We should be able to access other projections of the same constructor with _.

{{{
project Obj where
  f1 ^obj = _x + _y
  f2 ...  = _f1            <-- access f1&{Obj} via _f1
}}}


",benl
7,31,Implement dictionary passing.,Source to Core Translation,,,enhancement,,new,2009-05-13T03:27:58Z+0100,2010-10-12T01:13:30Z+0100,We'll want to use the projection system to extract fns from the dictionary.,benl
7,35,Allow embedded mutually recursive definitions.,Source Type Inferencer,,,enhancement,,new,2009-05-13T03:51:24Z+0100,2009-05-13T03:51:24Z+0100,At the moment mutual recursion is only supported at top level. Want to remove this constraint.,benl
7,49,Add monadic do expressions.,Source Parser,,,enhancement,,new,2009-05-13T04:54:16Z+0100,2009-05-13T04:54:16Z+0100,"Overloading <- has been done, but what about {{{then}} expressions?

{{{
do  Just 1
    Nothing
    Just 2
}}}

Is this supposed to be monadic or not? No way to tell, syntax is ambiguous. If it's
monadic the result is Nothing, if not it's Just 2. Should probably use {{{mdo}}} as a keyword for ""monadic do""

",benl
7,70,Implement operator sectioning,Source Parser,,,enhancement,erikd,new,2009-05-14T04:26:03Z+0100,2010-05-04T13:08:47Z+0100,"Added by Jared.

The following function fails to compile.

{{{example = (0 ==)}}}

The error message is:
{{{
ddc: PANIC in Source.DefixApps
        makeXDefixApps: parse error at
        ./Test.ds:1:13   xx = []
}}}
",benl
7,27,Rewrite primitive functions from RTS in Disciple,Libraries,,,refactor,,new,2009-05-13T03:16:31Z+0100,2009-05-13T03:17:04Z+0100,"Having custom C code for Arrays and such like is ok for starters, but want to move towards expressing all of this using primitive unboxed functions directly in Disciple.",benl
7,12,Revisit exception mechanism,Source Type Inferencer,,,task,,new,2009-05-12T12:43:27Z+0100,2009-05-12T12:44:14Z+0100,"We eliminated the effect masking operator from the type system due to the poisoning problem. Perhaps we can do something with Benton + Buchlovsky's ""Semantics of an effect analysis for exceptions"" paper. 

I remember seeing a ML paper on this saying there was a better way than try-catch. What was that?

Want typed exceptions, so we can thrown an object of arbitrary (user defined) type.",benl
7,25,Investigate support for polymorphic recursion,Source Type Inferencer,,,task,,new,2009-05-13T03:10:43Z+0100,2009-05-13T03:12:03Z+0100,"Manage this the same was as in Haskell, by requiring an explicit type signature. Do we need the whole signature, or can we get away with a partial one that only has quantifiers for the components that are used in the recursion?
",benl
7,48,Make a better graphics library,Libraries,,,task,,new,2009-05-13T04:52:35Z+0100,2009-05-13T04:52:35Z+0100,The current library is hacky and dangerous. If you draw outside the window you'll corrupt the heap. We should really use an OpenGL binding of some sort.,benl
7,54,Allow non-effectful CAFs to be recursive.,Build System,,,task,,new,2009-05-13T05:09:23Z+0100,2009-05-13T05:09:23Z+0100,"It'd be nice to support things like:

{{{
ones = (:) @ 1 ones
}}}

But we currently can't do it because the Sea translation doesn't support recursive CAFs. 
",benl
7,63,Mask closure terms which are constant,Source Type Inferencer,,,task,,new,2009-05-14T03:43:39Z+0100,2009-11-12T11:37:29Z+0000,Probably want to implement the Shared constraint from thesis at the same time.,benl
7,107,Definition order should not be important in  where block,Source Semantics,0.1.2,_|_,enhancement,steggles,assigned,2009-08-18T10:17:36Z+0100,2010-09-07T12:26:43Z+0100,"Two almost identical functions below. The first parses successfully, the second fails.

{{{
compileSuccess :: Int -> Int
compileSuccess x =
	x + y
  where
    -- This works becuase 'z' is defined before it is used.
    z = 4
    y = 3 + z

compileFail :: Int -> Int
compileFail x =
	x + y
  where
    -- Using 'z' before it is defined fails.
    y = 3 + z
    z = 4
}}}

",erikd
7,108,No support for infix operator definitions,Source Parser,0.1.2,_|_,enhancement,steggles,new,2009-08-19T01:49:10Z+0100,2010-09-07T12:27:05Z+0100,"We don't support infix definitions like:

{{{
f ++ g = ...
}}}

All operators must be define in prefix style like:
{{{
(++) f g = ...
}}}

I'm not sure it's a good idea to support the infix definition style, because GHC had problems with it when they introduced bang patterns. For example:

{{{
f ! x = ...
}}}

It that supposed to be a definition of the operator (!) or, the definition of a function ""f"" which is strict in its argument?

We may well want to support bang patterns or something similar in the future, so we're avoiding infix definitions for now.
",benl
