Tuesday, January 1, 2019

Now that RHEL8 is officially out, I can get back to my public daily record of what I am working on. I should have done that a bit sooner, but I was quite exhausted.

First things first:

This is a picture taken in London last August, with my beloved wife and four kids in front of Buckingam Palace. It was a lovely time together. This Christmas, we again had all four kids at home, and having this twice in the same year was a treat.

Lights are back on

This blog was not updated since August. There is a good and a bad reason for that.

The good reason is that my work for the past months was focusing on RHEL8, notably on demoing it internally and externally. Since RHEL8 was very much under wraps, I could not publicly document what I was working on, which I found a bit annoying.

In truth, there was a lot I could have documented, like my wrap-up work on SPICE "smart streaming". Smart streaming is the ability to adjust streaming parameters on the fly. I will talk about it at the next DevConf.cz in Brno. The same talk had also been accepted at FOSDEM, but I was stupid enough to not correctly read the acceptance email, and did not confirm in time, so the organizers picked someone else. Ouch. That will teach me to read TL;DR emails.

But I was tired in part because of the discussions around SPICE, transitioning to a new job, the conferences in August, and under some pressure to learn tons of new stuff about RHEL8. So in reality, this blog just took a big hit because I was not "in the mood", too tired to do it.

Vacation took care of the fatigue, I'm upbeat again, and ready to start the new year with the habit of writing down my thoughts daily.

During the Christmas Break

During the Christmas break, I decided to really get away from everything Red Hat. A problem with open source is that, at least for me, it's a bit like a hobby or like a drug. You never want to stop. It's really not like work. Plus I work from home, so what is there to stop me? Where is the boundary?

Right before the break, I could feel that I was really tired, cranky, annoying and unproductive. In all areas of my life, not just work. So I decided to really cut the cord and not do anything related to Red Hat during the break.

That does not mean I did not use my computer That would be too much to ask. I would have been quite lonely. I feel terrible for saying so, but my whole family actually enjoys being together around a table, each of us sitting in front of their screen, simply doing stuff we love while talking to one another. When I was a kid, I remember family reading parties that were exactly the same. All in the same room, each of us reading some good book, around a lit fire. That was Christmas This year, it was the same, all of us enjoying their own screen while still being happy to be together.

XL

One of the things that were really itching is the bad state of the XL compiler, so I spent a little bit of time on this.

Cleaning up the mess

Each time I need to create a presentation, I use Tao3D. And each time, I cringe, because it's bit-rotten. It's bit-rotten because XL itself is bit-rotten.

Tao3D is by far my largest contribution to the open-source community, but it's one of these many projects that has essentially no community and only one maintainer. As a result, it has seriously bit-rotten. The primary problem is that it uses LLVM, which never really paid much attention to compatibility between releases.

I tried to address that with an LLVM "compatibility restoration adaptive protocol", aka llvm-crap, but this was only moderately successful, since LLVM kept adding new and strange incompatibilities faster than I could address them.

As a result, Tao3D no longer can compile with any reasonably recent version of LLVM. Another related issue is that the Tao3D branch of XL was something I was not very happy with, language-wise, which led to various experimental spin-offs, like ELFE. All this led to many branches, many of which either no longer compiled or were incompatible with one another.

It was time for a big cleanup. So I did that. I merged together the latest changes in ELFE and a couple of experimental branches of XL, and all is now integrated in the native branch. The re-jit and re-xl branches, which were attempts at repairing the JIT and repairing XL, are both essentially integrated in native, and I plan no further work on them.

That being said...

XL - Types are complicated

I then spent a bit of time trying to resume my work on the type system. A discovery from a previous Christmas break (2016?) was that the type system in XL had to be expressed using parse tree shapes.

For example, in the complex arithmetic example, a complex number is represented as follows:

complex is type(re:real, im:real)

This means that a complex is something that has a parse tree shape similar to (1.2,2.6). In the long run, you could decide that having real numbers is an unnecessary restriction, so the long-term plan is to have soemthing like:

complex is type(re:number, im:number)

where number would be something like:

number is integer | real

I could also decide that I want something a little more explicit as a notation for complex numbers, e.g.

complex is type complex(re, im)

in which case you would need a "constructor notation" like complex(1,2) for the type system to recognize the parse tree as being a complex.

Some of the parse tree shapes are atoms, e.g. integers, real numers, text, characters, symbols, etc. That part is relatively easy.

When the shape is more complicated, e.g. an "infix" like the comma in 1,2, or the parenthesized block containing an infix as in (1,2), then the type system needs to match the actual "template" shape as defined by a parameter, for example if you write Z:complex, with the actual tree shape of the argument, e.g. if you pass (1.3,2.6). This happens for example in the definition of the subtraction operator:

Z1:complex - Z2:complex is (Z1.re - Z2.re, Z1.im - Z2.im)
writeln "(3,4) - (5,6)=", (3,4) - (5,6)

In that example, (3,4) will be matched to Z1, and as you can see, the code can then refer to Z1.re based on the names given in the shape of the complex type.

This is very similar to structures in languages such as C. And indeed, my goal is to generate machine code where this is essentially converted to a C-style structure type. However, this is much more flexible than C in two respects.

1. The shape of the type can be arbitrary. For example, you can write code that operates on if then else statements by writing an if_then_else type like this:

     if_then_else is type(if Condition then TrueStatement else FalseStatment)
     invert I:if_then_else is
         if not I.Condition then I.FalseStatement else I.TrueStatement
     

2. A given parse tree shape can belong to multiple types. For example, you can imagine having:

     complex is (re:number, im:number)
     list is (head, tail)
     

   This would not necessarily be a very wise idea for various reasons. But in that case, (1,2) would both be a list and a complex, whereas ('A', 'B', 'C') would only be a list.

Reintegrating XL2

Another result of the cleanup is the reintegration of XL2, the imperative variant of XL. That code had not bit-rotten yet, but it was an important part of the history that I did not want to lose.

Also, it is so far the only self-compiling XL compiler, with a C++ transpiler as a bootstrap stage. So I might as well preserve that.

What would native code look like now?

This brought me to doing something I wanted to do for a relatively long time, which is to write some native code to see where I wanted the language to go. That code won't compile at all, it's mostly ahead-of-time code written to solidify ideas of what the language should look like.

Syntactic sugar ideas

This led to another idea that came up during the Christmas break, namely a new syntax for some types of top-level declarations. Not really new, actually, since it's more like restoring the old XL2 syntax for some things.

For example, instead of writing

io is module with ...
complex is type complex(re, im)

I would rather write:

module io with ...
type complex is complex(re, im)

I find this second notation more natural. It can trivially be transformed into the first one, which is still the "consistent" one. The only prefix names that would be transformed that way as far as I can tell at the moment are type and module.

Yellow vests and constant voting

During the break, I was quite interested by the "Gilets Jaunes" (Yellow vests) movement. Of particular interest to me is all the discussion about how to reform democracy so that it's no longer a "fire and forget" approached with some elected subclass has all the power without much of a control for extended periods of time.

For a long time, I have been thinking about how technology could help making voting easier. I think that we are now at a point where representative should only deal with writing the low, not voting it. Voting can and should be left to the people.

The current discussion in France is around the "RIC" or "Referendum d'initiative citoyenne" (citizen-intitiated referendum). The idea has been successfully implemented in various countries like Switzerland, altough almost always in a rather limited form.

My own thoughts on the topic have revolved around "constant voting", the idea that if you vote several times a day (much like you consult your email or Facebook page), then you will focus on things that interest you out of necessity (much like for email and Facebook). So engineers will vote on engineering issues, and we might (just might) stop having idiotic and citizen-hostile laws like the infamous Article 13.

The Patreon debacle

A related topic is the Patreon debacle.

I am personally very concerned by reports of this nature. Technology companies, like anybody, have a power. They should never use this power for partisan reasons. It is not the role of technology companies to police their customers. Unfortunately, this has become a rather common trend, and it's a dangerous one.

On that front, I was extremely disappointed with Tim Cook's you have no place on our platform speech. Why does Tim Cook believe he's entitled to taking advantage of his position to exercise any kind of pressure on someone else for holding what he considers the wrong religious or political views?

"You have no place on our platform"? This is so wrong on so many levels. The only reason someone has a place on your platform is because you offer a service and they are willing to pay for it. This has absolutely nothing to do with your beliefs or mine, nor should it.

Anybody may refuse to perform a specific form of work for whatever reason. Apple may refuse to sell me Macs equipped with Windows, it's their prerogative since that would be me forcing them to do something that goes against their values. Similarly, I think it was perfectly legitimate for a baker to refuse to create a cake carrying a message that happens to offend him. I realize this is not a popular opinion these days, but it's still the only reasonable one.

However, what Tim Cook or Patreon have been doing here is not refusing to do specific work that goes against their values. They refuse to offer a service based on discrimination. In other words, they offer the service to everybodhy, unless they meet some criterion. That's the very definition of discrimination. It's as if the same baker, instead of refusing to write a specific message on a cake, refused to sell a generic cake to the gay couple. That would be discriminatory. What Patreon did was discriminatory. What Apple purports to do is discriminatory, and all the "hate speech" rhetoric is only a thin veil that does a very bad job hiding where the real hate lives..

Technologists are not the only ones with power. Imagine if everybody acted that way. "I won't sell bread to non-christians", "This electricity company cannot service you because you are muslim", "we only sell this car model to men", and so on. What if the electricity company decided to cut the power to Apple because they don't like Tim Cook's positions? What if in retribution the gas companies refused to sell gas to produce electricity? You see where this is going.

The Patreon case is even worse than the already egregious imaginary cases above, because Patreon cut the primary source of income of one of their customers, who was reportedly making about $12000 a month on the platform. I can't imagine very many offenses that would carry a $12000 fine in the US, much less a "we take all your income away" penalty. What on earth was Patreon thinking on this one?

This is all very dangerous. I am very much in line with Eric Raymond on this. If you have not, you should read his essay on the harm that so-called "Social Justice Warriors" (SJWs) can cause.

This is why software freedom is so important. This is why free-software based constant voting systems are in my opinion necessary. This is why crypto-currencies where nobody can play this kihd of dirty trick, not even a government, are so incredibly important.

We are at a turning point.