Don Stewart wrote:
> lanek:
>> Hi,
>>>> Why not to use YAML, YAML Ain't a Markup Language, with XMonad's configuration
>> files? ... Don't faint, there is no need to use full blown YAML.
>> Functions. You can't encode Haskell functions in YAML.
>> However, if we ignore arbitrary computable functions, all the value
> level configuration could be YAML, or JSON, or Read/Show or ...
>> See xmonad-light for non-function values only.
>> -- Don
The goals of xmonad-light and of this proposal are subtly different.
xmonad-light was not created to prevent users needing to learn Haskell
syntax (though it doesn't use it), it was created to remove the GHC
dependency for xmonad. If that latter goal could have been achieved
without sacrificing Haskell configs, xmonad-light would have used
Haskell (see for example the proposal from the ML about an online
compilation form as an alternative)
xmonad-light includes several data structures mapping names from a
user's plaintext config into Haskell functions (which are compiled as
part of xmonad-light, and allows a user's config to be built into the
data structures expected by xmonad without actually compiling).
Now, if non-Haskell configs were really desirable to new users,
xmonad-light would be a more popular way to at least get started with
xmonad. The reality is that it's pretty easy for a programmer to see
examples in contrib docs and assemble their own config in Haskell.
#xmonad is there to help, and someone will cheerfully make and explain
the edit if you can't get it to work yourself.
The real reason why a non-Haskell config is undesirable is that it takes
a new user about 90 minutes to want an extension xmonad-light doesn't offer.
xmonad-light has, to my knowledge, no users. And that's fine; it exists
mainly as a counterargument to the "it requires this massively heavy
toolchain" gripe about xmonad. If you like, it should be very easy to
write a converter in Perl from YAML to xmonad-light configs, allowing
you to configure xmonad in YAML.
Braden Shepherdson
shepheb