I definitely wasted some time overengineering this one. I was expecting part 2 to have more than two ranges per line and wrote a parser to handle that. I also made the parser do no dynamic allocation, because my I/O library supports that now.
advent/day4_2.adb at 3886b077597131c55f15bd23bf3f5dc14faeb4c8 · JeremyGrosser/advent · GitHub
Gained lots of time skipping much of the explanation… and also lost lots of time doing so, because I thought the format was:
.234..... 2-4
.....678. 6-8
instead of:
2-4,6-8
Anyway, the “final” code is here: hac/aoc_2022_04.adb at 74dd26dbb513dec406561fa5e8cc439f6abe802c · zertovitch/hac · GitHub
It’s been said that Advent of Code is really a reading comprehension test, not a programming test 
A way of avoiding the format issue is to download input.txt (and have a glimpse on it) early in the process…
Really? You were still done before I finished part 1 – I checked the leaderboard out of curiosity – and I think I finished both parts quicker than I finished part 1 on either of the previous 3 days!
This year seems a bit unusual: the first day has been the hardest to me, and they’ve gotten easier since – so much so that on Days 3 and 4 I implemented alternate solutions. I’m waiting for the other shoe to drop.
Yeah, I learned that during my first AoC back in 2020… 
I think I also did, but forgot again.
Now I have set up a check list.
Can be useful for those who are in a time zone where the puzzle pops up early in the morning…
If step 1 of a checklist must say “coffee” then you might be rising too early. 
I kind of wanted to create dynamically ranged arrays to check against, but actually have errands today so if statement it is!
This is what I came up with adventofcode/day4.adb at bee3c2dc4fd0bf7e6c1d8916f529dc30cf5beee1 · AJ-Ianozi/adventofcode · GitHub
Curious …
Anybody tried to read the file as a record of data ?
using Ada.Text_IO.Text_Streams and Ada.Streams to read each record (line) of data, implementing Data_Record'Read (Data_Stream, Data);
See my puzzle_04
Seems you all used plain Text_IO. 
Why not ? Pro/Cons ?
(Jeremy did still used a specific generic Stream library)
Anybody ? 
I used streams for all of my solutions last year and started to this year. However, yesterday I rewrote my I/O library to use mmap for the input file. This is much faster, but means my Read_Until helper isn’t compatible with the Root_Stream_Type interface anymore.
But you ignore Stream and read from Ada.Integer_Text_IO.Get also, no?
I used subtypes to check for overlaps in the second part:
function Overlap (Left, Right : Sect_Range) return Boolean is
subtype Left_Range is Natural range Left.Low .. Left.High;
subtype Right_Range is Natural range Right.Low .. Right.High;
begin
if Left.Low in Right_Range or else Left.High in Right_Range then
return True;
elsif Right.Low in Left_Range or else Right.High in Left_Range then
return True;
else
return False;
end if;
end Overlap;
As an Ada dilettante***, I know Text_IO. I am not familiar with Text_Streams. I actually remembering thinking last night that it would be nice to have a library that parses a line of input according to a known structure. How convenient is it to use and implement Text_Streams and Data_Record'Read?
***Calling me an amateur or hobbyist is an insult to amateurs and hobbyists.
I thought I could still do those elementary types with read (Stream, ...), but I didn’t succeed.
Isn’t it (IMHO) the conventional way of reading elementary types? (with get) so as to cope with variable integer length?
I’ll retry …
Well this game’s data are in plain text files. So why not using Text_IO?
I like to design software as the domain specification is described. (say “O.O.”)
With Ada, one may easily implement this specification directly in code. unlike C.
IMHO, you get super readability 
Using Text_IO.Streams gives me the opportunity to get an Ada data record (filled-up) per line, just by being (almost) declarative in the code.