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 »
Most people who like to use "unusual" non-mainstream language have to have a motivation for doing so. After all, there are reasons not to - a smaller user community, although that can be a good thing, means less libraries, less support for more unusual platforms, and less likelihood of your programming in that language ever earning you money.
When asked, most will say that they find programming in their chosen language easier, but it can be hard to explain why.
However, in a discussion in IRC recently, I think I may have captured part of it:
- alaricsp: I do a lot of programming in various languages, and I tend to find that the amount of coolness I can do per line in Scheme is higher, and I get less bugs
- alaricsp: As in, I decide to do something complex, sit down and write a hundred lines of scheme, try to run it and get lots of syntax errors due to typos, fix those, then it's semantically bug free about 75% of the time; and in the remaining 25% there's usually just one simple bug (last one was due to me getting confused with some boolean algebra over lists, doing an any? instead of an every? or something like that)
- alaricsp: I start in implementation space and build up in thin layers to get to problem space
- alaricsp: Cheap easy-to-use abstraction means it's cost-effective to have lots of thin layers
- alaricsp: And thin layers are easier to think about, so less buggy
To which somebody else followed up:
- sjamaan: Aye
- sjamaan: I find the barrier to creating an abstraction in OO languages to be very high, for example
- sjamaan: I actually sigh everytime I have to create a new class file!
- sjamaan: Whereas I don't even think about creating a lambda
- sjamaan: I just do it
Computing, Scheme | alaric | 
Wed 28th Jul 2010 6:20 pm | 
Comments (0) 
Subscribe
