guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing "stringly typed" data structures in Artanis


From: Amirouche Boubekki
Subject: Re: Fixing "stringly typed" data structures in Artanis
Date: Sun, 13 Dec 2015 20:41:32 +0100
User-agent: Roundcube Webmail/1.1.2

Le 2015-12-10 23:02, Thompson, David a écrit :
[ Changing the subject for this little rant below ]

I guess this is as good a time as any to voice a concern that I have
with Artanis before too many people depend on it and its not feasible
to change it.

Artanis is alpha nobody expects to code against it without having to change things
here and there.

In Scheme, we have the luxury of being able to easily
create embedded domain specific languages or otherwise take advantage
of s-expressions to avoid the tiring work of writing parsers and
interpreters for new languages.

tldr: Artanis should use a sexp instead of a string to declare URL patterns.

For an example that uses more proper Guile
Scheme idioms, take a look the source for the 'guix publish' tool in
GNU Guix. [0]  By viewing a URI as a list strings, we can represent
"/user/1" as the list ("image" "1").  From there, it's easy to use a
pattern matcher to match this route:

    (match uri (("user" id) (display-user-info id)))

From there we can get more advanced and assert various things about
"id" in the match expression, as 'guix publish' does with its routes.

It's more proper Guile (Scheme?) idiom but it's not enough. In particular
the code of guix publish doesn't handle various cases like

  '/article/1337-diy-a-web-framework'

where the split is not only done around slash. I'm not saying it's not
possible but the solution is not that simple.

AFAIK working with Artanis is still a win compared to getting guix publish
code working.

[...]


I hope this has made some sense.  I think Artanis is a great project,
and I hope issues like this can be fixed [...]


The rant falls short I guess.

This is a rather scary mail which would better fit the bug report format.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]