Hey, there! Long time no see.

Links to GitHub are in a comment, as per rules. Also, I'm Michal, the author of Par, human aside from other qualities.

I wanted to share with you what's been up with Par for the last half a year or so.

Par is a programming language that's quite unusual. (And breaks your mind at first.) It's trying to get some edgy theoretical stuff out there into practice, specifically: - Linear / session types - with duality, so every type has "the other side" - Automatic concurrency - everything that can run concurrently does - Totality - no runtime errors, no deadlock, no infinite loops

It's based on classical linear logic, and naturally combines functional programming, a version of object-oriented programming, and session-typed process communication, all under one paradigm.

But perhaps most importantly, Par is trying to make all of the above into a good practical language! That's quite big ambition, and this last half year we've gotten closer to that than ever.

Below is the most fancy new stuff. Let me know what you think!

New I/O Capabilities

The standard library now includes a richer set of I/O modules: - Console - stdio print and prompt - Http - HTTP server & client functionality - Os - files, env - Sql (new!) - PostgreSQL, MySQL, and SQLite (in memory too), transactions, row decoding - WebSocket (new!) - HTTP to WebSocket in both server & client mode

Auto-Cleanup

Linear types can't be dropped. That's their advantage and disadvantage. It enables automatic concurrency, but it used to make error handling rather noisy: on all error paths, linear resources needed to be explicitly closed.

So, we've introduced auto-cleanup, which allows you to specify, in the type, how a normally linear type can be dropped.

For example, here's Bytes.Writer:

type Bytes.Writer<e> = iterative choice {
  .close* => Try<e, !>,
  .flush => Try<e, self>,
  .write(Bytes) => Try<e, self>,
}

The * on the .close branch/method tells Par that if a Bytes.Writer remains unused, just drop it by calling .close.

This significantly simplified error handling, the book chapter for which also got updated.

3 Big Examples

I've completely revamped the examples folder in the repository (links in a comment). It now contains small and big examples.

Now that we can do a lot of real stuff, we want to show it in the examples. So, there are 3 big examples. All of them are HTTP servers that serve you a web page, via which you can interact with the backend written in Par.

• Chat - A chat server over WebSocket. Open it on multiple tabs, or host it somewhere, and chat in a single room.
• Downloader - Request files to be downloaded to your local drive, and observe the download progress in real time. Multiple files can keep downloading concurrently, and can be cancelled.
• Tasks - Create todo items and check them as down, persisted in an SQLite database.

Check the screenshots at the links!

Runtime performance improvements

Lots of optimizations done in the runtime. By my completely unscientific testing, I/O intensive applications are about 3x faster, while computation-intensive ones are about 6x faster, compared to half a year ago.

Since we don't have rigorous benchmarks yet, take this with a grain of salt, but in my private testing, this should be around the performance of Python 3.12, when discounting Python's highly-performant functions and libraries written in C.

Not bad, not bad.

A lot more...

Since we're not having official versions yet, there's no changelog to see, but some picks: - New @core/Time module - 120+ new functions in the @core package - include("file.txt") - compile-time file-as-value inclusion - todo - typed holes - LSP improvements, such as .-completion - Many bugs fixed

I've been trying to get my compiler (Speedie) working on Mac and Linux.

(EDIT: Speedie is now compiling on debian linux, and running wonderfully! But has missing dependancies that limit some programs (not speedie itself) from being built with speedie. Such as SDL2 missing, or /usr/bin/say missing.)

Now... I had it working in the past, but it got broken by simple additions like a (C++) function that returns an ivec4, but linux's gcc (unlike clang for MacOS) does not allow a ivec4 to be returned like this:

return {1.0f, 1.0f, 1.0f, 1.0f};

It needs this:

return (ivec4){1.0f, 1.0f, 1.0f, 1.0f};

So... something as simple as this can break my builds. My compiler works on my Mac perfect, but can't even compile on Linux.

Even worse, is something like my current situation. My compiler is acting differnetly on Linux. And I don't know why.

So I've been uploading "bad builds" to github, not realising. So I need to get it reliable for Mac and Linux, or theres no point trying to have a popular language.

I don't want to be manually testing each time, via VirtualBox. I want something automated.

Secondly... how do i even debug my app on linux? haha. Maybe The RAD Debugger is good? I don't know.

All I know is that, even after getting it compiling, it is behaving differently, but I don't know why.

...

If anyone wants to help me with this debugging, let me know. I'm available on discord / telegram if you don't mind me bugging you with questions?

As I am working on my current project, as well as doing other programming work that is recursive in nature, I often wish that the type systems had a bit more power to them. Especially with regarding to recursion and extension.

For example allowing enum variants to be types and to be allowed to be referred to as just a type itself. Or if a type could refer to a subset of another type, or a subset of the fields, or a subset of itself. Or if I could extend a recursive type with an extra variant and that new type's recursive variants now recurse to the new type.

In pondering this, I came up with a little proposal which I thought was pretty interesting, and I wanted to share.

The first thing is that I guess a system like this would probably be structural, as that lends itself a lot nicer to dealing with the behavior of types and comparing them, etc. So if we had an enum

type Food =
    | Apple
    | Banana
    | Croissant ;

We could create a subset by creating another type with a subset of the variants:

type Fruit =
    | Apple
    | Banana ;

Okay, so that is a way to have one type to be a subset of the other. Though note that it isn't necessarily a subtype. For example, take

type Person =
    .name is Str
    .age  is Int
    .job  is
        | Police
        | Firefighter
        | Teacher 
        | Businessman ;

type Unemployed =
    .name is Str
    .age  is Int;

The record Unemployed is actually a supertype of Person. Rather, it is more of a subset of the "behavior."

We don't we allow a way to define this in terms of the original type?

type Unemployed = Person restrict
    .name, age ;

Ok, so we are able to refer to a subset of another type, but we could do that without the need for a restrict, so is there any reason for this special syntax? Well, we could allow the restriction of data as well:

type PublicWorker = Person restrict
    .job restrict not
      | Businessman ;

Okay, but what about adding nominal typing to this structural type system? If we allow a uniqueification process, then we can essentially create "type realms," where all of the restrictions and extensions (to be discussed later) of that nominal type exist in that "realm."

type MyFood = unique Food;
# Now MyFood is unique. It is essentially a nominal type. 
# A Food.Apple is not equivalent to a MyFood.Apple
# But with restriction we can still explore this type realm

type MyFruit = Food restrict not
    | Croissant ;
# MyFruit.Apple is equivalent to MyFood.Apple

Okay, but now what about types that refer to a subset of themselves? Well it just follows:

type Direction =
    | Left
    | Right
    | Diagonal is self restrict not 
        | Diagonal ;

But why should we use self here instead of just the type name? This is part of the proposal idea, which is that a type cannot refer itself recursively. Instead it refers to a builtin self symbol, which refers to itself.

But why? Because this allows us to extend the type while retaining the recursive functionality. For example, take

type LinkedList =
    .value is Int
    .next  is self ;

type DoublyLinkedList = LinkedList ext
    .prev is self ;

Now in DoublyLinkedList, self refers to DoublyLinkedList, allowing for this kind of internal extension of the type. If we wanted to preserve the "boundary" of LinkedList, where it only refers to itself in the new type, then we could do an external extension, which is really just storing it as an additional field.

Now one question is why this potentially weird syntax? Well, it essentially functions as a kind of type pattern match if that makes any sense. Both restrict and extend function as like a kind of type transform. So we could even start to do things like the following

type Building =
    | Hut
    | Office is
        .owner_co is Company
    | Skyscraper is
        .floors is Int
ext
    | * ext
        .occupancy is Int ;

We extend the base type which consists of these variants by extending (ext) every (*) variant (|) with a field (.) called occupancy which is an Int.

There's probably more you could do with this. Like for example I haven't even thought about interfaces. But anyways these were just some thoughts I had come up with while wishing I had some of these functionalities in the languages I'm working in. What do you think of this? I do wonder if there are any projects out there that are trying something like this, and if are there any desirable or unfortunate properties that a system like this brings?

I think effects and effect handlers are not as tricky as they are made out to be. Calling them algebraic effects only increases the mystery.
A stateful handler is definitely the bit I found most tricky to get my head around.
This is my guide trying to explain how to build stateful handlers in EYG. https://eyg.run/guides/advanced-effects
I needed this to finish writing a testing framework which I hope to finish soon.

No, not that type of Agile....

With cloud-based computation now the rage, I'd like to see a language construct where I could declare methods that were "cloud eligible". Imagine code with the following method in it

promotable func MethodX(in int X, int int Y, out Z) { code }

This says "I have a method MethodX with defined input and output parameters (we'll need to have a common marshalling standard), and, this method can be transmitted Erlang-style to a defined cloud endpoint. When you invoke MethodX, it can run locally or remotely. You don't care -- that's a configuration detail.

It seems to me Erlang is almost there, but I'd like it to be a more general interface. Think something on the JVM. Serverless done right?

Rust is a clear winner in the AI era. However, it doesn't feel functional enough to spark joy.

Swift is slightly better, but still, is there anything like Haskell, SML or OCaml using reference counting and lifecycle management instead of a GC?

Here's the Github link!

The README explains quite a bit of how the code works, so I won't really go into it very deeply here. But, the gist of it is that the language only uses 8-bit hex numbers for everything.

Here is a simple "Hello, World!" program!

21 05 01 00
64 05 01 00
6C 05 01 00
72 05 01 00
6F 05 01 00
57 05 01 00
20 05 01 00
2C 05 01 00
6F 05 01 00
6C 05 01 00
6C 05 01 00
65 05 01 00
48 05 01 00

Fun, right?

If you are interested enough to try it out, please let me know what you'd like to see come to it/if there are any bugs you encounter! This is my first programming language after all, so I don't expect it to be perfect!

Thank you to everyone who gave feedback on my article about memory safety.

I used the input to vastly improve the article (see "Achieving memory safety").

Please take a look and share your thoughts again and consider starring the Seed7 project on GitHub.

I created a fun, completely normal and sane side project.