Compromises on basic things continue. I want to create an array whose size is not known at compile time. I believe I can declare this with

Mem : Array (Natural range <>) of Integer range -1..Integer'Last;

But this errors there's no initialization. You can initialize an array to a fixed value with (Others => -1), but then it doesn't know the size. I wind up making a sub-procedure *just* because that is the only syntax I can find for initializing an array to a size. https://github.com/mcclure/aoc2024/blob/b46079ddcb5c45d52af5882e940a593050c7beb9/09-01-disk/src/puzzle.adb#L14

Small observations:

- Inner procedures and functions of a larger procedure and function can access the outer procedure's local variables. That's nice. I suspect this is hiding some sort of horrible restriction on recursion, but it's nice.

- The error messages, at least in "gnat" the open source Ada compiler, are NOT good. I think this is downstream from the language having lots of minor similar-but-distinct concepts instead of single powerful concepts. There's a lot of jargon and lots of edges

Something I don't know how you'll feel about: You know how in every programming language except Lua you index arrays from 0, and in Lua you index arrays from 1? In Ada, if I'm understanding this correctly, you choose whether your code indexes arrays from 0 or 1. *On an array by array basis*. You could mix 0- and 1-indexed arrays in the same code. You could have an array which contains 10 elements at indexes 10 through 19 inclusive, if you wanted. An array is a map with integer keys in a range

…

Maybe the problem with Ada was that the things it was trying to do were too advanced for the tools that were available to the designers at the time.

I'm having an awful problem with a very straightforward bit of code because I want to scan over some code iterating a variable erratically. But I don't have any good value to give *before iteration begins*— because Ada integer types are range-limited, I can't use "0". This would be no problem at all I had Option<>. But I don't have Option<>.

Guh. Part 1 done. It was ok once I actually had my data loaded into memory, but every moment up until there was pulling teeth, and honestly the ergonomics weren't *great* after that. The final insult was it taking a startling amount of time trying to figure out how to convert an Integer to a Long_Integer when it turned out my result was over 32 bits. It's Long_Integer(), but StackOverflow was a bunch of "how do I cast in Ada?" "*bragging* In Ada, you don't NEED to cast!"

https://github.com/mcclure/aoc2024/blob/9048d0cd5d29fc8f987c4f7369360279199fc2b0/09-01-disk/src/puzzle.adb

I pushed through Part 2 just to get it over with. I could have done a very clean, efficient implementation in any other language, but Ada makes creating new arrays enough of a pain I just wound up like… doing it the dumb nested loops way. Whatever. I realized in literally the final line of code I wrote that part of why I was struggling with loops was I didn't know "exit" existed.

It works. It's even relatively efficient. I don't feel proud of this code.

https://github.com/mcclure/aoc2024/blob/3adbb87169b82453caafd75308837c203247edc4/09-02-disk/src/puzzle.adb#L80

A problem I anticipated with this "Babel of Code" project and sure am hitting now: The AOC puzzles are a great way to learn a language, but they'll always focus on *only part* of a language. When I hit smalltalk, I'll have little opportunity to use objects. Multiprocessing, or verification capabilities like Spark, can be applied in *some* puzzles, but it's hard to know *which* puzzles until it's half complete. Like, what formal properties does THIS puzzle have to verify?

https://adventofcode.com/2024/day/9

@mcc The thread made me mildly curious, so I took a stab at it.

Caveat, while I am on WG 9 and an observer on the Ada Rapporteur Group, I am there only as a liaison from Unicode; I have only written Ada recreationally, and not much of it at that. My father used to chair the ARG and work on Ada compilers; most of what I know is from him.

https://github.com/eggrobin/ada-playground/blob/master/src/ada_playground.2.ada

@mcc One thing where Ada shines that is relevant here is the ease with which you can define lots of integer types and subtypes and use them just like the predefined ones.

In this case, there are clearly two kinds of integers, and mixing those up is a bug—except in the weird checksum, where you needed a conversion anyway—: the block indices (and file sizes in blocks), and the file indices.

@mcc In my code at least, I rely on the file sizes being nonzero; this gets checked when reading the input just by introducing this subtype here, never mentioned again: https://github.com/eggrobin/ada-playground/blob/39ea262b9e581f88fd7aa5b9baf528ef1f6e1ace/src/ada_playground.2.ada#L11-L14.

On the runtime-sized array thing, I am recursing and returning a slice here: https://github.com/eggrobin/ada-playground/blob/39ea262b9e581f88fd7aa5b9baf528ef1f6e1ace/src/ada_playground.2.ada#L40-L63.

I think gnat has a “secondary stack” that lives on the heap, but some implementations for heap-averse applications returned those on the stack (with the caller not popping while the result is needed).