Not an issue/ Pastebin

[NonstickAtom785]

New Matrix List Ideas
https://pastebin.com/KnZzUFfi

[Zeda]

I don't understand the purpose of the "name" element, sorry.

A consideration that I'll have to take into account, too, is how to allocate memory for the list or matrix. It is a lot easier to code if the user tells where to write first, as opposed to looking for the →.

I think the name field isn't useful information to include; it has nothing to do with the data structure. That said, it might be useful for Grammer to have it's own variable interface. I'm thinking adding a modifier to Get( and Send(. Then you can give your data names and it doesn't have the restrictions of the OS :)

It would take a lot of work though, and I don't think I'm up for it. Just ideas.

[NonstickAtom785]

Well the original idea for the "NAME" element is for you to input where the data will be stored. So like an appvar or a temp program.

[Zeda]

Okay, I see. I still don't know that creating or locating the OS var should be this routine's responsibility since there will be many cases where you'll just want to write to a place like AppBackUpScreen (0x9872) or saveSScreen (0x86EC).

[NonstickAtom785]

Oh true. So instead of doing so much work why don't we just stick with some basics. like when writing bytes to code you could use a modifier in the place of A(?row,col or A[?row,col,elem using the question mark as the modifier or even a plot +. + could be matrix and plot . can be list. Just an idea. But I think it goes on with the idea of adding modifiers to the Get( and Send( commands. But if we really wanted to we could just make an in dept tutorial on creating and modifying arrays in Grammer. We don't need to make a function to do it for us because it might make it to complicated. I just thought it would be pretty cool to have something like BASIC but quicker in Grammer. I'll keep thinking about it though. I might come up with an easy system. I'm on day 11 in the assembly tutorials. Just learned about shadow registers.

[Zeda]

As an update, I've started up an experimental module to test ideas. Once it is working the way we want, I can add it into Grammer.

So the idea that I'm going with is akin to a filesystem, so it'll actually be useful beyond this Matrix/List idea. You'll be able to store strings and arrays and matrices and lists and other kinds of data. Because of this, data will need to be named, so there will be a NAME argument.

• First you'll need to set aside some scrap RAM to setup the filesystem. You can create an OS variable, or point it to scrap RAM. The advantage with a variable is that you can keep the filesystem data if you want to have it for the next time the program runs. I'm thinking a syntax like:

$INITFS ptr,size

To make a list:

$LIST "name",{elem0,elem1,...}

To make a matrix:

$MAT "name",{r0c0,r0c1,...},{r1c0,r1c1,...},...

To get a pointer to a var's data, give a name:

$NAME "name"

To get an element:

$GET ptr,index0[,index1,[...

(Note, multiple indices are needed for multi-dimensional lists/arrays, like matrices)
In this case, ptr is the pointer to a var, so an actual example could look like:

$NAME "mymatrix"->P
$GET P,0,0