 So if you've been following my videos on Ida's type system in the last one, I lied about what the next video would be. We're actually going to be doing arrays because I realized that that's something I ever actually covered and arrays in Ida are worthy of some pointing out. So we'll begin with one of the most basic things, how to actually define an array. One thing that's a little bit weird is because of Ida's type system being so incredibly strong, so incredibly nominative, oriented, or name oriented. We actually have to actually define the type of array rather than just saying, hey, it's just an array of integer like you can in most C-based languages especially, but if you're coming from something like Python, it's largely, even though they're a bit dynamic, it largely works the same, the same way. So we'll begin by that and we'll just do a simple integer array. Now you can name these whatever. The convention I normally see is the underscore array ending. I have sometimes just seen it as the plural of the type, so in this case, it would be integers. I generally don't like that for type names. For variable names, I find it fine, but for type names, I find it a little bit awkward at times, just given how the pluralities of things differ. But then much like other type naming or type definitions go, it's is and then the type and in this case it's an array. Now we'll need to define the index, but first I'll go and say that it's an array of and then in this case, should obviously be integer. Don't confuse people by putting something else in there. Now as for the index, there's a few ways to go about these, but before that, I want to cover one of the ways that is rather different from other languages. See in the C C plus plus style of languages, an array is typically zero index and goes up to whatever the length is minus one. So an array of eight elements would start at zero and go all the way up to seven. Still holds eight because you're starting at zero, not starting at one. In Ida, it's a little tricky because of two things. First, you don't actually have to index by an integer. You can rather index by any discrete type. So that would be integers, modulars, and as far as indexing purposes go, those would work the same way. But also enumerations. You can index through enumerations, which can be really handy if the different places in array have some type of specific meaning rather than just some numerical position. This can be really useful for things like hardware addressing. Where you have, say, a bunch of pins with specific names have an array that represents the entire set of pins, and you can actually use an enumeration to reference the specific pins rather than have to look up one number each thing is and then pass the thing, the full set of the array into the pins. Not all interfacing specifications work that way though. Sometimes you just have a specific pin, but I'm not getting into hardware standards. We'll begin with the simplest one of just indexing by a number. So we'll do integer, and we have to specify a range for this, because again, Ida is really strict about these things. At first, this might seem a little alarming, because what if you want a very generic thing? Integer array should be basically whatever length. Okay, I'll cover that in just a moment. I want to get the fixed size arrays first. So let's do integer range, and then 1 through 8. It does look like I need to fix that with the syntax highlighting. From there, we can define the array. So I terrible with example stuff. So I'll just do ia for integer array, and let's say that integer array, and we can go ahead and start defining this. Now, much like with the record aggregates, array aggregates work very similar in that if you don't specify exactly what value is where, it's assumed to be positional. So for arrays especially, this actually makes a lot of sense, and you typically don't need to define the exact position of values going in. You can just go with the standard, just write it out like normal. So we'll match these up exactly, 1, 2, 3, 4, 5, 6, 7, and 8. And just to make sure I'm not being an idiot with anything, because that happens. Let's try to build this. So from here, let's actually do something with this. This will be returning in an integer. So let's get the image of it. Oh Jesus, I did this again. I swear I do this every single one of the videos. I want to background. Oh cool, it's not responding when it loads. Be good? Be good? There we go. Okay. So we get the one which you'd expect, because we said that the array is indexed from 0 to, or from 1 to 8 rather. So the first one would obviously, if you were to change this just to show what I'm talking about, change this to from 0 to 7 and more like C style indexing. We can go ahead and build this again. And oh my God. And this should make sense, because even though we're saying it's the first index, we are also saying that the indexing begins at 0. So the, I guess I shouldn't say for 1th index, I guess. That seems weird though. I like that we can define arrays that start from 1, because at least in English, the entire convention is around beginning from 1. So it's bizarre to start from 0. But yeah, result is what would be expected. Typically speaking, I've really only seen starting from 0 or 0 indexing. When interfacing directly with C code, or when interfacing directly with hardware, where the convention with computers is always to start from 0, just so that you don't waste one of the possible values or pins or whatever. So for that purposes, I do see 0 indexing a lot when interfacing with hardware. Like I had said though, quite often you can have enumeration set up for that instead, which makes it, I find considerably more pleasant to work with than 0 indexing. Let's show off the enumeration thing though. And we'll just do four of these, but let's do, I think this will work. I don't remember if I need the range clause for enumeration. I don't think so. Oh right, because of this. So let's change that over to first. Build that and okay, run that and this should again make sense. The first part of the positions index and the first part of the array, everything lines up. Going back though, because you'll notice I didn't actually have to specify a range or anything for this, if we wanted to do a similar idea for integers, where it just sort of covers all of the integer, and it is going to complain about this. What it's complaining about is that when we say that the array is indexed by integer, we're saying, well really for any type, but we're saying that the array contains an element for every single index of the range of integer, which is huge. We're talking everywhere from, what is it, negative 2 to the 31st power all the way up to 2 to the 31st power minus 1, at least on the x86 line of processors. It's a ridiculously huge range and nobody in their right mind would write out values for all of that. And typically speaking, you don't want that whole range anyways. You can pass subtypes to this and one really easy way to show that, although it'll still complain, is if we use the positive subtype, where as you can see that's still valid. It's still complaining though, because positive would be everything from 1 all the way up to 2 to the 31st power minus 1. We can do this however. It's still complaining this time, but it rather because it only wants up to 10. Now it doesn't complain at all. This still isn't very useful for what most of arrays, at least that I've seen, get used for. I just wanted to show that off, that you can have the range defined elsewhere, that you can define a subrange either inside the type definition or as another subtype, which you do depends on whether or not you need to reuse that range for some reason. If you do want to reuse a range, use the subtype. Where we get into the much more practical array definition is with integer range, but an unspecified range. Now you should recognize this if you watch the last type system video on records, where this sort of, this, I think they call it a box. Honestly, I don't even remember all that well what they call it, because it's just sort of a generic placeholder. Like, I don't really know or care what this is right now. And nope. Why did you complain? Okay, I think I remember what's going on. I had to go into one of my old repositories. Something, some, just reference some code that I've written up before. I believe if we change this to positive, it should, right, let's get rid of this. Save that. Okay, we're good. And just to confirm, if we change this back to integer, save that. Okay, so what's going on with that? And I completely forgotten about this just because I'm so used to sort of always doing this. Ida's convention sort of, it's a very loose convention, but Ida's convention is to start indexing from one. So when we say that it's an integer range of whatever, it gets confused, basically. Because if it starts at one, well the range of integer is it starts before one. So get in the habit of using positive and then the sub range, or at least in this case, isn't the sub range or saying whatever is fine. What it'll do is for something like this, where we're passing an aggregate, it will set up the range from one up to whatever is required to hold this. So in this case, it will be 10 automatically. If we don't have an aggregate to pass to it, what we can do to set this up is just say that that is 10. It's going to complain a little bit or not. Let's do all right, one through 10. And there we go. And it complains that we're trying to read from something that hasn't been assigned yet. So we can go about it this way, and there you go. We run this, we get the expected results. Another thing to keep in mind, because this applies to a lot of value stuff aside from arrays, but I do want to make a point of this here because it's very relevant. And again, with the C style languages, a value is more of a reference, or the name of the variable, rather, is a reference to a value. And when you assign in those languages, you're changing what the variable refers to. Whereas in IDA, the variable does not refer to something, but rather it is that value. That's why when I talk about IDA specifically, I tend to use the two interchangeably, because they are. What we're saying here is that IA is this thing, not that it refers to that, and that value is somewhere tucked away in the computer, but that it is that thing. So if we reassign this, we should expect to get to any do. But this thing doesn't disappear. IA just, this literally overwrites what IA was before. This matters a lot, not so much in what I'm doing here, where the two different styles will behave the same, but that if I try to do something like this, it will fail. Because as I had said, it doesn't just start referring to something else, it tries to be that something else. And the length of this array is only five, but the IA is said to be an integer array of one through 10. So there's five values missing here that the compiler is rightfully going to complain about. This behavior is unexpected, very unexpected, coming from a lot of other popular languages. Similarly to the record aggregates, we can do an others clause where we specify something. Now it's not going to complain anymore, because it knows what to fill in the other values with, it knows the length of the array, and so therefore it knows how many values it needs to fill in. And just to show this off, since this is a good situation where I can do it, we can do this. So you'll notice that unlike with this array, in this one, the very first value is actually going to be zero, because we never specified the first, so it's going to use the others clause. And starting from the second, we have one, two, three, four, five. Starting from the seventh through the tenth, we have zeros again. So if we build this and run it, we get zero, like you would expect. I think there's one more thing I can show off. I am not sure if this applies only to strings, or if this is something that's actually defined for arrays in general. I will find out. I've never actually tried to do this with just like standard arrays. I've always only ever done this with strings, but strings are, strings are not special in Ida, much like characters are not special in Ida. Strings are quite literally just an array of characters. So this, unless it's something that's specially defined for them only, this should work. We'll find out. Let's do, I don't know, just do Ida. We will need to define these though, and I can remove the index. That's fine. So we do one, two, three, four, and five. Now we do IC is an integer array. And we're going to try concatenating these. I'm going to try typing right though. That kind of needs to be done first. Oh, I see. It does work. So this is possible only because the range is not predefined. So for IA, the range is calculated to be one through three. For IB, it's calculated to be one through two. And for IC, because it knows the range of IA and knows the range of IB, it can add them up together, know that the range needs to be one through five, and then just pack all the values in appropriately. And we get the correct result. If we switch these around, you would expect the array to be four, five, one, two, three. And if we run this, you do get the expected result again. So like I had said, arrays are mostly pretty standard in AIDA, but there are a few quirks due to how assignment works in AIDA, as well as AIDA's very flexible approach to array indexing, but also very aggressive approach to strong typing that warrant some pointing out of these differences. I hope you found this video helpful. If you have, consider giving a thumbs up and also consider subscribing and the notification bell because, yeah, YouTube. Have a, oh, if I take myself in the eye, have a better one than I'm having.