Author Topic: Consider native string & map  (Read 4324 times)

lerno

  • Full Member
  • ***
  • Posts: 247
    • View Profile
Consider native string & map
« on: October 17, 2018, 11:19:58 PM »
This is a rather uncooked idea, just to explain that I only suggest this as some inspiration rather than saying it should go into the language.

I blogged about this: https://medium.com/@christoffer_99666/why-system-level-languages-are-considered-difficult-a-different-take-7ad0982369b

Where my point is that the pain point of using C/C++/Rust etc is usually the lack of ergonomics for arrays, maps and strings. I would say that the main gain in going to a high level language is not OO, but having a lot less boilerplate for these.

Note also that Go 1 only has 2 generic structures: the array and the map. Everything else is non-generic.

These are also the only things that you REALLY need generics for (everything else are "nice to haves")

By adding a native generic array (including a variable size one) and a map + "real strings" and you increase the ergonomics immensely for the non-critical parts of a project.

bas

  • Full Member
  • ***
  • Posts: 220
    • View Profile
Re: Consider native string & map
« Reply #1 on: October 18, 2018, 08:44:05 PM »
I read your blogs. I had to laugh at your 'To OO or not' post, because so many examples were so familiar. I think a lot of develops
feel that way about OO these days. Also if you post something on a site like Reddit, my experience is that it quickly ends up in some
flame war with somebody calling you 'a complete moron'. Well done ignoring them  :)

I think array, map and string handling are important in a system level programming language. Also functions as first class citizens with
proper closures etc would make a lot of code better. Unfortunately all these features cannot be well implemented without some form
of garbage collection (as you can see in a lot of discussions on Go development). Since C2 does not have GC it will be fairly limited in
changing the C behaviour. Or do you perhaps have an idea on how to do this?

lerno

  • Full Member
  • ***
  • Posts: 247
    • View Profile
Re: Consider native string & map
« Reply #2 on: October 19, 2018, 10:39:57 AM »
Very good questions.

The way Zig seems to handle this is by explicitly pushing around a memory allocator. Jai on the other hand provides a thread local ”context” that’s hidden in every call. I think that is a better idea actually since it can just stay in a reserved register across all calls.

However, not even this is strictly necessary if we consider it a ”built in” implementation that just happens to have first class handling. It’s a convenience and not a high performance tool.
The same then goes for the maps and strings: they either bundle an allocator or uses some default one.

The map can be limited to ints and strings for keys. No memory management is done for values and strings are refcounted and lazy copied by default. Maps and arrays could always be passed ”by reference” to mimimize magic.

The key idea here is to think Pascal strings: they made string handling easy compared to C++ for simple tasks. This is so that when you want to just do some simple string handling you can actually do that with something built in that makes the simple tasks easy.

Using growing arrays in highly performance critical code is a no-no. Same with doing high speed templating work. But for these cases you should have custom solutions anyway.

I think the imolementations you get from C++ with STL’s map/vector/string is about what you need. However, for C2 we can’t really solve the problem that way (because of missing generics and overloading)

These are my current state of ideas anyway. I might end up with the opposite conclusion eventually  :)
« Last Edit: October 19, 2018, 01:36:54 PM by lerno »