Caterpillar

Daily Thought - 2024-09-08

< back to list

Right now, Caterpillar just has a single global context. But in the future, all functions will be defined in modules. I haven't fully worked out the design yet, but what if a module is just a function that is executed at compile-time, returning the items it wants to export? Then any argument to that module function would be available at compile-time.

If that were the case, here's how that Zig example I showed yesterday could look like:

mod compare: { |T: type|
    fn max: { |a: T, b: T|
        if a b > then { a } else { b } end
    }
}

Please ignore the specifics of the syntax. Caterpillar doesn't have modules, nor static types right now, so this is just a vague sketch of what that could look like. No idea how exactly this would end up, if it makes its way into the language.

What's important are the semantics: There's a module, compare, which is just a function, executed at compile-time, that receives a type parameter. Within it, there's a regular function, max, which is executed at runtime. Since all functions in Caterpillar are closures, it can access its environment, which includes the type parameter of the module.

<< previous thoughtnext thought >>