But the following might be easier syntax extension in Scheme, in which each variable URL path element can be mapped for the programmer directly to a Scheme variable binding in the closure:
IIUC, this is the handler for all requests, not just `GET` with path `/hello/<NAME>`.
It doesn't implement what many Web "backend" developers now call "routing", which means the programmer specifying a rule-based mapping of URL patterns to a set of handlers for different kinds of requests using a simple DSL, and then at run time the library/framework performing the parsing and dispatch based on those rules.
With that stock Guile library only, I think you'd instead have to manually parse the `request` argument, like in this example:
Why not keep the string as normal, but still do as you are suggesting? Shouldn't be too hard to have the macro parse it out so that the following would work, no?
Yes, with some of the fancier Scheme/Racket syntax transformers, you can do that string parsing at syntax expansion time.
Sometimes it makes sense (e.g., if you want to support chunks of hairy SQL pasted into the code).
I could go either way on how to specify Web server routes, but decided to go with the way I did, for 3 reasons:
1. Looks more familiar to Scheme programmers, without bindings coming out of strings (which I don't think is idiomatic Scheme).
2. Can be implemented more portably, including in Schemes that have only `syntax-rules` as a transformer.
3. If more semantics are added to the route specification later, such as type or validation, you might want want to be doing it in s-expressions rather than in a string.
Prevents the confusion of people that remove a parameter from every path it was in, without also removing the parameter it would have bound to. Though, I suppose you would probably need to do a bit more to allow moving from query to path and such?
IMO the whole point is to get rid of the string as normal. The whole "/hello/:who" syntax is weird and arbitrary, it is a different way of declaring a variable which adds an unnecessary extra step to understanding the code.
Maybe you can answer one thing that pickled my mind, no mention of CSRF protections,etc in the documentation that seems to cover quite a few bases. (apart from one xss symbol application that I couldn't fully decipher).
XSS should not be a problem with many Scheme dialects and Lisps, unless you render JS from user input. This is because SXML does not treat HTML as a mere string, but as structured data (as any sane library should, but very few do). So if you get some user input and want to display that in some label or paragraph or whatever, then SXML is aware what is a tag and what is text content of the tag, due to how you build the SXML expression. This is not PHP or something.
I do not know, whether GNU Artanis makes use of SXML all the way, but I think it is very likely, since SXML is in GNU Guile's standard library.
You're talking about injection attacks when escaping isn't present.
CSRF is cross site request forgery, f.ex. creating a POST form on a hostile site that targets a POST processing endpoint in on site with data that the user didn't want to supply, but whose login cookie would authorize the request at the target.
Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct CSRF-cookie.
Even if it is structured data, it's ultimately passed to the browser as a string. If I put text in between two tags, and that text came from user input, how is it going to solve that? Does it autoencode as html entity tags anything coming out in a text node?
While working on the HTML document in your program, you have it always represented as a tree of nodes, a nested list often. When you want to insert user input, that user input is available as a string (unless you first turn it into something else). When you put a string into that nested list, and then at the very end, when you form the response, ask SXML to turn your tree into the HTML string, SXML will error, because it wouldn't know how to handle the string.
(All the other nodes are symbols with potentially subtrees in them, which are also symbols with potentially more subtress in them.)
If you put your user input into one such node as a value of that node, lets say a paragraph tag <p>, then SXML sees the user input as it is, a string. It will make sure, that when it turns the tree into HTML, that string remains merely a string, by escaping things, so that for example when your string is <evil-tag-with attrs="bla"> this is exactly what will be seen as text inside your paragraph text, and not be interpreted.
Basically, SXML will render it like: "Oh, you want some string to be inside your p tag? Sure, can do ... This is what you wanted to be displayed to the user ... You didn't want to run that, did you? Nahh, because then you wouldn't have passed it in the SXML as text content of a p tag."
I don't think it uses some special type in any way. Rather, if you use sxml to build html in scheme and have a node in there that is a string, then the natural way to serialize this sxml into html will be to safely quote the string. Afterall, if you wanted html tags to be preserved and interpreted in the output, you would first parse the string into sxml and put that into your document. This is the difference between working with structured data vs. plain string interpolation.
But of course this only applies when you use sxml. Artanis apparently can also use plain strings or templates as responses, in which case you will have to take care of safely encoding things too.
SXML is a fairly old thing, but it isn't really typed. [0]
Rather, things are structured, so it's more like a in-memory representation of XML. It doesn't need to be serialised, only deserialised into XML's text syntax. In which case, each piece knows how it needs to be encoded.
'(h1 (@ (id "greeting")) "Hi, there")
Its just lists of Symbol types, and string or other type values.
This is an example of clickjacking protection, CSRF is cross site request forgery, f.ex. creating a POST form on a hostile site that targets a POST processing endpoint in on site with data that the user didn't want to supply but whose login cookie would authorize the request at the target.
Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct cookie.
If your problem is in authorisation, then it will be in your business logic, of what a user looks like, what the hierarchy is, and so on. It shouldn't live in your framework.
And the standard ways of doing that, generating single use tokens, will work the way they usually do.
As I said... I didn't use cookies. Which means none of what you listed applied in the first place. Logins were entirely ephemeral and died after a single session ended - as pains were taken to ensure anonymity.
I have to wonder why Guile hasn’t become more popular over the years, frameworks or not. It ships with so many distributions that the ease of access is there, but I’ve yet to come across any significant code base using it for web apps.
Little tooling: you need to use Emacs and there's no LSP, no great debugging capabilities, no great testing libs, etc
Bad docs for beginners: the docs are very complete in terms of coverage and yet have no tutorials or explanations in how to use Guile properly.
Very little visibility as well, Scheme is already a niche. By catering to only the most FOSS oriented/adamant part of the public, your pool of devs is very tiny.
Most guile libs can also only be installed through Guix or failing that, tar files.
The ergonomics of the language are bad and there no concerted community story and publicity around it either imo.
It's sad because it's a cool language and the efforts Wingo and people like the Spritely institute have put into it, are amazing.
The LSP is the biggest missing piece for these niche languages.
In my perspective the reason why it still hasn't taken over is because it's not a focused and supported effort. In my understanding Guile should have been "the GNU scripting language" but the integration is nowhere near what a universal language would be (GNU Make integration is disappointing and totally not what I was expecting).
Then the fact that the project seems to be hopping between different directions (last time I checked they wanted to be a runtime for more than one language).
And they also lived their own Python2 -> Python 3 "migration pain". (In my above gist, I specifically had to compile Guile from source because at that time some application with a hard dependency on Guile2 wasn't getting updated in Fedora, which was holding back the Guile v3 rollout).
This LSP performs reasonably well and having used it I'm not sure it's fair to call it "experimental". There's certainly some room for improvement in the code (e.g. diagnostics don't seem to run consistently with every change was the big one for me).
The greatest barrier I had with it was the installation.
That is why I created https://codeberg.org/ZelphirKaltstahl/guile-examples. I like GNU Guile and many things exist, even in the batteries that are included, but are not easy to find or one needs to figure out how to effectively use them. Also got an awesome list somewhere, but I need to migrate that to codeberg later.
Compared to some other languages, the ecosystem is small though. While in Python often you have 3 or 4 libraries solving the same or similar problem, in GNU Guile you often only have 1 or need to write your own. Knowledgeable people are able to quickly throw something together, or call out to C libraries using FFI, but I have not done FFI yet. Some day I really should look into that ... And into Hoot by Spritely Institute [1]
If one wants to check out more algorithmic stuff, I also have some stuff on that: AoC 2024[2] (and previous years too), and guile-algorithms[3] (not that much yet, but useful things, and trying to keep it fully functional). Some time ago I also wrote a toy implementation of a decision tree in Guile[4]. It is even parallelized and achieves linear speedup in my tests. I call it a toy, because you will have to do all the data preparation yourself, because it only deals with numbers, and there are probably smarter ways of storing the data for each node, maybe even avoiding duplication. There is also no library like numpy or dataframes like in Python, so I am using possibly not so optimal data structures. But it is probably worth checking out and adapting, if anyone wants to make a proper decision tree library. It is a start.
Guile is supported by conjure in neovim. It's a nice alternative to emacs, has some nice repl integration, and recently includes some autocompletions without an LSP.
Making it clear that I never worked with Racket... Guile was the most ergonomic Scheme I used. Great documentation, "mostly" batteries included, and a while loop macro (the blasphemy, but the convenience!).
The reason I switched was that I wanted to use my small programs on servers, and with Chicken Scheme it was easy to build a statically linked executable. Guile should definitely be packageable as such, if someone versed in C has the patience, but it isn't out of the box and there are no "project templates" out there.
Just my personal opinion: Racket and Gerbil Scheme are the most useful Schemes because of their fairly rich standard libraries. There are other Schemes I like to play with but I don’t do much with.
Sorry for the plug, but I wrote a Racket book last year and I am just now about 20% of the way through a Gerbil Scheme book. I have a luxury: I am retired so I can write on topics that fascinate me, even if I get small audiences.
And was a gag in the ancient Dick van Dyke show, where Dick's character gets a painting signed by `Artanis', and thinks it worthless, until someone spells it backward.
I so appreciate the website. So easy to read makes it appealing to try the framework, especially taking into account the most recent experience writing on Scheme was back in college 15 years ago.
Beautiful and clean website (loads well without JS and fonts); not sure why some people are reacting negatively to some poetry... I swear, HN crowd can be often worse than Mean Girls.
About Artanis itself... It looks really cool! Scheme is such a nice language to code and hack with; but, how safe would it be to expose it directly?
I see they are dogfooding on the Guix packages website, so... I'm guessing it's pretty well tested.
> Scheme is such a nice language to code and hack with; but, how safe would it be to expose it directly?
If you have really good Scheme programmers, who know their system, and built it competently, it's probably safer to expose that than your average conventional system.
(Example: A system in Scheme was the first to get a particular certification for sensitive data hosting on cloud servers. Partly because the very small team that developed it knew the stack inside and out, and could do whatever needed to be done, in a smart way.)
(Meanwhile, say, a consulting firm-led team who got a contract for a comparably complex system, and billed for 10 or 100 times the seat-warmers, with huge and ridiculously complex stacks they didn't understand... would just flounder, focus on appearances in sprint tasks, and churn out things implemented in poor ways, and with a large number of vulnerabilities, and probably take a lot longer before they could deliver a system that would survive the first day of use.)
In my experience this sentiment could be applied to anything. It's more about getting paid for "getting thing done" versus "working on thing".
I have particular personal experience with an app that could be done within several months with handful of people but was developed over several years by team of 50. I was flabbergasted at first but you need to understand politics first.
I can't fail to remember a joke about a law firm where the son of the most senior partner graduates from an ivy league university, joins the firm, and on the first day says he single-handedly sorted out one long-standing case. His father is angry: "You have just put an end to the case which was feeding us for last three years!"
Facing an avalanche of troubling, attention-grabbing, manipulative, and often misleading information, people protect their sanity by irony and nonchalance. A genuine expression, which does not employ irony and invites the reader to also cast away the shield of cynicism, feels both like an attack and the pull of something desirable but unattainable. The resulting pain, modulated by the protective irony, is expressed as cringe.
That's a great thing. Sites which restrict text to a narrow column are a horrible reading experience. I have a large monitor and I wish to use a large monitor!
> not sure why some people are reacting negatively to some poetry...
As another commenter pointed out, the poem is a parody of a Yeats poem. An an extract from another of his poems might offer some insight into the reactions...
The poem actually loaded, but then flipped to that. Thank god Yeats' work is protected by clever JavaScript from people in third-world countries who dare try to read it.
If you're defining a Web server route handler, it's reasonable to do it as you would in most languages, like this package's example:
But the following might be easier syntax extension in Scheme, in which each variable URL path element can be mapped for the programmer directly to a Scheme variable binding in the closure: (Of course, you'd also have a function to sanitize/escape `who` before injecting it into the HTML.)reply