Daily Thought - 2024-09-08
< back to listRight 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.