Yeah, okay, so I'm going to start my presentation now if I... Thank you. Okay, so my name is Alex Sussmanshausen.

I'm going to be presenting gaol-config, which is a little library that I'm writing or have written. It's just about ready to be released. It's kind of possibly more... The presentation is probably going to be more high level than all the presentations we've had so far. So yeah, I'm Alex Sussmanshausen. In my spare time, I just like to hack and gaol. And I work for PTFS Europe, which is a pretty cool company.

They kind of supply software to... Primarily open source software to academic, public and specialized libraries. And I get to work with the co-ILS community, which is a great community, so if you have a chance to hang out with people from there, do. They're all lovely. So I have an elevator pitch.

Basically the aim of... Okay, I'll just go through the elevator pitch. You know the situation when you're trying to write a command line utility. You have an awesome idea for a quick little program that does one thing and it does it well. And you start working, and you make great progress, and you have a prototype version, and it works wonderfully. And then you get some people to start using it, and they point out a different use case.

And then you find, okay, maybe that use case could require a command line flag, so maybe I'll just build that in, and then people can specify that on the command line. So you know, you add command line parsing. Yay, problem is solved. But then you find that there's another bit in your program that actually really, it should just have a default, a user defined default value,

so you can use an environmental variable, or you can use a configuration file. So what we do is, in this case, we just write a config file reader. We have a configuration file somewhere, we just read it, we parse it, and we use that as a default value. Wonderful. Then the user doesn't have to specify it in the command line every single time they run it. Yay, simple. But then some people then start complaining that, you know,

actually the configuration file isn't there by default, they don't really know what syntax it's supposed to have, so really it's all quite opaque. So then what you do is, well, similar problem, you create a config file that is automatically written, you make sure that it's created when it doesn't exist on the first time you run it, and then you kind of add common syntax to the configuration file

to make sure that people understand the configuration file when they actually look at it and start to modify it. So suddenly he moves from, oh, I'll just do a quick few lines of code to now you're also parsing configuration files, and you have a common syntax, and you parse command line things. So it's great fun. You have a simple program that does one thing and does it well, suddenly has all this kind of code that is a pain to maintain, basically.

Yay, fun. And now you've got a whole maze of command line arguments, and you don't even know how it works anymore. You were the one who wrote it, so you're totally confused. So this is where the help flag that pretty much all command line programs support needs to come in, so you need to write that.

So that's what you do. You write support for another command line option. This is the help flag. And then you write the most beautiful help output that you've ever seen. Very clear, super wonderful. And then you watch it burn as soon as you add another command line option. Or you now have documentation to maintain in the help output

in the configuration file where you write your commentary to help people, and also in your manual, which of course you maintain because manuals are important, right? So you've got three things to maintain now, and your code has become even more complicated. This is really depressing. So at least we've got the problem solved.

No one's going to complain about this, right? It's great, but your simple command line, you can't even quickly see what side is written anymore, and there's so much code going around that it's totally irrelevant to the actual thing that you want to do. It's not really a solution, I think, so it's really horrible. But hey, gall-config, a new library. That could solve your problem, maybe.

That's smiley, by the way. It was the first smiley. I did a search for smiley celebration. That was the first smiley I came up with. I was just like, what? That's a weird smiley to come up there. So I have to include it. So as a background, gall basically comes with a library, much like Puro also has a kind of get-up-long library, probably all kind of languages nowadays do.

Gall has eyes and then get-up-long, which is great. It allows you to specify command line arguments, and then it allows you to parse those command line arguments as they come into your program. It's really nice, and I use it all the time. And this is an example of it. So basically you can see at the top there, you've got the specification of the command lines that you support, the command line arguments you support,

and what kind of features they support. So for example, you have help, which is the long version, and as a single character, a short version, you've got h. And then the value, it doesn't require a value, it's just a flag. And you can go through that. There's a grammar for that. It's documented in the manual. It's quite easy to use. And then underneath that, you need to instantiate it. So when you actually run the program, you define ops to be,

you know, your command line syntax, which is defined as option grammar there. And then you pass it with program arguments to get-up-long, and that basically parses the command line arguments, and then you can just query the result to see whether someone has asked for help. And then if they have asked for help, you can emit usage or whatever with a help function in my case, or if they've asked for version,

you can emit version using a helper function there. And at the bottom, you can basically start, you know, do the rest of your program. So it's a relatively decent way to do it, but essentially it just addresses the first part of my elevator pitch. It's, you know, someone wants to have a command line option, you add it using get-up-long. That's just the first part of the problem.

So what this library is supposed to do, basically it's supposed to build on that, and it does that by basically using get-up-long as a kind of lower level, as a library, retaining its goodies in a sense. But then on top of that, it expands the grammar for specification of options, so that some options you can now basically specify that they can be specified in configuration files

as well in command line. It automatically creates configuration files, it automatically parses configuration files if they exist. If you have a program that doesn't need configuration files, then none of that will happen. You can automatically generate help usage and version from your option specification, and you can even, inside your specification, declare that you want to have a subcommand.

For example, Geeks has import as a subcommand, or package as a subcommand. So you can specify subcommands as part of your application, which again, in turn, have nested kind of command line flags or further subcommands.

So this is the example. It's slightly less elegant at this point, I think, syntax-wise than get-up-long, and part of that is just because it does so much more, so obviously if you need to get more information in there, it's going to be less concise. But the idea is basically that you have a configuration, in this case it's for a program called Backup Monitor, it's got a little explanation of what it does,

it's a configuration for Backup Monitor, and then you just have a list of options. So you've got at the top there another configuration for a subcommand called Rule World, which sounds quite nefarious, and then you've got an open option which is called Base, which is apparently a base directory for the backups, and then you've got a predicate, which is another option,

in this case a public option, and you can see that the open option basically specifies configuration files and command line options, and public options specify just command line options. And then underneath that, you just have a few more kind of keywords for that kind of configuration definition, so you can say where the configuration directory, so where the configuration files should be created, in this case it's in the home folder

under subdirectory called Backup Monitor. It kind of has a longer explanation, which will be added to the configuration file that is generated, and then there you can see that basically we ask for help to be automatically generated and usage to be automatically generated. It has an author and a copyright date and a license. Two more fields that you can't see now, unfortunately, because it's off-screen.

So it's basically specifying what I've just said. Configuration files are basically root configurations or subcommand specifications, and private options are kind of basically you can say there's this option that needs to be referenced, but it's only internal. Users don't need to change that option. So that's a private option.

And public options are command line options. So that's the bit that GitHub long does at the moment, just the public options. And open options are command line options, but also they're specified in configuration files. So yeah, and this is an example of it being instantiated. So where before you basically had,

so it still looks very similar in the sense that you still have the kind of GitHub config auto, which is assigned to ops after passing program arguments and configuration, and your configuration declaration. But you don't have to worry about doing the whole kind of checking for version, checking for usage, checking for help anymore because that's done automatically.

And then you can just start doing your stuff. And you can use the same syntax as with GitHub long, which is the option ref. It's basically the thing that allows you to check for options that are being passed in. So yeah, let's quickly look at an example. So this is the example of help output for backup monitor, which is the program that we just saw at the configuration specification of.

You can see basically generates the kind of usage line with short options and some example values, and then kind of has the long version as well with the kind of summary that it says in the configuration specification as well. So we can see here that, you know, help display help message and exit. Or, you know, we define predicate. So set test to success, test to failure. So it kind of generates that

from the configuration specification that we have. You can also see that there's a subcommand, rule world. Plan X-ray, hmm, wonder what that does. So then you can just go, well, it's a subcommand, it should have the same rules. So there we go, we get another help function because again, it's a nested configuration

so we can just understand it that way and we get the same thing. So that's what it does essentially. And hopefully it does it well. One thing and doing it well. The same anyway. So it creates configuration files, it kind of reads configuration files, there's quite a lot of I.O. going on there, so maybe there's a question about the functional paradigm which is encouraging Guile.

Obviously it's a multi-paradigm language so you can do whatever you want but I at least like the functional paradigm so I kind of tend to follow that. So the thing with option parsing and configuration file reading is generally the very first thing you do in a program. So generally you can basically have and that part is the part that really kind of contains the I.O. operations.

So by having that as the very first thing you do using this library you can basically, you can really easily maintain a functional core which is where you actually do your logic and it's just wrapped in that imperative, you know, that let basically that does the kind of parsing of the configuration files and configuration options. And there's also two approaches. I'm, you know, experimenting with monads which is proving painful but also exciting.

So I've actually like, I'm using this thing which I call the I.O. monad which is basically, it's a different style you can use. I showed you basically the kind of get along style which is kind of the standard style. The I.O. monadic style basically uses builds on kind of little weeks implementation

of the kind of monad functionality in Guile which he uses for geeks. I'm kind of using it for something else. And it's basically just really because Guile supports I.O. operations natively so it doesn't really need it but it's just a kind of somewhat computationally expensive way to maintain in your head clear boundaries between I.O. and functional operations. Whether it's useful is up to you.

I mean, I think it's quite useful but you can say that the price is too high. That's basically the overview of what kind of this thing does. I don't know how I'm doing on time. I think I'm doing alright actually. Perfect. So like I said before the declarative specification grammar is not super yet so I'm kind of thinking about how to improve that.

I'm a bit worried about kind of releasing 0.1 if I'm going to rewrite this because obviously that would kind of break things a little bit so I might just release 0.1 anyway. And there are a few issues with the getoblong library at the moment because it actually at points just exits.

For example, getoblong kind of allows you to check with predicates whether the incoming value matches what you expect it to match. So you could, for example, check for specific values like if you want input to either be success or failure like the string success or failure then getoblong can check whether it actually matches success or failure but at the moment if it doesn't

then it just exits the program and really what it should do or at least for my purposes what it should do is throw an error so I can catch it and then actually do some more processing. So I might hopefully and you can hold me to this if you want submit patches to the Gao community to try and implement that. And there are also some corner cases there's the whole kind of well

there's a question of what happens if you have name collisions somewhere in the configuration, nested configuration I haven't actually tested that yet so I should probably kind of do some testing or I might just not do it and if someone runs into it they can tell me and then I can work it out and there's also the special kind of dash dash command line option which many programs support which basically means stop processing command line arguments and take the rest as input to the program

that's not supported at the moment. And yeah there's also questions about positional arguments arguments that don't actually have a flag you know you have a program that just you know just literally expects let's say the target file name so you just literally pass the file name as the first argument you don't actually have a name for that argument

it's just a positional parameter I'm not doing anything clever with that and I think there's potential for doing clever things with that as well so I might look into that but that's for the future. You can get it at the moment it's hosted on GitHub which I have a love-hate relationship because it's super simple but it's ambivalent on free software things it's doing the right things in some ways

but it's not like entirely free software so I'm ambivalent towards it it's really easy to use you can get it from there for now and you can basically do the usual thing if you clone the directory if you clone the repository you can do auto recon and then configure and then make install and then it's fine or make and then make install and I also have an experimental Geeks recipe which as well

I will be submitting once I've released 0.1 fully and actually have an archive with the release table so I'll submit that to Geeks as well and then we can just use it that way and I think that's it the answer of joy to end with yay any questions? Anyone?

You don't? Yep What about internationalization? I have not focused on internationalization at all yet so I guess it's for configuration specification that's why internationalization is important because that's where it parses the strings yeah, actually that's a good point I've not considered that yet

I thought it was an internationalization free program but it's not, you're right I should implement that I can use the wonderful get text module that's part of GAL as well for that I would think so I will do that good point any other questions? okay, thank you Thank you Alex