Wolfgang Jeltsch
The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever.
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at "Foo." tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm