Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lerno

Pages: 1 ... 14 15 [16] 17
226
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.

227
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.

228
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.

229
General Discussion / Re: State of progress?
« on: October 17, 2018, 10:55:45 PM »
How is compilation speed at this point in time?

230
General Discussion / State of progress?
« on: July 14, 2018, 11:36:22 PM »
Is C2 really alive or is it put in suspended animation?

231
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.

232
General Discussion / Re: Struct "inheritance"
« on: June 28, 2018, 07:18:29 PM »
I disagree, but it was just a suggestion.

233
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.

234
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);


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

236
General Discussion / Struct "inheritance"
« on: June 24, 2018, 12:13:33 AM »
Taking a page from JAI, why not allow "struct includes":

Code: [Select]
type MyData struct {
    const char* name;
    State status;
}

type MyDataExtended struct {
    int32 foo;
    MyData data @(inline);
    ExtendedStatus extendedStatus;
}

MyDataExtended foobar;

// initialize foobar here
...
// Init done


Code: [Select]
printf("Value: %s\n", foobar.name) // Due to the @(inline) attribute.

func void MyData.parse(MyData* data) {
    // ...
}

func void randomizeData(MyData* data) {
  // ...
}

foobar.parse() // valid, equivalent to foobar.data.parse()
randomizeData(foobar) // valid, equivalent to randomizeData(foobar.data)

All of this is resolved during compile time, so this would not work for example:

Code: [Select]
func void funky(void *data) {
   randomizeData(cast<MyData>(data));
}

funky(cast<void>(foobar)); // Will not work as expected.
However, the code WOULD behave nicely if MyDataExtended did not start with the i32 field...

237
General Discussion / Re: Complex numbers
« on: June 23, 2018, 11:49:34 PM »
Simple operations on complex numbers, quaternions and matrices is pretty much all that a sane programmer uses to operator overloading for.

Support for this out of the box would be very nice, but it's important to understand that people will want to write their own optimized libraries to plug in into the system.

238
Ideas / Re: What about initialization in conditions?
« on: June 23, 2018, 10:50:25 PM »
Code: [Select]
while (Height h = getHeight()) {
  ..
}

This code confused me totally. What this compiles to is apparently:

Code: [Select]
Height h = getHeight();
while (h) {
  ..
}

NOT what I would expect actually. I suggest that:

Code: [Select]
while (Height h = getHeight()) {
  ..
}

// => should not compile

while (Height h = getHeight(); h) {
  ..
}

// => compiles to

Height h = getHeight();
while (h) {
  ..
}

Finally we then can have have

Code: [Select]
while (Height h; h = getHeight()) {
  ..
}

// Compiles to
Height h;
while ((h = getHeight()) {
  ..
}

Since this is all new, it's possible to actually try different syntax from C:

Code: [Select]
// Separate by ':'
while (i32 y = 0 : y > 0) {
while (i32 y = 0; i32 z = 0 : y < 100 && z < 3) {

// Group multiple declarations in { }:
while ({i32 x = 0; i32 y = 100;}; x < 100 && y < 500) {

I'm a bit fond of the ":" version since it cleanly separates what only occurs before the while evaluation (left of ':'), and what is part of the repeated evaluation (right of ':').

239
There is a good reason why one would like to allow it though: it allows something similar to class extensions.

For example, let's day one module defines a "string" struct, which then is a char pointer + length.

The code has a String.find(char *) function, but is missing String.beginsWith and String.endsWith – which are really useful for some string handling.

Obviously you can define string_begins_with and string_ends_with, but it will be less nice to have:

Code: [Select]
if (string_begins_with(string, "foo")) {
  return string.toUpper();
}

When we could have:
Code: [Select]
if (string.beginsWith("foo")) {
  return string.toUpper();
}

At least of me it's common to build up a complementary library of additional functions on various types. In many languages we are forced to create stand-alone functions, because the class definition is closed. In languages like Objective-C – or in any language with UFCS, we have the option to let ourselves extend this definition (regardless wether we are struct-based or use OO).


240
General Discussion / Why the module restriction on struct functions?
« on: June 22, 2018, 10:35:57 PM »
From the docs:

"struct-functions are defined in the same module as the struct (not necessary the same file!)"

Why this restriction?

Pages: 1 ... 14 15 [16] 17