I spent some time improving the Kap UI. Error reporting is a lot better, and I created a short video showing what it looks like.

I spent some time improving the Kap UI. Error reporting is a lot better, and I created a short video showing what it looks like.

Ljubljana is a city of lawyers - so it's no surprise that the earliest known mention of the town and the castle above it involves a certain Rudolphus Advocatus.
Click and let the kite take you back to the High Middle Ages, to the beginnings of Ljubljana castle and the triple town below it.
#kiteaerialphotography #KAP #kite #flying #aerial #history #archaeology #medieval #castle #town #Sponheim #Carniola #LjubljanskiGrad #Ljubljana #Slovenia

This is from Nomina Defunctorum, the Book of the Dead Benefactors who donated property to the Chapter of Aquileia (now in the Diocesan Archive of Udine): Nomina defunctorum is a simple list of the dates on which this or that benefactor died (so their souls could be duly prayed for on the correct day), and ... Read more
Thursday's long read: how we tried to colonize Ljubljana Marshes, why we kinda failed, and how we are now protecting this strange, wounded, beautiful ecosystem.
https://kapjasa.si/en/rewilding-a-tamed-wilderness-ljubljana-marshes/
#kite #kiteaerialphotography #KAP #kaerial #history #nature #colonization #marsh #moor #swamp #melioration #engineering #hydrology #rewilding #LjubljanaMarshes #LjubljanskoBarje #Barje #Ljubljana #Slovenia

There was nothing. There was no ‘there’ there. A hundred and fifty square kilometers of void. To be fair, only one species of animal thought that; millions of others were quite happily enjoying this purported “void,” thank you very much. And even the detractors once lived smack in the middle of it, back when it ... Read more
@jannem @Edent Interestingly enough, these languages originates from Ken Iverson's work on a notation for expression algorithms. This language (called APL) was not initially intended to be used on a computer, but for communication. This made it naturally terse, using symbols rather than words, because it was optimised for a blackboard rather than a terminal.
He invented some new notation that is used in maths today, including the symbols for floor and ceiling.
These days, I believe APL and its descendants (including Kap and BQN and others) are the only languages that actually use some variation of these symbols for the floor and ceil operations (in these languages, the symbols ⌊ and ⌈ are used.
So, to divide a by 2 and round down looks like this:
⌊a÷2
One thing Kap does which the other array languages do not is to allow the user to define functions, operators and even new syntax using glyphs that are not used by the language. Some functions in the language are defined in the standard library, and uses this technique.
So, today I implemented indexed assignment in Kap. I have for the longest time avoided doing so, because the semantics of the language is immutable, but the syntax itself looks like it mutates an array. After all, that's what pretty much every other language does when faced with this kind of code.
To illustrate, what do you think the following code will return?
foo ← 10 20 30
bar ← foo
foo[1] ← 50
bar[1] + foo[1] ⍝ In Kap, the last expression is the return value
If you guessed 70, you'd be right.
If you guessed this is because the assignment on the second line makes a copy, you'd be wrong. foo and bar indeed shares a reference to the same object.
What actually happens is the when you assign to a bracket expression, a new array is created with the updated content, and the value of foo is replaced.
In other words, it's equivalent to the following expression (which is what you had to write before):
foo ← {50}⍢(1⊇) foo
I.e. take element at index 1, replace it with 50 and put it back in the original array, finally assigning that result back to foo.
It turns out that in practice, you don't have to replace elements at specific locations very often, so explicit syntax for it wasn't really necessary.
But, as I was typing the new tutorial for the language, I realised that trying to explain structural under (i.e. ⍢) to a beginner is not something I want to do, so I just decided to implement the standard APL notation for this operation.
Now, to answer the obvious question why I was hesitating to do it earlier: The reason is that this is actually a very costly operation. The entire array is copied every time you replace a single element. It also prevents lazy evaluation, which is pretty bad, since that's what allows Kap to be fast.
Finally, a beginner user may use this in a loop to initialise an array, which would be a terribly slow.
I do have some ideas how to make the last case faster though. The idea is to allow an array to be mutable until any of its content is read. We'll see if it becomes necessary to implement this.
I've started a new effort to write a tutorial for Kap.
Do note it's not finished yet
But if anyone is willing to browse it to see if it's understandable, and even more importantly, interesting, please tell me if I'm on the right track.
Up until now it feels like the advent of code problems were designed for array languages.
There are certainly problems that takes multiple lines of code to solve (some of the early problems last year had that property). We'll see what happens in the next few days, but this one was remarkably concise when solved in Kap.
Here are two separate functions that solve the two parts:
∇ solveDay7part1 {
f ← @.≠ io:read "part07.txt"
+/ ∊ (1↓f) ∧ ¯1↓ { (⍺>⍵) ∨ ∨/ ¯1 1 ⌽¨ ⊂⍺∧⍵ }\ f
}
∇ solveDay7part2 {
+/ { (⍺×~⍵) + +/ ¯1 1 ⌽¨ ⊂⍺×⍵ }/ @.≠ io:read "part07.txt"
}
Part 2 was even shorter than part 1.
In both problems, the general approach is the same: Iterate over the rows, and update the correct state based on the locations of the splitters.
The second problem keeps track of the number of ways in which a certain cell can be reached, which means that the location of a beam is no longer just a boolean value, but a number indicating the number of ways in which this position can be reached. The result is then simply the sum of all beam values in the last row.
I also note that so far, most of the problems have not had weird edge cases. For example, in today's problem there were no cases of two splitters next to each other, or were there any splitters at the beginning or end of a line. If that had been the case, the solutions would be a bit more complicated.