Cheers to you, and I hope you're learning and having fun working on your project!

Curious about plans for this. When Haskell use exploded I followed a lot of the blogs talking about it someday being faster than C because purity made compiler reasoning easier and stream fusion and other things were going to change the world, but as time went on idiomatic Haskell never came even close to C. Now having a lot of performance experience I think a major factor is that functional languages insist on using lists for everything, which map poorly to hardware. Looking at your screenshots, it looks like it still employs the list paradigm.

Some specific questions about the language design: - Does your flavor of algebraic effects allow distinct effects of the same type (e.g. two separate int-valued `State`s)? I haven't seen anyone talk about this, but it seems like a potential problem with effects.

- Do you have plans for making pattern matching extensible? I've thought a lot about how this could be possible with optics (the FP construction), but haven't found a nice solution yet.

One question: does numerical destructing require that one of the terms be a constant? What happens if I write y ~ a + b ?

Also:

> In Tao, arg:f is shorthand for f(arg)

Did you mean arg -> f ?

As mentioned in the README, I don't see Tao as a production-quality language (at least, for the foreseeable future). I'll leave that to the experts. Instead, I'm more interested in exploring the limits of new language design ideas (effect systems in particular). There are already a few interesting things Tao does that I've not seen elsewhere.

The language does support limited sugar for tuples without parentheses in some specific cases, such as `match` and `let`:

    let x, y = 5, 4 in
    ...

    match x, y in
        | 4, 7 => None
        \ _, y => Just y

You're funny

Totality shouldn't have any special impact on memory usage as far as I know. It just restricts the kind of recursive functions and data types you can write.

For example, the typeclass `Eq` describes how values of a type might be compared for equality.

    class Eq =
        => eq : Self -> Self -> Bool

    for A, B member (A, B) of Eq where
        A < Eq,
        B < Eq,
    =
        => eq = fn (a0, b0), (b0, b1) => a0 == a1 && b0 == b1

Typeclasses become useful because they allow you to constrain generic type parameters. For example, we can now write a function that determines whether a list contains a matching value:

    fn contains A : A -> [A] -> Bool where
        A < Eq,
    =
        | _, [] => False
        \ k, [x .. xs] => x == k || xs->contains(k)

So, the typeclass itself is like an interface, but rather than having classes that implement that interface directly, you have typeclass instances which are like an adapter between a value (struct) and the interface - or like a virtual function table. You know how a class instance is essentially a struct + a (pointer to a) virtual function table? Imagine making those two pieces more distinct in code - the typeclass instance is the stanadlone virtual function table.

So your object state is more exposed - you can't really have private fields in this paradigm since your state is just a struct value. But it's clearer what's what, and it's much easier to adapt types to interfaces even when the authors didn't know about each other, since the typeclass instance can be defined separately from both the typeclass and the value type (although there are possible inference problems with this). So lots of secondary cross-cutting functionality problems where OO languages tend to end up with an ad-hoc type registry (e.g. serialization or database mapping - just look at what projects like jackson-datatype-joda or joda-time-hibernate have to do to get themselves registered) are easier to solve in this model.

In Tao, natural numbers don't support subtraction but you can decrement them by pattern-matching as in this example, allowing the compiler to 'check your workings' and statically prove that your program can never result in underflows.

In a similar vein, you can't index directly into a list (because indexing is a fallible operation). Instead, you must pattern-match on the list and explicitly handle the empty case (you can also write a utility function to do this for you like so)

    fn nth : Nat -> [A] -> Maybe A =
        | _, [] => None
        | 0, [x ..] => Just x
        \ n + 1, [.. tail] => tail->nth(n)

    [1, 2, 3]->nth(1) # Evaluates to `Some 2`

data Nat = Zero | Succ Nat

You could pattern match on this Nat, fetching the inner Nat, allowing the type system to prove that all cases are handled exhaustively. Arithmetic patterns just extend this notion to the built-in Nat type.

Full dependent typing is something I'd like to experiment with in time, but I'm not there yet.

I don't know whether I'll keep this syntax though. I'm increasingly wondering whether it's better to just bite the bullet and go all in with indentation sensitivity.

That said, the existing \ syntax can be quite nice to read: https://github.com/zesterer/tao/blob/master/lib/parse.tao#L5...

It echoes how I feel when I write programs in languages with strong static type systems: that of the compiler almost fatalistically leading me towards a solution that naturally fits the problem space. A metaphor I like to use is that of an artist knocking away pieces of marble to reveal the statue that was always there beneath.

And, yes, it's great fun to work on! Everybody should give writing a compiler and designing a language a try!

There is no module system yet (only a temporary C-like #include system): that's on my list of things to work on!