From john at repetae.net Mon Jun 2 18:47:23 2014 From: john at repetae.net (John Meacham) Date: Mon, 2 Jun 2014 11:47:23 -0700 Subject: [jhc] ANNOUNCE: jhc 0.8.2 Message-ID: Lots of internal improvements in this one, so may be of more interest to developers http://repetae.net/computer/jhc/ - completely replaced the front end parser/lexer with a new more flexible one. My rewritten one is about 3,250 lines shorter. - The new one uses a general precedence parser for application as well as infix operators, allowing consistent handling of bang, irrefutable, and @ patterns and allows prefix and infix operators with a higher precedence than application to be defined. Incidentally, this allows for ~ and @ in expressions. (~) = negate (prefixr 11) gives us a nice strongly binding negative and @ (infixr 12) is perfect for type directed name resolution without further overloading the humble dot. they parse exactly the same as they do in patterns so no new magic is being added to the symbols other than allowing them in expressions. - Layout algorithm is fully in the lexer now, no lexer/parser interaction needed and useful transformations happen between the two simplifying the parser. - updated a lot of the external libraries to new versions - improvements to the build based on feedback, now gives much better error messages about what went wrong. - include an experimental utility to automatically download 3rd party packages from hackage and install them, it has some kinks, but even if it can't do it automatically, it provides a template for easily modifying the package to work. - removed the last of the cabal-cruft from the library build system. - fixed a lot of bugs relating to errors not being caught early by jhc so they produce a cryptic message from the compiler later, attach source location to more errors for better reporting. - ghc 7.8 compatibilty contributed by others. (thanks!) - infix type constructor extension supported - field punning extension now supported - new option -fno-sugar to turn off all desugaring that would introduce any hidden dependencies, all literals are unboxed under it. WYSIWYG. - unboxed kinds now more general, work in more places - record field names may overlap - more efficient binary representation using LEB128 - Data.String added with mild magic. -- John Meacham - http://notanumber.net/ From john at repetae.net Wed Jun 4 01:29:26 2014 From: john at repetae.net (John Meacham) Date: Tue, 3 Jun 2014 18:29:26 -0700 Subject: [jhc] improved jhc manual Message-ID: Hi all, I just wanted to show off the new jhc manual http://repetae.net/computer/jhc/manual.html If anyone has any feedback, that would be great, even better would be patches of course :) Manual writing is not my strong point. The entire manual is in the darcs repo as markdown formatted files or as literate code embedded in the source files. Something I need to figure out is how to get haddock to not barf on jhc's input files. A problem with haddock is that it tries to replicate ghc's module chasing algorithm and falls down when anything is slightly off, jhc's ability to handle recursive modules throws it for a loop. Now I can easily get jhc to spit out fully resolved module names, it does so with the --annotate-source option, but need some sort of hook into haddock saying "don't try to resolve module names, here they all are." Even haddock just having a 'keep going' option would be great to get something out there. Or even improving haddock to handle recursive module imports. John -- John Meacham - http://notanumber.net/ From jim.crayne at gmail.com Mon Jun 9 05:24:51 2014 From: jim.crayne at gmail.com (James Crayne) Date: Mon, 9 Jun 2014 01:24:51 -0400 Subject: [jhc] Newbie question... Message-ID: I appologize if this is the wrong forum for this question, but I couldn't find anyone to help on IRC and I don't know what mailing list this should go to otherwise. I installed ajhc from cabal, following the instructions in the manual, and everything compiled seemingly without a hitch, but when I tried to use the compiler to compile a simple helloworld, it complained about libraries. What is the quikest/simplest remedy? Also, It would seem to me that the manual needs an update? As is, it implies pretty strongly that this should just work. $ cat helloworld.hs main = putStrLn "hello world." $ ajhc helloworld.hs ajhc helloworld.hs ajhc 0.8.0.10 (66a602abc10dec74e2c0bb9289819a015bf21e4f) Finding Dependencies... Using Ho Cache: '/home/jim//.ajhc/cache' Libraries not found: haskell-extras haskell2010 haskell98 Technically, I intend to compile to C, but I get the same error message with -C. From john at repetae.net Mon Jun 9 05:52:03 2014 From: john at repetae.net (John Meacham) Date: Sun, 8 Jun 2014 22:52:03 -0700 Subject: [jhc] Newbie question... In-Reply-To: References: Message-ID: Hi, you probably need to include '-L.' on the command line to have it look for libraries in the current directory if you are running it directly out of the build dir. John On Sun, Jun 8, 2014 at 10:24 PM, James Crayne wrote: > I appologize if this is the wrong forum for this question, but I > couldn't find anyone to help on IRC and I don't know what mailing list > this should go to otherwise. > > I installed ajhc from cabal, following the instructions in the manual, > and everything compiled seemingly without a hitch, but when I tried to > use the compiler to compile a simple helloworld, it complained about > libraries. What is the quikest/simplest remedy? Also, It would seem to > me that the manual needs an update? As is, it implies pretty strongly > that this should just work. > > $ cat helloworld.hs > main = putStrLn "hello world." > $ ajhc helloworld.hs > ajhc helloworld.hs > ajhc 0.8.0.10 (66a602abc10dec74e2c0bb9289819a015bf21e4f) > Finding Dependencies... > Using Ho Cache: '/home/jim//.ajhc/cache' > Libraries not found: > haskell-extras > haskell2010 > haskell98 > > Technically, I intend to compile to C, but I get the same error message with -C. > _______________________________________________ > jhc mailing list > jhc at haskell.org > http://www.haskell.org/mailman/listinfo/jhc -- John Meacham - http://notanumber.net/ From john at repetae.net Mon Jun 9 13:27:33 2014 From: john at repetae.net (John Meacham) Date: Mon, 9 Jun 2014 06:27:33 -0700 Subject: [jhc] jhc repo update Message-ID: Just an update on the recent changes in the repo: The good - completely rewritten from scratch deriving mechanism that actually, well, works in many cases the old one didn't. The old one relied on generating haskell source code that was then fed back into the compiler, the new one generates the AST directly. This is a drastic improvement. - standalone deriving now works for most classes, and multiple derived instances will not conflict. - deriving Typeable, Foldable, Traversable, Typeable, and Ix have been added. - LambdaCase extension implemented, this actually turned out to be extremely useful internally as it allows desugaring of do and list comprehensions directly without requiring a unique name source to be piped through, quite handy. The later I can move these desugarings the better the error messages jhc generates are. - -X extension handling revamped to be less ad-hoc. there is a map in src/Options/Map.hs to map -X flags to jhc internal feature flags. The bad - lamba case seems to tickle a bug in the type checker, I need to make special provisions to ensure it is applied Monomorphically just like a real lambda. - Read and Show formatting have slightly changed so break regtests but are still valid. need to tweak them. should probably just conform to what ghc does for whitespace in case anyone out there depends on the exact formatting. -- John Meacham - http://notanumber.net/ From kiwamu at debian.or.jp Tue Jun 10 10:13:15 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Tue, 10 Jun 2014 19:13:15 +0900 Subject: [jhc] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell Message-ID: Hi jhc-hackers, I have written a paper "Experience Report: Writing NetBSD Sound Drivers in Haskell". http://metasepi.org/papers.html It explains Ajhc customized jhc GC, and sometime useful to develop jhc. Thank's, -- Kiwamu Okabe at METASEPI DESIGN From john at repetae.net Tue Jun 10 10:55:21 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 03:55:21 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Oooh. and you documented jhc's RTS while you were at it. that is great :) I have been thinking about a way to extend JGC to seamlessly handle interfaces that utilize stack allocated C structs. The main target being GMP. Right now I can do pretty well by having a 'self-pointing' 'self-cleaning' ForeignPtr. The definition of ForeignPtr is > data ForeginPtr = ForeignPtr Addr_ However, it is a little magic in that you can allocate it in a larger space than it would naturally take up, I can then have Addr_ point to the word following it directly in memory. The garbage collector treats it just like normal and needs no finalizer, as long as the ForeginPtr is live, the area it points to is live since they are the same space, as far as the code is concerned it could be pointing to an external C structure. This is very efficient and a very fast way to throw around C structures without having to worry about whether they were allocated in haskell or in C. However, things like GMP require the memory region to be initialized and freed since it may have internal pointers. I could just continue with standard foreign pointers, attaching a destructor, but this has a couple problems - I have to initialize the memory area, this is hard to do without invoking the IO monad to ensure proper sequencing, for the result of an addition, that seems heavy, it is hard for the complier to "see through" an unsafePerformIO when optimizing. - every Integer will have to carry around two extra words, a self pointer that always points to its own memory location, and a pointer to a destructor that is always going to be the same. - memory will be destructed when it is likely to immediately be re-used as an Integer, it would be good to deforest this destruct-construct pair. To solve both I was thinking of assosciating a contructor/destructor with a type rather than a value. By creating an entire block of the same type, it can initialize the entire block at once, then delay the destructor until the entire block is freed. since GMP ints can be re-used in place, it would get rid of almost all initialization and destruction overhead. A 'delayed destructor' if you will, that only needs to be called if the memory location is going to be used for a different type. Allocations in jhc are already tagged by type so this isn't difficult to keep track of. I was thinking something like data {-# CCONSTRUCTOR "init_integer" #-} {-# CDESTRUCTOR delayed "fini_integer" #-} Integer_ :: # data Integer = Integer Integer_ since Integer_ is unboxed, we can ensure they are only created in the right heap by using a primitive to do so, there is no way for a user to conjure up an unboxed type that doesn't take part in unboxed num polymorphism so can be represented by 0# 1# etc. John On Tue, Jun 10, 2014 at 3:13 AM, Kiwamu Okabe wrote: > Hi jhc-hackers, > > I have written a paper "Experience Report: Writing NetBSD Sound > Drivers in Haskell". > > http://metasepi.org/papers.html > > It explains Ajhc customized jhc GC, and sometime useful to develop jhc. > > Thank's, > -- > Kiwamu Okabe at METASEPI DESIGN > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- John Meacham - http://notanumber.net/ From kiwamu at debian.or.jp Tue Jun 10 11:19:51 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Tue, 10 Jun 2014 20:19:51 +0900 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hi John, On Tue, Jun 10, 2014 at 7:55 PM, John Meacham wrote: > Oooh. and you documented jhc's RTS while you were at it. that is great :) BTW. How do you think about jgc having multiple "arena" with the context? It can realize reentrant GC on jhc. Of cause, I know you feel bad about the cost initializing jgc every call C=>Haskell. Do you have some idea for the multiple "arena"? Best regards, -- Kiwamu Okabe at METASEPI DESIGN From john at repetae.net Tue Jun 10 11:26:32 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 04:26:32 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hmm.. what were you thinking of in terms of how it would change the API? By reentrant do you mean you want C functions that were called by haskell to be able to call back into haskell again? what is the issue with the context that is stowed. or are you talking about SMP/lightweight threads? On Tue, Jun 10, 2014 at 4:19 AM, Kiwamu Okabe wrote: > Hi John, > > On Tue, Jun 10, 2014 at 7:55 PM, John Meacham wrote: >> Oooh. and you documented jhc's RTS while you were at it. that is great :) > > BTW. > How do you think about jgc having multiple "arena" with the context? > It can realize reentrant GC on jhc. > Of cause, I know you feel bad about the cost initializing jgc every > call C=>Haskell. > > Do you have some idea for the multiple "arena"? > > Best regards, > -- > Kiwamu Okabe at METASEPI DESIGN -- John Meacham - http://notanumber.net/ From john at repetae.net Tue Jun 10 11:28:16 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 04:28:16 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Ah. I think I see what you mean by reentrant in your paper. Can you point me to your context switching code in ajhc? Is SMP a concern for you or are you mainly concerned about hardware interrupts? On Tue, Jun 10, 2014 at 4:26 AM, John Meacham wrote: > Hmm.. what were you thinking of in terms of how it would change the API? > > By reentrant do you mean you want C functions that were called by > haskell to be able to call back into haskell again? what is the issue > with the context that is stowed. or are you talking about > SMP/lightweight threads? > > > > On Tue, Jun 10, 2014 at 4:19 AM, Kiwamu Okabe wrote: >> Hi John, >> >> On Tue, Jun 10, 2014 at 7:55 PM, John Meacham wrote: >>> Oooh. and you documented jhc's RTS while you were at it. that is great :) >> >> BTW. >> How do you think about jgc having multiple "arena" with the context? >> It can realize reentrant GC on jhc. >> Of cause, I know you feel bad about the cost initializing jgc every >> call C=>Haskell. >> >> Do you have some idea for the multiple "arena"? >> >> Best regards, >> -- >> Kiwamu Okabe at METASEPI DESIGN > > > > -- > John Meacham - http://notanumber.net/ -- John Meacham - http://notanumber.net/ From kiwamu at debian.or.jp Tue Jun 10 11:42:46 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Tue, 10 Jun 2014 20:42:46 +0900 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hi John, On Tue, Jun 10, 2014 at 8:28 PM, John Meacham wrote: > Ah. I think I see what you mean by reentrant in your paper. Can you > point me to your context switching code in ajhc? Here is. https://github.com/ajhc/ajhc/blob/arafura/rts/rts/conc.c#L33 It's a sample with pthread. But CLHs can choose any thread style with calling C code that generate context switch. > Is SMP a concern for you or are you mainly concerned about hardware interrupts? Both thread on SMP and interrupt. Former uses active context switch, and the example is the above. Later uses passive context switch, however the interrupt context begins on C context. The C context create new "arena" when calling C => Haskell. Thank's, -- Kiwamu Okabe at METASEPI DESIGN From john at repetae.net Tue Jun 10 11:49:19 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 04:49:19 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hmm... if we allocate the gc_stack on an aligned boundry, can we recover the arena by keeping a pointer at its base? sort of like I recover the cache block pointer from an arbitrary heap location by rounding down to the block boundry. The main issue would be how it affects allocation speed, its okay to make the GC slower as long as allocation is still fast, Before pre-populating the cache pointers sped things up considerably, how would it make sure to use one from the current arena without slowing down allocation in general? John On Tue, Jun 10, 2014 at 4:42 AM, Kiwamu Okabe wrote: > Hi John, > > On Tue, Jun 10, 2014 at 8:28 PM, John Meacham wrote: >> Ah. I think I see what you mean by reentrant in your paper. Can you >> point me to your context switching code in ajhc? > > Here is. > > https://github.com/ajhc/ajhc/blob/arafura/rts/rts/conc.c#L33 > > It's a sample with pthread. > But CLHs can choose any thread style with calling C code that generate > context switch. > > >> Is SMP a concern for you or are you mainly concerned about hardware interrupts? > > Both thread on SMP and interrupt. > Former uses active context switch, and the example is the above. > Later uses passive context switch, however the interrupt context > begins on C context. > The C context create new "arena" when calling C => Haskell. > > Thank's, > -- > Kiwamu Okabe at METASEPI DESIGN -- John Meacham - http://notanumber.net/ From kiwamu at debian.or.jp Tue Jun 10 11:58:08 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Tue, 10 Jun 2014 20:58:08 +0900 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hi John, On Tue, Jun 10, 2014 at 8:49 PM, John Meacham wrote: > The main issue would be how it affects allocation speed, its okay to > make the GC slower as long as allocation is still fast, Before > pre-populating the cache pointers sped things up considerably, how > would it make sure to use one from the current arena without slowing > down allocation in general? So I don't have any benchmark for it today. I worry about the cost initializing arena when C=>Haskell. Current jgc has no cost, but my jgc initializes arena when C=>Haskell everytime. Please imagine the cost call all of find_cache(). Regards, -- Kiwamu Okabe at METASEPI DESIGN From john at repetae.net Tue Jun 10 12:07:03 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 05:07:03 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Yeah, find_cache is fairly slow. In fact, just checking if it is NULL noticibly slows things down. So, something that could be done is generate a struct with each cache used as offsets in it, basically putting the entire generate s_cache table in a struct then initializing them all when the arena is allocated. that would add a single redirect thruogh the arena to the caches which might not be too bad... what would be better is to use a thread or processor local register. John On Tue, Jun 10, 2014 at 4:58 AM, Kiwamu Okabe wrote: > Hi John, > > On Tue, Jun 10, 2014 at 8:49 PM, John Meacham wrote: >> The main issue would be how it affects allocation speed, its okay to >> make the GC slower as long as allocation is still fast, Before >> pre-populating the cache pointers sped things up considerably, how >> would it make sure to use one from the current arena without slowing >> down allocation in general? > > So I don't have any benchmark for it today. > I worry about the cost initializing arena when C=>Haskell. > Current jgc has no cost, but my jgc initializes arena when C=>Haskell everytime. > Please imagine the cost call all of find_cache(). > > Regards, > -- > Kiwamu Okabe at METASEPI DESIGN -- John Meacham - http://notanumber.net/ From john at repetae.net Tue Jun 10 14:16:29 2014 From: john at repetae.net (John Meacham) Date: Tue, 10 Jun 2014 07:16:29 -0700 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hmm.. well in any case, collecting the whole context into a handy struct is a good cleanup anyway, even if there is just a single global one. So I should backport that as well as the pthreads code. On Tue, Jun 10, 2014 at 5:07 AM, John Meacham wrote: > Yeah, find_cache is fairly slow. In fact, just checking if it is NULL > noticibly slows things down. > > So, something that could be done is generate a struct with each cache > used as offsets in it, basically putting the entire generate s_cache > table in a struct then initializing them all when the arena is > allocated. that would add a single redirect thruogh the arena to the > caches which might not be too bad... > > what would be better is to use a thread or processor local register. > > John > > On Tue, Jun 10, 2014 at 4:58 AM, Kiwamu Okabe wrote: >> Hi John, >> >> On Tue, Jun 10, 2014 at 8:49 PM, John Meacham wrote: >>> The main issue would be how it affects allocation speed, its okay to >>> make the GC slower as long as allocation is still fast, Before >>> pre-populating the cache pointers sped things up considerably, how >>> would it make sure to use one from the current arena without slowing >>> down allocation in general? >> >> So I don't have any benchmark for it today. >> I worry about the cost initializing arena when C=>Haskell. >> Current jgc has no cost, but my jgc initializes arena when C=>Haskell everytime. >> Please imagine the cost call all of find_cache(). >> >> Regards, >> -- >> Kiwamu Okabe at METASEPI DESIGN > > > > -- > John Meacham - http://notanumber.net/ -- John Meacham - http://notanumber.net/ From kiwamu at debian.or.jp Tue Jun 10 14:22:49 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Tue, 10 Jun 2014 23:22:49 +0900 Subject: [jhc] [Haskell-cafe] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: References: Message-ID: Hi John, Thank's for your advice. On Tue, Jun 10, 2014 at 11:16 PM, John Meacham wrote: > Hmm.. well in any case, collecting the whole context into a handy > struct is a good cleanup anyway, even if there is just a single global > one. So I should backport that as well as the pthreads code. I think strongly depending on pthread is bad idea, because it will destroy jhc's minimalism. Ajhc is result that is chosen with the design of selectable thread arch, but slow than jhc... I should think more and more to merge CLHs into jhc... Thank's, -- Kiwamu Okabe at METASEPI DESIGN From kiwamu at debian.or.jp Wed Jun 11 00:03:38 2014 From: kiwamu at debian.or.jp (Kiwamu Okabe) Date: Wed, 11 Jun 2014 09:03:38 +0900 Subject: [jhc] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell In-Reply-To: <539779B7.8000404@henning-thielemann.de> References: <539779B7.8000404@henning-thielemann.de> Message-ID: Hi Henning, On Wed, Jun 11, 2014 at 6:33 AM, Henning Thielemann wrote: > Since you are concerned with low-level Haskell programming, what do you > think about the Reduceron project? I also wondered whether it would be > possible to teach functional programming to processors with customizable > machine code like the Transmeta processors. I don't know whether comparable > projects are still alive. http://www.cs.york.ac.uk/fp/reduceron/ Oh, I hasn't know it. Thank's. I am not good to talk about HDL. However,a part of jhc's runtime can be designed with HDL, perhaps. Main part of jhc's runtime is GC. The GC clears bit marking array before marking. The clearing can be executed by HDL in parallel. Regards, -- Kiwamu Okabe at METASEPI DESIGN From john at repetae.net Mon Jun 16 06:14:14 2014 From: john at repetae.net (John Meacham) Date: Sun, 15 Jun 2014 23:14:14 -0700 Subject: [jhc] [Haskell-cafe] improved jhc manual In-Reply-To: <7C77AAFA-D81D-43C7-BC2C-61A1F60F602F@gmail.com> References: <7C77AAFA-D81D-43C7-BC2C-61A1F60F602F@gmail.com> Message-ID: On Sun, Jun 15, 2014 at 10:10 PM, wrote: > The implementation of unboxed types and defined kinds in JHC appears to be incompatible with GHC (`Int_` instead of `Int#`, `data kind` instead of just `data` and promote every suitable type). Please fix this. They are different because they are somewhat different things. GHC and jhc have very different intermediate and back end languages, ghc's is based on system F with a backend distantly descended from the G machine and jhc has an intermediate language based on a PTS similar to the lambda-cube* and a backend descended from boquit's GRIN intermediate language and these decisions constrain the semantics of unboxed values for both compilers. Likewise, the type systems are different in some ways, for instance jhc supports polymorphism of unboxed types so there is no need for 1# and 1## being different types. It has a different kind hierarchy because in the back end 'evaluation' and 'case matching' are independent operations which in ghc they are intertwined, so you can directly branch on a value if you know it is already evaluated which is a particularly advantagous. jhc unboxed constructors are normal so no special Hash syntax is needed to denote them. Since jhc has no run-time it's unboxed values need to be at a lower level than GHC's to take advantage of optimizations based on that. For instance, ghc has independent types for unboxed Int's and Word's, however, as far as a CPU is concerned there are only values of a certain bit width and no signendedness information is on the type. Jhc follows CPU operations. It just happens that the instance Num Word in jhc uses unsigned primitives and the instance Num Int uses signed ones but they both are boxed 'Bits32_' underneath. The kind extensions were independently developed hence the different syntax, I am not a fan of eating syntax or filling the data tables with most likely unused kinds automatically... but I may change my mind on that in the future, User defined kinds are still fairly new so I want to see more how they are used in practice for a while, In any case, PolyKinds are next up in the kind system for implementation. *My IL is very similar to and was inspired by Henk actually (http://www.staff.science.uu.nl/~jeuri101/MSc/jwroorda/) -- John Meacham - http://notanumber.net/