The Kernel Programming Language | Hacker News Reader

The Kernel Programming Language

web.cs.wpi.edu

74 pointsadgasf23 comments

I wonder if it's possible to infer the types of a Kernel program.

Certainly not with our existing type systems. It might be possible if somebody could come up with a new system with the vau calculus at its core rather than lambda calculus (as Hindley-Milner etc. are).

I think it would be a dead-end with kernel-standard though. The presence of mutability and cyclic data structures seems like the problem would be as unsolvable as the halting problem. For any serious investigation of type inference, you would probably need to stick to an immutable Kernel subset. The Kernel Report does make mutability optional.

Hmm, I don’t see why vau-calculus should change things. Fexpr are more or less like expression trees in C# no? (Which are statically typed, at least where they compose with the rest of the program). Granted, dynamic languages in general can be a challenge, but TypeScript is a good argument for it being feasible at least.

The same idea - allowing a procedure to get either a reference to a value or syntactic description of the value coupled with the dynamic environment from the procedure call-site - is implemented in Io language.

Io is a purely OO language influenced by Smalltalk and Self the most; it has only objects and no classes, objects have named slots which reference other objects (some of which are "activatable" - callable, IOW - and they're then called methods) and all computation happens by sending messages between objects. If a message name corresponds to the slot name which holds a method, that message send (by default) results in the method being called.

Messages are just objects, which carry both dynamic environments from the place they were sent and the arguments, which are passed as message objects themselves. The method may then choose to evaluate some of the messages passed as arguments or not; but it can also change the messages before evaluating them, as the Message objects are mutable and respond to many of the same messages that Lists respond to, including `setAt(idx, val)` for example.

(One tricky part of all of this is getting the relation between Message objects and message-sends in Io. In short, Messages are objects which have target, name, and a list of arguments. These objects can be both serialized into, and read from a string, in which case they look like this:

    target msgName(arg1, arg2, ...)

The place in program text and the lexical environment at that point is a message-send, while Message is a runtime representation of that message-send and it references dynamic environment at the point of call.

And BTW, in the syntax of message-send above, both `target` and `(arg1, ...)` are optional. In Io, code like this:

is, in fact, a message send with `name` set to `"1"`; it's first sent to the current `this` object, and then bubbles up the inheritance chain to `Object`, which handles the message by returning a Number object with value of `1`.)

The effect is really interesting: the language is incredibly expressive, with metaprogramming support rivaling Lisp (Io is also homoiconic), but with a very different set of metaphors/concepts it's built on. It could be more approachable for normal devs (than Lisps), as its syntax is arguably closer to the mainstream, and the OO metaphor is widely known (although not really understood in a way Smalltalk, Self or Io understand it).

Anyway, being able to write functions which can decide whether they want, and how exactly, evaluate their arguments is a powerful technique. I think REBOL and Red are also able to do this, and I think TCL too. Factor would also count, probably. It's a shame it's not supported in more mainstream languages - may be hard to implement efficiently, or may not be that useful with non-homoiconic languages or something like that.

I’m a big fan of Io, but, sadly, it is no longer maintained. I’ve toyed around with writing a more minimalistic implementation suitable for lua-style embedding, but have never found the willpower to finish it.

That's true, although I'd say it's still maintainable, and Steve Dekorte still accepts Pull Requests. I had a bit of an adventure with Io last year[1], which was part of a side-project I had in mind for a very long time, namely a MUD server in the style of LPMUDs. I learned a lot and even wrote some of the code for the server, then decided to port pyparsing (parser combinator library) to Io, and then - as usual - the life happened and I forgot about it. Still, that project was with me for the past 20 years, and I believe I will get back to it at some point[2]... all that just to say that I'm not going to become the main maintaner, but if there are just a few interested people, I'd be willing to help :)

[1] https://klibert.pl/posts/adding_destructuring_bind_to_io.htm...

[2] Fortunately for me, Io has all I would need for this project, including async I/O and lightweight co-routines.

Thank you for this description. It nicely shows how OO is no less complex, and likely more complex and hard to "get" properly, than most other programming paradigms. It only feels intuitive after serious amounts of time have been invested in studying it, again much like most other paradigms.

> The Kernel Programming Language

Because no one uses `kernel` for anything already.

I mean, holy fucking hell, if you're creating a programming language, choose a name that you can fucking search for.

I vote they choose Colonel instead if they do any sort of rename.

I think the next programming language I write will be named the Software Programming Language.

Mine will be called simply Programming Language.

How about A Programming Language https://en.wikipedia.org/wiki/APL_(programming_language)? Yeah, that's the ticket.

And a recursive acronym to boot!

Or Programming Language One (https://en.wikipedia.org/wiki/PL/I)

Mine will be a scripting language called Compiler

Mine will be called lang. The docs can be found on the official website, langlang.org of course.

>Because no one uses `kernel` for anything already.

Because people will seriously be perplexed between an esoteric experimental programming language and operating system kernels, right?

Like that huge fiasco in the early 50s, when people confused OS kernels with corn...

no, it's called a "search result"

We have C, a language named after a letter, and Go, a language named after a verb, and your issue is with "Kernel"?

Just fucking add fucking "programming language" as the suffix to your fucking query about Kernel the PL, to mimic the tone of the original comment.

C, which was named before search engines were a thing, and Go, which is also a terrible name, but google is big enough they can make it work.

Also, it's not like things like the linux kernel have a specific enough dialect of C it could be considered a programming dialect/language itself, so there are multiple layers of poor naming here.

The point is if you want people to use your esoteric programming language, you want to minimize any blatantly obvious pain points. Choosing a decent name is a very easy pain point to avoid.

Searching for “kernel programming language” mostly turns up a bunch of results about what programming languages are good for kernel programming. Adding words doesn’t always disambiguate.

I mean, it doesn’t turn up any results about corn, so I guess that’s something, but beyond that it doesn’t seem terribly helpful.

People, no. Pretty much every search engine ever? Ohhhhh yeeeaaahhh.

Besides, the Linux kernel has a specific-enough dialect of C that I assumed this was about linux kernel programming based on the title.

> the Linux kernel has a specific-enough dialect of C that I assumed this was about linux kernel programming based on the title

Yeap, same here. This is a really poor naming choice.

Reply on news.ycombinator.com