Yeah, 'class' in Bon defines a typeclass. While I plan on adding x.norm() as syntactic sugar for norm(x), typeclasses in general are a bit more flexible. For example, while you can use it for polymorphic operator overloading [0], you can also overload a function by changing the types of multiple parameters [1] (as in multiple dispatch).
Thanks for checking it out. They are currently implemented similarly to OCaml, so yes they are linked lists.
This was purely for simplicity (they can be implemented in a couple of lines of code with algebraic data types). Simplicity of implementation is certainly not my priority, just a short term drive, so it will be revisited in the near future.
That's a fair comment. I will say however that the references to performance are more an attempt to keep it in mind from the beginning, rather than being an assertion at this point. I only began working on it shortly after my mom passed away last month (it's dedicated and named after her), so at this stage I'm mostly goal setting and rapidly prototyping.
I hope you can take time to give it another look when its further along. Thanks!
I wouldn't call it an extension, but I did use the tutorial to quickly prototype from. There are still some remnants left in the code, but I don't expect much if any to be left in the near future.
Hi Chris, thanks for checking it out. The first code push for Bon was today, so many things are of course rough around the edges.
Memory will be garbage collected, though I am aiming for zero-cost as much as possible. At the moment it just leaks memory like a sieve as I work out the semantics.
You can indeed import standard c library calls by using a cdef. You can find examples in the stdlib, e.g.:
I am happy you posted early when things are still fluid.
A fast scripting language that is not a PITA, and not tied to a proprietary ecosystem, could carve out a place.
But please ensure that something like destructors remain possible and uncrippled. There are so many more kinds of resources to manage than memory, and we are beginning to accumulate many kinds of memory, too. When you have a solution for general resource management, memory management itself becomes a trivium, or gets locally tunable.
I've seen both Rust's lifetimes/borrow-checker and Objective-C/Swift's automatic reference counting described as "zero cost" (since the bulk of the work is done at compile time).
Rust's borrow checker is zero-cost because it's not doing runtime analysis. But it's not a garbage collector, unless you're using Steve Klabnik's "static garbage collector" terminology [1]. Reference counting is definitely not zero cost. It reduces GC runtime latency for most workloads, but not to zero, and it does so at the cost of reduced bandwidth.
https://github.com/FBMachine/bon/blob/auto_mem/docs/ch02-01-...
Thanks for all of the feedback!