Types

[BookOwl]

Haumea is pretty limited with just integers right now. I plan on adding Floats, Strings, and Arrays.

[bates64]

Strings could be Arrays of characters?

Float/integer division, too (9 / 2 = 4 vs 9 // 2 = 4.5), please? :package:

[joker314]

Othere way around @nanalan I think?

[bates64]

@joker314 quite possibly.

[BookOwl]

OK, here is some syntax that I've come up with for declaring types:

/* Variable declarations
variable x is an Integer /* Same as "long x" in c */

variable foo is a String /* Same as "char* foo" in C */

variable y /* Same as we have now, makes y an Integer */

/* Function parameters */
to foo with (name is a String, foo is a Float, bar is an Integer, x) returns a Float ...

I'm not very happy with the function parameter syntax, do you guys have any better ideas?

[TheMonsterFromTheDeep]

Maybe 'as'?

to foo as Float with (name as String, foo as Float, bar as Integer) ...

this could also work for normal variables too:

variable x as Integer

[jeandrek]

Why static typing? But I think having the same syntax for declaring the types of parameters and other variables is a good idea.

[ghost]

@Jonathan50 I'm guessing it's because it compiles directly to C. Might be a bit dumb to try and make it dynamically typed

[jeandrek]

Might be a bit dumb to try and make it dynamically typed

Huh?

[TheMonsterFromTheDeep]

I think what IO means is that it's kind of a mess to have dynamic typing in a compiled language, even if it's just compiled to C.

[ghost]

Especially if the language that it's compiled to is statically typed.

[BookOwl]

Why static typing?

Because Haumea is a compiled language, and it's kind of hard to have dynamic typing in a compiled language (especially when the target is C)

I guess I could try and add type inference.

[jeandrek]

Okay. (You could just have a struct with a union member and a tag member) :+1: for type inference

[bates64]

Type inference please, too. It'd be nice to have a more consise syntax for defining variables as its a common thing..

[bates64]

Regarding the syntax for types, why not drop the variable tag altogether? It still reads correctly.

/* Variable declarations */
integer x /* Same as "long x" in c */

string foo /* Same as "char* foo" in C */

/* Function parameters */
to foo with (string name, float foo, integer bar) as string...

[BookOwl]

That looks great, but I still don't like the syntax for the return type for functions.

[bates64]

Agreed. If we get inference working there's no need for it anyway.

[bates64]

Is it worth having more simplistic types? e.g. string, list, and number?

[BookOwl]

Yes for string and list. I'm not so sure about combining floats and integers because integers can be much more accurate.

[bates64]

Nevermind that, seperate number types would (and still are for some) pretty confusing - such as two different kinds of division etc..

[TheMonsterFromTheDeep]

So are you guys going to use a pre-existing C library for these types, or write your own from the ground up?

(by the way, list libraries are a big mess because there's no templating system...)

[BookOwl]

For strings, ints, and floats I'm planning on using the C types. I'm not sure about for lists. @TheMonsterFromTheDeep, what do you think would be best? You have much more experience with C than I do.

[TheMonsterFromTheDeep]

@TheMonsterFromTheDeep, what do you think would be best? You have much more experience with C than I do.

There are a few different ways:

First, there is a raw macro-based approach like the guy is using in this stackoverflow post. This one is probably the fastest at run-time, but it could be a bad idea because it bloats compile time - whenever a list 'function' is used, it has to be re-compiled because it's actually a macro.

One way I've thought of before is using macros in a template-like system - essentially, there are a set of macros to generate list methods for some individual type, and then whenever a list of that type is used, those individual functions are used. This, I think, would also be pretty fast at runtime, and would reduce the number of functions compiled from one per use to like twenty per type.

Finally, it's also possible to have list types that are completely generic - they just use a void pointer and whenever the list is used it has it's pointer cast to the correct pointer type. I'm honestly not sure what the tradeoff is here - I would guess it would technically be slower at runtime because it has to cast the pointer every time, but I'm not sure if the performance hit would actually be noticeable.

I suppose it would be possible to put together a bunch of different tests for each of these different methods and see how they compare.

[jeandrek]

but it could be a bad idea because it bloats compile time - whenever a list 'function' is used, it has to be re-compiled because it's actually a macro.

What about having a define_list_of macro that defines a new global type and all its operations, and have the code generator scan the annotated program for used types and define all needed types only once? (And replace calls to list operations with calls to the appropriate C procedures depending on the types of the arguments.)

[TheMonsterFromTheDeep]

but it could be a bad idea because it bloats compile time - whenever a list 'function' is used, it has to be re-compiled because it's actually a macro.

What about having a define_list_of macro that defines a new global type and all its operations, and have the code generator scan the annotated program for used types and define all needed types only once? (And replace calls to list operations with calls to the appropriate C procedures depending on the types of the arguments.)

Yeah, that's what my second method meant:

One way I've thought of before is using macros in a template-like system - essentially, there are a set of macros to generate list methods for some individual type, and then whenever a list of that type is used, those individual functions are used. This, I think, would also be pretty fast at runtime, and would reduce the number of functions compiled from one per use to like twenty per type.

Maybe I wasn't being very clear. :P

[jeandrek]

Oh, sorry. I didn't read your whole post.

I would guess it would technically be slower at runtime because it has to cast the pointer every time, but I'm not sure if the performance hit would actually be noticeable.

Casting just tells the C compiler what type an expression's value is.

[TheMonsterFromTheDeep]

Casting just tells the C compiler what type an expression's value is.

Oh. Derp. :P

However, in that third method, the size would have to be passed to each function as a parameter, so I think it would still be slightly slower. ;)

[BookOwl]

How about this for function parameter type syntax?

to foo with (name is a String, foo is a Float, bar is an Integer, return is a Float) ...

[BookOwl]

Moved to https://github.com/haumea-lang/thinktank/issues/4