(Background: 12 Projects in 2013)
I wrote a bit about the general experience of programming in Icon a couple of weeks ago. This post is a brief post-mortem about a project that I tried to build using Icon. I'm not planning on releasing the source, because I don't consider the results very useful except as a personal learning experience about the Icon language and the problem domain. (And because I plan to rewrite the software in next month's new language: Go.)
The goal is to parse a book written in slightly-augmented Markdown into either HTML or "standard" Markdown so that other tools that consume Markdown can be used to generate friendly formats like PDF or ePub.
I was inspired by dexy, which works reasonably well, but I found it cumbersome to use.
The limitations in standard Markdown that I intend to augment are the
ability to include files, and to include the output of shell
commands. I added support for the syntax
!!directive args...; where
the processing tool defines a handful of directives, e.g.
bash_interactive, etc. These could be used, as in dexy, for ensuring
that code samples are correct, and that the output from these samples
is properly reflected in the text of the book.
As far as doing this in Icon goes: the language's string-handling
facilities made parsing Markdown easy. The problem I ran into that
caused the most difficulty is that Icon doesn't provide a good
mechanism for grabbing output from subprocesses. The
takes a "p" flag for reading/writing from/to a subprocess, but it's
nowhere near as rich as Perl, or, say, Python's
module. For one thing, there's no built-in support for capturing
both stdout and stderr. Also, it isn't obvious how to check the exit
status of a subprocess spawned via
If I was committed to using Icon for this project, I could have written C functions to provide better subprocess/pipe support, but the end of the month is approaching and I think it makes more sense to treat this as a prototype and rewrite it in Go (a language with a strong future) next month.