new user: maps are confusing

[saper]

I'd expect that a map can contain various types of objects, but currently it can be either numbers or text and it has to be pre-declared.

On the other hand, the key can be anything:

data:
  myMap is number map
procedure:
  store 5 in myMap:"xxxx"
  display myMap:"xxxx"

or

data:
  myMap is number map
procedure:
  store 5 in myMap:-1
  display myMap:-1

Why keys, but not values?

Also I find the colon syntax confusing.

data:
  myMap is number map
procedure:
  store 5 in myMap item indexed by -1
  display myMap item indexed by -1

(maybe indexed by should be for lists, maps should use something else, like identified by)

[Lartu]

Hi there!

Keys are in fact casted to strings. Keys are always strings, so you can use numbers the same way you would store a number in a string, it gets transformed into a string. You can store numeric values in text maps, but they will be casted into strings. The same happens when trying to store strings in numeric variables: if the string can be parsed as a number (for example "1" or "-567.92"), it is turned into said number. Otherwise it becomes a 0.

I think this ties to what we talked before, that doesn't seem to be properly explained in the docs, is it? I'll check that asap.

Regarding the colon syntax... It's odd. But that's too deeply ingrained in the compiler source to change that now. I do like that syntax, though. Once you get used to it it's likeable, haha!

[Lartu]

Hi there again! I found the type conversion section in the docs: https://docs.ldpl-lang.org/flow/#store-_-in-_

[saper]

The information about data types is spread out in the docs: Data Section & Variables describes the types, "Control flow statements" (why? STORE does not do any control...) described coercion and there are separate sections on Maps and Lists but only about their statements.

I don't want to infect LDPL docs with my object-oriented (alas) thinking, but maybe data types should have their own sections.

[Lartu]

No, actually that's fine, infect everything you can, haha. Different ways of thinking make projects like thus thrive. Yes, the way the docs are compiled it's odd and should be changed, I agree. And I agree that there should be a data types section that states all that.