ime scheme/racket really likes to shift rightwards; imo comment on the line above is preferable most of the time
Rightward drift is unreadable and should generally be avoided, for example by using internal definitions instead of let, by using cond instead of if, and by using match-define.
Line comments instead of trailing comments sounds like a reasonable addition to that list of guidelines
One possibility is store it in S-expression format, and parse it with read :slightly_smiling_face:
Make it a #lang!
lang info ?
That’s certainly one option. But quotation is pretty confusing and using lists-of-field-values instead of structs / dicts is very painful in config files.
Just joking. Is ini files just single lines with name and value separated by …mumble… ?
¯_(ツ)_/¯
@nma.arvydas.silanskas There is a #lang r7rs by @lexi.lambda: https://github.com/lexi-lambda/racket-r7rs
Also, I happen to think web development is a particular strength for Racket! I use it for everything at https://digitalricoeur.org, for example.
@soegaard2 most of the time. I’ve written a few python INI parsers because the builtin one confuses reading a configuration (and syntax) and manipulating the configuration
I played with it a bit, but I didn’t find an appeal for continuation based approach (in terms of memory footprint as well as persistency; url expiration wasn’t nice at all). Dealing with hashmaps to structs and back conversion was kinda pain. Also it’s not really clear how structure big application. (fwiw my daytime job is webdev with spring-boot framework)
@nma.arvydas.silanskas I agree re: the continuation based approach, but there is a lot of great functionality built-in for stateless web requests that don’t use continuations.
one pain point for the yaml package is that it doesn’t produce hashes in valid jsexper form, you have to convert the keys to symbols yourself
I also seriously considered switching my general config format over to sexps since yaml is a terror to parse, but since most languages have a yaml parser already I stayed with it
@nma.arvydas.silanskas, were you using stateful continuations? I recommend the “automatically REST-ful” continuations with #lang web-server, which should avoid memory footprint and persist forever by default. (Or, they persist until you make some change to the source code, when they deliberately expire to avoid bugs.) And serializable-struct in a few key places—fewer places than I initially thought—means there is no explicit data conversion needed. I find that I use continuations in a few specific parts of my app where there is an interaction with the user spread out over several requests. There, they are very convenient and save me from many bugs. In many parts of my app, I don’t need or use continuations at all. You can use the Racket web server entirely without continuations and write your apps the same way you would in any other language. Even then, the fact that the web server is integrated into the programming language makes it easy to do interesting things like run a reverse proxy that shares authentication logic with your Racket-implemented app. (I spoke about this at RacketCon.)
Hmm can you elaborate on serializeable-struct wrt converting to and from json?