Knitting is an acceptable Lisp So, I'm a knitter. And I pretend to be a designer some days, when I'm not knitting endless swathes of k2, p2 rib. But first and foremost, I'm an unabashed geek. As such, I took a look at KnitML. And it's neat. Well, in theory, it's neat. In practice, I haven't got the java dependencies set up on my computer yet to play with it. I do intend to do that, and am downloading them, but while I wait for them, I want to ponder through an idea that's been percolating in my brain. Namely, I think of knitting patterns in two ways. One is the chart. This is how I write patterns, really. And given the choice between a chart and a list of stitches, I'll pick the chart every time. It's a question of information density. The chart presents all the information that I need, in the least amount of space while still being human-readable. So, let's look at a chart. It's a fairly simple pattern, embedded moss stitch rib. And can be easily transformed into a written pattern: p2, k2, p1, k1, repeat to end of round p2, k2, p1, k1, repeat to end of round p2, k1, p1, k2, repeat to end of round p2, k1, p1, k2, repeat to end of round This is where my brain starts making clicky noises. See, my immediate reaction to that is that it's a simple program. One that generates a handsome little ribbing. However, my second line of thought runs straight for a programming principle: Don't Repeat Yourself. My process for generating a pattern is to draw charts in Inkscape, test those charts by knitting them, then translate the chart into written instructions. In future, I may also want to make my charts available in KnitML. What this immediately says to me as a programmer is that I should have a single piece of data from which I can generate: PNG graphics

This is the format I use to show charts. It's a useful format in that it does a good job of reducing low-colour line drawings (like knitting charts) to a fairly small file size with no loss of detail or crispness.

This is an even worse format to use as a data source, though. Rather than just interpreting the XML that SVG gives, I'd have to start into OCR territory.

This is the format I use to show charts. It's a useful format in that it does a good job of reducing low-colour line drawings (like knitting charts) to a fairly small file size with no loss of detail or crispness. This is an even worse format to use as a data source, though. Rather than just interpreting the XML that SVG gives, I'd have to start into OCR territory. SVG graphics

This is the format that I actually use to make charts. Unfortunately, it would be a considerable effort to use it as a starting point: Anything more complicated than a knit or purl stitch are relatively complex "groups", rather than simple objects.

However, they work admirably as a way to draw charts, and from my perusal of the spec, should be able to be drawn programmatically fairly easily.

This is the format that I actually use to make charts. Unfortunately, it would be a considerable effort to use it as a starting point: Anything more complicated than a knit or purl stitch are relatively complex "groups", rather than simple objects. However, they work admirably as a way to draw charts, and from my perusal of the spec, should be able to be drawn programmatically fairly easily. HTML lists

This actually isn't a bad starting point. Not good enough that I'd want to use it as a data source, but not bad enough, either, to discard it out of hand.

Specifically, if I look at the HTML describing the pattern: <ol>

<li> p2, k2, p1, k1, repeat to end of round

<li> p2, k2, p1, k1, repeat to end of round

<li> p2, k1, p1, k2, repeat to end of round

<li> p2, k1, p1, k2, repeat to end of round

</ol> Other than the <ol> and <li> tags, this actually isn't a bad representation of the data at all.

This actually isn't a bad starting point. Not good enough that I'd want to use it as a data source, but not bad enough, either, to discard it out of hand. Specifically, if I look at the HTML describing the pattern: Other than the <ol> and <li> tags, this actually isn't a bad representation of the data at all. Plaintext

What if I were to use the plaintext representation of the aforementioned list: p2, k2, p1, k1, repeat to end of round

p2, k2, p1, k1, repeat to end of round

p2, k1, p1, k2, repeat to end of round

p2, k1, p1, k2, repeat to end of round

That's actually, as I alluded before, a programmatic representation of knitting. And, were it not for that pesky "repeat to end of round", would be nearly perfect.

In fact, this is relatively close to what KnitML uses as a human-readable format, according to my reading of the spec.

What if I were to use the plaintext representation of the aforementioned list: That's actually, as I alluded before, a programmatic representation of knitting. And, were it not for that pesky "repeat to end of round", would be nearly perfect. In fact, this is relatively close to what KnitML uses as a human-readable format, according to my reading of the spec. S-Expressions

These little gems are the core of Lisp, and are easily transformable to and from XML if the need arises.

The core elements to them are lists and atoms. A list is multiple atoms surrounded by parentheses and separated by spaces. An atom is some text representing something.

Thus, the pattern described above becomes: (repeat 2

(repeat-to-end (p2 k2 p1 k1)))

(repeat 2

(repeat-to-end (p2 k1 p1 k2)))

And any Lisp programmer reading this just started twitching. As that's not properly-formed Lisp. On the other hand, it does represent a very interesting way to mix data and instructions.

Patterns become lists of stitches and transformative operations performed on those stitches. It's knitting as a pseudo-mathematical notation. So, taking s-expressions as a base, what does it all mean? Well, in that list of representations, the further along I went, the more the representation changed from being a depiction of the data to a representation. By the time we reach the plaintext version of the pattern, it is recognisable as a rudimentary program. The s-expression version isn't even a rudimentary one; if it were fed into an interpreter that recognised the words and symbols used, it is a program to generate a knitting pattern. Now that offers some interesting prospects, because the output of the interpreter by no means has to be fixed. For instance, I could have one interpreter that reads the pattern as a way to generate a plain text file, another interpreter that generates an SVG graphic and a third that reads the pattern as a way to generate the equivalent KnitML file. Why does all this matter? Well, I've become interested, in the past weeks, in the idea of an editor where I type in a row of stitches and it appears on the screen as a graphical pattern. Thinking about how to represent stitches is a first step on the road to knitting pattern zen. Newer Post Older Post Home