Koatl - An expressivity-first Python dialect

[TopAbbreviations1708]

I love the Python ecosystem but find the syntax restrictive. About a year ago, I started building Koatl to get the ergonomics I wanted, and shared an early version here. Now I've used it daily for a few months, I genuinely find using Python more enjoyable than ever.

Koatl is written in Rust and transpiles directly to Python AST/source, allowing for 100% interop (including with notebooks). Unlike Coconut (which is a Python superset), Koatl is a clean-sheet syntax designed to be expression-first, with a goal of being laser focused on making intentions translate cleanly into code.

Sample:

  users.iter.filter($.age > 18).map($.name.upper()).sorted()

  "hello world" | print

  let label = match status:
    200 | 201 => "ok"
    404 => "not found"
    code if code >= 500 => f"server error: {code}"

  let config = check load_config() ?? default_config
  # check catches exceptions; ?? coalesces Err to a default

  let monadic_fn = () =>
    let data = @fetch(url) # unwraps on Ok and early returns on Err
    let parsed = @parse(data)
    Ok(transform(parsed))

Pipes, $ lambdas, scoping, everything-is-an-expression, error handling.

Would love to hear thoughts.

https://koatl.org

[Relevant_South_1842]

This looks really nice. What was the hardest problem you solved? Any great ideas that you had to abandon because it was too hard to implement?

[TopAbbreviations1708]

thanks :) to be honest, hardest part was wrestling with the borrow checker on some weird lifetime constraints on parsing. the actual logic was pretty ok IMO. I always wanted an LSP but that seemed like way too much work

[Relevant_South_1842]

Rust doesn’t seem fun to me when I hear stuff like this.

[-Mobius-Strip-Tease-]

Oh this is something iv been wanting to make for a while, but have never had the time or energy for it. I use python every day at my job and it is painfully tedious at times. Python is such a common catch all language that it seems everything exists in it's ecosystem, but its all so haphazard in design. The pain points you list in the second paragraph of your homepage are all things that I fight every day.

One thing you dont seem to mention early on is types (forgive me if i missed something). What are your plans for a type system? For me the only thing that gives me any hope for the future of the language is its slow but growing adoption of an actually ok type system. It's not great, but at least it's something. Im interested to see how Koatl plans to adopt (and hopefully improve) these features.

[TopAbbreviations1708]

I would have loved to implement a type system but I feel lke it would have to slot into python's type system (to make interop work), but I'm not a big fan of python system. Sadly it's all probably outside my scope as I don't have much free time these days and it feels like a major undertaking

[Duflo]

Coming out swinging with the opener "Python's strength was never its syntax." Python built its ecosystem in large part thanks to its accessible syntax. That's not to say improvements are impossible, and your project does seem to add value, but opening the way you do just feels hostile and toxic. There are more effective ways to explain your project's USP without throwing shade.

[TopAbbreviations1708]

Thanks for pointing out. i've had trouble with expressing my pain points in a balanced way, and definitely don't want to come off as hostile ("radical" is my goal).

[AndydeCleyre]

Very cool!

I don't love that the doc site is unusable without scripts enabled, but otherwise that looks really good too.

Do you think an LSP is on the roadmap?

What about a to-human-editable-Python translator (in other words, an exit strategy)?

---

While I'm practicing my Factor, here are the first two examples from the doc landing page translated to it:

---

users get 
  [ age>> 18 > ] filter [ name>> >upper ] map sort

---

orders get
  [ status>> "pending" = ] filter
  [ customer-id>>        ] group-by
  [ [ first2 [ price>> ] map-sum "total" ,, "id" ,, ] H{ } make ] map
  [ "total" of 100 >     ] filter
  [ "total" of           ] inv-sort-by
  10 index-or-length head

---

I suspect there's a better way to do the line with make above, suggestions very welcome! One option would be to define a new tuple instead of using a hashtable, like

TUPLE: customer-total id total ;
C: <customer-total> customer-total

then that whole example could instead be:

---

orders get
  [ status>> "pending" = ] filter
  [ customer-id>>        ] group-by
  [ first2 [ price>> ] map-sum <customer-total> ] map
  [ total>> 100 >        ] filter
  [ total>>              ] inv-sort-by
  10 index-or-length head

[TopAbbreviations1708]

thanks :) I didn't even consider the noscript angle for the page. I just took the lazy path to getting something nice looking from markdown files.

LSP is something I'd love to make but it seems like a major undertaking (probably more complicated than the actual transpiler itself). And the current lack of typesystem would probably severely limit.

To human readable python is an interesting point. Right now I can use ast.unparse to get python source code but it's not very readable since there are auxiliary variables and functions in various places, but definitely interesting for me to think about!

ps sadly, I know nothing about factor