droundy:

On Wed, May 30, 2007 at 02:27:58PM -0500, Spencer Janssen wrote:

...

David Roundy wrote:

...

I know others here have far more experience in this arena than I do, but are there any plans to support hsplugins or the ghc api, or just plain running under ghci, so that a recompile-reinstall cycle won't be necesary to update one's configuration? I'd assume this'd be in the works for version 0.7 or so, but thought I might as well ask.

0.7? I don't think any of us have planned that far ahead :).

I think the current 'restart' (serialize state, exec, deserialize) is more promising than dynamic code reloading. We just need to make additional pieces of state serializable (layouts, especially).

You can cut out the reinstall stage by pointing 'restart' straight at your xmonad repo. You can skip the recompilation step by telling restart to 'runghc my/xmonad/dir/Main.hs'.

Ah, that's what I haven't tried. That almost seems to get us there--but not really, as you still need one copy of the source code per user, and the user interface actually becomes worse than compiling by hand, rather than better.

It leaves us with xmonad having no way to gracefully exit in case of syntax error. I'd prefer if xmonad itself could do the compiling, and in case of an error in ~/.xmonad/Config.hs it would fall back on using /etc/xmonad/Config.hs (or whatever), and displaying an appropriate error message to the user (and if /etc/xmonad/Config.hs fails to compile, it'd fall back on /usr/share/xmonad/Config.hs).

It'd be nice to know that there's a plan (or at least desire) to make xmonad useable by folks who aren't willing to compile their own software, and who don't think that one copy of each program per user is a good idea.

There's some desire, but it is balanced by the constraint that existing extensible systems in Haskell aren't really suitable: either too heavyweight (hs-plugins, ghc-api) or not supporting the language (YHC). Also, these are all relatively more unstable solutions. If something changes in this area, we can look again at it. -- Don

droundy:

On Thu, May 31, 2007 at 10:39:43AM +1000, Donald Bruce Stewart wrote:

...

...

It'd be nice to know that there's a plan (or at least desire) to make xmonad useable by folks who aren't willing to compile their own software, and who don't think that one copy of each program per user is a good idea.

There's some desire, but it is balanced by the constraint that existing extensible systems in Haskell aren't really suitable: either too heavyweight (hs-plugins, ghc-api) or not supporting the language (YHC).

Also, these are all relatively more unstable solutions. If something changes in this area, we can look again at it.

In what sense are hs-plugins and ghc-api too heavyweight? In the sense of memory-use and efficiency, or the sense of API complexity?

ghc-api is a 20M dependency, and not available on systems without ghci :/ hs-plugins requires ghc be available in the path -- its lighter weight than ghc-api, but still seems unnecessary (it effectively automtes the recompilation phase currently done manually).

If it's the former, I'd say it doesn't much matter. If it's the latter, then that's a real problem, and someone ought to come up with a simple API to hs-plugins to enable the use of Haskell as a scripting language. I sort of thought that this was what hs-plugins was (a stable easy-to-program layer over ghc-api).

Its a stable api over dynamic linking and compilation. Works well for plugins, works less well for dynamic extensions. For the latter, an interpreter/bytecode is best, and we have ghc-api there. But its too unstable and too big yet. -- Don