I believe I saw someone demonstrate that almost nothing in a Lisp implementation was written as a "built-in" language feature that required the underlying interpreter to provide the functionality.
The parser is very simple thanks to the s-expressions, and the only builtin special forms really needed are quote, cond and lambda, that’s pretty much it. The only data structure is a list, so functions are just lists, function calls are lists etc.
Are there two types of assignment?
p1[0] = 0
...
n := 0
car, cdr := car, cdr
>
> p1[0] = 0
> ...
> n := 0
>What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python >and C, respectively), but why (appear to) assign a pair to itself? This probably means something else, but it reads odd.
= is assignment and := is assignment and declaration.
x := 1 // create a new variable x with the value 1
x = 2 // assign 2 to x
y = 3 // error: y does not exist
x : u8 = 1 // a one byte unsigned integer with the value 1
> car, cdr := car, cdr
Odin has multiple assignment like Python, so this is a swap without temporary. edit: No, it isn't! Didn't read carefully. Swap would be
car, cdr = cdr, car
> If Odin is so similar to C, what are the "dark corners" where it outshines it?
Off the top of my head:
- No undefined behaviour
- Builtin string type, dynamic array type, slices
- Builtin map type
- Excellent tooling for 3D math: swizzling, matrix math, array programming
- Bounds checking
- Tooling for memory management: leak detection, temp allocator, arena allocators
- Builtin unit test framework
- Tagged unions with exhaustiveness checked switch statement
- for ... in loop syntax
Also I've moved it from Github to my own Forgejo instance: https://git.liten.app/krig/LISP
My impression of Odin is that it's a better C while still very much retaining the same flavor as C. It adds very little (no classes, no runtime) so porting from C is very straightforward, and it fixes a lot of the dark corners of C. It also seems to be pretty much finished as far as the language goes, so no big incompatible changes coming as far as I can tell.
I would say though that while the memory management story is vastly better than C^, it's still manual as fuck, so be prepared for that.
^: There's builtin test support, bounds checking and an optional leak detection allocator, plus as far as I know no UB.
https://git.liten.app/krig/LISP/src/branch/main/komplodin.od...
Andy Wingo has a good summary of how a very similar implementation works:
https://www.wingolog.org/archives/2022/12/10/a-simple-semi-s...
This mostly just ends up meaning that Odin's creator Ginger Bill will engage in pointless semantic arguments in which he defines away your problem.
There are places where C could reasonably have chosen to define what happens, or to make it Unspecified rather than Undefined, and so that's what Odin chooses, which is a meaningful benefit. However there are plenty of situations left in which what you've written would be UB in C and absolutely anything might happen, while in Odin absolutely anything might happen but Bill insists it isn't UB.
But I haven’t looked very closely at it myself, hence the afaik qualifier.
The function/struct definition in C could be placed in a header.