Opened 10 years ago

Last modified 4 months ago

#1409 new feature request

Allow recursively dependent modules transparently (without .hs-boot or anything)

Reported by: Isaac Dupree Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.10.2
Keywords: backpack Cc: dterei, pho@…, alfonso.acosta@…, mnislaih@…, lazycat.manatee@…, alexander.dunlap@…, id@…, lennart@…, ben.franksen@…, nr@…, ndmitchell@…, asr, explicitcall@…, kolmodin@…, lambda-belka@…, analytic@…, tora@…, sveina@…, ganesh, illissius@…, hackage.haskell.org@…, skilpat@…, leon.p.smith@…, nathanhowell@…, singpolyma@…, hvr@…, ghc@…, roma@…, zaretskysa@…, eir@…, william.knop.nospam@…, ekmett, angerman, mentheta, Tritlo
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9256 Differential Rev(s):
Wiki Page:

Description

Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done).

This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to "just" treat a subset of each .hs file as its .hs-boot).

When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one ".hi-boots" or ".his", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make.

In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 , #1072 , #1133 . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)

Change History (71)

comment:1 Changed 10 years ago by simonpj

See #1428

comment:2 Changed 10 years ago by igloo

Milestone: 6.1

comment:3 Changed 10 years ago by simonmar

Milestone: 6.10 branch_|_

We don't have any plans to do this, so remove it from the 6.10 milestone. Perhaps it could be done as part of some kind of support for module signatures?

comment:4 Changed 9 years ago by PHO

Cc: pho@… added

comment:5 Changed 9 years ago by fons

Cc: alfonso.acosta@… added

comment:6 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:7 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:8 Changed 8 years ago by fasta

Cc: ron@… added

comment:9 Changed 8 years ago by mnislaih

Cc: mnislaih@… added

comment:10 Changed 8 years ago by guest

Architecture: Unknown/Multiplex86
Cc: lazycat.manatee@… added; pho@… alfonso.acosta@… ron@… mnislaih@… removed
Operating System: Unknown/MultipleLinux
Version: 6.6.16.10.2

Please support "mutually recursive modules" in next release version. It's not little problem. It can save much time for Haskell programming.

Thanks!

-- Andy

comment:11 Changed 8 years ago by ajd

Cc: pho@… alfonso.acosta@… ron@… mnislaih@… alexander.dunlap@… added

Adding people who were in the CC list back in, plus adding myself.

comment:12 Changed 8 years ago by guest

Architecture: x86Unknown/Multiple
Cc: id@… added
Operating System: LinuxUnknown/Multiple

(affects all os/arch.) I'm still interested, although more cautiously so than when I reported it. Simon's point about "module signatures" could go along with work that essentially integrates hs-boot information into a .hs file (and is worthy work on its own). My wish that multiple modules could be compiled in one unit is complicated quite a bit more than I suggested in the description, by the many per-module language extensions that sometimes change semantics in a conflicting way (and reducing the amount of arbitrarily per-module / per-typechecking-unit extension stuff in some way, might be a good thing on its own too). -Isaac Dupree

comment:13 Changed 8 years ago by augustss

Cc: lennart@… added

I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g.,

{-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-}
data T = ...
foo :: ...
foo = ...

The values that have an annotation would have to have a type signature.

comment:14 Changed 8 years ago by guest

I *think* there are annoying situations involving recursive (or just lots of back-and-forth between modules) of data, type or class declarations that simply can't be solved with simple pragmas/hs-boots (possibly even some of those annoying situations would be non-terrible programming style :-) ). Maybe I should write a few examples?

P.S. also a pragma like "MODULE_MUTUAL_RECURSION_BREAKER" would involve a limited bit of NOINLINE & no strictness analysis (etc.) semantics, as we already have with hs-boot: just to be aware of.

-Isaac Dupree

comment:15 Changed 8 years ago by simonpj

Clearly a lot of people are interested in this ticket, but I'm not clear why:

  • Writing an hs-boot file is very like writing a module signature in ML; and that in turn is a bit like writing a type signature on a function. Why is that so bad?
  • At the moment I am very un-clear about the design of a viable alternative. Lennart's recent suggestion comes closest; but does that meet the goals of others.

Once there is a clear motivation, and a clear design, it'll become easier to comment about how easy or difficult it is to implement.

Simon

comment:16 Changed 8 years ago by augustss

For me the reason to get rid of the -boot files is that each of them is one more file. One more file that duplicates information that occurs somewhere else, so when I change something I have to change it in two places. There are also build system complications (not so much when using ghc --make), because there are new file types, new kinds of dependencies to figure out etc., etc. It just a medium pain, but enough of a pain that I sometimes go through unnatural contorions just to avoid mutually recursive modules when it would actually have been the natural solution.

I have an alternate design proposal: Leave the pragma as is, i.e. SOURCE on some modules, but require an explicit list of imports when using SOURCE. Also get rid of the -boot file. I can just about write a sed script that will generate the correct -boot file from that information, so it feels like ghc might be able to do it too.

comment:17 Changed 8 years ago by simonmar

Isn't the problem that you can't quite write a sed script to generate the hs-boot file, because you can't figure out what the imports should be? The point of the hs-boot file is that it lets GHC break the import recursion by specifying a smaller set of imports than the main .hs file has.

In reply to Simon's question: I think people would like GHC to resolve mutually recursive modules automatically by using a fixed-point calculation in the module system, in the way that Diatchki/Jones/Hallgren did in their Haskell Workshop '02 paper: http://portal.acm.org/citation.cfm?id=581692. This would be a huge upheaval in GHC of course, and it seems to be completely at odds with separate compilation.

comment:18 Changed 8 years ago by augustss

Well, I suggested that when using SOURCE you have to supply the import list. And I would also require the imported values to have type signatures in the other module. With those premises I can write a dodgy sed script that kinda does the work.

comment:19 in reply to:  16 Changed 8 years ago by guest

Replying to augustss:

For me the reason to get rid of the -boot files is that each of them is one more file. One more file that duplicates information that occurs somewhere else, so when I change something I have to change it in two places. There are also build system complications (not so much when using ghc --make), because there are new file types, new kinds of dependencies to figure out etc., etc. It just a medium pain, but enough of a pain that I sometimes go through unnatural contorions just to avoid mutually recursive modules when it would actually have been the natural solution.

I agree, Why need another file to contain those information? Why GHC can't pick-up those information through analysis source file? Maybe it's a hard work to GHC developer, but i think it's worth to do. It's not problem just write .hs-boot file, it's not too hard to write .hs-boot file. But Haskell programmer will spend too *much* time to synchronous information between .hs file and .hs-boot file, and special to *big* project.

And i think the *natural* way is GHC do those work automatically. Then save time and less problem (bug).

-- Andy

comment:20 Changed 8 years ago by guest

Cc: ben.franksen@… added

I absolutely hate it if I have to write a .hc-boot file. So I try to avoid mutually recursive modules if possible. This is bad because it makes me concentrate on boring things when I should be thinking about interesting things instead.

Cheers Ben Franksen

comment:21 Changed 8 years ago by nr

Cc: nr@… added

I am quite interested in extending Haskell import lists to be more like ML signatures (don't worry, no ML functors, I promise!). With such an explicit signature, I hope it would be possible to eliminate the hs-boot file. Or as a further step, one could compile signatures separately, then use them instead of .hs-boot. Also, I think Derek Dreyer could be persuaded to have a look at this problem.

comment:22 Changed 8 years ago by simonpj

"I absolutely hate it if I have to write a .hc-boot file" (I assume you mean hs-boot file). I'm interested in identifying precisely what it is that you hate, lest we fix the wrong thing:

  • Do you hate writing the type signatures of the functions that the module exports? (After all, most Haskell programmers do that routinely.)
  • Do you hate putting those type signatures in a physically different file? That is would the hate be alleviated if the signatures were in the same file as the module implementation?
  • Or perhaps you hate something else? Such as having to pick a place to cut the recursive loop at all?

I'm interested in this because the ML community regards it as a major virtue that module signatures and implementations are separate, so that you can

  • Import a module (via its signature) before you have written its implementation
  • Provide more than one implementation of a common signature, and thereby be confident that switching implementations will not cause errors.

Being clear about goals will help the design.

Simon

comment:23 in reply to:  18 Changed 8 years ago by simonmar

Replying to augustss:

Well, I suggested that when using SOURCE you have to supply the import list. And I would also require the imported values to have type signatures in the other module. With those premises I can write a dodgy sed script that kinda does the work.

Ah, I took that to mean that only SOURCE imports would need import lists, but now I see that you meant all imports - or at least all imports of entities referred to by an entity in the loop. I'm not keen on this, it seems worse than .hs-boot files.

comment:24 Changed 8 years ago by augustss

Reply to simonmar:

I guess it's a matter of style. I use import list on most modules I import. Even so, I'm willing to tolerate some pain to get rid of the very annoying -boot file.

comment:25 Changed 8 years ago by NeilMitchell

Cc: ndmitchell@… added

The -boot files are particularly annoying if you don't use --make, since then you need to write some reasonably complex build rules to get everything working. Having GHC perform this magic, even at the cost of essentially moving the -boot file in to the source file, would be nice.

comment:26 Changed 8 years ago by fasta

Cc: ron@… removed

comment:27 Changed 8 years ago by andresSR

Cc: andres.sicard.ramirez@… added

comment:28 in reply to:  22 Changed 8 years ago by guest

Replying to simonpj:

"I absolutely hate it if I have to write a .hc-boot file" (I assume you mean hs-boot file). I'm interested in identifying precisely what it is that you hate, lest we fix the wrong thing:

  • Do you hate writing the type signatures of the functions that the module exports? (After all, most Haskell programmers do that routinely.)

No, and I do it, too.

  • Do you hate putting those type signatures in a physically different file? That is would the hate be alleviated if the signatures were in the same file as the module implementation?

No; in fact sometimes I wish I could make module interfaces more explicit a la ML or Modula.

  • Or perhaps you hate something else? Such as having to pick a place to cut the recursive loop at all?

Yes. This is just distracting. Knowing that the compiler could do it automatically, I don't like to do it manually.

Another point is that hc-boot files are non-standard.

comment:29 Changed 8 years ago by guest

The "physically separate file" frustrates me. It would be less specifically-frustrating if type signatures were *always* in a separate file, not just the ones for loop-breaking... but I've been to C and C++ and I can't say that it made me happy to keep those different header/source files in sync. -Isaac Dupree

comment:30 Changed 8 years ago by guest

If some ghc hacker have time, please fix this problem. I waste too much time to fix import cycle problem, it's not little problem, special to big projects.

Example in my projects have 30 files, i got below information by ghc:

Module imports form a cycle for modules:
  main:Manatee.File[boot]
    imports: Manatee.Commander[boot] Manatee.View[boot]
             Graphics.UI.Gtk.Gdk.Events Data.ByteString.Lazy.UTF8
             Data.ByteString.Lazy Manatee.IORefObject Data.IORef
  main:Manatee.View[boot]
    imports: Manatee.Page Graphics.UI.Gtk.Abstract.Paned
  main:Manatee.Page
    imports: Manatee.TabGroup[boot] Manatee.File[boot]
             Manatee.ViewList[boot] Manatee.StringBuffer[boot]
             Manatee.PageList[boot]
             Manatee.IORefObject Manatee.PageBuffer Manatee.Utils Manatee.View
             Graphics.UI.Gtk Control.Monad Data.List System.FilePath
             Control.Applicative Data.Function Data.IORef Text.Printf
  main:Manatee.TabGroup[boot]
    imports: Manatee.PageList[boot] Manatee.Page[boot]
             Data.IORef
  main:Manatee.PageList[boot]
    imports: Manatee.Page[boot]
             Data.Set Data.IORef
  main:Manatee.Page[boot]
    imports: Manatee.View[boot] Manatee.IORefObject[boot]
             Manatee.PageBuffer Graphics.UI.Gtk
  main:Manatee.PageBuffer
    imports: Manatee.ViewList[boot] Manatee.View[boot]
             Graphics.UI.Gtk Data.IORef
  main:Manatee.ViewList[boot]
    imports: Manatee.Page[boot] Manatee.IORefObject[boot]
             Manatee.ViewNode[boot] Manatee.View[boot]
             Data.Set Data.IORef
  main:Manatee.StringBuffer[boot]
    imports: Manatee.PageBuffer Graphics.UI.Gtk.SourceView.SourceBuffer
  main:Manatee.IORefObject
    imports: Manatee.Commander[boot] Manatee.PageList[boot]
             Manatee.ViewNodeList[boot] Manatee.ViewList[boot]
             Manatee.Utils Graphics.UI.Gtk.Windows.WindowGroup
             Graphics.UI.Gtk.Abstract.Container Graphics.UI.Gtk Data.IORef
  main:Manatee.View
    imports: Manatee.PageList[boot] Manatee.Page[boot]
             Manatee.ListZipper Data.Foldable Manatee.ViewNode
             Manatee.IORefObject Manatee.PageBuffer Manatee.TabGroup
             Manatee.ViewList Graphics.UI.Gtk.Layout.VPaned
             Graphics.UI.Gtk.Layout.HPaned Graphics.UI.Gtk.Abstract.Paned
             Graphics.UI.Gtk.Abstract.Container Graphics.UI.Gtk Data.List
             Data.IORef Control.Monad.Reader Text.Printf Data.Function
             Data.Maybe Control.Applicative Control.Monad.State
  main:Manatee.ViewNode
    imports: Manatee.ViewNodeList[boot] Manatee.ViewList[boot]
             Manatee.View[boot]
             Manatee.Utils Manatee.IORefObject Graphics.UI.Gtk.Layout.VPaned
             Graphics.UI.Gtk.Layout.HPaned Graphics.UI.Gtk.Abstract.Paned
             Graphics.UI.Gtk Data.Function Control.Monad Text.Printf Data.Maybe
             Data.IORef Control.Applicative
  main:Manatee.TabGroup
    imports: Manatee.PageList[boot] Manatee.Page[boot]
             Data.Foldable Data.Sequence Manatee.Utils
             Graphics.UI.Gtk.SourceView.SourceBuffer Graphics.UI.Gtk Data.List
             Data.Sequence Control.Monad Text.Printf Control.Applicative
             Data.IORef
  main:Manatee.ViewList
    imports: Manatee.Page[boot] Manatee.View[boot]
             Manatee.ListZipper Manatee.IORefObject Manatee.ListZipper
             Manatee.Utils Manatee.ViewNode Graphics.UI.Gtk.Abstract.Container
             Graphics.UI.Gtk.Abstract.Paned Graphics.UI.Gtk Text.Printf
             Data.IORef Control.Applicative

Above information is really less help, if i change one file, i will got another different output.

I have spend more time to fix this problem along with my project increase everyday.

I'm really tired....

So please ghc expert fix this problem, then I'm free.

Thanks!

-- Andy

comment:31 Changed 8 years ago by explicitcall

Cc: explicitcall@… added

comment:32 Changed 8 years ago by kolmodin

Cc: kolmodin@… added

comment:33 Changed 8 years ago by lambda_belka

Cc: lambda-belka@… added

This restriction was a very unpleasant surprise. Double maintenance problem. It's hard to believe, that the feature is so hard to enable.

comment:34 in reply to:  description Changed 8 years ago by increpare

Cc: analytic@… added
Type of failure: None/Unknown

comment:35 Changed 7 years ago by TristanAllwood

Cc: tora@… added

comment:36 Changed 7 years ago by Baughn

Cc: sveina@… added

Maintaining a separate .hs-boot file is a pain if the interface changes a lot, as mine tend to do during development. I'm warping the structure of the programs to avoid cycles instead.

Please, deliver me from this evil.

comment:37 Changed 7 years ago by simonpj

Another thread has started on Haskell Cafe about this ticket. I thought it worth jotting down how I'd approach implementing the feature.

If we wanted to support mutually recursive modules transparently, which is a reasonable goal, then the Right Thing is surely to identify the strongly-connected components and compile each SCC all together, as if it were all in a single module.

From a design point of view, here are some thing to consider

  • Doing so would make each SCC all or nothing. If you make a change to any module, all get recompiled. With hs-boot files, the recompilation checker is more discriminating.
  • Would we expect to generate one .o and .hi file for the SCC, or one for each original module? Currently lots of built-system and GHC-internal stuff expects one-per-module. But that would mean splitting up the mixed-together definitions after compilation. (Not as trivial as it sounds: we might have done CSE across modules by that time.)
  • What to do in "batch mode", when you say ghc Foo.hs without --make? (To identify the SCC you need to do --make.)
  • Since we already have the hs-boot we'd need to figure out how it inter-operates with the new mehanism.

From an implementation point of view

  • The main compilation pipeline would have to be taught about reading several source files for one compilation run.
  • GHC does not currently expect to be compiling definitions from several modules at once. In principle there should be no difficulty here, but when you break a long-standing assumption there are always difficulties. Hard to know just what.

I think all of this is do-able. But it's a significant task.

Simon

comment:38 Changed 7 years ago by ganesh

Cc: ganesh added

comment:39 Changed 7 years ago by guest

@guest with big import cycle in 30 files

I was also shocked by such verbose GHC error message. However GHC does not only output the modules that form the cycle but much more stuff. So maybe we should open a ticket for a better import cycle report.

comment:40 Changed 7 years ago by guest

This is a long message coming from an observer at the edge of the Haskell solar system; here goes...

The archetypal UNIX philosophy is "do one thing and do it well", and GHC does just that - it takes one module, the interfaces of its imports, and generates the interface and binary for the given module; and a cracking job it does.

As I see it, the problem of mutually-dependent groups of modules comes down to missing interfaces - if they were already present, a single-module compiler could process each of the modules in such a group, just as it has always done.

So what seems to be needed is something else that does one thing well - take one mutually-dependent module group, the interfaces of their imports, and generate just the interfaces for the modules in the given group - a "resolver", if you will.

In this way, each tool deals with one key source of complexity - either generating optimised binaries, or resolving interdependent interfaces - instead of trying to build and maintain one enormous tool containing all that complexity.

A prototype could be built with the Programatica front and mid-section modified to read and write GHC interface files. This would get Haskell 98 working as a first step, with the various extensions being added later to the production version, be it scratch-built or derived from the prototype.

If nothing else, this approach would quickly close this ticket (one way or the other!) without the huge upheaval to the GHC codebase which everyone involved wants to avoid.

comment:41 Changed 7 years ago by simonpj

Re the verbosity of the error message, making it more concise would be a much easier task, if someone wants to undertake it.

Simon

comment:42 Changed 7 years ago by simonmar

Could someone give me an example of an error message that is too verbose? We do limit the error message to the strongly connected component in the cycle, and list only imports of other modules within the cycle.

comment:43 Changed 7 years ago by lambda_belka

I found the lack of this feature to be forcing me to design modules in a tree like structure. And this actually helped me to avoid some bad design. Sometimes it happened, that I declared mutual dependencies by error - error messages helped be to debug this. So I just wanted to point out, that it might be valuable (if the feature is implemented) if I could enable/disable possibility to do the mutual imports for some modules. This would be useful for debugging.

comment:44 in reply to:  22 Changed 6 years ago by illissius

Cc: illissius@… added

Replying to simonpj:

"I absolutely hate it if I have to write a .hc-boot file" (I assume you mean hs-boot file). I'm interested in identifying precisely what it is that you hate, lest we fix the wrong thing:

  • Do you hate writing the type signatures of the functions that the module exports? (After all, most Haskell programmers do that routinely.)
  • Do you hate putting those type signatures in a physically different file? That is would the hate be alleviated if the signatures were in the same file as the module implementation?

I hate having to write them twice, or having to put them in different places depending on an implementation detail. If GHC could re-use the signatures I already write anyways it would be a great improvement.

  • Or perhaps you hate something else? Such as having to pick a place to cut the recursive loop at all?

I'm interested in this because the ML community regards it as a major virtue that module signatures and implementations are separate, so that you can

  • Import a module (via its signature) before you have written its implementation
  • Provide more than one implementation of a common signature, and thereby be confident that switching implementations will not cause errors.

That's attractive, and if that were how things worked across the board I think it would have both benefits and drawbacks relative to the current system. But it seems to me that -boot files provide only the drawbacks.

comment:45 in reply to:  40 Changed 6 years ago by guest

Replying to guest:

This is a long message coming from an observer at the edge of the Haskell solar system; here goes...

About the Programatica suggestion...is this even possible? Having tried to get various bits of it going in the past, only to hit a fairly-solid mass of compilation errors...it would take some doing. Now even the Programatica repository has gone - the link to browse it now returns an error. Without ready access to that facility, this suggestion looks dead in the water...almost like this ticket (4, now 5 comments since the suggestion was put forward).

Transparent support for mutually-recursive modules may be listed as a feature in the Haskell 98 Report, but then, until recently, the C++ standard listed the export of templates as a feature, but almost no mainstream compiler supported that.

On a purely theoretical point - is this feature even possible now? Haskell has grown much larger since the Report, and this growth continues. It would come as no surprise if at least one major language extension came unstuck if this feature was added.

Yes, having this feature would be nice. World peace would also be nice. Fusion energy would be nice, too. Ending world poverty would be really nice. But all this requires people who are willing to roll up their sleeves and put in some SERIOUS effort. Until that happens, maybe the best thing is to archive this ticket, along with all the other nice suggestions that sit around and gather digital dust...

comment:46 Changed 6 years ago by liyang

Cc: hackage.haskell.org@… added

comment:47 Changed 6 years ago by dterei

My main gripe with .hs-boot files is the duplication. A solution like Lennart proposed would make me happy as I've run into issues with the .hs-boot file and .hs file getting out of sync. Transparent support for recursively dependent modules would be nice but I can't see anyone stepping up to do it so would rather push towards the easier solution for now.

comment:48 Changed 6 years ago by dterei

Cc: dterei added

comment:49 Changed 6 years ago by simonpj

Lots of people would like this fixed; but no one has proposed a precise, worked-out, design. The way lies open!

Simon

comment:50 Changed 6 years ago by skilpat

Cc: skilpat@… added

comment:51 Changed 5 years ago by lpsmith

Cc: leon.p.smith@… added

comment:52 Changed 5 years ago by nathanhowell

Cc: nathanhowell@… added

comment:53 Changed 5 years ago by singpolyma

I'm strongly considering using CPP and #include to work around this problem in my most recent project.

The problem I have is both the duplication of information in two places (very un-DRY) and having to pick a place to break the import cycle. I understand that doing this cross-package (if that even ever makes sense at all) would be very complex, but I think what most people here (correct me if I'm wrong) are interested in is the case where all the source for all the modules is in one project and thus can be build with a single GHC invocation.

Since pasting the contents of one module into the top of another instead of importing it works (hence my thoughts about CPP and #include) the way forward seems to be: treat all modules in a cycle as a single module with multiple names/export lists. That way the compiler has no problem (since it can compile all these as one module already, if I paste all the code together) and imports of any of the modules into *other* modules would still work (since GHC would just pick which things to import/can be imported from the mega-module based on which of its names was used).

comment:54 Changed 5 years ago by singpolyma

Cc: singpolyma@… added

comment:55 in reply to:  53 Changed 5 years ago by guest

Replying to singpolyma:
If it's not already too late, there's an old program called Haskell All-In-One which joins together all the given modules into one large module. The bitrot has definitely set in though - you'll have some work to do to get it going again.

comment:56 Changed 5 years ago by guest

One other suggestion for anyone interested in making this happen - ban defaulting in your initial version, get it working nicely, then add defaulting. This will help make the initial design simpler, and will require you to add more type information in the input modules you're testing it on, which should help to flush out more bugs.

Switching back to regular input modules for testing your production version will no doubt uncover a few extra bugs.

comment:57 Changed 5 years ago by hvr

Cc: hvr@… added

comment:58 Changed 5 years ago by diatchki

I also think that having more direct support for mutually recursive modules would be nice. Here is one corner case we encountered when we implemented this in Programatica (just documenting it here in case someone starts implementing this feature)

The problem is the specification of defaulting, which talks about a single module. If (i) there is a recursive binding group which happens to be spread across modules, and (ii) defaulting needs to happen, then it is not clear which module's defaulting rules should be used.

A simple solution would be to simply report and error in that situation, if the modules have different defaulting rules.

comment:59 Changed 5 years ago by ocharles

Cc: ghc@… added

comment:60 Changed 5 years ago by Feuerbach

Cc: roma@… added

comment:61 Changed 5 years ago by zaretskysa

Cc: zaretskysa@… added

comment:62 Changed 5 years ago by goldfire

Cc: eir@… added

comment:63 Changed 5 years ago by altaic

Cc: william.knop.nospam@… added

comment:64 Changed 3 years ago by ezyang

Keywords: backpack added

comment:65 Changed 3 years ago by asr

Cc: asr added; andres.sicard.ramirez@… removed

comment:66 Changed 3 years ago by thomie

See #9256 for a recent proposal.

comment:67 Changed 2 years ago by ezyang

Hi guys, I have another proposal for how to fix this: #10681

comment:68 Changed 2 years ago by ekmett

Cc: ekmett added

comment:69 Changed 11 months ago by angerman

Cc: angerman added

comment:70 Changed 5 months ago by mentheta

Cc: mentheta added

comment:71 Changed 4 months ago by Tritlo

Cc: Tritlo added
Note: See TracTickets for help on using tickets.