I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

Reading my own #SRFI and cringing. It's not that bad, I must say. But the whole oscillation between formal and informal language is disorienting. Like, Artyom, be more organic in your destruction of formality. Embrace the chaos. Reign the ruins of the standard.

Something to look up to in my next SRFI.

I regret not including return type/shape check in #Scheme SRFI 253 define-checked. It feels so obvious in the hindsight—typed functions should have return type listed in their definition. But past me didn't consider that for some reason.

Time for a new #SRFI?

Another bucket list item for 253 is having type support built-in, instead of relying on generic predicates. Say, by specifying typed? special syntax. As in

(check-arg (typed? long long) (factorial 23))

instead of using implementation-specific facilities and extending SRFI 253 primitives with them.

But then, providing literal implementation-specific types is not portable, so it's a smart decision I made sticking with standard predicates. Just a bit of extra work making it first-class on every implementation.

Look at what is coming to Scheme ecosystem:

https://nlnet.nl/project/SchemeTestingFramework

#scheme #guile #lisp #srfi #srfi64

A new SRFI-64 implementation by @graywolf is merged into Guile: https://git.savannah.gnu.org/cgit/guile.git/commit/?id=ad90f45a8c4fd00add44c214863850a425f787a0

#guile #scheme #lisp #srfi #srfi64

Examples using #srfi 125

https://gist.github.com/shegeley/d42e737b7d758c3ec7fb6e9918abe81b?permalink_comment_id=5068917#gistcomment-5068917

#hashtables #guile #scheme

Researching #srfi 125. All I need is hash-table=? in guile.

It was broken in the "upstream".

Fixed in this pull request https://github.com/scheme-requests-for-implementation/srfi-125/pull/11

Trying to build and use with #guix.

After "guix build -f srfi-125.scm" or "guix shell -f srfi-125.scm guile -- guile" it builds with no error, but guile won't see the module. Although when I just do
"guile -l srfi/125.body.scm -l 125.scm"
or
"cd <build-dir/share/guile/site/3.0/srfi>; guile -l srfi/125.body.scm -l 125.scm"
works fine.

Hot take: in terms of the language specified treated independently of the social process of standardization itself, everyone's beloved #r5rs is actually the worst post-#r4rs scheme, and #r6rs is easily the best and most revolutionary, hence the controversy surrounding it.

#lisp #srfi

SRFIs are modules, which are portable across different scheme implementations, also there is a process for proposing them. BTW, guile contains only subset of it.

ice-9 are basically guile modules, which could be (guile ...), but they are (ice-9 ...).

https://srfi.schemers.org/srfi-process.html

https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html

#guile #scheme #lisp #srfi #guix