Lists

[Lartu]

I've added LISTs to the language. LISTs work like C++ vectors do, they have a defined size, one can push elements to these lists, access, read and write to its indices, clear them, copy them, compare them and split strings into them. I've felt for a long time now that LDPL Vectors are not only not enough but might be confusing and counterproductive to use in some situations, so here we have lists. Also, as LDPL Vectors are, in fact, what common languages use to call "Maps" or "Dictionaries", one can now use foo IS NUMBER MAP instead of foo IS NUMBER VECTOR (the later still works for compatibility, but will be marked as deprecated in the documentation).

Please tell me what you think about this update. I'll add everything to the docs as soon as I can. @dvkt @dgarroDC

[dgarroDC]

I like this!

Should we have a struct like ldpl_map for ldpl_list to handle text and out of range indeces?

It seems that utf8_split_list isn't working with the special case where the separator is "".

[Lartu]

LISTs won't have text indices. They are just scalable arrays, if you need text indices you should use MAPs. At the moment I defined ldpl_list as an alias of vector, but it was done this way so we can eventually add a ldpl_list struct at any moment.

I don't really think, however, that out of range access is something we should handle. In any other language you get some kind of error, here you'll get a segfault. Maybe, though, a nicer error would look better and be more useful.

It seems that utf8_split_list isn't working with the special case where the separator is "".

Oof, nice catch! I'll fix it asap.

[Lartu]

It seems that utf8_split_list isn't working with the special case where the separator is "".

Fixed!

[xvxx]

This is great! I also love the rename to MAP :+1:

Maybe this is crazy, but I think we should consider doing as @dgarroDC intuited and have LISTs gracefully support out of range errors by returning default values instead of adding runtime errors. Like how the current vectors work. They could set ERRORCODE and ERRORTEXT, but return a 0 or "" depending on the LIST type.

Just a thought! I liked that about the old VECTORs, that you got back default values like a HASH but could kind of treat them like a LIST. Instead of stuff just crashing in your face.

I don't know if it's on purpose, but DIVIDE currently doesn't crash when you try to divide by 0. So it'd be like that, kinda, too.

[Lartu]

I don't know if it's on purpose, but DIVIDE currently doesn't crash when you try to divide by 0. So it'd be like that, kinda, too.

What? This is not an intended feature, I don't know why it doesn't crash! :open_mouth:

Maybe this is crazy, but I think we should consider doing as @dgarroDC intuited and have LISTs gracefully support out of range errors by returning default values instead of adding runtime errors. Like how the current vectors work. They could set ERRORCODE and ERRORTEXT, but return a 0 or "" depending on the LIST type.

Just a thought! I liked that about the old VECTORs, that you got back default values like a HASH but could kind of treat them like a LIST. Instead of stuff just crashing in your face.

I'll admit I'm not truly a fan of this. I don't really love when languages just hide your own mistakes under the rug and then pretend that nothing happened and keep running. Using this one would be able to commit unknown off-by-one errors without even noticing and that wouldn't be nice. Also, we'd have to define a different [ ] operator for both setting and reading values and that's not possible at the moment without completely recoding how MAPs work, as they both use [ ] to set and write values (and not something like .at).

I would rather just print a nice error telling the user that they tried to access a non-existent element in the array called . This would work for both assignment and reading using the same [ ] operator.

[xvxx]

I would rather just print a nice error telling the user that they tried to access a non-existent element in the array called .

:+1: Sounds good! That is definitely more clear.

[Lartu]

Awesome!