Messages

226

Ideas / Re: Consider native string & map

« 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 

227

Ideas / Re: Readability of keywords "uint32", "float64" etc

« on: October 19, 2018, 10:09:31 AM »

I’ve written quite a bit of code with the i32/i64/f32 format - as well as using uint/int etc. Two issues:

• i32/i64 has poor readability in a loop syntax wise
• You sometimes want ”fastest int” - c2 has no concept of that right now. It’s important to be able to use different code in different architectures.
• For a loop i32/i64 is overspecification. You only want the most efficient thing to keep in a register and inc/dec

I *like* i32 etc, but we need to make fast loops easy. And we need to be able to determine register size in an easy way.

Introducing int = ”fastest that is at least 32 bit” would hit a sweet spot.

228

General Discussion / Re: State of progress?

« on: October 19, 2018, 09:57:48 AM »

Can you explain the current pipeline? How does it depend on clang and llvm?

229

Ideas / Re: Cumbersome of struct-functions

« on: October 17, 2018, 11:34:28 PM »

The explicit argument is fine, the only thing I'm not sure of is the dot separator because at a glance I read that as accessing a variable.

I've thought of using the :: separator of C++:

Code: [Select]

func void Point::add(Point* p, i32 x) {
   p.x = x;
}
This adds quite a bit of readability for me.

230

Ideas / Re: Support of Unicode ?

« on: October 17, 2018, 11:26:54 PM »

Most languages go for UTF8. Everything else is standardizing on UTF8 as well. Since (forward) string search is easy in UTF8, you get like 95% of everything you want with UTF8.

For any text handling that needs more optimized handling, simply offer a conversion to other formats as a byte array. C libraries can handle everything else.

231

Ideas / 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.

232

Ideas / Re: Readability of keywords "uint32", "float64" etc

« on: October 17, 2018, 11:06:20 PM »

I prefer the shorter 'u8' 'i8' 'f32' etc. However, I would actually like to see a plain "int" which is "native data size" for the platform just to keep things simple, readable and efficient.

233

Ideas / Re: "uint128", "uint256", "uint512" - for add in future

« on: October 17, 2018, 11:00:26 PM »

128 bit floats already exist for some processors and is supported by LLVM. It should be included at least. For integers, LLVM would support i128 i256 i512 and up.

234

General Discussion / Re: State of progress?

« on: October 17, 2018, 10:55:45 PM »

How is compilation speed at this point in time?

235

General Discussion / State of progress?

« on: July 14, 2018, 11:36:22 PM »

Is C2 really alive or is it put in suspended animation?

236

Ideas / Re: What about initialization in conditions?

« on: June 28, 2018, 07:19:37 PM »

Yes, but your current code does not match the C++ behaviour.

237

General Discussion / Re: Struct "inheritance"

« on: June 28, 2018, 07:18:29 PM »

I disagree, but it was just a suggestion.

238

General Discussion / Re: Complex numbers

« on: June 25, 2018, 11:59:39 AM »

I don't know if there is a simple solution, but consider the difference between overloading and normal function calling:

Code: [Select]

// Operator overloading
result1 = matrix1 + (matrix2 - matrix3) / factor;

// Straight functions
result2 = matrix_add(matrix1, matrix_division(matrix_sub(matrix2, matrix3), factor);

Personally I dislike function overloading, but this is a special case.

Alternatively, allow free postfix function calls:

Code: [Select]

result2 = matrix1 matrix_add ((matrix2 matrix_sub matrix3) matrix_division factor);

There is one other solution though, in three steps:

• Add built-in types "matrix", "complex", "vector", "quaternion"
• Create default implementations of each as "matrix_add", "matrix_mult", "complex_add" etc
• Support monkey patching functions – basically allow overwriting the default implementations with a new function replacement within a module.

239

General Discussion / Re: Struct "inheritance"

« on: June 25, 2018, 11:37:45 AM »

No, not only, it also allows the programmer to use MyDataExtended with every function that takes a MyData. However, there obviously is a difference, for example – let's say that we have some function foo(MyData *) that wants to take ownership of MyData... Then we obviously have some issues with using MyDataExtended, unless the ordering is such that MyData comes first.

The advantage is that it's possible to do something like inheritance without the inheritance. E.g.:

Code: [Select]

type Node struct {
   Vector2 position;
   RenderFunction *renderFunction;
}

func void Node.addChild(Node *this, Node *childNode) {
   ...
}
   
func void Node.render(Node *this, RenderState *state) {
   state->push();
   ... // update render state
   for (... all child nodes behind in z order...) {
       node->render(state);
   }
   this->renderFunction(this, state);
   for (... all child nodes after in z order...) {
       node->render(state);
   }
   state->pop();
}

type SpriteNode struct {
   Node baseNode @(inline)
   Texture *texture;
}

func void SpriteNode.init(SpriteNode *this) {
   this.renderFunction = SpriteRenderFunction;
}

//
...
Node *scene;
SpriteNode *sprite;
...
scene->addChild(sprite);
scene->render(state);



240

General Discussion / Re: Why the module restriction on struct functions?

« on: June 25, 2018, 11:20:51 AM »

Not allowing duplicate names is a natural restriction. Allowing function overrides (basically a form of monkey patching) is interesting but not required.