From lemmih at gmail.com Sat Mar 1 01:55:46 2008 From: lemmih at gmail.com (Lemmih) Date: Sat Mar 1 01:53:31 2008 Subject: [jhc] darcs patch: Manually inline an important piece of code. (and 1 more) Message-ID: <47c8fdf4.226f420a.2e14.3fa8@mx.google.com> Sat Feb 23 02:50:27 CET 2008 Lemmih * Manually inline an important piece of code. Sat Mar 1 07:49:17 CET 2008 Lemmih * Fix a space leak caused by unevaluated stats when verbosity is 0. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8082 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080301/c222aacc/attachment.bin From lemmih at gmail.com Sat Mar 1 02:15:49 2008 From: lemmih at gmail.com (Lemmih) Date: Sat Mar 1 02:13:34 2008 Subject: [jhc] darcs patch: Avoid unnecessary substitutions. Message-ID: <47c902a8.1806420a.0d98.ffffc3e4@mx.google.com> Sat Mar 1 08:15:21 CET 2008 Lemmih * Avoid unnecessary substitutions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7615 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080301/fce97a4b/attachment-0001.bin From john at repetae.net Sat Mar 1 19:50:22 2008 From: john at repetae.net (John Meacham) Date: Sat Mar 1 19:48:01 2008 Subject: [jhc] darcs patch: Avoid unnecessary substitutions. In-Reply-To: <47c902a8.1806420a.0d98.ffffc3e4@mx.google.com> References: <47c902a8.1806420a.0d98.ffffc3e4@mx.google.com> Message-ID: <20080302005022.GB31255@sliver.repetae.net> I am not sure if this transformation is valid. Mainly, the 'info' and 'type' fields of the tvr may have been modified by other transformations so the variable may need to be substituted anyway even if its ident is the same. John -- John Meacham - ?repetae.net?john? From john at repetae.net Sat Mar 1 22:46:33 2008 From: john at repetae.net (John Meacham) Date: Sat Mar 1 22:44:12 2008 Subject: [jhc] ANNOUNCE: jhc 0.5.20080301 is out Message-ID: <20080302034633.GC31255@sliver.repetae.net> the much anticipated first 0.5 release is out. This incorperates Lemmih's great performance patches, a completely new mechanism for collecting and processing ho files, and a reworking of the rules infrastructure. in addition: jhc now has the beginnings of a manual! http://repetae.net/computer/jhc/manual.html The manual is in its infancy, and not quite complete or correct, but I hope to expand it quickly now that the infrastructure is in place. users of fedora linux can install simply via the following command: ; rpm -U http://repetae.net/computer/jhc/drop/jhc-0.5.20080301-1.i386.rpm there are also tarballs for other distributions. information is at the homepage here: http://repetae.net/computer/jhc jhc currently passes all its regressions but one (BinaryTrees) but I decided to make a release anyway since there has been a lot of work done. Once I figure out the bug affecting this last regression, I will make another point release and do a more general announcement on the main haskell list. enjoy! John -- John Meacham - ?repetae.net?john? From lemmih at gmail.com Sun Mar 2 08:14:09 2008 From: lemmih at gmail.com (Lemmih) Date: Sun Mar 2 08:11:46 2008 Subject: [jhc] darcs patch: Avoid unnecessary substitutions. In-Reply-To: <20080302005022.GB31255@sliver.repetae.net> References: <47c902a8.1806420a.0d98.ffffc3e4@mx.google.com> <20080302005022.GB31255@sliver.repetae.net> Message-ID: On Sun, Mar 2, 2008 at 1:50 AM, John Meacham wrote: > I am not sure if this transformation is valid. Mainly, the 'info' and > 'type' fields of the tvr may have been modified by other transformations > so the variable may need to be substituted anyway even if its ident is > the same. Right, but if the info has changed then the occurance (sic) is set to LoopBreaker. Anyhow, I see your point. I don't like the patch so feel free to discard it. It's just a shame that doing an empty run requires as much memory as an full run. That is, doing no optimizations is as expensive as doing a ton of optimization. -- Cheers, Lemmih From john at repetae.net Tue Mar 4 17:27:57 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 4 17:25:28 2008 Subject: [jhc] benchmark results Message-ID: <20080304222756.GA22215@sliver.repetae.net> I am starting to get some very interesting benchmark results: http://repetae.net/computer/jhc/results.html Although most programs did not compile with jhc, every one which successfully did ran signifigantly faster than ghc, several times faster in most cases. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Thu Mar 6 11:52:01 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 6 11:49:24 2008 Subject: [jhc] CPP extension, .cabal parsing Message-ID: It looks like JHC doesn't support the CPP extension. It also looks like it tries to parse .cabal files by itself -- which doesn't work right with flags. Together, this makes it hard to compile quickcheck. (Mostly the former, though.) From john at repetae.net Thu Mar 6 18:43:19 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 6 18:40:40 2008 Subject: [jhc] CPP extension, .cabal parsing In-Reply-To: References: Message-ID: <20080306234319.GI4914@sliver.repetae.net> On Thu, Mar 06, 2008 at 11:52:01AM -0500, Samuel Bronson wrote: > It looks like JHC doesn't support the CPP extension. > It also looks like it tries to parse .cabal files by itself -- which > doesn't work right with flags. > Together, this makes it hard to compile quickcheck. (Mostly the former, though.) jhc supports both cpp and m4 as preprocessors, use the '-fcpp' or '-fm4' options to enable them. I can pretty easily add support for the LANGUAGE pragma if that helps. The library format is not quite a cabal file, but rather just a subset. ideally ones build system (such as autoconf, or cabal-install, or cook, or whatever) would examine the current system and spit out an appropriate one to invoke jhc on. In the meantime, it is easy enough to modify a cabal file into a form jhc can grok until tools learn to cope. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Thu Mar 6 19:02:31 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 6 18:59:54 2008 Subject: [jhc] CPP extension, .cabal parsing In-Reply-To: <20080306234319.GI4914@sliver.repetae.net> References: <20080306234319.GI4914@sliver.repetae.net> Message-ID: On 3/6/08, John Meacham wrote: > jhc supports both cpp and m4 as preprocessors, use the '-fcpp' or '-fm4' > options to enable them. I can pretty easily add support for the LANGUAGE > pragma if that helps. Yeah, that would definately help. From naesten at gmail.com Fri Mar 7 23:27:48 2008 From: naesten at gmail.com (Samuel Bronson) Date: Fri Mar 7 23:25:07 2008 Subject: [jhc] Classes Message-ID: John, can you please document your implementation of classes a bit? I'm trying to implement class aliases... we #haskellers are getting sick of having no such mechanism to play around with... but it would be a lot easier if I understood the module FrontEnd.Class. From naesten at gmail.com Sat Mar 8 11:51:34 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sat Mar 8 11:48:54 2008 Subject: [jhc] darcs patch: Misc. comments Message-ID: Sat Mar 8 11:49:34 EST 2008 Samuel Bronson * Misc. comments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8637 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080308/fead9d42/attachment.bin From john at repetae.net Mon Mar 10 09:34:53 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 09:32:04 2008 Subject: [jhc] new bugfix version up. Message-ID: <20080310133453.GC24790@sliver.repetae.net> I put a new version up that rolls up a lot of my changes to get more of nobench to compile. quite a few bugs have been fixed. new rpms and tarballs are available in the standard locations. This weekend I was going to write a new GC but I accidentally wrote a scheme interpreter. Hmm... I wonder how that happened. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Mar 10 09:56:55 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 09:54:05 2008 Subject: [jhc] Classes In-Reply-To: References: Message-ID: <20080310135654.GD24790@sliver.repetae.net> On Fri, Mar 07, 2008 at 11:27:48PM -0500, Samuel Bronson wrote: > John, can you please document your implementation of classes a bit? > I'm trying to implement class aliases... we #haskellers are getting > sick of having no such mechanism to play around with... but it would > be a lot easier if I understood the module FrontEnd.Class. Well, there are two parts to classes in jhc. There is the Front End, which has to typecheck them, keep track of instances and so forth, and the back end, which generates the code for them. Oddly enough, due to the way jhc implements classes, there is no need for the two to communicate :). Since jhc examines the type variables directly, after type checking the class contexts on haskell functions are just discarded when converting to jhc core. For class aliases, you just need to worry about the front end, which, unfortunately is the less clean of the two. The design evolved directly from hatchet, which evolved from the THIH paper[1]. So, understanding that paper might be a good place to start, however you should not need to touch the type checker at all for class aliases so they can actually be quite easy to implement. The information about each class is collected in a FrontEnd.Class.ClassRecord, a 'ClassHierarchy' is just a bunch of class records. when reading in multiple files, their class hierarchies are combined, which simply means combining the instances. what actually happens in the compiler is: a class definition module Main where class Foo a where foo :: a -> Int produces the following bit of core (written in psuedo-haskell) {-# NOINLINE foo #-} Main.foo :: forall a . a -> Int Main.foo = error "Placeholder" as far as everything else is concerned, this is just another routine like any other, since it is never inlined, the fact that its body is 'error' is never exposed. an instance instance Foo Char where foo c = ord c produces the following core Instance@.Main.Foo.foo.Prelude.Char :: Char -> Int Instance@.Main.Foo.foo.Prelude.Char c = ord c {-# RULES "foo/char/instance" Main.foo Char = Instance@.Main.Foo.foo.Prelude.Char #-} (note the explicity application of Main.foo to Char in the head of the rule, haskell hides these applications, the 'forall a' in foo's type signature is how you know it is secretly there) now, whenever Main.foo is called at a Char, it gets replaced with the appropriate instance method. before final compilation, all the RULES attached to any placeholder are turned into an explicit case on the type variable. This mechanism also allows SUPERSPECIALIZE and allows for 'run time rules', though that has not been explored. Umm.. I guess I got sidetracked from class aliases... For those what you want to do is add a new type of 'ClassRecord' that encodes all the information about a class alias, then in the front end (the desugarer is probably easiest, but in the type checker will probably allow better error messages) when you come across a class alias, expand it to its underlying class via the class alias rules. you should not need to modify anything other than the frontend for that, though a few things will have to be taught to ignore the new ClassAlias entries in ClassHierarchy. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 10 13:50:09 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 10 13:47:19 2008 Subject: [jhc] Classes In-Reply-To: <20080310135654.GD24790@sliver.repetae.net> References: <20080310135654.GD24790@sliver.repetae.net> Message-ID: On 3/10/08, John Meacham wrote: > what actually happens in the compiler is: > > a class definition > > module Main where > class Foo a where > foo :: a -> Int > > produces the following bit of core (written in psuedo-haskell) > > {-# NOINLINE foo #-} > Main.foo :: forall a . a -> Int > Main.foo = error "Placeholder" > > as far as everything else is concerned, this is just another routine > like any other, since it is never inlined, the fact that its body is > 'error' is never exposed. > > an instance > > instance Foo Char where > foo c = ord c > > produces the following core > > Instance@.Main.Foo.foo.Prelude.Char :: Char -> Int > Instance@.Main.Foo.foo.Prelude.Char c = ord c > > {-# RULES "foo/char/instance" Main.foo Char = Instance@.Main.Foo.foo.Prelude.Char #-} Hmm. What should I name default implementations? From john at repetae.net Mon Mar 10 16:03:37 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 16:00:48 2008 Subject: [jhc] Classes In-Reply-To: References: <20080310135654.GD24790@sliver.repetae.net> Message-ID: <20080310200336.GA7210@sliver.repetae.net> On Mon, Mar 10, 2008 at 01:50:09PM -0400, Samuel Bronson wrote: > On 3/10/08, John Meacham wrote: > > instance Foo Char where > > foo c = ord c > > > > produces the following core > > > > Instance@.Main.Foo.foo.Prelude.Char :: Char -> Int > > Instance@.Main.Foo.foo.Prelude.Char c = ord c > > > > {-# RULES "foo/char/instance" Main.foo Char = Instance@.Main.Foo.foo.Prelude.Char #-} > > Hmm. What should I name default implementations? Those are named 'Instance@.Main.Foo.foo.default' and have the type 'forall a . a -> Int' . A default method always exists, even if it is just an error saying no default method was supplied. RULES are generated for the default methods as well in the same fashion. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 10 19:52:34 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 10 19:49:43 2008 Subject: [jhc] Classes In-Reply-To: <20080310200336.GA7210@sliver.repetae.net> References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> Message-ID: On 3/10/08, John Meacham wrote: > On Mon, Mar 10, 2008 at 01:50:09PM -0400, Samuel Bronson wrote: > > On 3/10/08, John Meacham wrote: > > > instance Foo Char where > > > foo c = ord c > > > > > > produces the following core > > > > > > Instance@.Main.Foo.foo.Prelude.Char :: Char -> Int > > > Instance@.Main.Foo.foo.Prelude.Char c = ord c > > > > > > {-# RULES "foo/char/instance" Main.foo Char = Instance@.Main.Foo.foo.Prelude.Char #-} > > > > Hmm. What should I name default implementations? > > Those are named 'Instance@.Main.Foo.foo.default' and have the type > 'forall a . a -> Int' . A default method > always exists, even if it is just an error saying no default method was > supplied. RULES are generated for the default methods as well in the > same fashion. Well, I meant the additional default methods offered by class aliasses... and what can I do to keep track of what the proper method name is so I can generate the RULES later... From john at repetae.net Mon Mar 10 20:21:00 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 20:18:10 2008 Subject: [jhc] Classes In-Reply-To: References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> Message-ID: <20080311002100.GA9625@sliver.repetae.net> On Mon, Mar 10, 2008 at 07:52:34PM -0400, Samuel Bronson wrote: > > Those are named 'Instance@.Main.Foo.foo.default' and have the type > > 'forall a . a -> Int' . A default method > > always exists, even if it is just an error saying no default method was > > supplied. RULES are generated for the default methods as well in the > > same fashion. > > Well, I meant the additional default methods offered by class > aliasses... and what can I do to keep track of what the proper method > name is so I can generate the RULES later... you can use 'FrontEnd.Class.instanceName' and 'FrontEnd.Class.defaultInstanceName' for generating appropriate names. since class aliases desugar to normal instances, you should not need to create any new rules at all. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 10 20:27:20 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 10 20:24:29 2008 Subject: [jhc] Classes In-Reply-To: <20080311002100.GA9625@sliver.repetae.net> References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> <20080311002100.GA9625@sliver.repetae.net> Message-ID: On 3/10/08, John Meacham wrote: > On Mon, Mar 10, 2008 at 07:52:34PM -0400, Samuel Bronson wrote: > > > Those are named 'Instance@.Main.Foo.foo.default' and have the type > > > 'forall a . a -> Int' . A default method > > > always exists, even if it is just an error saying no default method was > > > supplied. RULES are generated for the default methods as well in the > > > same fashion. > > > > Well, I meant the additional default methods offered by class > > aliasses... and what can I do to keep track of what the proper method > > name is so I can generate the RULES later... > > you can use 'FrontEnd.Class.instanceName' and > 'FrontEnd.Class.defaultInstanceName' for generating appropriate names. > since class aliases desugar to normal instances, you should not need to > create any new rules at all. Eh? Won't that generate the same name as before? Or were you thinking it would just combine the alias' name with local component of the method name -- which won't work if the alias expands to classes which have methods of the same name. Which COULD happen, and should work. From john at repetae.net Mon Mar 10 21:32:01 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 21:29:11 2008 Subject: [jhc] Classes In-Reply-To: References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> <20080311002100.GA9625@sliver.repetae.net> Message-ID: <20080311013201.GB9625@sliver.repetae.net> On Mon, Mar 10, 2008 at 08:27:20PM -0400, Samuel Bronson wrote: > Eh? Won't that generate the same name as before? Or were you thinking > it would just combine the alias' name with local component of the > method name -- which won't work if the alias expands to classes which > have methods of the same name. Which COULD happen, and should work. Ah, yeah you should probably include the class alias name in there. as in something like ClassAlias@.[Module].[AliasName].[method] John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Mar 11 08:17:43 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 11 08:15:00 2008 Subject: [jhc] Classes In-Reply-To: <20080311013201.GB9625@sliver.repetae.net> References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> <20080311002100.GA9625@sliver.repetae.net> <20080311013201.GB9625@sliver.repetae.net> Message-ID: On Mon, Mar 10, 2008 at 9:32 PM, John Meacham wrote: > On Mon, Mar 10, 2008 at 08:27:20PM -0400, Samuel Bronson wrote: > > Eh? Won't that generate the same name as before? Or were you thinking > > it would just combine the alias' name with local component of the > > method name -- which won't work if the alias expands to classes which > > have methods of the same name. Which COULD happen, and should work. > > Ah, yeah you should probably include the class alias name in there. as > in something like > > ClassAlias@.[Module].[AliasName].[method] But how to tell where the alias name ends and the method name begins? The method name will need to be qualified, won't it? From naesten at gmail.com Tue Mar 11 19:38:46 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 11 19:35:57 2008 Subject: [jhc] darcs patch: Convenience command :recompile for GHCi usage; accompa... Message-ID: Tue Mar 11 19:36:21 EDT 2008 Samuel Bronson * Convenience command :recompile for GHCi usage; accompanying Makefile.am changes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 760 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080311/d1d3a3dc/attachment.bin From john at repetae.net Tue Mar 11 22:13:27 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 11 22:10:35 2008 Subject: [jhc] Classes In-Reply-To: References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> <20080311002100.GA9625@sliver.repetae.net> <20080311013201.GB9625@sliver.repetae.net> Message-ID: <20080312021327.GA11088@sliver.repetae.net> On Tue, Mar 11, 2008 at 08:17:43AM -0400, Samuel Bronson wrote: > On Mon, Mar 10, 2008 at 9:32 PM, John Meacham wrote: > > On Mon, Mar 10, 2008 at 08:27:20PM -0400, Samuel Bronson wrote: > > > Eh? Won't that generate the same name as before? Or were you thinking > > > it would just combine the alias' name with local component of the > > > method name -- which won't work if the alias expands to classes which > > > have methods of the same name. Which COULD happen, and should work. > > > > Ah, yeah you should probably include the class alias name in there. as > > in something like > > > > ClassAlias@.[Module].[AliasName].[method] > > But how to tell where the alias name ends and the method name begins? > The method name will need to be qualified, won't it? You may need to do something like that. In any case you should never parse existing names to pull out the info about it, you should just call 'classAliasDefaultName alias method' and use the result. As in, I never need to look at a name to find out it is an instance, I Just know that the result of 'instanceName' will be a valid existing name of the right type so I can refer to it directly. The actual format of the name would never occur anywhere in code other than the 'classAliasDefaultName' function so it would be pretty easy to change later in any case. John -- John Meacham - ?repetae.net?john? From john at repetae.net Wed Mar 12 14:49:29 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 12 14:46:33 2008 Subject: [jhc] darcs patch: Convenience command :recompile for GHCi usage; accompa... In-Reply-To: References: Message-ID: <20080312184929.GB15073@sliver.repetae.net> Thanks for the patch, but could you resubmit it with the .ghci file in 'utils' as a non-hidden file? I don't like having hidden files in the repo and people can just ln -s it to .ghci if they want it. (that and I, and probably others, already have a customized .ghci in my project directory) this is in line with utils/grin.vim - syntax highlighting for grin code utils/debug.gdb - gdb macros for deconstructing and printing thunks on the heap. perhaps calling it something like utils/ghci.rc ? hmm.. utils/jhc.ghci? or whatever seems best to you. John On Tue, Mar 11, 2008 at 07:38:46PM -0400, Samuel Bronson wrote: > Tue Mar 11 19:36:21 EDT 2008 Samuel Bronson > * Convenience command :recompile for GHCi usage; accompanying Makefile.am changes Content-Description: A darcs patch for your repository! > > New patches: > > [Convenience command :recompile for GHCi usage; accompanying Makefile.am changes > Samuel Bronson **20080311233621] { > addfile ./.ghci > hunk ./.ghci 1 > +:def recompile \_ -> return . unlines $ [":!make built-sources", ":reload"] > hunk ./Makefile.am 193 > -i: > +built-sources: $(BUILT_SOURCES) > + > +i: $(BUILT_SOURCES) > hunk ./Makefile.am 198 > -.PHONY: ho-clean hl-clean i update-datestamp manual > +.PHONY: ho-clean hl-clean built-sources i update-datestamp manual > } > > Context: > > [update datestamp > John Meacham **20080309042215] > [Misc. comments > Samuel Bronson **20080308164934] > [TAG frinredvos > John Meacham **20080307160355] > Patch bundle hash: > 10dfaa873295ea15a1215c0a34dafbd407cf511b > -- > jhc mailing list > jhc@haskell.org > http://www.haskell.org/mailman/listinfo/jhc -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 12 16:28:23 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 12 16:25:27 2008 Subject: [jhc] darcs patch: Convenience command :recompile for GHCi usage; accompa... In-Reply-To: <20080312184929.GB15073@sliver.repetae.net> References: <20080312184929.GB15073@sliver.repetae.net> Message-ID: On 3/12/08, John Meacham wrote: > Thanks for the patch, but could you resubmit it with the .ghci file in > 'utils' as a non-hidden file? I don't like having hidden files in the > repo and people can just ln -s it to .ghci if they want it. (that and I, > and probably others, already have a customized .ghci in my project directory) How about utils/recompile.ghci? It is, after all, a .ghci file... From naesten at gmail.com Wed Mar 12 16:31:17 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 12 16:28:23 2008 Subject: [jhc] Classes In-Reply-To: <20080312021327.GA11088@sliver.repetae.net> References: <20080310135654.GD24790@sliver.repetae.net> <20080310200336.GA7210@sliver.repetae.net> <20080311002100.GA9625@sliver.repetae.net> <20080311013201.GB9625@sliver.repetae.net> <20080312021327.GA11088@sliver.repetae.net> Message-ID: On 3/11/08, John Meacham wrote: > On Tue, Mar 11, 2008 at 08:17:43AM -0400, Samuel Bronson wrote: > > On Mon, Mar 10, 2008 at 9:32 PM, John Meacham wrote: > > > ClassAlias@.[Module].[AliasName].[method] > > > > But how to tell where the alias name ends and the method name begins? > > The method name will need to be qualified, won't it? > > You may need to do something like that. > > In any case you should never parse existing names to pull out the info > about it, you should just call 'classAliasDefaultName alias method' and > use the result. As in, I never need to look at a name to find out it is > an instance, I Just know that the result of 'instanceName' will be a > valid existing name of the right type so I can refer to it directly. > > The actual format of the name would never occur anywhere in code other > than the 'classAliasDefaultName' function so it would be pretty easy to > change later in any case. Well, I wasn't planning to try and parse it, but I think your suggested way could lead to duplicates, regardless of whether you meant for the names to have been qualified or not (though in different ways in each case, of course, and if qualified these conflicts would be much less likely...) From john at repetae.net Wed Mar 12 16:35:00 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 12 16:32:07 2008 Subject: [jhc] darcs patch: Convenience command :recompile for GHCi usage; accompa... In-Reply-To: References: <20080312184929.GB15073@sliver.repetae.net> Message-ID: <20080312203458.GC15073@sliver.repetae.net> On Wed, Mar 12, 2008 at 03:28:23PM -0500, Samuel Bronson wrote: > On 3/12/08, John Meacham wrote: > > Thanks for the patch, but could you resubmit it with the .ghci file in > > 'utils' as a non-hidden file? I don't like having hidden files in the > > repo and people can just ln -s it to .ghci if they want it. (that and I, > > and probably others, already have a customized .ghci in my project directory) > > How about utils/recompile.ghci? It is, after all, a .ghci file... sounds good to me. Hmm.. I should make a ghci.vim syntax highlighting mode sometime... John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 12 18:02:10 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 12 17:59:17 2008 Subject: [jhc] darcs patch: Convenience command :recompile for GHCi usage; accompa... Message-ID: Wed Mar 12 18:00:54 EDT 2008 Samuel Bronson * Convenience command :recompile for GHCi usage; accompanying Makefile.am changes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1699 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080312/5b7be3e1/attachment.bin From naesten at gmail.com Sat Mar 15 16:38:07 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sat Mar 15 16:35:01 2008 Subject: [jhc] darcs patch: Class aliases halfway done? (and 1 more) Message-ID: Well, I got somewhere, but I'm not sure how to (a) fix the types for the default methods or (b) get those default methods to be used... Fri Mar 14 21:51:52 EDT 2008 Samuel Bronson * Class aliases halfway done? Sat Mar 15 16:25:15 EDT 2008 Samuel Bronson * Doesn't quite work -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 17841 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080315/b7dbb23e/attachment-0001.bin From john at repetae.net Sat Mar 15 19:23:41 2008 From: john at repetae.net (John Meacham) Date: Sat Mar 15 19:20:34 2008 Subject: [jhc] darcs patch: Class aliases halfway done? (and 1 more) In-Reply-To: References: Message-ID: <20080315232340.GA5971@sliver.repetae.net> Excellent work! thanks. Since you are working on the class stuff, although some not insignifigant work needs to be done in the middle end to support MPTCs, if you come across anything in the front end that needs to be done to support them, feel free to do so. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Sat Mar 15 19:47:20 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sat Mar 15 19:44:13 2008 Subject: [jhc] darcs patch: Class aliases halfway done? (and 1 more) In-Reply-To: <20080315232340.GA5971@sliver.repetae.net> References: <20080315232340.GA5971@sliver.repetae.net> Message-ID: On Sat, Mar 15, 2008 at 7:23 PM, John Meacham wrote: > Excellent work! thanks. Since you are working on the class stuff, > although some not insignifigant work needs to be done in the middle end > to support MPTCs, if you come across anything in the front end that > needs to be done to support them, feel free to do so. Yeah. It does need a lot of work too... I fear I may not be entirely helping... From naesten at gmail.com Sat Mar 15 19:54:41 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sat Mar 15 19:51:45 2008 Subject: [jhc] darcs patch: Class aliases halfway done? (and 2 more) Message-ID: Fri Mar 14 21:51:52 EDT 2008 Samuel Bronson * Class aliases halfway done? Sat Mar 15 16:25:15 EDT 2008 Samuel Bronson * Doesn't quite work Sat Mar 15 19:50:17 EDT 2008 Samuel Bronson * Nearly working, at least for test/latticeUser.hs and test/Lattice.lhs If only it wouldn't drop the default methods on the floor... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 20796 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080315/003f6f99/attachment.bin From naesten at gmail.com Sun Mar 16 19:35:18 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 16 19:32:19 2008 Subject: [jhc] darcs patch: Fix parsing of @ patterns so that Data.H... (and 1 more) Message-ID: Sun Mar 16 19:29:16 EDT 2008 Samuel Bronson * Fix parsing of @ patterns so that Data.HashTable parses Sun Mar 16 19:33:39 EDT 2008 Samuel Bronson * Jhc.IOArray module implementing extremely basic IOArray functionality -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 4179 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080316/48138d3c/attachment-0001.bin From naesten at gmail.com Sun Mar 16 20:40:10 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 16 20:37:00 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile Message-ID: Sun Mar 16 20:22:51 EDT 2008 Samuel Bronson * Get Data.Typeable to compile -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 3735 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080316/01b4d9f3/attachment.bin From naesten at gmail.com Sun Mar 16 22:11:47 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 16 22:08:38 2008 Subject: [jhc] (->) not working too well... Message-ID: This fails horribly in Jhc: {-# OPTIONS_NHC98 --prelude #-} ----------------------------------------------------------------------------- -- | -- Module : Control.Monad.Instances -- Copyright : (c) The University of Glasgow 2001 -- License : BSD-style (see the file libraries/base/LICENSE) -- -- Maintainer : libraries@haskell.org -- Stability : provisional -- Portability : portable -- -- 'Functor' and 'Monad' instances for @(->) r@ and -- 'Functor' instances for @(,) a@ and @'Either' a@. module Control.Monad.Instances (Functor(..),Monad(..)) where import Prelude instance Functor ((->) r) where fmap = (.) instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r instance Functor ((,) a) where fmap f (x,y) = (x, f y) instance Functor (Either a) where fmap _ (Left x) = Left x fmap f (Right y) = Right (f y) From john at repetae.net Mon Mar 17 05:09:15 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 05:06:04 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile In-Reply-To: References: Message-ID: <20080317090915.GB5971@sliver.repetae.net> Hi, I don't want to use cpp ever more than strictly necessary, so, when using it, only put it on individual files with an {-# OPTIONS_JHC -fcpp #-} and and use {-# OPTIONS_JHC -N #-} for no implicit prelude. though, for unsafecoerce, I think just the following will do fine {-#OPTION_JHC -N #-} module Unsafe.Coerce(unsafeCoerce) where import Jhc.Prim unsafeCoerce = unsafeCoerce__ in general, almost all uses of CPP should be replaced by constant expressions when possible, like foo = if (sizeOf Int == 32) then foo32 else fooOther and for doing 'meta-programming' 'm4' is much nicer than CPP so I expect the main use of CPP will be in external libraries rather than any of the jhc built in ones. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 06:48:39 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 06:45:34 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile In-Reply-To: <20080317090915.GB5971@sliver.repetae.net> References: <20080317090915.GB5971@sliver.repetae.net> Message-ID: On Mon, Mar 17, 2008 at 4:09 AM, John Meacham wrote: > Hi, I don't want to use cpp ever more than strictly necessary, so, when > using it, only put it on individual files with an > > {-# OPTIONS_JHC -fcpp #-} and > and use {-# OPTIONS_JHC -N #-} for no implicit prelude. > > though, for unsafecoerce, I think just the following will do fine > > {-#OPTION_JHC -N #-} > module Unsafe.Coerce(unsafeCoerce) where > import Jhc.Prim > unsafeCoerce = unsafeCoerce__ > > in general, almost all uses of CPP should be replaced by constant > expressions when possible, like > > foo = if (sizeOf Int == 32) then foo32 else fooOther > > and for doing 'meta-programming' 'm4' is much nicer than CPP so I expect > the main use of CPP will be in external libraries rather than any of the > jhc built in ones. Well, I *did* copy and paste this from the main base repository, but I guess that *was* rather overkill in this instance since it doesn't share more than one line of actual code... out of three lines in the entire module. For other, less trivial modules from that source, it would be okay to use cpp, wouldn't it? From john at repetae.net Mon Mar 17 10:58:46 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 10:55:34 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile In-Reply-To: References: <20080317090915.GB5971@sliver.repetae.net> Message-ID: <20080317145846.GC5971@sliver.repetae.net> Well, it depends. Ideally what I want is for the 'jhc' distribution to contain just the haskell' libraries (once they are finalized) which will likely be much smaller than the current extended 'base' that ghc uses, so I don't want to get in the habit of importing code from the ghc repo in large quantities. that said, for practical reasons, and since a lot of the stuff in ghc base isn't separately packaged, I do need some way to make it available. I think what would be best is to have the current 'base' library just contain a fairly minimal base, what we expect to be in haskell' or what is jhc specific enough to be interesting.as well as what is enough to build 'haskell98'. then create another 'base-extras' library which will contain mostly unchanged code from the ghc repo that is in ghc's base. like System.Console.GetOpts can probably go there. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Mar 17 11:03:31 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 11:00:18 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: Message-ID: <20080317150331.GD5971@sliver.repetae.net> yeah, that doesn't surprise me that much, though it will likely be not too hard to fix. basically, since we need to sometimes treat types as values we can scrutinize (->) has a reified form of the type constructor that takes two arguments named Jhc@.-> defined in Name.Names as tc_Arrow. Code just needs to make sure that it translates between the two forms as needed. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Mar 17 11:22:40 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 11:19:28 2008 Subject: [jhc] newer results Message-ID: <20080317152240.GE5971@sliver.repetae.net> newer results, a few more compile, jhc still kicks ass when it can compile something, but there were a couple regressions I am looking into. I believe it has something to do with the final mangling pass before converting jhc core to grin. http://repetae.net/computer/jhc/results3.html John -- John Meacham - ?repetae.net?john? From taralx at gmail.com Mon Mar 17 14:26:15 2008 From: taralx at gmail.com (Taral) Date: Mon Mar 17 14:23:05 2008 Subject: [jhc] newer results In-Reply-To: <20080317152240.GE5971@sliver.repetae.net> References: <20080317152240.GE5971@sliver.repetae.net> Message-ID: On 3/17/08, John Meacham wrote: > http://repetae.net/computer/jhc/results3.html Can you make the .actual links work in there? -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From naesten at gmail.com Mon Mar 17 15:52:28 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 15:49:17 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile In-Reply-To: <20080317145846.GC5971@sliver.repetae.net> References: <20080317090915.GB5971@sliver.repetae.net> <20080317145846.GC5971@sliver.repetae.net> Message-ID: On 3/17/08, John Meacham wrote: > Well, it depends. Ideally what I want is for the 'jhc' distribution to > contain just the haskell' libraries (once they are finalized) which will > likely be much smaller than the current extended 'base' that ghc uses, > so I don't want to get in the habit of importing code from the ghc repo > in large quantities. > > that said, for practical reasons, and since a lot of the stuff in ghc > base isn't separately packaged, I do need some way to make it available. > I think what would be best is to have the current 'base' library just > contain a fairly minimal base, what we expect to be in haskell' or what > is jhc specific enough to be interesting.as well as what is enough to > build 'haskell98'. then create another 'base-extras' library which will > contain mostly unchanged code from the ghc repo that is in ghc's base. > like System.Console.GetOpts can probably go there. Wouldn't it be more sensible to put the JHC-specific code in a library called jhcbase, like hugs does (only of course theirs is called hugsbase or something), and just use the "base" repository that everyone else uses for the not-really-jhc-specific bits? From john at repetae.net Mon Mar 17 16:13:37 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 16:10:24 2008 Subject: [jhc] darcs patch: Get Data.Typeable to compile In-Reply-To: References: <20080317090915.GB5971@sliver.repetae.net> <20080317145846.GC5971@sliver.repetae.net> Message-ID: <20080317201337.GB14807@sliver.repetae.net> On Mon, Mar 17, 2008 at 03:52:28PM -0400, Samuel Bronson wrote: > > that said, for practical reasons, and since a lot of the stuff in ghc > > base isn't separately packaged, I do need some way to make it available. > > I think what would be best is to have the current 'base' library just > > contain a fairly minimal base, what we expect to be in haskell' or what > > is jhc specific enough to be interesting.as well as what is enough to > > build 'haskell98'. then create another 'base-extras' library which will > > contain mostly unchanged code from the ghc repo that is in ghc's base. > > like System.Console.GetOpts can probably go there. > > Wouldn't it be more sensible to put the JHC-specific code in a library > called jhcbase, like hugs does (only of course theirs is called > hugsbase or something), and just use the "base" repository that > everyone else uses for the not-really-jhc-specific bits? Well, I actually wanted 3 packages: jhc - nothing that relys on Prelude, everything the compiler needs or knows about is in here somewhere. as in, the compiler has no built in knowledge of anything that doesn't live in 'jhc'. should be fairly small. base - basic functionality, enough to implement one of the language standards, either haskell98, haskell' or one of the random alternate prelude systems that are floating about. base-extras (or some other name) - something just to fill out compatibility with ghc's base but stuff that wouldn't normally need to be distributed with a compiler. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 17:32:01 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 17:28:50 2008 Subject: [jhc] (->) not working too well... In-Reply-To: <20080317150331.GD5971@sliver.repetae.net> References: <20080317150331.GD5971@sliver.repetae.net> Message-ID: On 3/17/08, John Meacham wrote: > yeah, that doesn't surprise me that much, though it will likely be not > too hard to fix. basically, since we need to sometimes treat types as > values we can scrutinize (->) has a reified form of the type > constructor that takes two arguments named Jhc@.-> defined in Name.Names > as tc_Arrow. > > Code just needs to make sure that it translates between the two forms as > needed. That's easy for you to say... but JHC doesn't seem to get the kind right on (->) at this point... From john at repetae.net Mon Mar 17 18:01:35 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 17:58:21 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: <20080317150331.GD5971@sliver.repetae.net> Message-ID: <20080317220135.GC14807@sliver.repetae.net> On Mon, Mar 17, 2008 at 05:32:01PM -0400, Samuel Bronson wrote: > On 3/17/08, John Meacham wrote: > > yeah, that doesn't surprise me that much, though it will likely be not > > too hard to fix. basically, since we need to sometimes treat types as > > values we can scrutinize (->) has a reified form of the type > > constructor that takes two arguments named Jhc@.-> defined in Name.Names > > as tc_Arrow. > > > > Code just needs to make sure that it translates between the two forms as > > needed. > > That's easy for you to say... but JHC doesn't seem to get the kind > right on (->) at this point... Well, the kind of (->) is fairly tricky due to the fact it is kind-polymorphic for the same reason it is in ghc. since functions need to accept unboxed arguments and return unboxed tuples. Though, restraining it to * -> * -> * in class heads probably makes sense. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 18:32:58 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 18:29:45 2008 Subject: [jhc] (->) not working too well... In-Reply-To: <20080317220135.GC14807@sliver.repetae.net> References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> Message-ID: On 3/17/08, John Meacham wrote: > On Mon, Mar 17, 2008 at 05:32:01PM -0400, Samuel Bronson wrote: > > On 3/17/08, John Meacham wrote: > > > yeah, that doesn't surprise me that much, though it will likely be not > > > too hard to fix. basically, since we need to sometimes treat types as > > > values we can scrutinize (->) has a reified form of the type > > > constructor that takes two arguments named Jhc@.-> defined in Name.Names > > > as tc_Arrow. > > > > > > Code just needs to make sure that it translates between the two forms as > > > needed. > > > > That's easy for you to say... but JHC doesn't seem to get the kind > > right on (->) at this point... > > > Well, the kind of (->) is fairly tricky due to the fact it is > kind-polymorphic for the same reason it is in ghc. since functions need > to accept unboxed arguments and return unboxed tuples. > > Though, restraining it to * -> * -> * in class heads probably makes > sense. I'm trying an explicit declaration in Jhc.Basics (yes, I changed the name to be a name in Jhc.Basics instead of Jhc@ everywhere...) From john at repetae.net Mon Mar 17 18:44:21 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 18:41:08 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> Message-ID: <20080317224421.GD14807@sliver.repetae.net> Hrmm... that might not work so well. We actually need the kind overloaded sort for (->) and I wouldn't want an incorrect definition there. No matter what some treating of it specially will have to happen in the code proper, the internal representation of (->) just isn't a data constructor. (a -> b) is actually shorthand for ?(_?a).b John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 18:48:46 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 18:45:33 2008 Subject: [jhc] (->) not working too well... In-Reply-To: <20080317224421.GD14807@sliver.repetae.net> References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> <20080317224421.GD14807@sliver.repetae.net> Message-ID: T24gMy8xNy8wOCwgSm9obiBNZWFjaGFtIDxqb2huQHJlcGV0YWUubmV0PiB3cm90ZToKPiBIcm1t Li4uIHRoYXQgbWlnaHQgbm90IHdvcmsgc28gd2VsbC4gV2UgYWN0dWFsbHkgbmVlZCB0aGUga2lu ZAo+IG92ZXJsb2FkZWQgc29ydCBmb3IgKC0+KSBhbmQgSSB3b3VsZG4ndCB3YW50IGFuIGluY29y cmVjdCBkZWZpbml0aW9uCj4gdGhlcmUuIE5vIG1hdHRlciB3aGF0IHNvbWUgdHJlYXRpbmcgb2Yg aXQgc3BlY2lhbGx5IHdpbGwgaGF2ZSB0byBoYXBwZW4KPiBpbiB0aGUgY29kZSBwcm9wZXIsIHRo ZSBpbnRlcm5hbCByZXByZXNlbnRhdGlvbiBvZiAoLT4pIGp1c3QgaXNuJ3QgYQo+IGRhdGEgY29u c3RydWN0b3IuIChhIC0+IGIpIGlzIGFjdHVhbGx5IHNob3J0aGFuZCBmb3IgptAoX6HLYSkuYgoK RWg/IEkndmUgbmV2ZXIgc2VlbiBhbnkgptBzIGluIEhzIGNvZGUuLi4gaW4gYW55IGNhc2UsIEkg d3JvdGUgdGhpczoKCmRhdGEgKC0+KSA6OiA/PyAtPiA/IC0+ICoKCndoaWNoIGhhcyB0aGUgcmln aHQga2luZC4gSWYgdGhlIGtpbmQgaW5mZXJlbmNlIGVuZ2luZSBjYW4ndCBoYW5kbGUKdGhpcywg dGhpcyBwcm9iYWJseSB3b24ndCBldmVyIHdvcmsgcmlnaHQuLi4K From john at repetae.net Mon Mar 17 18:53:34 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 18:50:21 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> <20080317224421.GD14807@sliver.repetae.net> Message-ID: <20080317225334.GE14807@sliver.repetae.net> On Mon, Mar 17, 2008 at 06:48:46PM -0400, Samuel Bronson wrote: > On 3/17/08, John Meacham wrote: > > Hrmm... that might not work so well. We actually need the kind > > overloaded sort for (->) and I wouldn't want an incorrect definition > > there. No matter what some treating of it specially will have to happen > > in the code proper, the internal representation of (->) just isn't a > > data constructor. (a -> b) is actually shorthand for ?(_?a).b > > Eh? I've never seen any ?s in Hs code... in any case, I wrote this: > > data (->) :: ?? -> ? -> * > > which has the right kind. If the kind inference engine can't handle > this, this probably won't ever work right... Oh, it can handle it internally, I just wasn't sure if the front end actually handled that declaration properly. but if it is.. then super. There is a built in declaration in 'DataConstructors.hs' for tc_Arrow you will likely have to take out. which is a good thing if this works. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 19:05:50 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 19:02:38 2008 Subject: [jhc] (->) not working too well... In-Reply-To: <20080317225334.GE14807@sliver.repetae.net> References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> <20080317224421.GD14807@sliver.repetae.net> <20080317225334.GE14807@sliver.repetae.net> Message-ID: T24gMy8xNy8wOCwgSm9obiBNZWFjaGFtIDxqb2huQHJlcGV0YWUubmV0PiB3cm90ZToKPiBPbiBN b24sIE1hciAxNywgMjAwOCBhdCAwNjo0ODo0NlBNIC0wNDAwLCBTYW11ZWwgQnJvbnNvbiB3cm90 ZToKPiA+IE9uIDMvMTcvMDgsIEpvaG4gTWVhY2hhbSA8am9obkByZXBldGFlLm5ldD4gd3JvdGU6 Cj4gPiA+IEhybW0uLi4gdGhhdCBtaWdodCBub3Qgd29yayBzbyB3ZWxsLiBXZSBhY3R1YWxseSBu ZWVkIHRoZSBraW5kCj4gPiA+IG92ZXJsb2FkZWQgc29ydCBmb3IgKC0+KSBhbmQgSSB3b3VsZG4n dCB3YW50IGFuIGluY29ycmVjdCBkZWZpbml0aW9uCj4gPiA+IHRoZXJlLiBObyBtYXR0ZXIgd2hh dCBzb21lIHRyZWF0aW5nIG9mIGl0IHNwZWNpYWxseSB3aWxsIGhhdmUgdG8gaGFwcGVuCj4gPiA+ IGluIHRoZSBjb2RlIHByb3BlciwgdGhlIGludGVybmFsIHJlcHJlc2VudGF0aW9uIG9mICgtPikg anVzdCBpc24ndCBhCj4gPiA+IGRhdGEgY29uc3RydWN0b3IuIChhIC0+IGIpIGlzIGFjdHVhbGx5 IHNob3J0aGFuZCBmb3IgptAoX6HLYSkuYgo+ID4KPiA+IEVoPyBJJ3ZlIG5ldmVyIHNlZW4gYW55 IKbQcyBpbiBIcyBjb2RlLi4uIGluIGFueSBjYXNlLCBJIHdyb3RlIHRoaXM6Cj4gPgo+ID4gZGF0 YSAoLT4pIDo6ID8/IC0+ID8gLT4gKgo+ID4KPiA+IHdoaWNoIGhhcyB0aGUgcmlnaHQga2luZC4g SWYgdGhlIGtpbmQgaW5mZXJlbmNlIGVuZ2luZSBjYW4ndCBoYW5kbGUKPiA+IHRoaXMsIHRoaXMg cHJvYmFibHkgd29uJ3QgZXZlciB3b3JrIHJpZ2h0Li4uCj4KPiBPaCwgaXQgY2FuIGhhbmRsZSBp dCBpbnRlcm5hbGx5LCBJIGp1c3Qgd2Fzbid0IHN1cmUgaWYgdGhlIGZyb250IGVuZAo+IGFjdHVh bGx5IGhhbmRsZWQgdGhhdCBkZWNsYXJhdGlvbiBwcm9wZXJseS4gYnV0IGlmIGl0IGlzLi4gdGhl biBzdXBlci4KPiBUaGVyZSBpcyBhIGJ1aWx0IGluIGRlY2xhcmF0aW9uIGluICdEYXRhQ29uc3Ry dWN0b3JzLmhzJyBmb3IgdGNfQXJyb3cKPiB5b3Ugd2lsbCBsaWtlbHkgaGF2ZSB0byB0YWtlIG91 dC4gd2hpY2ggaXMgYSBnb29kIHRoaW5nIGlmIHRoaXMgd29ya3MuCgpPZiBjb3Vyc2UgaXQgZGlk bid0ISBCdXQgdGhhdCdzIGVhc2llciB0aGFuIHVuZGVyc3RhbmRpbmcgYWxsIHRoaXMKa2luZCBz dHVmZiwgb3IgaW4gYW55IGNhc2UgdGhhbiBzcGVjaWFsLWNhc2luZy4K From john at repetae.net Mon Mar 17 19:10:08 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 19:06:55 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> <20080317224421.GD14807@sliver.repetae.net> <20080317225334.GE14807@sliver.repetae.net> Message-ID: <20080317231008.GF14807@sliver.repetae.net> On Mon, Mar 17, 2008 at 07:05:50PM -0400, Samuel Bronson wrote: > > Oh, it can handle it internally, I just wasn't sure if the front end > > actually handled that declaration properly. but if it is.. then super. > > There is a built in declaration in 'DataConstructors.hs' for tc_Arrow > > you will likely have to take out. which is a good thing if this works. > > Of course it didn't! But that's easier than understanding all this > kind stuff, or in any case than special-casing. Yes. certainly. I just hadn't realized I implemented that. (apparently not fully). but moving (->) to a real declaration is certainly the right thing to do. I have been slowly but surely eradicating all the special case code/predeclared stuff I can in jhc. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Mar 17 23:40:41 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 17 23:37:36 2008 Subject: [jhc] darcs patch: Remove duplicate case in kiType (and 1 more) Message-ID: Mon Mar 17 16:05:47 EDT 2008 Samuel Bronson * Remove duplicate case in kiType Mon Mar 17 23:34:31 EDT 2008 Samuel Bronson * Improve (->) situation somewhat Control.Arrow still won't quite work... something about Control.Arrow.172_a not getting a kind inferred... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 5312 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080317/b83f1152/attachment-0001.bin From naesten at gmail.com Tue Mar 18 18:09:22 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:06:07 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain Message-ID: I don't understand how FrontEnd.KindInfer.constrain is supposed to deal with KindSimple constraints... it doesn't seem to have any way of replacing ?? or ? with *. Why not? From john at repetae.net Tue Mar 18 18:32:21 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 18:29:04 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: Message-ID: <20080318223221.GH14807@sliver.repetae.net> On Tue, Mar 18, 2008 at 06:09:22PM -0400, Samuel Bronson wrote: > I don't understand how FrontEnd.KindInfer.constrain is supposed to > deal with KindSimple constraints... it doesn't seem to have any way of > replacing ?? or ? with *. Why not? that is done in the FrontEnd.Tc.Kind.kindCombine routine. The kind inference algorithm is based on the impredicative boxy type inferencer used as the main typechecker. this is because jhc is going to be a kind-polymorphic system, much like the Omega language (based on haskell). That and I find the impredicative boxy typechecking algorithm quite elegant. And when my moratorium on adding new features ends, I want to finish support for bang kinds. so, data List a = Cons a (List a) | Nil will actualy declary a type of List :: forall (k1::**) (k2::**) . \(a::k2) -> k1 (** is the supersort of boxed (but not necessarily lazy) values. this means you can have List * * - lazy list of lazy elements List ! * - strict list of lazy elements List * ! - lazy list of strict elements List ! ! - strict list of strict elements John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Mar 18 18:37:29 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:34:13 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080318223221.GH14807@sliver.repetae.net> References: <20080318223221.GH14807@sliver.repetae.net> Message-ID: On 3/18/08, John Meacham wrote: > On Tue, Mar 18, 2008 at 06:09:22PM -0400, Samuel Bronson wrote: > > I don't understand how FrontEnd.KindInfer.constrain is supposed to > > deal with KindSimple constraints... it doesn't seem to have any way of > > replacing ?? or ? with *. Why not? > > that is done in the FrontEnd.Tc.Kind.kindCombine routine. The kind > inference algorithm is based on the impredicative boxy type inferencer > used as the main typechecker. this is because jhc is going to be a > kind-polymorphic system, much like the Omega language (based on > haskell). That and I find the impredicative boxy typechecking algorithm > quite elegant. And when my moratorium on adding new features ends, I > want to finish support for bang kinds. so, > > data List a = Cons a (List a) | Nil > > will actualy declary a type of > > List :: forall (k1::**) (k2::**) . \(a::k2) -> k1 > > (** is the supersort of boxed (but not necessarily lazy) values. > > this means you can have > > List * * - lazy list of lazy elements > List ! * - strict list of lazy elements > List * ! - lazy list of strict elements > List ! ! - strict list of strict elements So what is KindInfer.constrain for, then? From naesten at gmail.com Tue Mar 18 18:48:36 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:45:21 2008 Subject: [jhc] darcs patch: Improve (->) situation somewhat (and 1 more) Message-ID: Mon Mar 17 23:34:31 EDT 2008 Samuel Bronson * Improve (->) situation somewhat Control.Arrow still won't quite work... something about Control.Arrow.172_a not getting a kind inferred... Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 6295 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080318/f8b4f087/attachment.bin From john at repetae.net Tue Mar 18 18:50:01 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 18:46:44 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318223221.GH14807@sliver.repetae.net> Message-ID: <20080318225001.GI14807@sliver.repetae.net> On Tue, Mar 18, 2008 at 06:37:29PM -0400, Samuel Bronson wrote: > On 3/18/08, John Meacham wrote: > > On Tue, Mar 18, 2008 at 06:09:22PM -0400, Samuel Bronson wrote: > > > I don't understand how FrontEnd.KindInfer.constrain is supposed to > > > deal with KindSimple constraints... it doesn't seem to have any way of > > > replacing ?? or ? with *. Why not? > > > > that is done in the FrontEnd.Tc.Kind.kindCombine routine. The kind > > inference algorithm is based on the impredicative boxy type inferencer > > used as the main typechecker. this is because jhc is going to be a > > kind-polymorphic system, much like the Omega language (based on > > haskell). That and I find the impredicative boxy typechecking algorithm > > quite elegant. And when my moratorium on adding new features ends, I > > want to finish support for bang kinds. so, > > > > data List a = Cons a (List a) | Nil > > > > will actualy declary a type of > > > > List :: forall (k1::**) (k2::**) . \(a::k2) -> k1 > > > > (** is the supersort of boxed (but not necessarily lazy) values. > > > > this means you can have > > > > List * * - lazy list of lazy elements > > List ! * - strict list of lazy elements > > List * ! - lazy list of strict elements > > List ! ! - strict list of strict elements > > So what is KindInfer.constrain for, then? 'constrain' refines a type subject to constraints, kindCombine actually returns what the unification of the kinds are. constrain works on constraints, combine works on kinds. constraints don't necessarily map to kinds, though currently most have an analog. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Mar 18 18:50:14 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:46:59 2008 Subject: [jhc] darcs patch: Improve (->) situation somewhat (and 1 more) In-Reply-To: References: Message-ID: On 3/18/08, Samuel Bronson wrote: > Mon Mar 17 23:34:31 EDT 2008 Samuel Bronson > * Improve (->) situation somewhat > Control.Arrow still won't quite work... something about Control.Arrow.172_a not getting a kind inferred... > > Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson > * Add Control.Monad.Instances to base package Note that the second patch serves as a nice regression test for the first ;-). From naesten at gmail.com Tue Mar 18 18:52:04 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:48:48 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080318225001.GI14807@sliver.repetae.net> References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> Message-ID: On 3/18/08, John Meacham wrote: > 'constrain' refines a type subject to constraints, kindCombine actually > returns what the unification of the kinds are. constrain works on > constraints, combine works on kinds. constraints don't necessarily map > to kinds, though currently most have an analog. Eh? Doesn't KindInfer run before typechecking begins? From naesten at gmail.com Tue Mar 18 19:00:56 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 18:57:41 2008 Subject: [jhc] darcs patch: Improve (->) situation somewhat (and 2 more) Message-ID: Mon Mar 17 23:34:31 EDT 2008 Samuel Bronson * Improve (->) situation somewhat Control.Arrow still won't quite work... something about Control.Arrow.172_a not getting a kind inferred... Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package Tue Mar 18 18:56:40 EDT 2008 Samuel Bronson * Add Control.Category -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7878 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080318/97c95704/attachment-0001.bin From john at repetae.net Tue Mar 18 19:01:12 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 18:57:55 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> Message-ID: <20080318230112.GJ14807@sliver.repetae.net> On Tue, Mar 18, 2008 at 06:52:04PM -0400, Samuel Bronson wrote: > On 3/18/08, John Meacham wrote: > > > 'constrain' refines a type subject to constraints, kindCombine actually > > returns what the unification of the kinds are. constrain works on > > constraints, combine works on kinds. constraints don't necessarily map > > to kinds, though currently most have an analog. > > Eh? Doesn't KindInfer run before typechecking begins? excuse me, I meant 'kind', not 'type'. this terminology is real trickylike... At least I made sure that jhc core's axioms allowed a stratified type system so 'term','type','kind','superkind' all are distinct sets and have no cyclic dependencies... though, I am not sure if there are practical languages where that is not the case.. though wacky type systems are fun to play with. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Mar 18 19:06:25 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 19:03:09 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080318230112.GJ14807@sliver.repetae.net> References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> Message-ID: On 3/18/08, John Meacham wrote: > On Tue, Mar 18, 2008 at 06:52:04PM -0400, Samuel Bronson wrote: > > On 3/18/08, John Meacham wrote: > > > > > 'constrain' refines a type subject to constraints, kindCombine actually > > > returns what the unification of the kinds are. constrain works on > > > constraints, combine works on kinds. constraints don't necessarily map > > > to kinds, though currently most have an analog. > > > > Eh? Doesn't KindInfer run before typechecking begins? > > excuse me, I meant 'kind', not 'type'. this terminology is real > trickylike... At least I made sure that jhc core's axioms allowed a > stratified type system so 'term','type','kind','superkind' all are > distinct sets and have no cyclic dependencies... though, I am not sure > if there are practical languages where that is not the case.. though > wacky type systems are fun to play with. Well, it seems like constrain doesn't really have any choice but to throw an error when asked to constrain a KBase KQuest with a KindSimple constraint... it has no way of indicating that the result should be a KBase KStar! From naesten at gmail.com Tue Mar 18 22:48:20 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 22:45:04 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 4 more) Message-ID: This patch bundle consists of Control.Arrow along with the modules it depends upon. Control.Arrow does not compile even with the (->) improvement patch I previously sent to the list; I believe this to be due to problems in kind inference. Could you look at the error, John? (Recall that this should all work in *standard* haskell, and so helping will not be a violation of the moratorium on extensions.) Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package Tue Mar 18 18:56:40 EDT 2008 Samuel Bronson * Add Control.Category Tue Mar 18 21:37:59 EDT 2008 Samuel Bronson * Add Control.Arrow Tue Mar 18 21:38:54 EDT 2008 Samuel Bronson * Add Control.Monad.Fix Tue Mar 18 21:43:36 EDT 2008 Samuel Bronson * Add Data.Function -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 20588 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080318/b36c4556/attachment.bin From john at repetae.net Tue Mar 18 23:06:25 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 23:03:09 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 4 more) In-Reply-To: References: Message-ID: <20080319030625.GL14807@sliver.repetae.net> Hi, could you re-record all of your patches dealing with getting instances of function to work as a single patch with the finished result? (just the jhc changes, not the library ones) Also, if you arn't already, running the regression suite between every change to the type system is good. (perl regress/regress.prl) will do that. That suite really needs to be fleshed out actually, I will probably add some of the more problematic nobench programs to it. Is the arrows package available seperately from ghc? if so, I would rather have it be a separate library and not in 'base' for jhc.. perhaps we should do something like we do for the haskell98 package, have the user pull down that darcs repo and just include appropriate 'cabal' files in the jhc repo, that might be a better long term solution. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Mar 18 23:08:06 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 23:04:49 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 4 more) In-Reply-To: References: Message-ID: <20080319030806.GM14807@sliver.repetae.net> And thanks for all the contributions! :) jhc development is picking up. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Mar 18 23:22:47 2008 From: naesten at gmail.com (Samuel Bronson) Date: Tue Mar 18 23:19:30 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 4 more) In-Reply-To: <20080319030625.GL14807@sliver.repetae.net> References: <20080319030625.GL14807@sliver.repetae.net> Message-ID: On Tue, Mar 18, 2008 at 10:06 PM, John Meacham wrote: > Hi, could you re-record all of your patches dealing with getting > instances of function to work as a single patch with the finished > result? (just the jhc changes, not the library ones) I sent multiple patches about (->)? I was pretty sure I had just sent the one... that one that removes a case from that ki function was purely cosmetic. > Also, if you arn't already, running the regression suite between every > change to the type system is good. (perl regress/regress.prl) will do > that. That suite really needs to be fleshed out actually, I will probably > add some of the more problematic nobench programs to it. Okay. > Is the arrows package available seperately from ghc? if so, I would > rather have it be a separate library and not in 'base' for jhc.. perhaps > we should do something like we do for the haskell98 package, have the > user pull down that darcs repo and just include appropriate 'cabal' > files in the jhc repo, that might be a better long term solution. Er, well, there is an arrow[s] package, but Control.Arrow is apparantly in base, along with all of those others. I suppose we could stick it in some other package for JHC's purposes. Really, I just want to be able to compile the collections package... because then I can instantiate Set as a (bounded below) lattice in my test code for class aliases ;-). From lemmih at gmail.com Wed Mar 19 11:49:06 2008 From: lemmih at gmail.com (Lemmih) Date: Wed Mar 19 11:45:46 2008 Subject: [jhc] darcs patch: Be less noisy when not in verbose mode. (and 2 more) Message-ID: <47e135ee.0589300a.04dc.1b8e@mx.google.com> Wed Mar 19 16:44:04 CET 2008 Lemmih * Be less noisy when not in verbose mode. Wed Mar 19 16:46:02 CET 2008 Lemmih * Print '[ X of N ] name' for each module. Wed Mar 19 16:48:48 CET 2008 Lemmih * Layout wibble. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7742 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080319/c0bd7689/attachment.bin From naesten at gmail.com Wed Mar 19 18:21:45 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 19 18:18:27 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> Message-ID: On 3/18/08, Samuel Bronson wrote: > On 3/18/08, John Meacham wrote: > > On Tue, Mar 18, 2008 at 06:52:04PM -0400, Samuel Bronson wrote: > > > On 3/18/08, John Meacham wrote: > > > > > > > 'constrain' refines a type subject to constraints, kindCombine actually > > > > returns what the unification of the kinds are. constrain works on > > > > constraints, combine works on kinds. constraints don't necessarily map > > > > to kinds, though currently most have an analog. > > > > > > Eh? Doesn't KindInfer run before typechecking begins? > > > > excuse me, I meant 'kind', not 'type'. this terminology is real > > trickylike... At least I made sure that jhc core's axioms allowed a > > stratified type system so 'term','type','kind','superkind' all are > > distinct sets and have no cyclic dependencies... though, I am not sure > > if there are practical languages where that is not the case.. though > > wacky type systems are fun to play with. > > Well, it seems like constrain doesn't really have any choice but to > throw an error when asked to constrain a KBase KQuest with a > KindSimple constraint... it has no way of indicating that the result > should be a KBase KStar! I was hoping you might have something to say about this? From john at repetae.net Wed Mar 19 18:48:30 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 19 18:45:11 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> Message-ID: <20080319224830.GA27335@sliver.repetae.net> On Wed, Mar 19, 2008 at 06:21:45PM -0400, Samuel Bronson wrote: > On 3/18/08, Samuel Bronson wrote: > > On 3/18/08, John Meacham wrote: > > > On Tue, Mar 18, 2008 at 06:52:04PM -0400, Samuel Bronson wrote: > > > > On 3/18/08, John Meacham wrote: > > > > > > > > > 'constrain' refines a type subject to constraints, kindCombine actually > > > > > returns what the unification of the kinds are. constrain works on > > > > > constraints, combine works on kinds. constraints don't necessarily map > > > > > to kinds, though currently most have an analog. > > > > > > > > Eh? Doesn't KindInfer run before typechecking begins? > > > > > > excuse me, I meant 'kind', not 'type'. this terminology is real > > > trickylike... At least I made sure that jhc core's axioms allowed a > > > stratified type system so 'term','type','kind','superkind' all are > > > distinct sets and have no cyclic dependencies... though, I am not sure > > > if there are practical languages where that is not the case.. though > > > wacky type systems are fun to play with. > > > > Well, it seems like constrain doesn't really have any choice but to > > throw an error when asked to constrain a KBase KQuest with a > > KindSimple constraint... it has no way of indicating that the result > > should be a KBase KStar! > > I was hoping you might have something to say about this? Ah, sorry. I was mulling it over. Basically, it has to do with the issue that '?' and '??' are not real kinds. they are just shorthand for kind abstractions. when you say: data App :: ?? -> ? -> * you actually mean: (in psuedo-haskell) data App :: forall (k1 | k1 `elem` [*,#]) (k2 | k2 `elem` [*,#,(#)]) . k1 -> k2 -> * the constraints are what is to the right of the |'s there. (I could also do this with superkinds, though I think constrained polymorphism is the way to go here.). so, ? should not actually be a kind of type '?' but actually a newly instantiated kind variable with a KindQuest constraint on it. This instantiation should be done whenever we pull something out of the kind environment. However, since full kind polymorphism isn't availibe in the front end, we use ? and ?? as placeholders in our code as well as data structures. they actually behave the same as if they had been declared: kindsynonym ?? = exists k | k `elem` [*,#] . k Right now, for compatability with haskell 98 and because I would need to modify some data structures to handle it, we perform a 'defaulting', defaulting all kindvars to * at the end of inference. we could just as easily perform a generalization there and get true kind polymorphism. (and this will be done eventually) note that type synonyms are already kind polymorphic: type UIO a = World__ -> (# World__, a #) 'UIO Int' and 'UIO Bits32_' are both fine. UIO :: forall k . k -> * (actually, to be fully formal, UIO has superkind polymorhism, but that is irrelevant since type synonyms don't make it to jhc core, jhc can handle that fine, but I think I will wait until 'kind level' programming becomes popular before crossing that bridge :) ) so. to answer the question of why that case dealing with KQuest isn't in constrain, it is either because 1. I forgot it, it actually should be there. or 2. an actual '?' or '??' is sneaking in as a kind when it should have been turned into a freshly instantiated kind variable with a ? or ?? constraint as appropriate. as an aside, it is interesting to note that methodless type classes give a sort of constrained polymorphism at the type level, I am not sure the signifigance exactly of this, but it might lead to a more elegant handling of kinds in the future... uncharted waters. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 19 18:55:29 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 19 18:52:10 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080319224830.GA27335@sliver.repetae.net> References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> Message-ID: On 3/19/08, John Meacham wrote: > > > Well, it seems like constrain doesn't really have any choice but to > > > throw an error when asked to constrain a KBase KQuest with a > > > KindSimple constraint... it has no way of indicating that the result > > > should be a KBase KStar! > > > > I was hoping you might have something to say about this? > > Ah, sorry. I was mulling it over. Basically, it has to do with the issue > that '?' and '??' are not real kinds. they are just shorthand for kind > abstractions. > > when you say: > data App :: ?? -> ? -> * > > you actually mean: > > (in psuedo-haskell) > > data App :: > forall (k1 | k1 `elem` [*,#]) (k2 | k2 `elem` [*,#,(#)]) . k1 -> k2 -> * > > the constraints are what is to the right of the |'s there. (I could also > do this with superkinds, though I think constrained polymorphism is the > way to go here.). > > so, ? should not actually be a kind of type '?' but actually a newly > instantiated kind variable with a KindQuest constraint on it. This > instantiation should be done whenever we pull something out of the kind > environment. > > However, since full kind polymorphism isn't availibe in the front end, > we use ? and ?? as placeholders in our code as well as data structures. > > they actually behave the same as if they had been declared: > > kindsynonym ?? = exists k | k `elem` [*,#] . k > > > Right now, for compatability with haskell 98 and because I would need to > modify some data structures to handle it, we perform a 'defaulting', > defaulting all kindvars to * at the end of inference. we could just as > easily perform a generalization there and get true kind polymorphism. > (and this will be done eventually) > > note that type synonyms are already kind polymorphic: > > type UIO a = World__ -> (# World__, a #) > > 'UIO Int' and 'UIO Bits32_' are both fine. > > UIO :: forall k . k -> * > > (actually, to be fully formal, UIO has superkind polymorhism, but that > is irrelevant since type synonyms don't make it to jhc core, jhc can > handle that fine, but I think I will wait until 'kind level' programming > becomes popular before crossing that bridge :) ) > > > so. to answer the question of why that case dealing with KQuest isn't in > constrain, it is either because > > 1. I forgot it, it actually should be there. > > or > > 2. an actual '?' or '??' is sneaking in as a kind when it should have > been turned into a freshly instantiated kind variable with a ? or ?? > constraint as appropriate. Where is this process supposed to happen? I didn't see anything that looked like that in KindInfer, and I don't think it could be anywhere else, since the monad it would need to work in is only available in that module... > as an aside, it is interesting to note that methodless type classes give > a sort of constrained polymorphism at the type level, I am not sure the > signifigance exactly of this, but it might lead to a more elegant > handling of kinds in the future... uncharted waters. From john at repetae.net Wed Mar 19 19:09:56 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 19 19:06:36 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318223221.GH14807@sliver.repetae.net> <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> Message-ID: <20080319230956.GB27335@sliver.repetae.net> On Wed, Mar 19, 2008 at 06:55:29PM -0400, Samuel Bronson wrote: > > 2. an actual '?' or '??' is sneaking in as a kind when it should have > > been turned into a freshly instantiated kind variable with a ? or ?? > > constraint as appropriate. > > Where is this process supposed to happen? I didn't see anything that > looked like that in KindInfer, and I don't think it could be anywhere > else, since the monad it would need to work in is only available in > that module... Well, that's the thing, I never implemented users being able to use '?' and '??' directly, so I never needed to implement it for user defined kinds. where it currently happens is in KindInfer in all the calls to 'newKindVar' in kiType. notice that when you have an unboxed tuple for instance, its subkinds are declared with ?? constraints. likewise for a function call and so forth. so what needs to happen for user defined ones to work is for 'lookupKind' to create a freshly instantiated version of the constructor with no literal ? or ??'s in it, just constrained kindvars. note that this brings up intruging possibilities. like data Complex (a :: ??) = a :+: a notice you can now have data structures with polymorphic unboxed values in them! so your complex Float can actually have two unboxed floats next to each other. but this raises several other issues when it comes to actaully generating code for that. note also that the primitive pre-defined tArrow in DataConstructors has the wrong type. this is a known bug but the current workarounds are okay for now and it will be a fairly complicated one to fix. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 19 19:16:16 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 19 19:12:57 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080319230956.GB27335@sliver.repetae.net> References: <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> <20080319230956.GB27335@sliver.repetae.net> Message-ID: On 3/19/08, John Meacham wrote: > On Wed, Mar 19, 2008 at 06:55:29PM -0400, Samuel Bronson wrote: > > > 2. an actual '?' or '??' is sneaking in as a kind when it should have > > > been turned into a freshly instantiated kind variable with a ? or ?? > > > constraint as appropriate. > > > > Where is this process supposed to happen? I didn't see anything that > > looked like that in KindInfer, and I don't think it could be anywhere > > else, since the monad it would need to work in is only available in > > that module... > > Well, that's the thing, I never implemented users being able to use '?' > and '??' directly, so I never needed to implement it for user defined > kinds. Well, what are the KBase constructors for, then? "Future proofing" is clearly not a very good answer... > where it currently happens is in KindInfer in all the calls to > 'newKindVar' in kiType. notice that when you have an unboxed tuple for > instance, its subkinds are declared with ?? constraints. likewise for a > function call and so forth. > > so what needs to happen for user defined ones to work is for > 'lookupKind' to create a freshly instantiated version of the constructor > with no literal ? or ??'s in it, just constrained kindvars. > > note that this brings up intruging possibilities. like > > data Complex (a :: ??) = a :+: a > > notice you can now have data structures with polymorphic unboxed values > in them! so your complex Float can actually have two unboxed floats next > to each other. but this raises several other issues when it comes to > actaully generating code for that. > > note also that the primitive pre-defined tArrow in DataConstructors has > the wrong type. this is a known bug but the current workarounds are okay > for now and it will be a fairly complicated one to fix. > > John > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > jhc mailing list > jhc@haskell.org > http://www.haskell.org/mailman/listinfo/jhc > From john at repetae.net Wed Mar 19 19:32:30 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 19 19:29:11 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> <20080319230956.GB27335@sliver.repetae.net> Message-ID: <20080319233230.GC27335@sliver.repetae.net> On Wed, Mar 19, 2008 at 07:16:16PM -0400, Samuel Bronson wrote: > On 3/19/08, John Meacham wrote: > > On Wed, Mar 19, 2008 at 06:55:29PM -0400, Samuel Bronson wrote: > > > > 2. an actual '?' or '??' is sneaking in as a kind when it should have > > > > been turned into a freshly instantiated kind variable with a ? or ?? > > > > constraint as appropriate. > > > > > > Where is this process supposed to happen? I didn't see anything that > > > looked like that in KindInfer, and I don't think it could be anywhere > > > else, since the monad it would need to work in is only available in > > > that module... > > > > Well, that's the thing, I never implemented users being able to use '?' > > and '??' directly, so I never needed to implement it for user defined > > kinds. > > Well, what are the KBase constructors for, then? "Future proofing" is > clearly not a very good answer... Oh, it is a direct analogy to a 'type scheme' in the type level typechecker. A kind can be either a 'kind' or a 'kind scheme' a 'kind scheme' is something you must instantiate to get a 'kind', just like 'forall a . a -> a' is not a type[1], but rather a type scheme. an actual type it can be instantiated to would be 'Int -> Int' or 'v1 -> v1' (where v1 is a type variable). now, I could extend the 'Kind' type to actually have the full quantification, but since the polymorphism allowed is always of a specific variety, it is easier and more straightforward to just have KQuest and KQuestQuest as placeholders. and Future Proofing is always a good answer, assuming one can back it up, full kind polymorphism is an eventual goal and the kind inference algorithm and terminology used was written with that in mind. oddly enough it leads to a much cleaner implementation than the THIH implementation as a side effect... oh, also note that for all _infered_ kinds, due to defaulting, the kind scheme and the kind will be identical, but the distinction is quite important. [1]. we are ignoring rank 2 polymorphism for now, it doesn't complicate things really from an algorithmic point of view, but it would complicate the discussion and isn't relevant to kinds anyway. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 19 19:37:55 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 19 19:34:36 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: <20080319233230.GC27335@sliver.repetae.net> References: <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> <20080319230956.GB27335@sliver.repetae.net> <20080319233230.GC27335@sliver.repetae.net> Message-ID: On 3/19/08, John Meacham wrote: > On Wed, Mar 19, 2008 at 07:16:16PM -0400, Samuel Bronson wrote: > > On 3/19/08, John Meacham wrote: > > > On Wed, Mar 19, 2008 at 06:55:29PM -0400, Samuel Bronson wrote: > > > > > 2. an actual '?' or '??' is sneaking in as a kind when it should have > > > > > been turned into a freshly instantiated kind variable with a ? or ?? > > > > > constraint as appropriate. > > > > > > > > Where is this process supposed to happen? I didn't see anything that > > > > looked like that in KindInfer, and I don't think it could be anywhere > > > > else, since the monad it would need to work in is only available in > > > > that module... > > > > > > Well, that's the thing, I never implemented users being able to use '?' > > > and '??' directly, so I never needed to implement it for user defined > > > kinds. > > > > Well, what are the KBase constructors for, then? "Future proofing" is > > clearly not a very good answer... > > Oh, it is a direct analogy to a 'type scheme' in the type level > typechecker. A kind can be either a 'kind' or a 'kind scheme' a 'kind > scheme' is something you must instantiate to get a 'kind', just like > 'forall a . a -> a' is not a type[1], but rather a type scheme. an > actual type it can be instantiated to would be 'Int -> Int' or 'v1 -> > v1' (where v1 is a type variable). > > now, I could extend the 'Kind' type to actually have the full > quantification, but since the polymorphism allowed is always of a > specific variety, it is easier and more straightforward to just have > KQuest and KQuestQuest as placeholders. > > and Future Proofing is always a good answer, assuming one can back it > up, full kind polymorphism is an eventual goal and the kind inference > algorithm and terminology used was written with that in mind. oddly > enough it leads to a much cleaner implementation than the THIH > implementation as a side effect... It's only a good answer if the code actually works... dead code doesn't get much testing, generally... > oh, also note that for all _infered_ kinds, due to defaulting, the kind > scheme and the kind will be identical, but the distinction is quite > important. > > [1]. we are ignoring rank 2 polymorphism for now, it doesn't complicate > things really from an algorithmic point of view, but it would complicate > the discussion and isn't relevant to kinds anyway. From john at repetae.net Wed Mar 19 19:41:25 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 19 19:38:05 2008 Subject: [jhc] jhc type inference algorithm In-Reply-To: <20080319233230.GC27335@sliver.repetae.net> References: <20080318225001.GI14807@sliver.repetae.net> <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> <20080319230956.GB27335@sliver.repetae.net> <20080319233230.GC27335@sliver.repetae.net> Message-ID: <20080319234125.GD27335@sliver.repetae.net> Oh, this might be useful: http://research.microsoft.com/~simonpj/papers/boxy/ Originally jhc's type and kind inference algorithm was based on the one from the 'typing haskell in haskell' paper. Now they are both brand new implementations based on SPJ's boxy type inference algorithm explained in the above paper. Among other advantages, this gives me existentials, rank-n polymorphism, better error messages, and polymorphic unboxed values[1]. I also find it more elegant and is a few thousand less lines of code. [1]. A jhc exclusive! John -- John Meacham - ?repetae.net?john? From john at repetae.net Wed Mar 19 20:04:59 2008 From: john at repetae.net (John Meacham) Date: Wed Mar 19 20:01:38 2008 Subject: [jhc] explanation of FrontEnd.KindInfer.constrain In-Reply-To: References: <20080318230112.GJ14807@sliver.repetae.net> <20080319224830.GA27335@sliver.repetae.net> <20080319230956.GB27335@sliver.repetae.net> <20080319233230.GC27335@sliver.repetae.net> Message-ID: <20080320000459.GE27335@sliver.repetae.net> On Wed, Mar 19, 2008 at 07:37:55PM -0400, Samuel Bronson wrote: > > and Future Proofing is always a good answer, assuming one can back it > > up, full kind polymorphism is an eventual goal and the kind inference > > algorithm and terminology used was written with that in mind. oddly > > enough it leads to a much cleaner implementation than the THIH > > implementation as a side effect... > > It's only a good answer if the code actually works... dead code > doesn't get much testing, generally... Hrm? I am not sure what you mean. I knew I needed a constrained polymorphic inference algorithm so thats what I wrote. The difference between kind schemes and kinds may not have been obvious because ghc uses a similar (but distinct algorithmically) subtyping algorithm. you might as well complain about someone writing fst3 (x,_,_) = x without explicitly saying fst3 :: (Int,Char,Foo) -> Int because that happens to be the way it is used. one of the most beautiful things about haskell is that the general solution is almost always _easier_ than just solving a specific problem. you gotta work harder to constraint 'fst3', and having to throw away my kindchecker just because I introduced kind schemes would have been a whole lot more work (especially since I knew I was going to introduce them). jhc couldn't exist if I didn't think about the future of every bit of code I write. Luckily, haskell is such a great language, it's hard to write code that isn't future safe, but I'm not gonna go out of my way to work myself into a corner. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Mar 19 23:30:48 2008 From: naesten at gmail.com (Samuel Bronson) Date: Wed Mar 19 23:27:29 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 4 more) In-Reply-To: References: Message-ID: On 3/18/08, Samuel Bronson wrote: > This patch bundle consists of Control.Arrow along with the modules it > depends upon. Control.Arrow does not compile even with the (->) > improvement patch I previously sent to the list; I believe this to be > due to problems in kind inference. Could you look at the error, John? > (Recall that this should all work in *standard* haskell, and so > helping will not be a violation of the moratorium on extensions.) It really looks like kind inference isn't paying any attention to instance headers... (nevermind that instance declarations are gone by this point ;-). From naesten at gmail.com Thu Mar 20 00:42:06 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 20 00:38:46 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 2 more) Message-ID: Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package Tue Mar 18 18:56:40 EDT 2008 Samuel Bronson * Add Control.Category Thu Mar 20 00:37:16 EDT 2008 Samuel Bronson * ArrowMonad test Ooh, so close... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 10073 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080320/bb8677dc/attachment-0001.bin From naesten at gmail.com Thu Mar 20 00:42:28 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 20 00:39:08 2008 Subject: [jhc] darcs patch: Add -dsquare-stats option for terminals with poor char... Message-ID: Wed Mar 19 23:48:32 EDT 2008 Samuel Bronson * Add -dsquare-stats option for terminals with poor character coverage -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 4982 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080320/83cb873a/attachment.bin From naesten at gmail.com Thu Mar 20 11:54:48 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 20 11:51:29 2008 Subject: [jhc] darcs patch: Add Control.Monad.Instances to base package (and 2 more) Message-ID: Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package Tue Mar 18 18:56:40 EDT 2008 Samuel Bronson * Add Control.Category Thu Mar 20 08:55:01 EDT 2008 Samuel Bronson * ArrowMonad test -- valid this time oops, I left out this change in the previous version... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 10266 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080320/e79485a2/attachment.bin From lemmih at gmail.com Thu Mar 20 13:13:48 2008 From: lemmih at gmail.com (Lemmih) Date: Thu Mar 20 13:10:26 2008 Subject: [jhc] Loops. Message-ID: Hiya, x :: IO () -- This type signature works fine, <> is printed x :: a -- This type signature blows the stack of jhc x = x main = x Is this a known bug? -- Cheers, Lemmih From john at repetae.net Thu Mar 20 13:39:30 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 20 13:36:08 2008 Subject: [jhc] Loops. In-Reply-To: References: Message-ID: <20080320173930.GF27335@sliver.repetae.net> On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote: > x :: IO () -- This type signature works fine, <> is printed > x :: a -- This type signature blows the stack of jhc > x = x > main = x > > Is this a known bug? Well, it's not really a bug as all detection of loops is a bonus, if the optimizer comes across something of exactly 'x = x' it will replace it with error "<>" but not all loops optimize to that form. x :: forall a . a x = x turns into x :: (a::*) -> a x a = x a in core, so it is not recognized as a loop. I doubt it will be much of a problem in practice, and eta reduction is an anti-optimization in general. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Thu Mar 20 13:51:20 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 20 13:47:57 2008 Subject: [jhc] Loops. In-Reply-To: <20080320173930.GF27335@sliver.repetae.net> References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: On 3/20/08, John Meacham wrote: > x :: (a::*) -> a > x a = x a > > in core, so it is not recognized as a loop. I doubt it will be much of a > problem in practice, and eta reduction is an anti-optimization in > general. Why isn't that recognized as a loop? Isn't it typically beneficial in the body of a function to replace calls like that with the return value? For example: fix :: (a -> a) -> a fix f = f (fix f) From lemmih at gmail.com Thu Mar 20 14:06:55 2008 From: lemmih at gmail.com (Lemmih) Date: Thu Mar 20 14:03:32 2008 Subject: [jhc] Loops. In-Reply-To: <20080320173930.GF27335@sliver.repetae.net> References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote: > On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote: > > x :: IO () -- This type signature works fine, <> is printed > > x :: a -- This type signature blows the stack of jhc > > x = x > > main = x > > > > Is this a known bug? > > Well, it's not really a bug as all detection of loops is a bonus, if the > optimizer comes across something of exactly 'x = x' it will replace it > with error "<>" but not all loops optimize to that form. Blowing the stack is not a bug? -- Cheers, Lemmih From lemmih at gmail.com Thu Mar 20 14:16:20 2008 From: lemmih at gmail.com (Lemmih) Date: Thu Mar 20 14:12:59 2008 Subject: [jhc] Loops. In-Reply-To: References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: On Thu, Mar 20, 2008 at 7:06 PM, Lemmih wrote: > On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote: > > On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote: > > > x :: IO () -- This type signature works fine, <> is printed > > > x :: a -- This type signature blows the stack of jhc > > > x = x > > > main = x > > > > > > Is this a known bug? > > > > Well, it's not really a bug as all detection of loops is a bonus, if the > > optimizer comes across something of exactly 'x = x' it will replace it > > with error "<>" but not all loops optimize to that form. > > Blowing the stack is not a bug? Sorry, I see that I wasn't clear. It blows the stack of jhc when compiling the program. -- Cheers, Lemmih From john at repetae.net Thu Mar 20 14:17:29 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 20 14:14:06 2008 Subject: [jhc] Loops. In-Reply-To: References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: <20080320181729.GG27335@sliver.repetae.net> On Thu, Mar 20, 2008 at 07:06:55PM +0100, Lemmih wrote: > On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote: > > On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote: > > > x :: IO () -- This type signature works fine, <> is printed > > > x :: a -- This type signature blows the stack of jhc > > > x = x > > > main = x > > > > > > Is this a known bug? > > > > Well, it's not really a bug as all detection of loops is a bonus, if the > > optimizer comes across something of exactly 'x = x' it will replace it > > with error "<>" but not all loops optimize to that form. > > Blowing the stack is not a bug? Ah! are you saying 'jhc' blows its stack or the compiled program does? sorry, I misunderstood. yeah, that is a bug then. I have actually run into a few programs that blow stack, perhaps this is the cause. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Thu Mar 20 16:03:41 2008 From: naesten at gmail.com (Samuel Bronson) Date: Thu Mar 20 16:00:19 2008 Subject: [jhc] darcs patch: Oops... left out one of the most important parts of -d... Message-ID: Thu Mar 20 15:21:34 EDT 2008 Samuel Bronson * Oops... left out one of the most important parts of -dsquare-stats -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 5108 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080320/d4662519/attachment.bin From john at repetae.net Thu Mar 20 18:29:46 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 20 18:26:23 2008 Subject: [jhc] Loops. In-Reply-To: References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: <20080320222945.GA4245@sliver.repetae.net> On Thu, Mar 20, 2008 at 07:16:20PM +0100, Lemmih wrote: > > Blowing the stack is not a bug? > > Sorry, I see that I wasn't clear. It blows the stack of jhc when > compiling the program. Ah. Do you have any good way of tracking down this sort of error BTW? I hear there is a new ghci debugger, but it didn't seem to help when I tried it but perhaps others have more debug-foo. There are also some programs (chess from nobench is one I think) that just lock up in an infinite loop somewhere in optimization that I have not been able to track down. John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Mar 20 18:44:01 2008 From: john at repetae.net (John Meacham) Date: Thu Mar 20 18:40:38 2008 Subject: [jhc] Loops. In-Reply-To: References: <20080320173930.GF27335@sliver.repetae.net> Message-ID: <20080320224400.GB4245@sliver.repetae.net> On Thu, Mar 20, 2008 at 12:51:20PM -0500, Samuel Bronson wrote: > On 3/20/08, John Meacham wrote: > > in core, so it is not recognized as a loop. I doubt it will be much of a > > problem in practice, and eta reduction is an anti-optimization in > > general. > > Why isn't that recognized as a loop? Isn't it typically beneficial in > the body of a function to replace calls like that with the return > value? For example: > > fix :: (a -> a) -> a > fix f = f (fix f) Oh, it is recognized as recursive*, but not as an infinite loop. When the jhc optimizer comes across something it knows is equivalent to bottom, it replaces it with 'error "<>"'. ghc does the same thing. it is this replacement that jhc wasn't doing, which is okay since the replacement is really just an optimization jhc will take advantage of when it can find, but doesn't look to hard for. (though, other optimizations likely expose more 'manifest loops'. * though the fact jhc is blowing stack means that perhaps there is a bug whereby it isn't being recognized as recursive. -- John Meacham - ?repetae.net?john? From naesten at gmail.com Fri Mar 21 00:46:24 2008 From: naesten at gmail.com (Samuel Bronson) Date: Fri Mar 21 00:43:06 2008 Subject: [jhc] darcs patch: Fix spelling of constrain in FrontEnd.Ki... (and 16 more) Message-ID: This is just a dump of all of the patches in my tree at the moment, since I'm leaving tomorrow for easter... Tue Mar 18 14:18:41 EDT 2008 Samuel Bronson * Fix spelling of constrain in FrontEnd.KindInfer error message Tue Mar 18 18:43:45 EDT 2008 Samuel Bronson * Add Control.Monad.Instances to base package Tue Mar 18 18:56:40 EDT 2008 Samuel Bronson * Add Control.Category Tue Mar 18 21:37:59 EDT 2008 Samuel Bronson * Add Control.Arrow Tue Mar 18 21:38:54 EDT 2008 Samuel Bronson * Add Control.Monad.Fix Tue Mar 18 21:43:36 EDT 2008 Samuel Bronson * Add Data.Function Thu Mar 20 08:55:01 EDT 2008 Samuel Bronson * ArrowMonad test -- valid this time oops, I left out this change in the previous version... Thu Mar 20 12:01:16 EDT 2008 Samuel Bronson * get Data.Typeable working Thu Mar 20 14:30:39 EDT 2008 Samuel Bronson * Improve (->) situation somewhat Thu Mar 20 15:21:34 EDT 2008 Samuel Bronson * Oops... left out one of the most important parts of -dsquare-stats Thu Mar 20 15:32:51 EDT 2008 Samuel Bronson * Infer kinds based on predicates *before* looking at the type Thu Mar 20 16:42:02 EDT 2008 Samuel Bronson * Actually define (->)... Thu Mar 20 17:09:09 EDT 2008 Samuel Bronson * Nicer error handling for Ki monad Thu Mar 20 17:09:45 EDT 2008 Samuel Bronson * Debugging stuff in KindInfer Thu Mar 20 17:13:05 EDT 2008 Samuel Bronson * Swap another mapM_ kiPred about Thu Mar 20 17:33:26 EDT 2008 Samuel Bronson * Make Control.Category actually not import Prelude... Fri Mar 21 00:29:22 EDT 2008 Samuel Bronson * Split TArrows where appropriate -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 33383 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080321/1b9abe5d/attachment-0001.bin From isaacdupree at charter.net Fri Mar 28 10:15:28 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Mar 28 10:11:42 2008 Subject: [jhc] (->) not working too well... In-Reply-To: References: <20080317150331.GD5971@sliver.repetae.net> <20080317220135.GC14807@sliver.repetae.net> <20080317224421.GD14807@sliver.repetae.net> Message-ID: <47ECFD80.7060806@charter.net> Samuel Bronson wrote: > Eh? I've never seen any ?s in Hs code... in any case, I wrote this: > > data (->) :: ?? -> ? -> * isn't it (->) :: ? -> ?? -> * ? The result, not the argument, can be unboxed tuple > which has the right kind. If the kind inference engine can't handle > this, this probably won't ever work right... (agreed that the kind inference ought to handle this) -Isaac From naesten at gmail.com Sun Mar 30 00:56:14 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 30 00:52:24 2008 Subject: [jhc] darcs patch: Allow irrefutable patterns in lambdas + regression test Message-ID: Sun Mar 30 00:33:58 EDT 2008 Samuel Bronson * Allow irrefutable patterns in lambdas + regression test -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7184 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080330/db19f8ba/attachment.bin From naesten at gmail.com Sun Mar 30 15:09:06 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 30 15:05:21 2008 Subject: [jhc] darcs patch: Oops... left out one of the most important parts of -d... Message-ID: Thu Mar 20 15:21:34 EDT 2008 Samuel Bronson * Oops... left out one of the most important parts of -dsquare-stats -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7311 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080330/98820be5/attachment.bin From naesten at gmail.com Sun Mar 30 17:08:13 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 30 17:04:19 2008 Subject: [jhc] darcs patch: Change base.cabal to reflect Jhc.IOARray -> Data.Array... Message-ID: Sun Mar 30 16:03:03 EDT 2008 Samuel Bronson * Change base.cabal to reflect Jhc.IOARray -> Data.Array.IO move -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 6999 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080330/c1d5b8c5/attachment-0001.bin From naesten at gmail.com Sun Mar 30 22:03:37 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 30 21:59:52 2008 Subject: [jhc] darcs patch: Fix kind inference + test Message-ID: Sun Mar 30 19:43:26 EDT 2008 Samuel Bronson * Fix kind inference + test Also, comment out the case in kindOf that makes things look fine when they aren't -- unless of course * isn't the right kind -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 9852 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080330/3da96301/attachment.bin From naesten at gmail.com Sun Mar 30 22:27:05 2008 From: naesten at gmail.com (Samuel Bronson) Date: Sun Mar 30 22:23:10 2008 Subject: [jhc] darcs patch: Fix kind inference + test In-Reply-To: References: Message-ID: On Sun, Mar 30, 2008 at 10:03 PM, Samuel Bronson wrote: > Sun Mar 30 19:43:26 EDT 2008 Samuel Bronson > * Fix kind inference + test > Also, comment out the case in kindOf that makes things look fine when > they aren't -- unless of course * isn't the right kind Hmm. This doesn't actually pass... goofy me... After adding a "main" to the test, I find that MetaVars are leaking into the .ho file... From naesten at gmail.com Mon Mar 31 14:39:20 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 31 14:35:47 2008 Subject: [jhc] darcs patch: Not everyone has a fast computer -- extend default reg... Message-ID: Mon Mar 31 14:37:58 EDT 2008 Samuel Bronson * Not everyone has a fast computer -- extend default regression test timeout to compensate for this -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7727 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080331/544ae5d1/attachment.bin From naesten at gmail.com Mon Mar 31 15:02:40 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 31 14:58:43 2008 Subject: [jhc] darcs patch: Fix kind inference + test (and 1 more) Message-ID: Mon Mar 31 07:28:01 EDT 2008 Samuel Bronson * Fix kind inference + test Also, comment out the case in kindOf that makes things look fine when they aren't -- unless of course * isn't the right kind Mon Mar 31 11:18:39 EDT 2008 Samuel Bronson * Work around type inference bug relating to main (I didn't do it!) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 10690 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080331/7f864fec/attachment-0001.bin From naesten at gmail.com Mon Mar 31 19:35:43 2008 From: naesten at gmail.com (Samuel Bronson) Date: Mon Mar 31 19:32:05 2008 Subject: [jhc] darcs patch: Make Data.Char not depend on Prelude anymore Message-ID: Mon Mar 31 19:24:37 EDT 2008 Samuel Bronson * Make Data.Char not depend on Prelude anymore Yay for reducing the size of the monster SCC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8677 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20080331/cbce28cc/attachment.bin