I basically forked the Go scanner/parser, and changed the syntax to have functions return a single value. This enable proper Result/Option type to be used as well as propagating errors with an operator.
I also wanted to have short "type inferred" anonymous functions to be able to use functions like Map/Reduce/Filter, without having to use 100 characters to specify the types.
https://docs.vlang.io/type-declarations.html#optionresult-ty... in particular
eg: the @LINE "Compile time pseudo variable"
https://github.com/alaingilbert/agl/blob/8b656a385207e57fd0f...
https://docs.vlang.io/conditional-compilation.html#compile-t...
This seems to nicely smooth out a lot of the pain points I had back when I regularly wrote Go but also switched to other more expression-based languages occasionally. Being able to get all these conveniences while still being able to call into existing Go code seems amazing!
Also, I appreciate the pun, but did you have to use AI for the logo? Haha
For example, I'd like to have the pointers being automatically wrapped in a Option[T], but then if you have something like a linked list, with a struct containing pointers to other nodes, it gets complicated.
Propagation of optional values is an unconventional design decision. Why have you chose it over short circuiting as in C#, JS, Swift?
What’s your opinion on error wrappers and stack trace providers that are often used in go projects complicating simple error propagation? Have you consciously avoided adding similar functionality or just haven’t thought about it yet?
Thanks for the feedback, it's good to know when something does not make sense ^^
Are nil pointers still possible/allowed in AGL? After a lack of enums, this is my biggest pet peeve.
mayli•5h ago
adammarples•3h ago