Moonlight Xanadu

@ Syntax

blog@michal-atlas.cz (Michal Atlas) — Sat, 14 Mar 2026 00:00:00 +0000

Ada has a neat syntax since 2021.</p>

X</span> :</span>= @ * 2</span>;
</span></code></pre>
The @</code> always signifies the LHS of the assignment.
Even in more complex situations like this:</p>
Cursor(3</span>, Next) := @ * 2</span> + Sqrt(@);
</span></code></pre>
It’s a very nice way of doing all the +=</code>, *=</code>, |=</code>, <<=</code>, etc.
which seems slightly more readable to me, for the
basic cases I still learnt to see :=@+</code> as a +=</code>,
and in the more complex expressions where you don’t actually
want to just have the final operation be +</code> the old value,
it comes in way more handy.</p>
Ofc doing this with macros is trivial.</p>



OCaml has curried keywords
blog@michal-atlas.cz (Michal Atlas) — Sat, 14 Mar 2026 00:00:00 +0000
I spoke about keywords improving readability
in an older post</a>.</p>
And actually found something that does it close to what I described.</p>
OCaml calls it “Labelled Arguments</a>”:</p>
#</span> let</span> add</span> ~</span>x</span></span> ~</span>y</span></span> =</span></span> x +</span> y;;</span>
</span>val</span> add</span> :</span> x</span>:</span>int</span> </span>-></span> y</span>:</span>int</span> </span>-></span> int</span> =</span> <</span>fun></span>
</span></span>
</span></span>#</span> add ~x:</span></span>2</span> ~y:</span></span>4</span>;;</span>
</span>-</span> : int</span> =</span> 6</span>
</span>
</span>#</span> add ~y:</span></span>2</span> ~x:</span></span>5</span>;;</span>
</span>-</span> : int</span> =</span> 7</span>
</span>
</span>#</span> add ~y:</span></span>4</span>;;</span>
</span>-</span> : x:int</span> -></span> int</span> =</span> <</span>fun></span>
</span></code></pre>
Sadly you can’t do something like add ~x</code> to remove the label from
the argument, it’s a labelled argument, it’s a different type
and that’s that unless you wrap it in a lambda.</p>
They also have an interesting approach to optional arguments</a>,
where you can just skip over them when applying a later label?
This of course means you need a sentinel value if there are no
non-optional arguments and also that optional arguments come first rather than last.</p>


CFFI Struct Vectors
blog@michal-atlas.cz (Michal Atlas) — Sat, 07 Mar 2026 00:00:00 +0000
(</span>asdf</span>:</span>load-system</span></span> :</span>cffi</span>)</span></span>
</span>
</span>(</span>cffi</span>:</span>defcstruct</span></span> point</span>
</span></span>  (</span>x</span></span> :</span>int</span>)</span></span>
</span></span>  (</span>y</span></span> :</span>int</span>)</span></span>)</span></span>
</span>
</span>(</span>cffi</span>:</span>with-foreign-object</span></span> (</span>vec</span></span> '</span>(</span>:</span>struct</span> point</span>)</span></span> 4</span></span>)</span></span>
</span></span>  (</span>loop</span>
</span></span></span></span>    :</span>with</span> idx</span> :</span>=</span> 0</span></span>
</span></span></span></span>    :</span>for</span> i</span> :</span>to</span> 4</span></span>
</span></span></span></span>    :</span>do</span>
</span></span></span></span>       (</span>cffi</span>:</span>with-foreign-slots</span></span> 
</span></span></span></span></span>         (</span>(</span>x</span></span> y</span>)</span></span>
</span></span></span></span></span></span>          (</span>cffi</span>:</span>mem-aptr</span></span> vec</span> '</span>(</span>:</span>struct</span> point</span>)</span></span> i</span>)</span></span>
</span></span></span></span></span></span>          (</span>:</span>struct</span> point</span>)</span></span>)</span></span>
</span></span></span></span></span>         (</span>setf</span></span>
</span></span></span></span></span></span>          x</span> (</span>incf</span> idx</span>)</span></span>
</span></span></span></span></span></span>          y</span> (</span>incf</span> idx</span>)</span></span>)</span></span>)</span></span></span>)</span></span>
</span></span>  (</span>sb-vm</span>:</span>hexdump</span></span> vec</span>)</span></span>)</span></span>
</span></code></pre>


On GO's unused variable error
blog@michal-atlas.cz (Michal Atlas) — Sat, 27 Dec 2025 00:00:00 +0000
Many people have ranted about the GO compiler’s
insistance on all variables being used.</p>
On a surprisingly related note,
I wondered what’s forcing me to deal with errors
if they’re just a separate value.</p>
It’s</a>
not</a>
too</a>
difficult</a>
to find opinion upon opinion on this subject.</p>
I also used to think this was kind of annoying
however after gaining some knowledge
on linear types, and other forms of dealing
with errors and program flow
I realized that there is one great reason to keep this.</p>

Imagine now that you want to open a file in Go:</p>
f</span> :=</span> os</span>.</span>Open</span>(</span>"</span>..."</span></span>)</span>
</span></code></pre>
Okay, now the compiler states</p>

assignment mismatch: 1 variable but os.Open returns 2 values</p>
</blockquote>
Right, opening can fail, lemme just…</p>
f</span>,</span> err</span> :=</span> os</span>.</span>Open</span>(</span>"</span>..."</span></span>)</span>
</span></code></pre>

declared and not used: err</p>
</blockquote>
You see?
This forces me to deal with the error in some way.
I could obviously have just added f, _</code> but that
would’ve been a visible smell.</p>
Programmers are forgetful, distracted and time-pressured
human beings so having anything remind you that
something needs to be done that isn’t visible is a boon.</p>
I think that considering their goal is “simplicity”
just forcing every variable to be used
is a reasonable solution to the “what if someone forgets to handle my error value”
issue.
Implementing this in other ways is probably more “complex”
and unused variables are something people
expect to be a warning anyway.</p>
Ignoring all the returns is not a warning,
which is okay here as you always want to hold on
to the result, however something that returns an error
but otherwise either side-effects or works on arguments
might go uncaught.</p>
I do have one more point though on the os.Open</code> API,
forgetting to defer</code> closing of the file is unchecked afaik,
however that is handled already</a>
by the .Open</code> function and defer</code> just makes closing more predictable
as opposed to relying on GC. So that’s alright.</p>


Arrays and Boxing in Common Lisp & SIMD in SBCL
blog@michal-atlas.cz (Michal Atlas) — Tue, 23 Dec 2025 00:00:00 +0000



<Hackmore></span>
 Hey
Releston
what are you up to?</p>
</blockquote>



<Releston></span>
 Looking at this here sensor code,
it’s supposed to be rated for much higher resolution that we’re running.
I mean a rock could come at us flying and the ship wouldn’t react in time.</p>
</blockquote>



<Hackmore></span>
 What?!? Am I supposed to feel even more scared
than I already am? Okay, show me.</p>
</blockquote>



<Releston></span>
 Here… look at this for example, it’s supposed to remove the background noise from the sensor array.</p>
</blockquote>
(</span>defun</span></span> distance-sensors-delete-background-noise</span> (</span></span></span>distances</span> backgrounds</span>)</span></span>
</span></span></span>  (</span>loop</span> :</span>for</span> distance</span> :</span>across</span> distances</span>
</span></span></span></span></span>        :</span>for</span> background</span> :</span>across</span> backgrounds</span>
</span></span></span></span></span>        :</span>for</span> index</span> :</span>from</span> 0</span></span>
</span></span></span></span></span>        :</span>do</span> (</span>setf</span></span> (</span>aref</span></span> distances</span> index</span>)</span></span>
</span></span></span></span></span></span>                  (</span>if</span> (</span><</span> distance</span> background</span>)</span></span> 0</span></span> distance</span>)</span></span>)</span></span></span>)</span></span></span>)</span></span>
</span></code></pre>



<Releston></span>
 It takes over 300ms just to clear the noise, who knows
how slow everything else here is.</p>
</blockquote>
Array Specialization🔗</a></h1>



<Hackmore></span>
 Right, I see some weirdness here I think I could help with,
first of all, what is the type of that input array?</p>
</blockquote>



<Releston></span>
 It’s just a simple-array</code> nothing special, why?</p>
</blockquote>



<Hackmore></span>
 Oh, that might mean the values are all boxed, let’s look.</p>
</blockquote>
CL-USER> (sb-vm:hexdump v)
</span>120CA3FA20: 0000000000000089
</span>120CA3FA28: 0000000000000006 = 3
</span>120CA3FA30: 000000120413C3CF = 1.3d0
</span>120CA3FA38: 0000001204E5C89F = 1.2134d0
</span>120CA3FA40: 000000120A7FA69F = 1.3d0
</span>120CA3FA48: 0000000000000000 = 0
</span></code></pre>



<Hackmore></span>
 You see those values in there? Or rather a lack thereof?
All of those are just pointers to the heap, not actually the numbers you’re working with.</p>
</blockquote>



<Releston></span>
 How do you see that?</p>
</blockquote>



<Hackmore></span>
 Honestly, I’m not sure how to tell for sure,
however there are a few giveaways.
The addresses</strong> show you generally where you can expect allocated heap objects to end up,
the values in the cells of the vector are suspiciously close to that.
The other more obvious telltale is that the two double-float</code>s with an equal value
have completely different binary representations</strong>,
both of which are not actually representations of the number.</p>
</blockquote>



<Releston></span>
 Oh, that’s ugly, so Common Lisp doesn’t have non-boxed arrays?</p>
</blockquote>



<Hackmore></span>
 Of course it has, they are however sadly quite implementation dependent.</p>
</blockquote>
Let’s start with the fact that array semantics are based on boxes,
for various reasons,
by default they can hold absolutely any type
and if you don’t know the sizes of anything
you can’t make an array out of them,
since an array is literally just “places of the same size next to each other”.</p>
So without any further knowledge Common Lisp is forced to assume
you might want to do anything and just box.
However, nothing is stopping you from actually telling it what
you’ll be using your array with.</p>
Common Lisp defines something called “Specialized Arrays”,
these allow the implementation to store the elements in a
“more efficient” manner.
Common Lisp itself only requires (vector bit)</code> (a.k.a. bit-vector</code>) and (vector character)</code> (a.k.a. string</code>) specializations,
however implementations are allowed to create additional
specializations as they see fit.</p>
To inspect what is optimized in a particular
environment the standard provides #'upgraded-array-element-type</code>.
This function takes a type and returns what the most specialized
array capable of holding it is actually capable of holding.
That might’ve just sounded weird,
why am I interested in what it holds rather than the type itself?
It would be redundant, since the type that holds is just an (array <that-type>)</code>
anyways.
So if I wanted to store an (unsigned-byte 3)</code>, I could run
(upgraded-array-element-type '(unsigned-byte 3))</code> which for me
returns (unsigned-byte 4)</code>.
This means that the implementations has some alternative way to
treat arrays of your type and if you ask for one it’ll use
the one that is specialized for use with (unsigned-byte 4)</code>
but you can feel free to store your (unsigned-byte 3)</code>
in there the array’ll handle it.</p>
Nonetheless, we can use this to inspect the various
better options an implementation offers us.
In the case of SBCL I found a special variable which
happens to line up with what gets optimized:</p>
(</span>map</span></span> '</span>vector</span>
</span></span>  (</span>alexandria</span>:</span>rcurry</span></span> #'</span>slot-value</span></span> '</span>sb-vm</span>::</span>specifier</span>)</span></span>
</span></span>  sb-vm</span>:</span>*specialized-array-element-type-properties*</span>)</span></span>
</span></code></pre>
Which lists their specializations for us:</p>

NIL</code></li>
BASE-CHAR</code></li>
CHARACTER</code></li>
SINGLE-FLOAT</code></li>
DOUBLE-FLOAT</code></li>
BIT</code></li>
UNSIGNED-BYTE</code>

2</li>
4</li>
7</li>
8</li>
15</li>
16</li>
31</li>
32</li>
62</li>
63</li>
64</li>
</ul>
</li>
SIGNED-BYTE</code>

8</li>
16</li>
32</li>
64</li>
</ul>
</li>
FIXNUM</code></li>
COMPLEX</code>

SINGLE-FLOAT</code></li>
DOUBLE-FLOAT</code></li>
</ul>
</li>
</ul>
The list looks kinda bizarre at times,
I’m sure every entry has a very good reason.
Including the fun NIL</code> entry (CL’s equivalent of the bottom type),
which just says congratulates you for trying to use it.</p>
This itself doesn’t tell you the elements aren’t boxed but might give you a pretty good idea what types to look for when optimizing.
With SBCL we can verify our assumption quite trivially,
by constructing v</code> with :element-type 'double-float</code>:</p>
CL-USER> (sb-vm:hexdump v)
</span>1209ABBB60: 00000000000000D5
</span>1209ABBB68: 0000000000000006 = 3
</span>1209ABBB70: 3FF4CCCCCCCCCCCD
</span>1209ABBB78: 3FF36A161E4F7660
</span>1209ABBB80: 3FF4CCCCCCCCCCCD
</span>1209ABBB88: 0000000000000000 = 0
</span></code></pre>



<Hackmore></span>
 See? Now try it with this.</p>
</blockquote>



<Releston></span>
 … … … It’s slower!!!</p>
</blockquote>



<Hackmore></span>
 Well, they do always say to benchmark and test,
the reason why this is slower is currently slightly beyond my grasp.</p>
</blockquote>
I’m reasonably sure it has to do with re-boxing floats,
as the main problem is that with no element-type</code> there
are no allocations when run, but with it equal to double-float</code>
it allocates a lot.
If I want to operate on a generic array I have to call
the generic functions with standard Lisp values,
which for a double-float</code> means it needs to be boxed,
so every read from the array is sort of associated with allocating memory.
We need to show to Lisp that the array is safely able to provide
and accept unboxed floats.
Adding a declaration suffices to get rid of that issue.</p>
This also changes speed due to plenty of inlining of math, etc.
that however seems to speed up only by about half without the specialization.</p>
(</span>defun</span></span> distance-sensors-delete-background-noise2</span> (</span></span></span>distances</span> backgrounds</span>)</span></span>
</span></span></span>  (</span>declare</span> (</span>type</span> (</span>simple-array</span> double-float</span>)</span></span> distances</span> backgrounds</span>)</span></span>)</span></span>
</span></span></span>  (</span>loop</span> :</span>for</span> index</span> :</span>below</span> (</span>length</span></span> distances</span>)</span></span>
</span></span></span></span></span>        :</span>for</span> distance</span> :</span>=</span> (</span>aref</span></span> distances</span> index</span>)</span></span>
</span></span></span></span></span>        :</span>for</span> background</span> :</span>=</span> (</span>aref</span></span> backgrounds</span> index</span>)</span></span>
</span></span></span></span></span>        :</span>do</span> 
</span></span></span></span></span>           (</span>setf</span></span> (</span>aref</span></span> distances</span> index</span>)</span></span>
</span></span></span></span></span></span>                 (</span>if</span> (</span><</span> distance</span> background</span>)</span></span> 0.</span>0d0</span></span> distance</span>)</span></span>)</span></span></span>)</span></span></span>)</span></span>
</span></code></pre>



<Releston></span>
 That’s more like it, under 20ms or so, that’s one hell of an improvement.</p>
</blockquote>



<Hackmore></span>
 This was supposed to be rather educational,
not just about optimizing,
so don’t go doing this everywhere before really finding out
why something isn’t the way you want and make sure the edit
actually makes it that way.</p>
</blockquote>



<Releston></span>
 Okay, I guess that’s it, we can’t get below that,
there’s minimal work being done save for actually going over the elements
one by one.</p>
</blockquote>
SIMD🔗</a></h2>



<Hackmore></span>
 Actually there might still be one thing,
it’s actually why I came down here.
I just read in the manual that they fitted our ship’s computer
with AVX2</a>.</p>
</blockquote>



<Releston></span>
 Elaborate</p>
</blockquote>
The SBCL Manual</a>
actually has a good section to introduce you to this,
however I had my own problems understanding it
so I will re-iterate and partly show how this works anyway.</p>
Modern processors are fitted with chonky registers to help with
operations on vectors.
These vary from 128-bits in SSE all the way up to 512-bits in AVX-512.
All these SSE and AVX acronyms are descriptions of
which registers are present on a CPU.
The most common around me at the time of writing is AVX2,
which includes 256-bit registers.</p>
These registers can load from memory all at once
and then apply operations that act as if they had
multiple separate numbers inside them.
Emulating this behaviour with a normal register
would be problematic, since placing let’s say
2 32-bit integers into a 64-bit register and
trying to add them could overflow from one number to the other.
Other operations would provide their own little problems,
so we have specialized registers and instructions for this process.</p>
For AVX2 SBCL provides functions like f64.4+</code> or f32.8<</code>,
if you do the math you’ll find that 4xf64</code> and 8xf32</code> is both
256-bits.
This means that you are using a 256-bit register to operate on
4 double-floats</code>
or 8 single-floats</code> respectively.
SBCL provides these inside the sb-simd</code> package,
along with sb-simd-<extension-version></code> for
those parts of SIMD only applicable to certain extensions.</p>
Things like sb-simd:f64</code> and sb-simd:u8</code> are mostly
just type aliases for the actual built-in Common Lisp types.
So using sb-simd:u16+</code> on two numbers or
sb-simd:f32*</code> on two floats is perfectly acceptable.</p>
How do we get multiple double-floats</code> for example then,
so we can use these functions on them?
We use <type>.<count>-aref</code> on an array restricted to the given type.
It’s that easy, this returns a “SIMD pack” as SBCL calls it,
and we can operate on it, before setf</code>ing back.
In essence you only replace aref</code> with ...-aref</code> and +</code> with ...-+</code> and you’re done.
One thing to note is that SIMD if</code> works a bit differently,
since we need to make a choice over multiple numbers at the same time.
<</code> actually creates a boolean mask which SIMD if</code>
uses to choose a number from one of the other two arguments,
however to do that both must already be pre-calculated.</p>
If our dear crew strictly assumes AVX2 is present they could
write something like this:</p>
(</span>defun</span></span> distance-sensors-delete-background-noise3</span> (</span></span></span>distances</span> backgrounds</span>)</span></span>
</span></span></span>  (</span>loop</span> :</span>for</span> index</span> :</span>below</span> (</span>length</span></span> distances</span>)</span></span> :</span>by</span> 4</span></span>
</span></span></span></span></span>        :</span>for</span> distance</span> :</span>=</span> (</span>sb-simd-avx2</span>:</span>f64.4-aref</span></span> distances</span> index</span>)</span></span>
</span></span></span></span></span>        :</span>for</span> background</span> :</span>=</span> (</span>sb-simd-avx2</span>:</span>f64.4-aref</span></span> backgrounds</span> index</span>)</span></span>
</span></span></span></span></span>        :</span>do</span> (</span>setf</span></span> (</span>sb-simd-avx2</span>:</span>f64.4-aref</span></span> distances</span> index</span>)</span></span>
</span></span></span></span></span></span>                  (</span>sb-simd-avx2</span>:</span>f64.4-if</span></span>
</span></span></span></span></span></span></span>                   (</span>sb-simd-avx2</span>:</span>f64.4<</span></span> distance</span> background</span>)</span></span>
</span></span></span></span></span></span></span>                   0.</span>0d0</span></span>
</span></span></span></span></span></span></span>                   distance</span>)</span></span>)</span></span></span>)</span></span></span>)</span></span>
</span></code></pre>
This is slower than before,
but I meant mostly to show off the features
as they took me way too long for me to understand
and I find them interesting and productive to know.
For more complex calculations or
when used with larger leverage,
like with bytes where the register
can support 32 of them at once, the
performance of SIMD is incomparable.</p>


WebRings
blog@michal-atlas.cz (Michal Atlas) — Tue, 09 Dec 2025 00:00:00 +0000
WebRings🔗</a></h3>

geekring</a>

[Previous</a>]</li>
[Next</a>]</li>
[Random</a>]</li>
</ul>
</li>
retronaut</a>

[Previous</a>]</li>
[Next</a>]</li>
[Random</a>]</li>
</ul>
</li>
</ul>






EUR/CZK Table
blog@michal-atlas.cz (Michal Atlas) — Mon, 08 Dec 2025 00:00:00 +0000

Moonlight Xanadu

@ Syntax

OCaml has curried keywords

CFFI Struct Vectors

On GO's unused variable error

Arrays and Boxing in Common Lisp & SIMD in SBCL

Array Specialization🔗</a></h1> <Hackmore></span> Right, I see some weirdness here I think I could help with, first of all, what is the type of that input array?</p> </blockquote>

WebRings

WebRings🔗</a></h3> geekring</a> [Previous</a>]</li> [Next</a>]</li> [Random</a>]</li> </ul> </li> retronaut</a> [Previous</a>]</li> [Next</a>]</li> [Random</a>]</li> </ul> </li> </ul>

EUR/CZK Table

WebRings 🔗</a></h3>

geekring</a>

[Previous</a>]</li>
[Next</a>]</li>
[Random</a>]</li> </ul> </li>
retronaut</a>

[Previous</a>]</li>
[Next</a>]</li>
[Random</a>]</li> </ul> </li> </ul>