cvs commit: ports/archivers/hs-zip-archive Makefile distinfo pkg-descr pkg-plist ports/devel/hs-binary Makefile distinfo pkg-descr pkg-plist ports/devel/hs-darcs/files patch-Setup.lhs patch-darcs.cabal ports/devel/hs-darcs Makefile distinfo pkg-d

[Alexey Dokuchaev]

On Thu, May 27, 2010 at 03:49:30PM +0200, Gabor Pali wrote:
> You might say that "I could care less about the language that uses
> noone", but please abstract away from that: here we are talking about
> a global problem effecting on every similar category.

I would not say that.  :-)  In fact, slowly growing codebase is better
in terms of maintainability and allows to invest more time and thinking to
implement supporting infrastructure correctly.

> And they are also in the same primary categories. By analyzing them
> will lead to my solution.  Only two of them is accidental (toilet and
> jack), all the others are matching for a definite reason.  The reason
> is: they want to provide Haskell bindings to the given application
> (e.g. gnuplot, graphviz, llvm, etc.) or provide a Haskell-based
> solution for the very same problem, therefore it has the same name
> (e.g. calc, wol).  I do not see clear guarantee for avoiding name
> problems without a prefix (which is a "qualifier" in that sense).
> 
> What to do with darcs and xmonad then?  Because both of them might be
> used without Haskell (however, for xmonad, I am still in doubt),
> "split" but not "share" them between the interested audiences.  Let us
> take darcs as an example.
> 
> - Create a devel/darcs port which contains everything but Haskell
> libraries and the Haskell API documentation.  If somebody wants to use
> darcs as an end-user application and not a module, this must be fine.
> 
> - Keep the devel/hs-darcs port as a Haskell binding to devel/darcs
> (itself) with a dependency on devel/darcs.  This way the user (or a
> dependent port) has both the application and its modules.

Sounds interesting, probably this is nice way to go.  May I see patches
when you have them?  Want to take a look to see the details of
implementation, and possibly comment on them.

> For xmonad it is tricky, because you need to "develop with xmonad" in
> order to configure it.  This approach is also used in xmonad-contrib.

While configuring Xmonad implies Haskell knowledge and being able to
code in it, people in tiling WM forums discuss it pretty much on par
with other window managers, meaning it is pretty usable as generic
application.  If you mean that it is not immediately obvious how to
separate `x11-wm/xmonad' frontend port from `x11-wm/hs-xmonad' (rather
Haskell than user related), I'm sure there is acceptable solution.

./danfe