Inspired by conversation last night at the virtual meetup, I wrote a blog post to introduce the toy language I’ve been working on.

"That’s some baba yaga shit" (affectionate)

didn’t mention in the post that the language is called baba yaga just so that I can have

.baba

or

.yaga

files

This is lovely! Did you consider some sort of separator like

|

between guards/clauses? I've been reading Dijkstra's Discipline, and love the symmetry between his

if ... | ... | ... fi

and

do ... | ... | ... od

constructs. But your one liner conditionals are much harder to read than his. Particularly when (when!) you get to more than 2 cases on a line. (With 2 cases the

_

kinda saves your bacon.) Then again, Dijkstra is designing for mutation. Maybe you won't need one liners with more than 2 branches.. Do you support curried functions with return types? Some potential for ambiguity there..

A copy pasta from baba yaga’s docs (which you of course haven’t seen because they’re just on my computer)

### Curried Typed Functions

Curried functions take one parameter at a time and return functions for partial application:

```baba
// Curried function with typed first parameter and function return type
mul : (x: Float) -> (Float -> Float) -> y -> x * y;
double : mul 2.0;          // Partial application: double : (Float -> Float)
result : double 3.5;       // 7.0

// Three-parameter curried function
add3 : (x: Int) -> (Int -> (Int -> Int)) -> y -> z -> x + y + z;
add5 : add3 5;             // add5 : (Int -> (Int -> Int))
add5and3 : add5 3;         // add5and3 : (Int -> Int)
result : add5and3 2;       // 10

### Function Type Syntax Function types use the syntax `(ParamType -> ReturnType)`:

baba
// Simple function type
transform : (x: Int) -> (Int -> Int) -> y -> x + y;

// Function that returns another function
makeAdder : (x: Int) -> (Int -> Int) -> y -> x + y;
add5 : makeAdder 5;           // add5 : (Int -> Int)
result : add5 3;              // 8

Heads up! Complex nested parameter types like (f: (Int -> Int)) aren't implemented. The first parameter must use simple types like Int, Float, String, or Bool.```

That is lovely! I found it funny that "no if/else or switch" was immediately followed by an example using the keyword

if

. And it got me thinking: Have you considered the keyword

where

? Seems to flow better as a sentence: "`when` entity

is

out_of_range

if

distance self out_of_range > 1

then

..." as opposed to "`when` entity

is

out_of_range

where

distance self out_of_range > 1

then

..." — the first one grammatically to me seems to invite one-to-many branches "when entity is out_of_range [then] if ... otherwise ..." rather than one-to-one "when entity is out_of_range (where [defining out_of_range]) then ...". I guess the latter could also invite syntax flexibility, having the where clauses next to their targets or gathering them at the end of the "when" statement, it was a long time since I did anything in Haskell but that seems like an idea I must have gotten from there right? I wouldn't have mentioned it, but you referred to toki pona so discussing choice of words didn't seem too far off topic :^) Also, when skimming the rest I see you are using

where

in the array programming interface (which I guess is in userland rather than a keyword but alas), so thematically you already have a

where

playing this role, which should make it enticing to simplify both cases to the same word, right...? 💞 /Ivan