|
21 April 2023 10:00
It seems I'm having a theme recently on this blog, of making emacs-related posts. Here's another.
I write a bunch of stuff in markdown, such as my emacs init-file, blog-posts and other documents. I try to be quite consistent about vertical spacing, for example a post might look like this:
# header1
Some top-level stuff.
## header2
Some more details.
## header2
Some more things on a related topic.
# header2
Here I'm trying to breakup sections, so there is a "big gap" between H1 and smaller gaps between the lesser-level headings.
After going over my init file recently, making some changes, I noticed that the spacing was not at all consistent. So I figured "How hard could it be to recognize headers and insert/remove newlines before them?"
A trivial regexp search for "^#" identifies headers, and that counting the "#" characters lets you determine their depth. From their removing any previous newlines is the work of a moment, and inserting the appropriate number to ensure consistency is simple.
I spent 15 minutes writing the initial implementation, which was markdown-specific, then another 30 minutes adding support for org-mode files - because my work-diary is written using the org-diary package (along with other helpers, such as the org-tag-cloud.
Anyway the end result is that now when I save a markdown/org file the headers are updated automatically:
Tags: emacs
|
24 February 2023 10:00
As I've mentioned in the past I keep a work-log, or work-diary, recording my activities every day.
I have a bunch of standard things that I record, but one thing that often ends up happening is that I make references to external bug trackers, be they Jira, Bugzilla, or something else.
Today I hacked up a simple emacs minor-mode for converting these references to hyperlinks, automatically, via the use of regular expressions.
Given this configuration:
(setq linkifier-patterns '(
("\\\<XXX-[0-9]+\\\>" "https://jira.example.com/browse/%s")
("\\\<BUG-[0-9]+\\\>" "https://bugzilla.example.com/show?id=%s")))
When the minor-mode is active the any literal text that matches the pattern, for example "XXX-1234", will suddenly become a clickable button that will open Jira, and BUG-1234 will become a clickable button that opens the appropriate bug in Bugzilla.
There's no rewriting of the content, this is just a bit of magic that changes the display of the text (i.e. I'm using a button/text-property).
Since I mostly write in org-mode I could have written my text like so:
[[jira:XXX-1234][XXX-1234]]
But that feels like an ugly thing to do, and that style of links wouldn't work outside org-files anyway. That said it's a useful approach if you're only using org-mode, and the setup is simple:
(add-to-list 'org-link-abbrev-alist
'("jira" . "http://jira.example.com/browse/%s"))
Anyway, cute hack. Useful too.
Tags: emacs
|
28 December 2022 10:00
This year had a lot of things happen in it, world-wide, as is always the case.
Being more selfish here are the things I remember, in brief unless there are comments/questions:
- I learned more Finnish.
- Lots of things with our child.
- I helped teach him to swim.
- He learned to tell the time with an analog clock/watch.
- I took him to a circus for the first (only) time ever.
- He cut his hair for the first time in six years.
- He spent his a birthday with my parents, in the UK - His languages skills were on top-form, understanding the various UK accents.
- And another with family here in Finland - Where he watched me roll, naked, in the snow after sauna, and then he asked "Daddy why you did that?"
On the topic of Finnish I'm getting pretty damn good at understanding, albeit less good in speaking. Finnish is all about the suffixes, so:
- A car
- My car
- In a car
- In my car
- With my car
- From a car
- Car-less
Most of this is regular, so you can be childless via the "ton" suffix - lapsiton is "lapsi" (child) "ton" (less). The hard part in communication is thus twofold:
- Knowing the word you want to use, be it car, cake, spoon, or smile.
- Getting the appropriate suffix for the use you want.
Our child turned six recently, and most of the year was spent doing things with him, for him, and to him. He's on the verge of learning to read (English and Finnish), he's interested in maths and completes little puzzles freely and happily. He likes to help with Sodoku, for example and not just the child-versions.
In the past couple of weeks I let him play Super Mario & Super Mario Bros 3, on a NES Classic, and he dies constantly, with a smile on his face. But he does love to tell me what to do when he watches me play!
He's learned to ice-skate, and ski, and almost learned to swim. (I'll say he can swim 3m inside a pool, without aid, but then he starts to sink.) We've got a couple of regular rituals with each other - including going to sauna every week or two, and other similar things.
He's gotten more interested in helping me cook, and his mother too. (My wife and I live in separate houses..)
I guess the next big milestone will be him walking to school by himself, which will start next year. As things stand I wake up early, go over to his house, and do all the morning-things, before I take him there. I expect I'll still want to go there, give him his breakfast, his medicine, and help him get dressed. After that I guess I kick him out, and he makes his own way there.
Happily the walk to school is a few hundred meters, and doesn't involve crossing any roads. But of course it does bring other complications: if he's not collected, and walks home himself, then he needs a key to one/other house, and there's the potential need for a phone to say "I'm late", "I'm lost", or us to say "Where are you?".
Anyway .. interesting year .. good year. Despite everything else.
Tags: 2022, family, personal, random
|
28 November 2022 22:00
I recently wrote about yet another lisp I'd
been having fun with.
Over the past couple of years I've played with a few toy scripting languages,
or random interpreters, and this time I figured I'd do something beyond the
minimum, by implementing the Language Server Protocol.
In brief the language server protocol (LSP) is designed to abstract
functionality that might be provided by an editor, or IDE, into a small
"language server". If the language-server knows how to jump to definitions,
provide completion, etc, etc, then the editor doesn't need to implement those
things for NN different languages - it just needs to launch and communicate
with something that does know how to do the job.
Anyway LSP? LISP? Only one letter different, so that's practically enough
reason to have a stab at it.
Thankfully I found a beautiful library that implements a simple framework
allowing the easy implementation of a golang-based LSP-serverÖ
Using that I quickly hacked up a server that can provide:
- Overview of all standard-library functions, on hover.
- Completion of all standard-library functions.
I've tested this in both GNU Emacs and Neovim, so that means I'm happy
I support all editors! (More seriously if it works in two then that
probably means that the LSP stuff should work elsewhere too.)
Here's what the "help on hover" looks like, within Emacs:
Vim looks similar but you have to press K to see the wee popup. Still
kinda cute, and was a good experiment.
Tags: golang, lisp, lsp
|
3 November 2022 22:00
So this week I recycled a talk I'd given in the past, about how even using
extremely simple parsers allows a lot of useful static-analysis to be done,
for specific niche use-cases.
This included examples of scanning comments above classes to ensure they
referred to the appropriate object, ensuring that specific function
calls always included a specific (optional) parameter, etc.
Nothing too complex, but I figured I'd give a new example this time, and
I remembered I'd recently written a bunch of functions for an interpreter
which I'd ordered quite deliberately.
Assume you're writing a BASIC interpreter, you need to implement a bunch of
built-in maths functions such as SIN, COS, TAN, then some string-related
functions LEFT$, RIGHT$, MID$, etc.
When it comes to ordering there are a couple of approaches:
- Stick them all in one package:
- Create a package and group them:
builtins/maths.gobuiltins/string.go- .. etc
Personal preference probably dictates the choice you make, but either way I think it would be rational and obvious that you'd put the functions in alphabetical order:
func ABS( args []primitive.Object) (primitive.Object, error) {
..}
func COS( args []primitive.Object) (primitive.Object, error) {
..}
func SIN( args []primitive.Object) (primitive.Object, error) {
..}
func TAN( args []primitive.Object) (primitive.Object, error) {
..}
I did that myself, and I wrote a perl-script to just parse the file using a simple regexp "^func\s+([^(]+)\(" but then I figured this was a good time to write a real static-analysis tool.
The golang environment is full of trivial little linters for various purposes, and the standard "go vet .." driver makes it easy to invoke them. Realizing that I was going to get driven in the same way it was obvious I'd write something called "alphaVet".
So anyway, half written for a talk, half-written because of the name:
- Golang linter that reports failures if functions aren't in alphabetical order
Tags: alphavet, golang, linting
|
8 October 2022 15:00
Over the past few months (years?) I've posted on my blog about the various toy interpreters I've written.
I've used a couple of scripting languages/engines in my professional career, but in public I think I've implemented
- BASIC
- evalfilter
- FORTH
- Lisp
- Monkey
- TCL
Each of these works in similar ways, and each of these filled a minor niche, or helped me learn something new. But of course there's always a question:
In the real world? It just doesn't matter. For me. But I was curious, so I hacked up a simple benchmark of calculating 12! (i.e. The factorial of 12).
The specific timings will vary based on the system which runs the test(s), but there's no threading involved so the relative performance is probably comparable.
Anyway the benchmark is simple, and I did it "fairly". By that I mean that I didn't try to optimize any particular test-implementation, I just wrote it in a way that felt natural.
The results? Evalfilter wins, because it compiles the program into bytecode, which can be executed pretty quickly. But I was actually shocked ("I wrote a benchmark; The results will blow your mind!") at the second and third result:
BenchmarkEvalFilterFactorial-4 61542 17458 ns/op
BenchmarkFothFactorial-4 44751 26275 ns/op
BenchmarkBASICFactorial-4 36735 32090 ns/op
BenchmarkMonkeyFactorial-4 14446 85061 ns/op
BenchmarkYALFactorial-4 2607 456757 ns/op
BenchmarkTCLFactorial-4 292 4085301 ns/op
here we see that FOTH, my FORTH implementation, comes second. I guess this is an efficient interpreter too, bacause that too is essentially "bytecode". (Looking up words in a dictionary, which really maps to indexes to other words. The stack operations are reasonably simple and fast too.)
Number three? BASIC? I expected better from the other implementations to be honest. BASIC doesn't even use an AST (in my implementation), just walks tokens. I figured the TCO implemented by my lisp would make that number three.
Anyway the numbers mean nothing. Really. But still interesting.
Tags: basic, forth, github, lisp, tcl
|
23 September 2022 19:00
In my previous post I introduced yet another Lisp interpreter. When it was posted there was no support for macros.
Since I've recently returned from a visit to the UK, and caught COVID-19 while I was there, I figured I'd see if my brain was fried by adding macro support.
I know lisp macros are awesome, it's one of those things that everybody is told. Repeatedly. I've used macros in my emacs programming off and on for a good few years, but despite that I'd not really given them too much thought.
If you know anything about lisp you know that it's all about the lists, the parenthesis, and the macros. Here's a simple macro I wrote:
(define if2 (macro (pred one two)
`(if ~pred (begin ~one ~two))))
The standard lisp if function allows you to write:
(if (= 1 a) (print "a == 1") (print "a != 1"))
There are three arguments supplied to the if form:
- The test to perform.
- A single statement to execute if the test was true.
- A single statement to execute if the test was not true.
My if2 macro instead has three arguments:
- The test to perform.
- The first statement to execute if the test was true.
- The second statement to execute if the test was true.
- i.e. There is no "else", or failure, clause.
This means I can write:
(if2 blah
(one..)
(two..))
Rather than:
(if blah
(begin
(one..)
(two..)))
It is simple, clear, and easy to understand and a good building-block for writing a while function:
(define while-fun (lambda (predicate body)
(if2 (predicate)
(body)
(while-fun predicate body))))
There you see that if the condition is true then we call the supplied body, and then recurse. Doing two actions as a result of the single if test is a neat shortcut.
Of course we need to wrap that up in a macro, for neatness:
(define while (macro (expression body)
(list 'while-fun
(list 'lambda '() expression)
(list 'lambda '() body))))
Now we're done, and we can run a loop five times like so:
(let ((a 5))
(while (> a 0)
(begin
(print "(while) loop - iteration %s" a)
(set! a (- a 1) true))))
Output:
(while) loop - iteration 5
(while) loop - iteration 4
(while) loop - iteration 3
(while) loop - iteration 2
(while) loop - iteration 1
We've gone from using lists to having a while-loop, with a couple of simple macros and one neat recursive function.
There are a lot of cute things you can do with macros, and now I'm starting to appreciate them a little more. Of course it's not quite as magical as FORTH, but damn close!
Tags: forth, github, lisp
|
15 July 2022 13:00
Recently I've been working with simple/trivial scripting languages, and I guess I finally reached a point where I thought "Lisp? Why not". One of the reasons for recent experimentation was thinking about the kind of minimalism that makes implementing a language less work - being able to actually use the language to write itself.
FORTH is my recurring example, because implementing it mostly means writing a virtual machine which consists of memory ("cells") along with a pair of stacks, and some primitives for operating upon them. Once you have that groundwork in place you can layer the higher-level constructs (such as "for", "if", etc).
Lisp allows a similar approach, albeit with slightly fewer low-level details required, and far less tortuous thinking. Lisp always feels higher-level to me anyway, given the explicit data-types ("list", "string", "number", etc).
Here's something that works in my toy lisp:
;; Define a function, `fact`, to calculate factorials (recursively).
(define fact (lambda (n)
(if (<= n 1)
1
(* n (fact (- n 1))))))
;; Invoke the factorial function, using apply
(apply (list 1 2 3 4 5 6 7 8 9 10)
(lambda (x)
(print "%s! => %s" x (fact x))))
The core language doesn't have helpful functions to filter lists, or build up lists by applying a specified function to each member of a list, but adding them is trivial using the standard car, cdr, and simple recursion. That means you end up writing lots of small functions like this:
(define zero? (lambda (n) (if (= n 0) #t #f)))
(define even? (lambda (n) (if (zero? (% n 2)) #t #f)))
(define odd? (lambda (n) (! (even? n))))
(define sq (lambda (x) (* x x)))
Once you have them you can use them in a way that feels simple and natural:
(print "Even numbers from 0-10: %s"
(filter (nat 11) (lambda (x) (even? x))))
(print "Squared numbers from 0-10: %s"
(map (nat 11) (lambda (x) (sq x))))
This all feels very sexy and simple, because the implementations of map, apply, filter are all written using the lisp - and they're easy to write.
Lisp takes things further than some other "basic" languages because of the (infamous) support for Macros. But even without them writing new useful functions is pretty simple. Where things struggle? I guess I don't actually have a history of using lisp to actually solve problems - although it's great for configuring my editor..
Anyway I guess the journey continues. Having looked at the obvious "minimal core" languages I need to go further afield:
I'll make an attempt to look at some of the esoteric programming languages, and see if any of those are fun to experiment with.
Tags: github, lisp
|
1 July 2022 19:00
So my previous post introduced a trivial interpreter for a TCL-like language.
In the past week or two I've cleaned it up, fixed a bunch of bugs, and added 100% test-coverage. I'm actually pretty happy with it now.
One of the reasons for starting this toy project was to experiment with how easy it is to extend the language using itself
Some things are simple, for example replacing this:
puts "3 x 4 = [expr 3 * 4]"
With this:
Just means defining a function (proc) named *. Which we can do like so:
proc * {a b} {
expr $a * $b
}
(Of course we don't have lists, or variadic arguments, so this is still a bit of a toy example.)
Doing more than that is hard though without support for more primitives written in the parent language than I've implemented. The obvious thing I'm missing is a native implementation of upvalue, which is TCL primitive allowing you to affect/update variables in higher-scopes. Without that you can't write things as nicely as you would like, and have to fall back to horrid hacks or be unable to do things.
# define a procedure to run a body N times
proc repeat {n body} {
set res ""
while {> $n 0} {
decr n
set res [$body]
}
$res
}
# test it out
set foo 12
repeat 5 { incr foo }
# foo is now 17 (i.e. 12 + 5)
A similar story implementing the loop word, which should allow you to set the contents of a variable and run a body a number of times:
proc loop {var min max bdy} {
// result
set res ""
// set the variable. Horrid.
// We miss upvalue here.
eval "set $var [set min]"
// Run the test
while {<= [set "$$var"] $max } {
set res [$bdy]
// This is a bit horrid
// We miss upvalue here, and not for the first time.
eval {incr "$var"}
}
// return the last result
$res
}
loop cur 0 10 { puts "current iteration $cur ($min->$max)" }
# output is:
# => current iteration 0 (0-10)
# => current iteration 1 (0-10)
# ...
That said I did have fun writing some simple test-cases, and implementing assert, assert_equal, etc.
In conclusion I think the number of required primitives needed to implement your own control-flow, and run-time behaviour, is a bit higher than I'd like. Writing switch, repeat, while, and similar primitives inside TCL is harder than creating those same things in FORTH, for example.
Tags: github, golang, tcl
|
21 June 2022 13:00
Recently I was reading Antirez's piece TCL the Misunderstood again, which is a nice defense of the utility and value of the TCL language.
TCL is one of those scripting languages which used to be used a hell of a lot in the past, for scripting routers, creating GUIs, and more. These days it quietly lives on, but doesn't get much love. That said it's a remarkably simple language to learn, and experiment with.
Using TCL always reminds me of FORTH, in the sense that the syntax consists of "words" with "arguments", and everything is a string (well, not really, but almost. Some things are lists too of course).
A simple overview of TCL would probably begin by saying that everything is a command, and that the syntax is very free. There are just a couple of clever rules which are applied consistently to give you a remarkably flexible environment.
To get started we'll set a string value to a variable:
set name "Steve Kemp"
=> "Steve Kemp"
Now you can output that variable:
puts "Hello, my name is $name"
=> "Hello, my name is Steve Kemp"
OK, it looks a little verbose due to the use of set, and puts is less pleasant than print or echo, but it works. It is readable.
Next up? Interpolation. We saw how $name expanded to "Steve Kemp" within the string. That's true more generally, so we can do this:
set print pu
set me ts
$print$me "Hello, World"
=> "Hello, World"
There "$print" and "$me" expanded to "pu" and "ts" respectively. Resulting in:
puts "Hello, World"
That expansion happened before the input was executed, and works as you'd expect. There's another form of expansion too, which involves the [ and ] characters. Anything within the square-brackets is replaced with the contents of evaluating that body. So we can do this:
puts "1 + 1 = [expr 1 + 1]"
=> "1 + 1 = 2"
Perhaps enough detail there, except to say that we can use { and } to enclose things that are NOT expanded, or executed, at parse time. This facility lets us evaluate those blocks later, so you can write a while-loop like so:
set cur 1
set max 10
while { expr $cur <= $max } {
puts "Loop $cur of $max"
incr cur
}
Anyway that's enough detail. Much like writing a FORTH interpreter the key to implementing something like this is to provide the bare minimum of primitives, then write the rest of the language in itself.
You can get a usable scripting language with only a small number of the primitives, and then evolve the rest yourself. Antirez also did this, he put together a small TCL interpreter in C named picol:
Other people have done similar things, recently I saw this writeup which follows the same approach:
So of course I had to do the same thing, in golang:
My code runs the original code from Antirez with only minor changes, and was a fair bit of fun to put together.
Because the syntax is so fluid there's no complicated parsing involved, and the core interpreter was written in only a few hours then improved step by step.
Of course to make a language more useful you need I/O, beyond just writing to the console - and being able to run the list-operations would make it much more useful to TCL users, but that said I had fun writing it, it seems to work, and once again I added fuzz-testers to the lexer and parser to satisfy myself it was at least somewhat robust.
Feedback welcome, but even in quiet isolation it's fun to look back at these "legacy" languages and recognize their simplicity lead to a lot of flexibility.
Tags: github, golang, tcl
|
|
