La première Madame Pipi de l'espace profond

Outre la première victoire au Tour de France d'Eddy Merckx, 1969 fut une année qui marqua trois événements très importants.

1. Le premier homme sur la Lune
2. L'invention du système UNIX
3. La naissance de Linus Torvalds.

Deux de ces événements ont encore aujourd'hui un impact quotidien dans votre vie.

Adolescent, j'étais fasciné par les vidéos de Neil Armstrong descendant l'échelle du module lunaire et faisant quelques pas. Je tentais d'imaginer ce que j'aurais ressenti si j'avais vécu cet instant. J'espérais d'ailleurs aller un jour moi-même dans l'espace.

Il y a 20 ans, je suivais en quasi direct la découverte de Titan par la sonde Huygens.

• Mon dieu, c'est plein d'étoiles ! (ploum.net)

Aujourd'hui, pour la première fois depuis 1972, quatre humains ont quitté l'orbite basse terrestre et sont en route vers la Lune. Cela devrait être un truc incroyablement excitant. Mais comme le dit très bien Kevin Boone, tout le monde semble s'en foutre.

• Did somebody just launch a Moon rocket? (larsthebear.me)
• Le même lien sur le Web

Kevin donne plusieurs explications : la catastrophe climatique et les guerres nous rendent beaucoup moins enthousiastes envers la technologie. Mais, surtout, notre attention est trop fragmentée pour nous rendre compte de l'exploit, pour nous y intéresser.

Among the many crimes that can be attributed to Google and the other tech giants, perhaps the worst is that they've created a world in which a Moon landing is unexciting.

Il n'empêche que quatre humains vont tourner autour de la Lune pour la première fois de mon vivant. Trois hommes et une femme, Christina Koch, qui est donc d'ores et déjà la femme la plus éloignée de la Terre de l'histoire de l'humanité.

• Christina Koch - Wikipédia (fr.wikipedia.org)

Et devinez quel est le rôle de Christina à bord du vaisseau sachant qu'elle est l'astronaute la plus expérimentée des quatre ?

Je vous le donne en mille !

Elle est responsable des toilettes !

Je n'invente rien, je l'ai lu sur Wikipédia dans la section « Spécialiste de Mission 1 ».

• Page Wikipédia de la mission Artemis II

Christina Koch est donc la première Madame Pipi de l'espace profond !

Ça semble terriblement sexiste, mais, en réalité, les toilettes sont réellement critiques dans l'espace. Les astronautes des missions Apollo déféquaient dans des sacs en plastique à l'étanchéité douteuse et les étrons flottants n'étaient pas rares. Il me semble avoir lu qu'un cas de diarrhée faillit causer l'annulation d'une des missions, car il y en avait partout.

• Artemis II's toilet is a moon mission milestone (www.scientificamerican.com)

Dans « Stagiaire au spatioport Omega 3000 », j'ironisais sur le fait que les femmes astronautes n'étaient pas prêtes à laisser la responsabilité d'être Madame Pipi à un homme.

À voir si, comme mon héros Nathan Pasavan, Chrisina Koch recevra à l'atterrissage l'emblématique cache-poussière rose et l'assiette à piécette, insigne historique de cette fonction honorifique…

Bref, pendant qu'ils tournent là-haut, je vous invite à (re)lire cette nouvelle et toutes les autres qui peuplent le recueil, dont « Les filons chocolatifères de la Lune », qui se passe également sur notre satellite.

• Présentation de Stagiaire au spatioport Omega 3000 (ploum.net)
• Commander Stagiaire au spatioport Omega 3000 (pvh-editions.com)

04 Apr 2026 6:21am GMT

One of the things I really like about open source is that a project is never only about the software. Yes, code is important. Very important. But a project like MariaDB exists and grows because of people. People who contribute code, of course, but also people who help users, review bugs, write blog posts, speak […]

04 Apr 2026 6:21am GMT

Procurement frameworks aren't the most exciting topic. But the European Commission is about to propose the Cloud and AI Development Act (CADA), and how it treats Open Source will affect every Open Source project and Open Source business operating in Europe. This is one of those moments where the details matter.

Last month, I proposed a Software Sovereignty Scale that grades software from A to E based on how easily your rights can be taken away. My core argument: if you want sovereignty that lasts, Open Source matters more than buying European proprietary software.

I submitted the Software Sovereignty Scale as feedback to the European Commission, recommending that Open Source carry more weight in the Cloud Sovereignty Framework, the tool EU institutions like the Commission and Parliament use to evaluate cloud providers when purchasing cloud services for their own operations.

The Cloud Sovereignty Framework only applies to how EU institutions buy their own cloud services. The Cloud and AI Development Act, which is expected to build on its approach, would set rules for the entire EU cloud market, across all 27 member states. The difference in scale is enormous, and the time to get this right is now.

My original recommendation was to give Open Source more weight in the Cloud Sovereignty Framework's scoring. I've since realized that isn't enough. Licensing shouldn't be in the sovereignty score at all. It should be a prerequisite.

Open Source is not a rounding error

The Cloud Sovereignty Framework evaluates providers across eight sovereignty objectives, each weighted into a composite score, as shown in the screenshot below. Contracting authorities use that score to rank and compare providers when selecting software and cloud services.

Screenshot of how the European Commission computes its composite sovereignty score. Technology Sovereignty (SOV-6), which covers open licensing, accounts for 15% of the total. Source: Cloud Sovereignty Framework, version 1.2.1, October 2025.

Technology Sovereignty (SOV-6), the objective that covers Open Source, accounts for 15% of the total. Within it, open licensing is one of four contributing factors. That means software being Open Source can contribute roughly 4% to a provider's final sovereignty score.

Does that feel right to you? The one thing that guarantees sovereignty long-term is worth ~4%.

A framework designed to measure sovereignty treats the one factor that makes sovereignty permanent as a rounding error. I could argue the percentage should be higher, or that Open Source supports other objectives, but even at 40%, licensing would still be in the wrong place.

Licensing is fundamentally different from every other objective in the framework. Skype checked every sovereignty box until eBay acquired it in 2005. Every credential was valid before the acquisition and meaningless after.

Had Skype been Open Source, no one could have taken the code away. You would still retain the right to use, modify, and fork it regardless of who acquired the company. That right is permanent, but a European headquarters is not.

That makes licensing a prerequisite, not something to average into a score. Scores compare trade-offs. Prerequisites define what is non-negotiable.

The gate already exists

Beyond the composite score, the framework defines Sovereign Effectiveness Assurance Levels, or SEAL levels. These range from SEAL-0 (no sovereignty at all) to SEAL-4 (full EU control with no critical non-EU dependencies).

For each of the eight sovereignty objectives, the contracting authority sets a minimum SEAL level. Any provider that falls below the minimum is rejected outright. These minimums work as pass/fail gates.

My proposal: licensing belongs in the gate, not in the score. Make Open Source a minimum requirement for the highest SEAL levels.

The Software Sovereignty Scale could map onto SEAL levels like this:

Under this proposal, mission-critical software with high switching costs would require a minimum of SEAL-3, making Open Source a requirement. For lower-risk procurement where the software is easy to replace, SEAL-2 would allow proprietary providers to compete.

Won't this exclude many proprietary providers? Yes, it would. But we have to be honest: proprietary software doesn't give you sovereignty that lasts.

I support the push to buy homegrown technology ("Buy European"). It keeps investment in Europe. But it doesn't solve the underlying problem.

Which government is sovereign?

Consider two scenarios. In the first, a government runs proprietary software on a sovereign European cloud. The provider gets acquired by a non-EU company, and the government can't migrate without replacing the software entirely. It has jurisdiction but ultimately no control. It's not very sovereign.

In the second, a government runs Open Source software on Amazon Web Services (AWS), a US-owned cloud provider with data centers in Europe. If AWS becomes a problem because of the CLOUD Act, policy changes, or geopolitics, the government can move the same software to a European cloud provider. Switching cloud providers can be hard, but switching software is much harder.

It may seem counterintuitive, but the second government is in a stronger position. Open Source on a non-European cloud gives you more sovereignty than proprietary software on a European one, because you can always change the infrastructure. You can't fix the licensing.

This doesn't make the second scenario risk-free. The ideal solution would be Open Source on a sovereign European cloud.

People overestimate jurisdiction and underestimate licensing. Licensing is not one sovereignty factor among many. It's the sovereignty prerequisite.

Special thanks to Tiffany Farriss and Sachiko Muto for their review of this blog post.

04 Apr 2026 6:21am GMT

On June 19 and 20, I will cycle a little over 100 miles from downtown Chicago and its wonderful Millenium Park to New Buffalo, Michigan, as part of the Tour de Shore 2026. The ride passes through northwest Indiana and the extended Indiana Dunes National Park ending the next morning in the southwestern Michigan town of New Buffalo. I rode Tour de Shore once before in 2024 and had a generally wonderful time (even considering some soreness after a century of miles over 1 1/2 days).

Tour de Shore is riding in support of Maywood Fine Arts Center, a local arts and sports center in Maywood, Illinois, a suburb one over from where I live and hence just a few good miles west of downtown. Maywood, Illinois is home to legends such as the late John Prine as well as several NBA players such as player and coach Doc Rivers.

But Maywood, Illinois is also little less well off than other western suburbs. The Maywood Fine Arts Center is simply legendary is what they do for this community (and surrounding communities), and especially the youth support. They can use a dollar a two. Their story about Tour de Shore is worth a read too for background and motivation.

I have bootstrapped my donation page page with a dollar for each mile to be cycled. It would be simply terrific if you could join me. A nickel, a dime, or a quarter per mile cycled would help. Multiples of that help too: More is of course still always better.

Anything you can afford will go a long way towards a worthy goal in a community that could use the help.

Of and if you are local to the area, I believe you can still register for Tour de Shore 2026. So see you out there in June? And if not, maybe help with a dollar or two?

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog.

04 Apr 2026 1:08am GMT

There are still a few of us (at least two) who are using MK:DEFSYSTEM. The venerable system construction tool has accumulated a lot of ancient cruft, some of which quite convoluted.

Recently I went back to MK:DEFSYSTEM and "cleaned up" some of the code, especially regarding the pathname construction for each component. I also used some simpler hierarchical tricks using defstruct only.

The result should be more solid and clearer in the steps that comprise some "macro tasks". Of course, a rewrite using CLOS would change the coding style, but the choice has been made to keep the MK:DEFSYSTEM code base quite... retro (and somewhat simple).

Why did I went back to MK:DEFSYSTEM? As usual, it is because of a rabbit-hole I fell into: I will blog about it later on (hint: HEΛP).

MK-DEFSYSTEM quick history as of March 2026

MK-DEFSYSTEM (or MK:DEFSYSTEM, or MAKE:DEFSYSTEM) was originally written by Mark Kantrowitz as part of the original "CMU Lisp Utilities" collection; an early "public" set of Common Lisp code and utilities that, in the writer's opinion form one of the basis of most Common Lisp writing to date.

As stated (by M. Kantrowitz himself) in this file header, the original version of MK-DEFSYSTEM was inspired by the Symbolics DEFSYSTEM (or DEFSYS) tool. Yet, MK-DEFSYSTEM differs significantly from it.

In its original form, MK-DEFSYSTEM was built in the CLtL1 era, accommodated a lot of variance among filesystems and CL implementations and it still bears those idiosycrasies. CLtL2 (1992) first and ANSI (1994) next, started reshaping the code base then.

MK-DEFSYSTEM was originally distributed under a license agreement that made redistribution tricky. In 1999, the writer - that'd be me, Marco Antoniotti - contacted Mark Kantrowitz offering to become a maintainer while reworking the distribution license to hammer some FOSS into it. Mark Kantrowitz graciously agreed and, after that, the writer got literally and physically hugged by a few Common Lisp developers because they could use MK-DEFSYSTEM more freely.

Of course, ASDF came along and it solved the same problems that Symbolics (and Kent Pitman's) DEFSYS and MK-DEFSYSTEM solve, plus much more.

Yet, MK-DEFSYSTEM has some nice features (in the eye of the beholder).

MK-DEFSYSTEM still ships in one file - defsystem.lisp - that you can LOAD in your Common Lisp init file. Of course, a big chunk of its current code base is "backward compatibility" and new ok-we-miss-UIOP-and-or-at-least-CL-FAD functionality, plus an ever growing ongoing commentary like this one.

Given this background, the writer has been maintaining MK-DEFSYSTEM for a long time, and more recently, Madhu has made significant changes (and maintains himself a fork with some bells and whistles of his own) since 2008.

Of course, many other contributors helped over the years, and are acknowledged in the early Change Log and in comments in the code.

In early 2026, the writer cleaned up the code and reworked some of the logic, by factoring out some code from main functions. In particular, the CREATE-COMPONENT-PATHNAMES, GENERATE-COMPONENT-PATHNAMES, COMPONENT-FULL-PATHNAME, COMPONENT-FULL-NAMESTRING interplay is better organized; plus new structures, leveraging DEFSTRUCT :INCLUDE feature have been introduced, rendering the code TYPECASE-able.

MK-DEFSYSTEM is old, but it works. It is quirky but it works (at least for the two or three known users - which, in 2026, is already a big chunk of the Common Lisp users' community). Moreover, it does have, at least in the eye of the beholder, some more user friendly user API, for most use case, especially for plain Common Lisp code.

The current MK-DEFSYSTEM repository is at https://gitlab.common-lisp.net/mantoniotti/mk-defsystem

(*) It is assumed that the reader knows about all the acronyms, tools and systems referred to in the text.

'(cheers)

03 Apr 2026 1:04am GMT

Haven't written here about it, but last March we finally started on our journey to get our own house build, so we can move out of the rented flat here.

That will be a big step, both the actual building, but also the moving - I am living at this one single place for 36 years now.

If you can read german there is a dedicated webpage where I sometimes write about the process. Will have much more details (and way more ramblings) than the following part.

If you can't read german, a somewhat short summary follows. Yes, still a lot of text, but shortened, still.

What? Why now?

Current flat has 83m² - which simply isn't enough space. And the number of rooms also doesn't fit anymore. But it is hard to find a place that fits our requirements (which do include location).

Moving to a different rented place would also mean changed amount of rent. And nowadays that would be huge increase (my current rent is still the price from about 30 years ago!).

So if we go and pay more - we could adjust and pay for something we own instead. And both, my wife and I had changes in our jobs that made it possible for us now, so we started looking.

Market

Brrrr, looking is good, actually finding something that fits - not so. We never found an offer that fit. Space wise, sure. But then location was off, or price was idiotically high. Location fit, but then size was a joke, and guess about the price… Who needs 200 square meters with 3 rooms? Entirely stupid design choices there. Or how about 40 square meters of hallway - with 50m² of tiny rooms around. What are they smoking? Oh, there, useful size, good rooms - but now you want more money than a kidney is worth, or something. Thanks, no.

New place

In February 2025 we finally got lucky and found a (newly opened) area with a large number of places to build a house on. Had multiple talks with someone from on of the companies developing that area (there are two you can select from), then talked with banks and signed a contract in March 2025. We got promised that actual house construction would be first quarter of 2026, finished in second quarter.

House type

There are basically 2 ways of building a new house (that matter here). First is called "Massivhaus", second is called "Fertighaus" in german, roughly translating to solid and prefabricated. The latter commonly a wood based construction, though it doesn't need to be. The important part of it is the prefabrication, walls and stuff get assembled in a factory somewhere and then transported to your place, where they play "big kid lego" for a day and suddenly a house is there.

A common thought is "prefabricated" is faster, but that is only a half true. Sure, the actual work on side is way shorter - usually one or two days and the house is done - while a massive construction usually takes weeks to build up. But that is only a tiny part of the time needed, the major part goes of into planning and waiting and in there it doesn't matter what material you end up with.

Money fun

Last year already wasn't the best time to start a huge loan - but isn't it always "a few years ago would have been better"? So we had multiple talks with different banks and specialised consultants until we found something that we thought is good for us.

Thinking about it now - we should have put even more money on top as "reserve", but who could have thought that 2026 turns into such a shitshow? Does not help at all, quite the contrary. And that damn lotto game always ends up with the wrong numbers, meh.

Plans and plans and more plans - and rules

For whichever reason you can not just go and put something on your ground and be happy. At least not if you are part of the normal people and not enormously rich. There is a large set of rules to follow. Usually that is a good thing, even though some rules are sometimes hard to understand.

In Germany, besides the usual laws, we have something that is called "Bebauungsplan", which translates to "development plan" (don't know if that carries the right meaning, it's a plan on what and how may be build, which can have really detailed specifications in). It basically tells you every aspect on top of the normal law that you have to keep in mind.

In our case we have the requirement of 2 full floors and CAN have a third smaller on top, it limits how high the house can be and also how high our ground floor may be compared to the street. It regulates where on the property we may build and how much ground we may cover with the house, it gives a set of colors we are allowed to use, it demands a flat roof that we must have as a green roof and has a number of things more that aren't important enough to list here. If you do want to see the full list, my german post on it has all the details that matter to us.

With all that stuff in mind - off to plans. Wouldn't have believed how many details there are to take in. Room sizes are simple, but how to arrange them for ideal usage of the sun, useful ways inside the house, but also keeping in mind that water needs to flow through and out. Putting a bath room right atop a living room means a water pipe needs to go down there. Switch the bath room side in the house, and it suddenly is above the kitchen - means you can connect the pipes from it to the ones from kitchen, which is much preferred than going through the living room. And lots more such things.

It took us until nearly end of October to finalize the plans! And we learned a whole load from it. We started with a lot of wishes. The planner tried to make them work. Then we changed our minds. Plans changed. Minds changed again. Comparing the end result with the first draft we changed most of the ground floor around, with only the stairs and the entrance door at the same position. Less changes for the upper floor, but still enough.

Side quests

The whole year was riddled with something my son named side quests. We visited a construction exhibition near us, we went to the house builders factory and took a look on how they work. We went to many different other companies that do SOME type of work which we need soon, say inside floors, painters, kitchen and more stuff.

Of course the most important side quest was a visit to the notary to finalize the contracts, especially for the plot of land (in Germany you must have a notary for that to get entered into the governments books). Creates lots of fees, of course, for the notary and also the government (both fees and taxes here).

Building permit

We had been lucky and only needed a small change to the plans to get the building permit - and the second part, the wastewater permit (yes, you need a separate one for this) also got through without trouble.

Choices, so many of them

So in January we finally had an appointment for something that's called "Bemusterung" which badly translates to "Sampling". Basically two days at the house builders factory to select all of what's needed for the house that you don't do in the plans. Doors, inside and out and their type and color and handles. Same things for the windows and the blinds and the protection level you want the windows to have. Decide about stairs, design for the sanitary installations - and also the height of the toilet! - and the tiles to put into the bathrooms. Decisions on all the tech needed (heating system, ventilation and whatnot.

Two days, busy ones - and you can easily spend a lot of extra money here if you aren't careful. We managed to get "out of it" with only about 4000€ extra, so pretty good.

Electro and automation

Now, here I am special. Back when I was young the job I learned is electrician. So here I have very detailed wishes. I am also running lots of automatism in my current flat - obviously the new house should be better than that. So I have a lot of ideas and thoughts on it, so this is entirely extra and certainly out of the ordinary the house builder usually see.

Which means I do all of that on my own. Well, the planning and some of the work, I must have a company at hand for certain tasks, it is required by some rules. But they will do what I planned, as long as I don't violate regulations.

Which means the whole electrical installation is … different. Entirely planned for automatisms and using KNX for it. I am so happy to ditch Homeassistant and the load of Homematic, Zigbee and ZWave based wireless things.

Ok, Homeassistant is a nice thing - it can do a lot. And it can bridge between about any system you can find. But it is a central single point of failure. And it is a system that needs constant maintenance. Not touched for a while? Plan for a few hours playing update whack-a-mole. And often enough a component here or there breaks with an update. Can be fixed, but takes another hour or two.

So I change. Away from wireless based stuff. To wires. To a system thats a standard for decades already. And works entirely without a SPOF. (Yes, you can add one here too). And, most important, should I ever die - can easily be maintained by anyone out there dealing with KNX, which is a large number of people and companies. Without digging through dozens of specialised integrations and whatnot.

I may even end up with Homeassistant again - but that will entirely be as a client. It won't drive automations. It won't be the central point to do anything for the house. It will be a logging and data collecting thing that enables me to put up easy visualizations. It may be an easy interface for smartphones or tablets to control parts of the house, for those parts where one wants this to happen. Not the usual day-to-day stuff, extras on top.

Actual work happening

Since march there finally is action visible. The base of the house is getting build. Wednesday the 1st April we finally got the base slab poured on the construction site and in another 10 days the house is getting delivered and build up. A 40ton mobile crane will be there.

02 Apr 2026 9:23pm GMT

The diffoscope maintainers are pleased to announce the release of diffoscope version 316. This version includes the following changes:

[ Jelle van der Waa ]
* Fix compatibility with LLVM version 22.

[ Chris Lamb ]
* Add some debugging info for PyPI debugging.

You find out more by visiting the project homepage.

02 Apr 2026 12:00am GMT

Pointer-rich data layouts lead to suboptimal performance on modern hardware. For an excellent introduction to this, see the article The Road to Valhalla. While it is specifically about Java, many parts of the article also apply to other languages. To summarize some of the key points of the article:

• In 1990, a main memory fetch was about as expensive as an arithmetic operation. Now, it might be a hundred times slower.
• A pointer-rich data layout involving indirections between data at different locations is not ideal for today's hardware.
• A language should make flat (cache-efficient) and dense (memory-efficient) memory layouts possible without compromising abstraction or type safety.

Consider a vector of records (or tuples, structures, product types - I'll stay with "record" in this article). A pointer-rich layout has each record allocated separately in the heap, with a vector containing pointers to the records. For example, given a "Point" record of two numbers:

The flat and dense layout has the records directly in the array:

(Note that there is another flat layout, namely, using one vector per field of the record. This is better suited to instruction-level parallelism or specialized hardware (e.g., GPUs), especially when the record fields have different sizes. But it is less suited for general-purpose computing, as reading a single vector element requires one memory access per field, whereas the "vector of records" layout above requires only one access per record. Such a layout can be easily implemented in any language that has arrays of native types, whether in the language itself or in a library (e.g., OCaml's Owl library). Thus, in this article, I will only consider the "array of records" layout above.)

Functional language considerations

Things should be much easier in functional languages than in Java: we have purity, referential transparency, and everything is a value. So it should be simple enough to store these values in memory in their native representation. But there are reasons that that is often not the case in practice:

• Lazyness: a value can be a computation that produces a value only when needed.
• Layout polymorphism: unless we replicate the code for every type (as, for example, Rust does), we need to be able to store every possible value in the same kind of slot.
• Dynamically typed languages require type information at runtime.
• Functional languages often have automatic memory management, which may require runtime type information.
• Many of our languages are not purely functional, but contain impure features.
• Pure languages often lack traditional vectors or arrays, since making them perform well in immutable code is not easy.
• Historical reasons: Graph reduction was a common implementation technique for lazy languages, and graphs involve pointers.
• Implementation restrictions: not being mainstream, fewer resources are devoted to implementation and optimization.

Many implementations can not even lay out native types flat in records, so a Point record of IEEE 754 double-precision numbers may actually look like this in memory:

The (very short) List

So, given a record type, which functional languages allow a collection of values of that type to have a flat, linear memory layout? The number of programming languages that claim to be "functional" is huge, so the ones listed here are just a selection based on my preferences - mainly languages that allow that layout, and some I have some experience with and can speculate on how easy or hard it would be to add that as a library or extension.

Since the Point record can be misleading in its simplicity when it comes to the question of whether the functionality could be implemented as a library, I'll point out that there are records where the layout is a bit more interesting:

• Records containing different types with different storage sizes, for example, one 64-bit float and one 32-bit integer. On most architectures, this will require 4 bytes of padding between elements.
• Records containing native values along with something that has to be represented as a pointer, for example, a reference-type or a lazy value. In a flat layout, this means that every nth element will be a pointer, requiring special support from the memory management system, either by providing layout information or by using a conservative GC that treats everything as a potential pointer.

Pure languages:

Clean

Yes: Clean has unboxed arrays of records in the base language.

Caveat: it does not have integer types of specific sizes and only one floating-point type, making it harder to reduce memory usage by using the smallest type just large enough to support the required value range. It seems possible to implement such types in a library (the mTask system does that).

Futhark

No. Futhark does not intend to be a general-purpose language, so this is not surprising.

I mention it here because it does have arrays of records, but, since it targets GPUs and related hardware, it uses the "record of arrays" layout mentioned above.

Haskell

Yes. Not in the base language, but there is library support via Data.Vector.Unboxed. Types that implement the Unbox type class can be used in these vectors. Many basic types and tuples have an Unbox instance. However, when you care about efficiency, you probably do not want to use tuples but rather a data type with strict fields, i.e., not:

type Point = (Double, Double)

but:

data Point = Point !Double !Double

Writing an Unbox instance for such a type is not trivial. The vector-th-unbox library makes it easier, but requires Template Haskell. Unboxed vectors are implemented by marshalling the values to byte arrays, so records with pointer fields are not supported.

Impure Languages

F#

Yes, even records with pointer fields. Records have structural equality, and you can use structs or the [<Struct>] attribute to get a flat layout.

And that's all I could find. Unless I follow Wikipedia's list of functional programming languages, which contains languages such as C++, C#, Rust, or Swift, that allow the flat layout, but don't really fit my idea of a functional language. But SML, OCaml, Erlang (Elixir, Gleam), Scala? Not that I could see (but please correct me if I'm wrong).

Rolling your own

Since there is a library implementation for Haskell, maybe that's a possibility for other languages?

You should be able to implement flat layouts in any language that supports byte vectors. More interesting is how well such a library fits into the language, and whether a user of the library has to write code or annotations for user-defined record types, or whether the library can handle part or all of that automagically.

I'll only mention my beloved Lisp/Scheme here. Lisp's uniform syntax and macro system are a bonus here, but the lack of static typing makes things harder.

In Scheme, R6RS (and R7RS with the help of some SRFIs) has byte-vectors and marshalling to/from them in the standard library. But Scheme does not have type annotations, so you either need to offer a macro to define records with typed fields or to define how to marshal the fields of a regular (sealed) record. Since you can shadow standard procedures in a library, you can write code that looks like regular Scheme code, but, perhaps surprisingly, loses identity when storing/retrieving values from records:

(let ((vec (make-typed-vector 'point 1000))
      (pt (make-point x y)))
  (vector-set! vec 0 pt)
  (eq? (vector-ref vec 0) pt))
 ⇒ #f

(But then, you probably shouldn't be using eq? when doing functional programming in Scheme).

The same approach is possible in Common Lisp. In contrast to Scheme, it does have optional type annotations, and, together with a helper library for accessing the innards of floats and either the meta-object protocol to get type information or (probably better) a macro to define typed records, an implementation should be reasonably straightforward. Making it play nice with inheritance and the dynamic nature of Common Lisp (e.g., adding slots to classes or even changing an object's class at runtime) would be a much harder undertaking.

Conclusion

Of the functional languages I looked at, only F# fully supports flat and dense memory layouts. Among the pure languages, Haskell and Clean come close.

The question is how important this really is. There's a good argument to be made for turning to more specialized languages like Futhark if you mainly care about performance. On the other hand, having a uniform codebase in one language also has advantages.

Then, the performance story has changed, too. While the points Project Valhalla raises remain true in principle, processor designers are aware of this as well. They are doing their best to hide memory latency with techniques such as out-of-order execution or humongous caches. Thus, on a modern CPU, the effects of a pointer-rich layout are often only observable with large working set sizes.

Still, given the plethora of imperative language that can get you to Valhalla, support for this in the functional landscape seems lacking. In the future, I hope to see more languages or libraries that will make this possible.

12 Mar 2026 11:17am GMT

FSet v2.3.0 added transients! These make it faster to populate new collections with data, especially as the collections get large. I shamelessly stole the idea from Clojure.

They are currently implemented only for the CHAMP types ch-set, ch-map, ch-2-relation, ch-replay-set, and ch-replay-map.

The term "transient" contrasts with "persistent". I'm using the term "persistent" in its functional-data-structure sense, as Clojure does: a data structure is persistent if multiple states of it can coexist in memory efficiently. (The probably more familiar use of the term is in the database sense, where it refers to nonvolatile storage of data.) FSet collections have, up to now, all been persistent in this sense; a point modification to one, such as by with or less, takes only O(log n) space and time to return a new state of the collection, without disturbing the previous state.

A transient encapsulates the internal tree of a collection so as to guarantee that it holds the only pointer to the tree; this allows modifications to tree nodes to be made in-place, so long as the node has sufficient allocated space. Once the collection is built, the tree is in the same format that existing FSet code expects, and can be accessed and functionally updated as usual.

Some quick micro-benchmarking suggests that speedups, for constructing a set from scratch, range from 1.6x at size 64 to as much as 2.4x at size 4096.

You don't necessarily even have to use transients explicitly in order to benefit from them. Some FSet builtins such as filter and image use them now. The GMap result types ch-set etc. also use them.

For details, see the GitLab MR.

07 Mar 2026 8:04am GMT

Are you ready for another challenge? We're excited to host the second yearly edition of our treasure hunt at FOSDEM! Participants must solve five sequential challenges to uncover the final answer. Update: the treasure hunt has been successfully solved by multiple participants, and the main prizes have now been claimed. But the fun doesn't stop here. If you still manage to find the correct final answer and go to Infodesk K, you will receive a small consolation prize as a reward for your effort. If you're still looking for a challenge, the 2025 treasure hunt is still unsolved, so舰

29 Jan 2026 11:00pm GMT

If your non-geek partner and/or kids are joining you to FOSDEM, they may be interested in spending some time exploring Brussels while you attend the conference. Like previous years, FOSDEM is organising sightseeing tours.

26 Jan 2026 11:00pm GMT

With FOSDEM just a few days away, it is time for us to enlist your help. Every year, an enthusiastic band of volunteers make FOSDEM happen and make it a fun and safe place for all our attendees. We could not do this without you. This year we again need as many hands as possible, especially for heralding during the conference, during the buildup (starting Friday at noon) and teardown (Sunday evening). No need to worry about missing lunch at the weekend, food will be provided. Would you like to be part of the team that makes FOSDEM tick?舰

26 Jan 2026 11:00pm GMT