If you are paid monthly, then it makes sense to work on a monthly budget. Many expenses are paid monthly, so this works out quite nicely.
However, some things are paid quarterly, or even yearly. If those things are big enough that they can't just disappear into the noise of your monthly budget, you need to budget for a share of them each month, and put that money aside somewhere to save up for the annual costs.
And some things are paid weekly, or (worse) every four weeks. We used to have a self-storage room that cost us about two hundred pounds every four weeks, which was a royal pain as sometimes this meant we paid £200 a month, and sometimes £400. It was hard to lose THAT in the noise.
So, I decided to write some software to work all this out for me.
Read more »
I've always liked syntax diagrams as a way of describing languages. They make it clear what options are legal in any given situation.
However, drawing them by hand is tedious, so after a moment's thought, I realised it would be pretty trivial to design a reasonable layout algorithm to generate them automatically.
And so, on a train journey, banterpixra was born!
It's quite simple. It takes a BNF-esque grammer, encoded in s-expressions like so:
(rule
. (choice
rule-label
literal
(seq "(elidable" " " literal ")")
(seq "(optional" " " rule ")")
(seq "(zero-or-more" " " rule ")")
(seq "(one-or-more" " " rule ")")
(seq "(seq" (one-or-more (seq " " rule)) ")")
(seq "(choice" (one-or-more (seq " " rule)) ")")
(seq "(optional-choice" (one-or-more (seq " " rule)) ")")
(seq "(comment" " " literal " " rule ")")))
...and it turns it into a nice syntax diagram, rendered as an SVG file. I found producing an SVG to be a very easy way of generating vector images - SVG is quite a decent format to generate, and inkscape will happily convert .svg files to .png and .pdf from the command line, so it's easy to automate rendering.
The layout algorithm is quite easy. The BNF is parsed, and a tree of layout objects generated from the bottom up. Layout objects may contain other layout objects, recursively, and cover a rectangular extent of the two-dimensional plane. New layout objects are created at the origin, and then the parent layout looks at the sizes of the child layouts within it, and relocates them to appropriate locations within itself. When the layout object tree has been generated, it's processed top-down to generate actual SVG. Each different type of layout object renders its children recursively (unless it's a terminal, in which case it just renders itself at the chosen location), then it adds the arrows and lines that join the children together.
That's really all there is to it.
The output is quite decent, if your browser supports SVG!
I've not had much time to hack on Ugarit lately, which is a shame - but just to keep you enthusiastic, here's my current roadmap.
Read more »
There has been recent discussion on r6rs-discuss about the r7rs draft charters, most of it arguing from various camps.
I want a Scheme that lets me apply advanced programming language techniques - lightweight Higher-order functions and Hygienic macros rather than Boilerplate code, Continuations rather than a fixed set of predefined Control flow mechanisms, symbols rather than Enumerated types, Functional programming rather than getting tangled with too much state, dynamically-scoped parameters rather than God objects - to my day-to-day tasks. I'm a professional programmer; for a living, I've written code in Java, C, C++, PHP, Perl, Python, Ruby, SQL, AWK, shell and JavaScript, and I'd love to have been able to use Scheme for all of the above. I'm limited more by the usual commercial pressure than by any technical issues with Scheme or the qualities of my favourite implementation, Chicken, so my wishes for R7RS are relatively minor in terms of changing the semantics of the language. What I really want is a Scheme report that will unit the Scheme community, so we can continue to have a wide array of innovative implementations that all have their own strengths and weaknesses - but with much better portability of libraries between them, so they really do start to feel like one language with multiple implementations rather than separate languages.
So I feel that things like module systems and access to networking needs to be standardised, so each implementation doesn't gratuitously have their own syntax for doing the same thing. But these things need to be optional, so implementations are not constrained to be large in order to earn the name "R7RS Scheme".
So I thought I'd step up and propose a solution.
Read more »
One of the neat things in Unix is that you can make 'shell pipelines' of commands, from a suite of tools that come with most Unix systems, by feeding the output of one command into the input of another.
Read more »