Thanks for writing another yarn implementation, the testing tool. I
too welcome it. It helps to have different takes on how it should
work, and to drive in the point that there should really be a formal
specification for the yarn language.
I don't currently have time to work on yarn, being busy with a slew of
other personal projects. A couple of years ago Daniel and I happened
to be in front of the same whiteboard and came up with some ideas for
improvements, documented in the link Daniel posted. Since then I've
felt that it'd be nice if yarn tests were easier to debug, but I
haven't got any concrete ideas for how to achieve that.
On Mon, Feb 11, 2019 at 12:36:38PM -0500, Richard Ipsum wrote:
On Mon, 11 Feb 2019, at 08:49, Daniel Silverstone wrote:
> On Sun, Feb 10, 2019 at 18:14:26 -0500, Richard Ipsum wrote:
> > Perhaps slightly odd to post this here, but I know for certain that there are
> > two yarn devs on this list and one contributor.
>
> As one of those, I don't mind :D
>
> > Recently I've been playing with OpenBSD and found that I wasn't able to
run
> > my yarns there, so I wrote Tiny Yarn, which is a quite hacky implementation
> > in Lua/C.
>
> Interesting. What in C did you need which Luxio et al. didn't provide for you?
I could have used Luxio, but I wanted to keep dependencies to an absolute minimum,
this started off as a pure C project but I decided I didn't want to do string
handling in C.
I'm in favour of keeping dependencies to a minimum, as long as it
doesn't result in too much extra work for the implementor.
I've not had time to try tinyyarn, but if I did, I'd be mostly
concerned about having to convert my PCRE regexes to plain POSIX ones.
Most of my yarns use PCRE extensions, I think. I used them originally
because, well, Python supports them out of the box.
If we decided to do a deep re-think of yarn, and re-design it from
scratch, this would be one of the things that would be thought about.
Some day.
--
I want to build worthwhile things that might last. --joeyh