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. It could even be added *transparently*, i.e., as a separate program generating Haskell output. Why?, because YAML's format is _truly_ human-readable (and concise), there is no Lua or whatever that can be better. And, in our context (reduced/subset YAML), a snap to learn and grasp. I am using myself my 'cqac' program written in Perl (celerius quam asparagi cocuntur, more swiftly than asparagus is cooked, a favorite expression of Augustus to say that something was done quickly), which is an implementation and extension of the Blackbox window manager original menu (nop's inclusive). 'cqac' uses X::Osd (Perl extension to the X On Screen Display library, xosd), no mouse, YAML::Tiny, and, unfortunately, X11::Protocol ... from the latter I need exclusively Grab- and UngrabKeyboard, hence I am thinking to put the original X11::Protocol on *diet*, and skim unnecessary fat away. Anyway, 'cqac', which at present still uses YAML::Tiny in-line, i.e., still reads its '.yml'-configuration file on the flight, and uses the original, jumbo-sized X11::Protocol is reasonably fast (on a okay/acceptable/no-ancient notebook) ... in Perl!, and with a no-toy cqac.yml. (Well, for that I also have nicknamed it like I have.) There is nothing more annoying than to being obliged to pass from the stage of *inheriting* default setups or monkeying setups from guru X, master Y, and wizard Z, *merging* and *pruning* a' la trial and error m more or less mysterious configuration files until one learns to read--and write--Haskell, Lua, whatever. (No, in ten minutes reading and studying one learns what there is to know to use YAML::Tiny's format, just in case; quicker than memorizing all the meta chars to use a given window manager. Better still: one doesn't need to *restudy* Haskell, Lua, whatever if, after m months, he decides to modify the configuration file ... _and_ he doesn't use Haskell, Lua, whatever n hours a day.) Cheers, /Roy Lanek (West Sumatra) P.S. cqac ... I have used--not longer--Ion: never have liked its *application launcher*, worse, I am not a fan of Lua (though I may understand that it's cute); never have used Ion's status bar, by the way ... a dumb (notebook) idea. Ditto for dwm's dmenu. -- :::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::9:: ::::::::::;::@@@:::::::::::::::@P:::::::::::::::::::::::::::::::::::::::9:: :::::::@@@@::::@::L;:;;:::::;;;7F:;LL:;;;::::;LL:;L::;:::LLL:;;::;L;::::9:: :::::::@@L@::::@::7@@FH@:::@FH@>@@@@7:9F7::::77@;:H@MH@;:77@@FHF@F77@:::@:: :::::::::7@::::@:::@:::7E:H4::7>F::7@:@:::9L::::@:@F:::@:::@L:::F:;;@:::::: ::::::@@F:@L:::@:::@::::@:@::::>F:::@:@:::9L::::@:A::::@:::@::::@:777:::::: ::B:::@:::@:;:@@:::@L;;@@:AL:::::::;@:7@@@@L@:;@F:7@;:;@:::@::::7@@L::::::: ::E:::7@@@57HM7@@@L:7HF7@M:@@@::::@@E:@@@77L@HN7:::7HMF@@::@::::@;;@L:::::: ::E:::::::::::::::::::::::::::::::::::::::9@:::::::::::::::@@L::@7F7::::::: ::E:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::AMMMMMMMMMM Slackware Linux MMMMMMMMMM:::::::::::::::::::::::::::::::::::
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
Functions. You can't encode Haskell functions in YAML.
You can't. But you could still *embed* them 1-1 ... as, e.g., in - Functions: ######### - Something: ######### - function_a: | Haskell_code \ Haskell_code - function_b: | Haskell_code \ Haskell_code - Whatever: ######## - function_a: | Haskell_code \ Haskell_code - function_b: | Haskell_code \ Haskell_code should it be really necessary.
However, if we ignore arbitrary computable functions, all the value level configuration could be YAML, or JSON, or Read/Show or ...
Yes, actually I was rather thinking at that, the level configuration stuff. (Tabbing, *standard*-hooks, etc., this should come in the vanilla/default repertoire already.) /Roy -- ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, # , (@@ @P # @#@@ @ L, ,, ,,,7F ,LL ,,, ,,, ,L , LLL ,, ,L, # #@&# @ *@###@ ###@(@@@@* ##* "*#,'#@###, ""#@##F#W"7@ # "@ @ @ 7E #" "(F 7@ @ #L @ #F @ #" F ,,# @## #L @ @ @ # (F # @ #L @ # # # @ #WW B @ @ #@ #L,,@@ #L " ,# 7@@@@L@ ,#" 7@, ,@ # #@@L # 7#@#*"##*@@@ *##*@M @@@ @@E @@@"#L###" 7##W#@ # @,,@+ # #@ #@L #"#* # #MMMMMMMMMM Slackware Linux MMMMMMMMMM
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
Not sure to have interpreted you correctly. Are you saying, or implying that XMonad has been implemented for the fun and recreation of the Haskell programmers? Or, if XMonad has not to be regarded as a toy, or a sandbox, that it can't be more adequately configured except than by writing native Haskell files? Please notice that I am not saying that _everything_ is configuration file needs to be trashed if it's written in Haskell. I am in favor of a hybrid solution: Haskell there where it would be clumsier, more laborious, or error prone to try to circumvent it. Other formats, a simplified YAML e.g., there where things are mundane or trivial. Maybe it can get close to something such 80/20. Plus, as YAML::Tiny shows, there is no loss of efficiency. XMonad doesn't interest me because of some exotic reasons ... Haskell being chic, say. What is attracting me--notice that there are window managers that *might* be better (a relative notion) than XMonad ... still, at the least--is the choice of the _implementation_ language ... finally away from C and C++! (I can program in both C and C++ FYI.) And XMonad's potential (being programmed in Haskell ... I modestly regard myself as an expert in using and interpreting lint). Personally I would have chosen Modula-3 (I know, Modula-3 has been *terminated*.) But Haskell is a good choice too.
The real reason why a non-Haskell config is undesirable is ...
Not real to me. I make you an example, a ... *classic* one. Statistics show that cigarettes smokers and meat eaters die sooner. And true, certainly smoking and excessive meat eating are factors. But perhaps more *negative* than tobacco or the meat per se is that cigarette smokers, coffee drinkers and meat eaters live and behave differently than vegetarians, yogurt eaters, and herbal tea drinkers in general. Cheers, /Roy lanek -- :::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::9:: ::::::::::;::@@@:::::::::::::::@P:::::::::::::::::::::::::::::::::::::::9:: :::::::@@@@::::@::L;:;;:::::;;;7F:;LL:;;;::::;LL:;L::;:::LLL:;;::;L;::::9:: :::::::@@L@::::@::7@@FH@:::@FH@>@@@@7:9F7::::77@;:H@MH@;:77@@FHF@F77@:::@:: :::::::::7@::::@:::@:::7E:H4::7>F::7@:@:::9L::::@:@F:::@:::@L:::F:;;@:::::: ::::::@@F:@L:::@:::@::::@:@::::>F:::@:@:::9L::::@:A::::@:::@::::@:777:::::: ::B:::@:::@:;:@@:::@L;;@@:AL:::::::;@:7@@@@L@:;@F:7@;:;@:::@::::7@@L::::::: ::E:::7@@@57HM7@@@L:7HF7@M:@@@::::@@E:@@@77L@HN7:::7HMF@@::@::::@;;@L:::::: ::E:::::::::::::::::::::::::::::::::::::::9@:::::::::::::::@@L::@7F7::::::: ::E:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::AMMMMMMMMMM Slackware Linux MMMMMMMMMM:::::::::::::::::::::::::::::::::::
Addendum:
From the manual:
YAML::Tiny - Read/Write YAML files with as little code as possible PREAMBLE The YAML specification is huge. Really, really huge. It contains all the functionality of XML, except with flexibility and choice, which makes it easier to read, but with a formal specification that is more complex than XML. The original pure-Perl implementation YAML costs just over 4 megabytes of memory to load. Just like with Windows .ini files (3 meg to load) and CSS (3.5 meg to load) the situation is just asking for a YAML::Tiny module, an incomplete but correct and usable subset of the functionality, in as little code as possible. Like the other "::Tiny" modules, YAML::Tiny will have no non-core dependencies, not require a compiler, and be back-compatible to at least perl 5.005_03, and ideally 5.004. And truly YAML::Tiny is _very_ fast ... I am not able to distinguish a 'cqac' [see prev. post] which uses YAML::Tiny on the flight, from a 'cqac' which reads already parsed, dumped non YAML formatted data from a file. Ergo, it's better/less complicated to use just one, YAML-configuration file. This for Perl already. I imagine with Haskell, where ghc is generating a, in general, significantly faster code ... /Roy -- :::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::9:: ::::::::::;::@@@:::::::::::::::@P:::::::::::::::::::::::::::::::::::::::9:: :::::::@@@@::::@::L;:;;:::::;;;7F:;LL:;;;::::;LL:;L::;:::LLL:;;::;L;::::9:: :::::::@@L@::::@::7@@FH@:::@FH@>@@@@7:9F7::::77@;:H@MH@;:77@@FHF@F77@:::@:: :::::::::7@::::@:::@:::7E:H4::7>F::7@:@:::9L::::@:@F:::@:::@L:::F:;;@:::::: ::::::@@F:@L:::@:::@::::@:@::::>F:::@:@:::9L::::@:A::::@:::@::::@:777:::::: ::B:::@:::@:;:@@:::@L;;@@:AL:::::::;@:7@@@@L@:;@F:7@;:;@:::@::::7@@L::::::: ::E:::7@@@57HM7@@@L:7HF7@M:@@@::::@@E:@@@77L@HN7:::7HMF@@::@::::@;;@L:::::: ::E:::::::::::::::::::::::::::::::::::::::9@:::::::::::::::@@L::@7F7::::::: ::E:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::AMMMMMMMMMM Slackware Linux MMMMMMMMMM:::::::::::::::::::::::::::::::::::
BTW, If you're interested in this, you can certainly write a contrib extension that loads the configuration data for xmonad from a yaml file. there's a library here for parsing yaml, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsSyck so now it is just a matter of constructing a module to read in that file, xmonad.hs: main = xmonad =<< readyaml lanek:
Addendum:
From the manual:
YAML::Tiny - Read/Write YAML files with as little code as possible
PREAMBLE
The YAML specification is huge. Really, really huge. It contains all the functionality of XML, except with flexibility and choice, which makes it easier to read, but with a formal specification that is more complex than XML.
The original pure-Perl implementation YAML costs just over 4 megabytes of memory to load. Just like with Windows .ini files (3 meg to load) and CSS (3.5 meg to load) the situation is just asking for a YAML::Tiny module, an incomplete but correct and usable subset of the functionality, in as little code as possible.
Like the other "::Tiny" modules, YAML::Tiny will have no non-core dependencies, not require a compiler, and be back-compatible to at least perl 5.005_03, and ideally 5.004.
And truly YAML::Tiny is _very_ fast ... I am not able to distinguish a 'cqac' [see prev. post] which uses YAML::Tiny on the flight, from a 'cqac' which reads already parsed, dumped non YAML formatted data from a file.
Ergo, it's better/less complicated to use just one, YAML-configuration file.
This for Perl already. I imagine with Haskell, where ghc is generating a, in general, significantly faster code ...
/Roy -- :::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::9:: ::::::::::;::@@@:::::::::::::::@P:::::::::::::::::::::::::::::::::::::::9:: :::::::@@@@::::@::L;:;;:::::;;;7F:;LL:;;;::::;LL:;L::;:::LLL:;;::;L;::::9:: :::::::@@L@::::@::7@@FH@:::@FH@>@@@@7:9F7::::77@;:H@MH@;:77@@FHF@F77@:::@:: :::::::::7@::::@:::@:::7E:H4::7>F::7@:@:::9L::::@:@F:::@:::@L:::F:;;@:::::: ::::::@@F:@L:::@:::@::::@:@::::>F:::@:@:::9L::::@:A::::@:::@::::@:777:::::: ::B:::@:::@:;:@@:::@L;;@@:AL:::::::;@:7@@@@L@:;@F:7@;:;@:::@::::7@@L::::::: ::E:::7@@@57HM7@@@L:7HF7@M:@@@::::@@E:@@@77L@HN7:::7HMF@@::@::::@;;@L:::::: ::E:::::::::::::::::::::::::::::::::::::::9@:::::::::::::::@@L::@7F7::::::: ::E:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::AMMMMMMMMMM Slackware Linux MMMMMMMMMM::::::::::::::::::::::::::::::::::: _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
* Roy Lanek
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.
You see, most of us (xmonad developers, contributors and power users) love xmonad not just because it's great wm, but because we love Haskell. So it's unlikely that we trade our xmonad.hs for xmonad.yaml, or even learn some new syntax. Let's imagine you wrote translator from yaml to Haskell. Are you sure you can provide the same quality support for users as they currently have? Who will answer the questions "How to do X" or "Why Y does not work"? Who will add support for the new extensions and features? It's a lot of work. And if users do not get support, they end up frustrated and dissatisfied with xmonad. That's why we rather teach users Haskell in 5 minutes (that part of Haskell they need now) than speak with them in different languages. -- Roman I. Cheplyaka (aka Feuerbach @ IRC) http://ro-che.info/docs/xmonad.hs
On Fri, Feb 06, 2009 at 12:01:01PM +0700, Roy Lanek wrote:
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.
It could even be added *transparently*, i.e., as a separate program generating Haskell output.
Why?, because YAML's format is _truly_ human-readable (and concise), there is no Lua or whatever that can be better. And, in our context (reduced/subset YAML), a snap to learn and grasp.
I am using myself my 'cqac' program written in Perl (celerius quam asparagi cocuntur, more swiftly than asparagus is cooked, a favorite expression of Augustus to say that something was done quickly), which is an implementation and extension of the Blackbox window manager original menu (nop's inclusive). 'cqac' uses X::Osd (Perl extension to the X On Screen Display library, xosd), no mouse, YAML::Tiny, and, unfortunately, X11::Protocol ... from the latter I need exclusively Grab- and UngrabKeyboard, hence I am thinking to put the original X11::Protocol on *diet*, and skim unnecessary fat away.
Anyway, 'cqac', which at present still uses YAML::Tiny in-line, i.e., still reads its '.yml'-configuration file on the flight, and uses the original, jumbo-sized X11::Protocol is reasonably fast (on a okay/acceptable/no-ancient notebook) ... in Perl!, and with a no-toy cqac.yml. (Well, for that I also have nicknamed it like I have.)
There is nothing more annoying than to being obliged to pass from the stage of *inheriting* default setups or monkeying setups from guru X, master Y, and wizard Z, *merging* and *pruning* a' la trial and error m more or less mysterious configuration files until one learns to read--and write--Haskell, Lua, whatever. (No, in ten minutes reading and studying one learns what there is to know to use YAML::Tiny's format, just in case; quicker than memorizing all the meta chars to use a given window manager. Better still: one doesn't need to *restudy* Haskell, Lua, whatever if, after m months, he decides to modify the configuration file ... _and_ he doesn't use Haskell, Lua, whatever n hours a day.)
Cheers,
/Roy Lanek (West Sumatra)
P.S.
cqac ... I have used--not longer--Ion: never have liked its *application launcher*, worse, I am not a fan of Lua (though I may understand that it's cute); never have used Ion's status bar, by the way ... a dumb (notebook) idea.
Ditto for dwm's dmenu.
Configuration in Haskell, the same language as xmonad's core is written in, is a central and defining characteristic of xmonad. We're simply not going to consider moving away from pure Haskell to some mark up language. Of course you're free to write an extension to xmonad that uses YAML (much as has already been done with xmonad-light), or you can fork xmonad and try out your ideas there. Cheers, Spencer Janssen
participants (5)
-
Braden Shepherdson -
Don Stewart -
Roman Cheplyaka -
Roy Lanek -
Spencer Janssen