I’ve implemented preliminary support in extensible-match for running on Guile, using module reflection to implement pattern syntax lookup instead of identifier properties.
There is one outstanding issue (pattern syntax bindings within the local scope of a block may have non-local effect), so it isn’t merged into master yet. But I would like to encourage people to try it out and see what they think. Hopefully version 0.75 (which will come out with draft 2 of the SRFI) will make this support official. <https://codeberg.org/dpk/extensible-match/src/branch/guile-support> I should warn in advance that pattern match expansion is unfortunately pretty slow. Just a simple (match '(1 . 2) ((cons a b) (values a b))) takes about half a second to expand on my machine. The test suite takes about four and a half minutes to compile and run. This is mostly just an unfortunate consequence of the somewhat brute-force approach I have to take to find pattern syntax in imported libraries – I don’t think there’s much more I can do to optimize it :-( This only affects expansion and compile time, though. Expanded patterns seem to run and optimize just as well under Guile as they do under Chez. Sequence pattern matches seem maybe a little slow, to judge from the test suite timings. Hopefully when Guile gets real identifier property support (Ludo told me today on Mastodon he thinks it would be nice to have them), expansion performance will be much more tolerable. This does demonstrate that implementations can, in theory, use other mechanisms than full identifier properties to implement pattern syntax definition and expansion for SRFI 262. (It also demonstrates how flexible the traditional Lisp evaluator style of implementation is.) I hope I’ll have time later in the week to fix the known problem with local pattern syntax definitions. If you find any others, please let me know. Daphne
